[freetds] Connection timeout problem on HP-UX
ZIGLIO, Frediano, VF-IT
Frediano.Ziglio at vodafone.com
Thu Apr 12 10:50:07 EDT 2007
> 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
> It's always safe to assign an int to a long. That's C.
> Endianism doesn't
> 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
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
- give error :'(
More information about the FreeTDS