Skip to Content.
Sympa Menu

freetds - RE: [freetds] FreeTDS on OpenVMS (compiler messages)

freetds AT lists.ibiblio.org

Subject: FreeTDS Development Group

List archive

Chronological Thread  
  • From: "ZIGLIO, Frediano, VF-IT" <Frediano.Ziglio AT vodafone.com>
  • To: "FreeTDS Development Group" <freetds AT lists.ibiblio.org>
  • Subject: RE: [freetds] FreeTDS on OpenVMS (compiler messages)
  • Date: Fri, 19 Mar 2004 09:18:25 +0100

>
> Hi,
>
> I've got FreeTDS (only just tested with TSQL) working on our
> OpenVMS system
> (had some trouble with iconv, but solved that almost the same
> as I saw later
> in the mailinglist).
>
> Our OpenVMS version is 7.3, C Compiler is version 6.4, SQL Server are
> 2000-versions. TCP/IP stack on the VMS server is TCPWare 5.3.
>
> The TCPWare implementation has the following definition for the
> sockaddr_in-struct:
>
> /*
> ** Socket Address Structure (internet style):
> */
> struct sockaddr_in {
> short sin_family;
> unsigned short sin_port;
> struct in_addr sin_addr;
> char sin_zero[8];
> };
>
>
> struct in_addr {
> unsigned long s_addr;
> };
>
> 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, it should be INADDR_NONE. Fixed in CVS. However INADDR_NONE is just
(unsigned long) -1, so it shouldn't be a problem.

>
> 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 ?
>

Just an assert. This work even if srclen is a TDS_INT so I don't see any
reason to remove srclen >= 0 test.

> 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.
>

tds_iconv should return (size_t) -1 on error, fixed for read.c and
write.c. This is not a problem (perhaps on 64 bit platforms and on some
compilers...)

> user.c/meber.c
> ==============
> tds->in_len is checked for "-1" values. It is defined as
> unsigned in tds.h.
>

I'll have a look. Not a problem if you don't use pool server.

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

Well, if tests pass they are just warnings...

bye
freddy77




Archive powered by MHonArc 2.6.24.

Top of Page