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: Alexandre Oliva <aoliva at redhat dot com>
- To: "Carlos O'Donell" <carlos at redhat dot com>
- Cc: codonell at redhat dot com, libc-alpha at sourceware dot org
- Date: Sat, 01 Feb 2014 00:57:12 -0200
- 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> <52EB67C5 dot 6020608 at redhat dot com> <ord2j7myge dot fsf at livre dot home> <52EC4FB8 dot 6010807 at redhat dot com>
On Jan 31, 2014, "Carlos O'Donell" <carlos@redhat.com> wrote:
> OK to checkin if the answer to the question below is "Yes."
>> +In most cases, the identifier will name a set of functions, but it may
>> +name global objects or function arguments, or identifiable properties or
>> +logical components associated with them, with a notation such as
>> +e.g. @code{:buf(arg)} to denote a buffer associated with the argument
>> +@var{arg}, or @code{:brk(fd)} to denote the @code{brk} terminal property
>> +of a file descriptor @var{fd}.
> OK, as long as the idenfifier's only purpose is to group several functions.
Well, I can't answer âYesâ to that.
Under âsigâ, for example, we document that the identifier specifies the
signal that is unsafely used.
The cases of brk(filedes) and tcattr(filedes) name actual properties
that may conflict with other functions that set properties of a
terminal, as mentioned under âtermâ.
In a number of cases, we don't even group *several* functions; a single
function may be named, when it's the only function using some static
buffer.
Nevertheless...
> In which case `buf(arg)' is technically an opaque identifier that groups
> other `buf(arg)'s together right?
I guess I could say âyesâ to this, with the caveats above. In *most*
cases it's ok to just use it as an opaque grouping identifier, in spite
of the attempts to make it mnemonic as well. But there's the
brk/tcattr/term exception; IIRC that's the only one in which treating
the identifiers are purely opaque would enable safe workarounds for
safety problems. E.g., on BSD, someone who wanted to call âtermâ-marked
functions would have to guard tcattr- and brk-marked functions operating
on the same file descriptor.
So, is this good enough? Or should brk(filedes) be marked with
tcattr(filedes) as well, to ensure proper guarding based on strict
matching of identifiers?
--
Alexandre Oliva, freedom fighter http://FSFLA.org/~lxoliva/
You must be the change you wish to see in the world. -- Gandhi
Be Free! -- http://FSFLA.org/ FSF Latin America board member
Free Software Evangelist Red Hat Brazil Toolchain Engineer