[PATCH] Avoid more problems with type clashes

[J. Johnston]

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.