This is the mail archive of the newlib@sources.redhat.com mailing list for the newlib project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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


On Mon, Mar 21, 2005 at 05:06:32PM -0500, Jeff Johnston wrote:
>Corinna Vinschen wrote:
>>On Mar 18 10:34, Corinna Vinschen wrote:
>>
>>>On Mar 17 15:21, Jeff Johnston wrote:
>>>
>>>>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.  [...]
>>
>>
>>Following a hint I got from Richard Henderson, I'll propose the following
>>patch, which keeps binary backward compatibility.  He suggested to use
>>direct assembler directives instead of abusing the alias directive.
>>
>>
>>Corinna
>>
>>	* libc/ctype/ctype_.c (_ctype_): For Cygwin, define using assembler
>>	so to not break binary backward compatibilty.
>>
>
>This is introducing machine-specific code into a shared file.  I would 
>rather see you add a new ctype_.c file in libc/machine/i386 which uses the 
>.asm method and avoids the array aliasing altogether.  That should solve 
>your problem and remove the need for Cygwin flag checks in the shared 
>ctype_.c file.

I wasn't paying close attention here but I don't understand the recent changes
to _ctype_ handling.  I understand that the original code was "a kludge" possibly
requiring the original author to be dragged through the street and tarred and
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.

cgf


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]