This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: [MTASCsft PATCH 09/??] MT-, AS- and AC-Safety docs: manual/errno.texi
- From: "Carlos O'Donell" <carlos at redhat dot com>
- To: Alexandre Oliva <aoliva at redhat dot com>
- Cc: codonell at redhat dot com, libc-alpha at sourceware dot org
- Date: Fri, 31 Jan 2014 04:07:17 -0500
- Subject: Re: [MTASCsft PATCH 09/??] MT-, AS- and AC-Safety docs: manual/errno.texi
- Authentication-results: sourceware.org; auth=none
- References: <ortxelb5zd dot fsf at livre dot home> <or4n4uoncj dot fsf at livre dot home> <oreh3xfnq3 dot fsf_-_ at livre dot home> <52EA0931 dot 4000802 at redhat dot com> <or4n4l6ee0 dot fsf at livre dot home>
On 01/30/2014 03:51 AM, Alexandre Oliva wrote:
> On Jan 30, 2014, "Carlos O'Donell" <carlos@redhat.com> wrote:
>
>> On 01/24/2014 09:39 AM, Alexandre Oliva wrote:
>
>>> The other is the use of conditionals for safety remarks, such as
>>> /error_one_per_line in the documentation of error_at_line. I realize
>>> now that I have not documented the /condition syntax anywhere. I guess
>>> I should, somewhere in intro.texi, but where exactly? Suggestions?
>
>> I suggest removing the markup from the safety notes. Simplify the
>> markings to provide the bare minimum information required to decide
>> if it's safe or not.
>
> The point is that several functions are safe under certain conditions,
> and unsafe under others. The /!ps-marked functions in charset (that
> were already checked in) come to mind, but there are others whose safety
> depends on the underlying kernel, or on global variables (as in this
> file). I think this is useful information, so I'd rather keep it
> available to users.
We should not add things that we have not described in the introduction.
For example tcsendbreak has "race:brk(filedes)/bsd".
I know what `race' is, and I expected "race:fileds".
The "brk(...)" and "/bsd" are not described anywhere.
We can leave them in the source, but they should not show up unless we
have described them.
If another /foo has made it in, then that was my fault for not noticing
it in the review :-)
Cheers,
Carlos.