This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: [MTASCsft PATCH WIP6 01/33] MT-, AS- and AC-Safety docs
- From: "Carlos O'Donell" <carlos at redhat dot com>
- To: Alexandre Oliva <aoliva at redhat dot com>
- Cc: libc-alpha at sourceware dot org
- Date: Wed, 22 Jan 2014 13:39:19 -0500
- Subject: Re: [MTASCsft PATCH WIP6 01/33] MT-, AS- and AC-Safety docs
- Authentication-results: sourceware.org; auth=none
- References: <ortxelb5zd dot fsf at livre dot home> <52D6162F dot 50204 at redhat dot com> <orsisnhctt dot fsf at livre dot home>
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.