[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
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
- Re: [Bug-gnulib] linebreak.c proposed patches for size-calculation overflows, (continued)
- [Bug-gnulib] Re: linebreak.c proposed patches for size-calculation overflows, Simon Josefsson, 2003/11/19
- [Bug-gnulib] Re: linebreak.c proposed patches for size-calculation overflows, Paul Eggert, 2003/11/19
- Re: [Bug-gnulib] Re: linebreak.c proposed patches for size-calculation overflows, Bruno Haible, 2003/11/19
- Re: [Bug-gnulib] Re: linebreak.c proposed patches for size-calculation overflows, Paul Eggert, 2003/11/19
- [Bug-gnulib] Re: linebreak.c proposed patches for size-calculation overflows, Simon Josefsson, 2003/11/19
- [Bug-gnulib] Re: linebreak.c proposed patches for size-calculation overflows, Simon Josefsson, 2003/11/19
- Re: [Bug-gnulib] Re: linebreak.c proposed patches for size-calculation overflows,
James Youngman <=
- Re: [Bug-gnulib] Re: linebreak.c proposed patches for size-calculation overflows, Paul Eggert, 2003/11/19
- [Bug-gnulib] Re: linebreak.c proposed patches for size-calculation overflows, Paul Eggert, 2003/11/19
- Re: [Bug-gnulib] Re: linebreak.c proposed patches for size-calculation overflows, Bruno Haible, 2003/11/19
- [Bug-gnulib] Re: linebreak.c proposed patches for size-calculation overflows, Simon Josefsson, 2003/11/19