This is the mail archive of the newlib@sourceware.org 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: [PATCH/RFA] Internationalize ctype functionality


On Jun 18 14:39, Antony King wrote:
> Hi,
> 
> I have a customer complaining that some static libraries (supplied by a
> 3rd party) that had been built using the headers from an older version
> of newlib (1.16.0) no longer link with the latest version of newlib
> (1.18.0) due to the deletion of the __ctype_ptr variable from ctype_.c
> due to the following change:
> 
> On 26/03/2009 21:01, Corinna Vinschen wrote:
> > - I removed __ctype_ptr (no trailing underscores) and only kept
> >   __ctype_ptr__.  __ctype_ptr was never used in Cygwin and AFAIK we have
> >   no other dynamically linking target for newlib which has to maintain
> >   backward compatibility.
> 
> (see http://sourceware.org/ml/newlib/2009/msg00370.html)
> 
> Would it be safe to re-introduce the definition of this variable back
> into ctype_.c with the attached patch ?

Since this seems to be a single backward incompatibility in a specific
scenario, wouldn't it make most sense to ask the third party first to
rebuild their lib against newlib 1.18.0?

If that's really not an option, I'd suggest that we introduce a guard
for __ctype_ptr, just like __CYGWIN__ guards the old __ctype_ definition
for backward compatilbilty.  There's no use that all targets have to
carry on with the old variable.

What about

  #if defined(NEED_OLD_CTYPE_PTR_DEFINITION)
  ...
  #endif


Corinna

-- 
Corinna Vinschen
Cygwin Project Co-Leader
Red Hat


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