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 11:31:07AM -0500, J. Johnston wrote:

Ok, I see now.

I would prefer a cleaner solution that doesn't do this via the _COMPILING_NEWLIB
flag in stdio.h. I also would like it to be a generic solution so other platforms can
use it, if desired/needed.


What I am thinking of is to add the wrapper functions that take the external type and
call the correct function underneath. For example, we change the current fgetpos
routine to be called _fgetpos() which takes _fpos_t and we also add to fgetpos.c,
an fgetpos() wrapper routine that takes fpos_t. The wrapper function calls _fgetpos()
or fgetpos64 based on a compiler flag. Prototypes for _fgetpos() etc..
could be hidden in stdio/local.h. The wrapper function would be #ifdef'd
out if the flag isn't set and instead, we redefine _fgetpos to be fgetpos.


Currently you are using __CYGWIN_USE_BIG_TYPES__, but if this were renamed to
be something more generic (e.g. __LARGE64_DEFAULTED__), then any platform
could use it if desired.


I can implement the patch if you would like.


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.

There's also a problem with already existing function calls which are
expected in the underlying system API.  E. g. you can't change lseek to
_lseek and open to _open for that reason.


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.


-- Jeff J.



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