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 09/??] MT-, AS- and AC-Safety docs: manual/errno.texi


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


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