[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

From: James Youngman
Subject: Re: [Bug-gnulib] Re: linebreak.c proposed patches for size-calculation overflows
Date: Wed, 19 Nov 2003 16:48:53 +0000
User-agent: Mutt/1.3.28i

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

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

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 


and the following suffixes 


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

> 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

reply via email to

[Prev in Thread] Current Thread [Next in Thread]