Newlib _ctype_ alias kludge now invalid due to PR middle-end/15700 fix.

Corinna Vinschen
Fri Mar 18 09:34:00 GMT 2005

On Mar 17 15:21, Jeff Johnston wrote:
> I have just checked in a patch to newlib that changes the ctype macros to 
> use __ctype_ptr instead of _ctype_.  In addition, a configuration check is 
> made to see whether the array aliasing trick can be used or not.
> The code allows for backward compatibility except in the case where the old 
> code is using negative offsets and the current version of newlib is built 
> with a compiler that does not support the array aliasing trick.
> Corinna, if this causes any Cygwin issues, please let me know.

The change will break Cygwin's backward compatibility as soon as we start
building Cygwin with gcc 4.0.  Older applications using the _ctype_ array
with negative indices will begin to fail and probably run into segmentation

Even if the array aliasing trick doesn't work anymore, the _ctype_ array
must stay intact from the view of existing, already built applications.

I tried a definition like the below.  If I understand the change in
gcc 4.0 correctly, the only restriction is that the alias must reference
an existing symbol in the same translation unit.  So, if _ctype_b is
defined as a struct, it should be possible to use it in an alias attribute.

  #pragma pack (push, 1)

  static const struct {
	 const char _ctype_b0[127];
	 const char _ctype_b1[  1];
	 const char _ctype_b2[256];
  } _ctype_b = {

  #pragma pack (pop)

  _CONST char *__ctype_ptr = _ctype_b._ctype_b2;

  extern _CONST char _ctype_[1 + 256] \
    __attribute__ ((alias ("_ctype_b._ctype_b1")));

Unfortunately it doesn't work.  When compiling this, _ctype_ is entirely
missing in the symbol table and _ctype_b._ctype_b1 is treated as undefined
symbol.  So, right now, I have no idea how to keep backward compatibility.


Corinna Vinschen
Cygwin Project Co-Leader
Red Hat, Inc.

More information about the Newlib mailing list