FreeTDS Development Group

["ZIGLIO, Frediano, VF-IT" <Frediano.Ziglio AT vodafone.com>]

> 
> ZIGLIO, Frediano, VF-IT wrote:
> > 
> > So:
> > - if linux or hpux (freebsd?? solaris?? tru64?? sgi??) use int
> > - if win32 use u_long
> > - if possible (that is not cross compiling) do a small test (using
> > configure)
> > - give error :'(
> > 
> > I don't like autoconf that much but I think I'll have to 
> write some m4
> > code before release... and even backport it !!
> 
> Before you do this, can you show me correct code that doesn't 
> work on all
> systems?  What is the "bug", exactly?  Which function are we talking
> about?  
> 
> It's always safe to assign an int to a long.  That's C.  
> Endianism doesn't
> matter.  
> 
> If there is a function that is defined differently in 
> different OS's (e.g.
> getservbyname_r) then we might need an m4 file for it, if 
> autoconf doesn't
> already handle it.  
> 
> I prefer to write correct code not obscured by preprocessor macros. 
> Sometimes we can include documented patches in the 
> distribution for broken
> OS's.  
> 

The function is ioctl (fcntl have similar issues). This function is
declared something like

int ioctl(int fd, int req, ...);

(the "..." is C code!)

now, if req is FIONBIO "..." type is a "const int *" or a "const long
int *" (depending on system platform) so the "unsafe cast" is "const
int*" <-> "const long int*". Using a big endian machine with long
(64bit) while system expect int (32bit) cause non-blocking request to
become a blocking request.

Oh... I forgot one point:
- if sizeof(int) == sizeof(long) use int
- if linux or hpux (freebsd?? solaris?? tru64?? sgi??) use int
- if win32 use u_long
- if possible (that is not cross compiling) do a small test (using
configure)
- give error :'(

Frediano