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

[Jeff Johnston]

Corinna Vinschen wrote:
> On Mar 22 11:06, Christopher Faylor wrote:
> 
>>feathered but it seems like the replacement code now causes an extra pointer
>>dereference for a popular set of macros.  I don't understand how that's a good
>>thing for a library which is supposed to run on an embedded target.
>>
>>As far as cygwin is concerned, I'm not happy about having to export a new variable
>>just for the benefit of slowing the code down.  It will mean years of "Why cygwin
>>say __ctype_ptr not found?  Should I reinstall windows?" email.
>>
>>Corinna has suggested an assembly language method which uses gas pseudo-ops to
>>accomplish the goal of reenabling _ctype_.  I'd like to offer my endorsement of
>>this technique, or at least I'd like to suggest that we not just casually move
>>to replacing _ctype_ with __ctype_ptr.
> 
> 
> I agree.  Since the assembler method should work on every target, there's
> no good reason anymore to move to __ctype_ptr.
>

You are forgetting about locale support.  Just because newlib is currently 
hard-wired to the C locale, doesn't mean it should be locked this way forever. 
The most straight-forward method is to have ctype macros reference a pointer 
which can be altered by setlocale() dynamically.  There is no advantage to the 
previous implementation so why would you object to having new code use the pointer?

I also brought up the point in my previous note that the asm method is depending 
on the prepending character being "_" which does not apply to every target.

Most platforms are statically linked so the whole concept of binary 
compatibility is moot for them.  Cygwin cares, Linux cares, and RTEMS may care 
(I don't know if they build dynamic libraries).  In the first two cases, there 
is one file that satisfies both.  It is relatively easy to put machine-specific 
ctype_.c files for any other platform of interest.

Regarding the comment that "__ctype_ptr" won't be found:  this will only occur 
if a user compiles with the latest header files and an old library.  While I 
realize that Cygwin is sensitive to backwards compatability, it is not 
reasonable to expect this to hold in all cases for an indeterminate period of 
releases.  Please note that there is a mechanism in place for Cygwin to freeze 
any header file (and even the ctype_c.c file) as it chooses by placing it in 
sys/cygwin.  The sys/cygwin directory was removed in a previous Cygwin patch but 
it is simple to put it back.

-- Jeff J.

> 
> Corinna
>