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




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.



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