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: [PATCH] Avoid more problems with type clashes


On Thu, Mar 13, 2003 at 06:51:16PM -0500, J. Johnston wrote:
> Corinna Vinschen wrote:
> >Hmm, I don't think it's actually necessary to do it that complicated.
> >The only unclean part is IMHO the usage of __CYGWIN_USE_BIG_TYPES__
> >in stdio.h which should be changed to a more generic name but otherwise
> >everything's fine as it is.
> >
> 
> Not exactly fine.  This change is still very cygwin-specific.  You are 
> prototyping an
> external function which is not provided in newlib.  Internally, there is an 
> fgetpos()
> which takes an _fpos_t, but to the external user, they will see an 
> fgetpos() which takes
> fpos_t = fpos64_t which is not provided.  This requires that a platform 
> provide
> their own fgetpos to override newlib's.

It doesn't have to.  It just defines fgetpos=fgetpos64 which is in newlib
as well.  But...

> There are the _r wrapper functions in libc/reent to handle newlib internal 
> calls
> (which should be calling the _r versions).  The syscalls code can likewise 
> be modified to
> handle external calls.  I don't claim this is going to be bullet-proof, but
> it seems that it wouldn't be that bad to implement.  As I said, I am 
> willing to help
> out with this as I see it could be of use for supporting Linux.

... I see your point.  I would be glad if you could start that transition.
This would allow us to clean up our Makefile.in since we don't need the
newlib function overrides (scheme: foo calls foo64) anymore.  Of course
we still have a lot of other 32/64bit functions (e.g. mmap64) but that's
obviously not newlibs problem. 

Btw., you should consider to have a look into the cygwin headers
winsup/cygwin/include/cygwin/{types,stat,grp}.h.  These files already
defined 32/64 bit types when they weren't introduced in newlib.  I used
a __off32_t/__off64_t scheme which is implemented this way also in 
Cygwin internally.  We could drop this in favour of _off_t and _off64_t.
However, we also need other type changes as a new dev_t, blkcnt_t and
especially uid_t and gid_t changing to 32 bit.  This all also requires 
to change struct stat as you can see in Cygwin's stat.h.

Please keep in mind that Cygwin has 99% of the transition to 32/64 bit
types done.  It would be nice if the change in newlib could be made
as careful as possible to not break Cygwin again.

Would it be possible to check in my patch as a interim solution?  We
have the problem that Cygwin currently is non-functional when built
from CVS unless newlib has these (or similar) changes in.

Thanks,
Corinna

-- 
Corinna Vinschen
Cygwin Developer
Red Hat, Inc.
mailto:vinschen at redhat dot com


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