This is the mail archive of the
newlib@sources.redhat.com
mailing list for the newlib project.
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.