This is the mail archive of the libc-alpha@sourceware.org mailing list for the glibc project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [MTASCsft PATCH WIP6 01/33] MT-, AS- and AC-Safety docs


On 01/16/2014 03:49 PM, Alexandre Oliva wrote:
> On Jan 15, 2014, "Carlos O'Donell" <carlos@redhat.com> wrote:
> 
>> There are only a few nits here and there, please review.
>  
> Thanks!  I'm still going through the long review message (thanks!), but
> I thought I'd ask for feedback on this one point early, before I
> consider the patch fully revised and ready for resubmission.
> 
>>> +* Unconditional Unsafety::      Features that make functions
>>> +                                 unconditionally unsafe.
> 
>> The double-un is not common usage in English. I would just simplify
>> as "Features that make functions unsafe" with the title being
>> "Unsafe Features."
> 
>>> +* Avoidable Unsafety::          Features that make functions unsafe,
>>> +                                 but that can be worked around.
> 
>> Again, this phrase is awkward in English. I would rewrite this as
>> "Potentially Unsafe Features." That is to say the features have the
>> potential for being unsafe unless you work around those problems.
> 
> How about:
> 
> * Unsafe Features::             Features that make functions unsafe.
> * Conditionally Safe Features:: Features that make functions unsafe
>                                  in the absence of work-arounds.

Excellent use of the noun form `work-around'; do you have a preference
for `work-around' vs `workaround?' Both forms are correct, but I think
we may wish to use `workaround' in the manual since it's one less
character and perhaps more common in our technical field.

Otherwise looks good to me.

Cheers,
Carlos.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]