Re: [Bug-gnulib] Re: linebreak.c proposed patches for size-calculation overflows

[James Youngman]

On Wed, Nov 19, 2003 at 05:01:59PM +0100, Simon Josefsson wrote:

> This seem like a rather serious argument against '_t'.  Is *_t
> reserved, or just some subset?  Now that you mention it, I also
> vaguely recall something about _t being reserved for "system types" or
> something like that.

Section 2.2.2 "The Name Space" of the current POSIX standard indicates
that conforming implementations are allowed to define "symbols" with
the suffix _t in any header.  While it says "symbol" I think it is
fair to read "or type name" since _t is normally used only for type
names.

My reading of this is that this is not quite the same as being
"reserved", that is, the standard doesn't forbit programs to use it,
but it does allow a conforming POSIX implementation to use those
names.

Therefore application developers wishing not to have their code clash
with some random POSIX implementation should avoid the use of the
suffix _t.

In fact there are other commonly used forms for which the situation is
similar, notably the following prefixes 

        to[a-z]
        is[a-z]
        mem[a-z]
        msg

and the following suffixes 

        _MAX
        _MIN
        _t

There are several dozen more.  Some of the above (e.g. _MAX and _MIN)
apply only if you have included a specific header (in this case
<limits.h>).

> Some things, like a library context handle, will never be anything but
> a pointer to a struct, 

Well personally for that I normally use void* to discourage the user
from fiddling with my data.

-- 
James Youngman.
CSSC Bug reporting page:       http://sf.net/tracker/?group_id=8064&atid=108064
GNU Findutils bug reporting page: http://savannah.gnu.org/bugs/?group=findutils