Re: MT string, issues with C9x types

[Nathan Myers <ncm at best dot com>]

On Wed, Mar 22, 2000 at 11:01:19PM -0800, Benjamin Kosnik wrote:
> Why were C9x types used for the MT string _State_type and
> _Signed_state_type? This assumes <inttypes.h>, which does not exist on
> many platforms, newlib/cygwin in particular.

We use the same type in libstdc++ basic_string<> as the arguments
declared in <atomicity.h>.  This begs the question, why does
<atomicity.h> use the types it does?  (It uses uint32_t* and int.  
In fact, it performs an implicit conversion; it dereferences a 
pointer to a uint32_t, and returns the value as an int.)

Standard C++ (like C) provides a type, sig_atomic_t, which should 
be more appropriate for this purpose.  However, we need a signed 
type, and sig_atomic_t isn't (guaranteed to be) signed.  (Why do we 
want a signed type?  So we can do an efficient three-way comparison.  
Sometimes we compare ==0, sometimes <=0, sometimes >=0.)

Diverging from the <atomicity.h> definition used in glibc is not 
something we can do lightly.  Although anything rational that we do 
would be equally rational for glibc, glibc has backward-compatibility 
issues.  Fortunately, these are inline functions, and we don't intend 
to change any underlying in-memory representations, so it's purely a 
source-compatibility issue; anything already compiled into object files 
would be unaffected by changes.

Probably we should define new functions with rational signatures,
and provide backward-compatible functions with the old names, which
cast their arguments and call the new functions; and then deprecate 
the old names.

What type should the (replacement for the) exchange_and_add() function
operate on?  It doesn't have to be a standard name, but it should be 
signed, and already defined for each platform.  If it's not standard,
it should be typedef'd in <atomicity.h> itself.

Nathan Myers
ncm@nospam.cantrip.org