Re: [PATCH] Re: Your addition of BT_SSIZE

[Mark Mitchell <mark at codesourcery dot com>]

On Tue, 2003-08-19 at 12:20, Zack Weinberg wrote:
> "Joseph S. Myers" <jsm@polyomino.org.uk> writes:
> 
> > On Tue, 19 Aug 2003, Zack Weinberg wrote:
> >
> >> against -1, then convert to size_t; for that to work properly ssize_t
> >> has to be the signed type corresponding to size_t.  Therefore the
> >> possibility that ssize_t will be something else is an illusion, and
> >> making a distinction in the compiler is pointless.
> >
> > It only needs to be of the same size; I wouldn't be surprised at a system
> > where int and long are the same size which chose unsigned int and signed
> > long or unsigned long and signed int for the types.  Consider that we have
> > existing supported systems where size_t and ptrdiff_t differ in this way
> > (see e.g. i386/djgpp.h), and ptrdiff_t is just as logically related to
> > size_t.
> 
> Okay, that's a halfway plausible scenario, but I still think changing
> anything before a target shows up that actually needs it is a waste of
> time.

I would be surprised, but not flabbergasted, to see a historical system
(like DJGPP or an old SVR4 derivative) where size_t is "unsigned int"
and ssize_t is "signed long".

I'd be pretty taken aback if some system which does not yet exist were
to appear with this oddity.  People building new systems seem to be
acting sensibly about these kinds of things these days.

That said, I don't really think anyone would seriously object to a patch
that did:

  #define ssize_t_type_node signed_size_type_node

and then used "ssize_t_type_node" in the functions where that made
sense.

If something really needs these to be different later, we could then
make that define conditional.

I agree with Zack that this strikes me as a waste of time, but I'd also
probably approve such a patch if someone wants to do it.

-- 
Mark Mitchell <mark@codesourcery.com>
CodeSourcery, LLC