[PATCH] Avoid more problems with type clashes

J. Johnston jjohnstn@redhat.com
Fri Mar 14 17:50:00 GMT 2003



Corinna Vinschen wrote:
> 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.
> 

Yes, that would be fine for now.

-- Jeff J.




More information about the Newlib mailing list