FreeTDS Development Group

["Craig A. Berry" <craigberry AT mac.com>]

At 11:00 AM +0100 3/18/04, Gert de Boom wrote:

>In login.c the following code is used:
>
>       sin.sin_addr.s_addr = 
> inet_addr(tds_dstr_cstr(&connect_info->ip_addr));
>       if (sin.sin_addr.s_addr == -1) {
>               tdsdump_log(TDS_DBG_ERROR, "%L inet_addr() failed, IP = 
> %s\n", connect_info->ip_addr);
>               tds_free_socket(tds);
>               return TDS_FAIL;
>       }
>
>I get a compiler message on the compare. Seems logical, because an unsigned 
>long is very unlikely to become negative.
>
>Is this TCPWare specific ?

No.  There are various APIs (including sockets) where -1 is the
traditional error return value but the return type at some point
became unsigned in order to represent a greater data range for the
non-error cases.  Rather confusingly (but understandably for
backwards compatibility reasons), -1 remains the value returned on
error even though the type is unsigned.  I believe the correct thing
to do in these cases is to use the constant -1UL instead of -1 when
checking the return value.  I've long meant to work up a patch for
these cases but have just never gotten to it.

>Further I got some more compiler messages due to signed/unsigned typedefs.
>
>convert.c
>=========
>TDS_INT
>tds_convert(TDSCONTEXT * tds_ctx, int srctype, const TDS_CHAR * src, 
>TDS_UINT srclen, int desttype, CONV_RESULT * cr)
>{
>       TDS_INT length = 0;
>
>       assert(srclen >= 0 && srclen <= 2147483647u);
>
>The assert statement is checking for values that are already defined by the 
>type TDS_UINT. Is TDS_UINT for some systems/compilers of another type ?

Here the compiler is noticing that since srclen is unsigned, it will
always be greater than or equal to zero; there's no way you could
make it otherwise, so there's not much point in checking.  This
compiler message catches those cases where you do actually need to
check for negative values but have mistakenly used an unsigned
variable.  Here I think the "srclen >= 0" does no harm but also does
no good (except as documentation). The line as written is equivalent
to:

        assert(srclen <= 2147483647u);

>read.c/write.c
>==============
>tds_iconv function return value is of size_t (and checked for "-1" values). 
>The size_t type is defined in the DEC C headers as an unsigned int.
>
>user.c/meber.c
>==============
>tds->in_len is checked for "-1" values. It is defined as unsigned in tds.h.

Here too the constants should ideally be written as -1U or -1UL,
which would make the compiler stop whining but wouldn't make any
difference in the code it generates.

>Should I worry about these compiler messages (and make adjustments) or 
>should I just ignore and enjoy a working FreeTDS library ?

Enjoy.  I believe these are informational messages only (i.e., not
warnings or errors), so the code will work just as well as it does on
systems with less vocal compilers.

>I still have to find out how to link the library to a Fortran-program. 
>Anyone has any experience (examples) for doing this on VMS ?

Linking is the easy part.  Calling C from FORTRAN is straightforward
but does require an understanding of the OpenVMS Calling Standard,
currently documented here:

http://h71000.www7.hp.com/doc/73final/5973/5973PRO.HTML

Generally speaking, you'll have to construct null-terminated C
strings and pass them by reference.  Or you could build an
intermediate layer in C that accepts strings by descriptor and passes
them along as C strings.



-- 
________________________________________
Craig A. Berry
mailto:craigberry AT mac.com

"... getting out of a sonnet is much more
 difficult than getting in."
                 Brad Leithauser