FreeTDS Development Group

[christos AT zoulas.com (Christos Zoulas)]

On Dec 8,  5:37pm, LowdenJK AT bernstein.com ("Lowden, James K") wrote:
-- Subject: [freetds] warnings and oddities

| This message is in MIME format. Since your mail reader does not understand
| this format, some or all of this message may not be legible.
| 
| ----=_NextPart_ST_17_34_51_Monday_December_08_2003_27670
| Content-Type: text/plain;
|       charset="iso-8859-1"
| 
| I might be the first person to compile yesterday's snapshow with gcc 3.3 on
| Tru64.  It griped 114 warnings, and some apparent misdetections, too.
| Attached.  
| 
| Some of the complaints are about not declaring vsnprintf(3), even though
| it's installed and recognized by configure.  Evidence below.  
| 
| There are some warnings I just don't know how to avoid, and some I think we
| should advise be turned off, e.g.:
| 
| replacements/iconv.c:200: warning: cast from pointer to integer of different
| size
| 
| That line is:
| 
|       if ((int)cd == UCS2LE_ASCII && !isascii(**inbuf)) {
| 
| We know perfectly well that "cd", while declared an iconv_t, contains an
| enumerated value, an int.  So we *cast* it, and still the warning?  What
| warning-proof syntax can we use?  

1. Well an enumerated type is not guaranteed to be an int. It could be smaller
   than an int, if all enumerated type values fit and the ABI supports it.
2. You are being extremely naughty here. iconv_t is supposed to be an opaque
   type, in some cases defined to be a pointer to an undefined struct. By
   casting to int you are casting a pointer to an int, and thus the warning.
   you could use (intptr_t) as an intermediate task, but this kind of casting
   is guaranteed to break certain implementations.

| Here's my favorite:
| 
|       tds/config.c:810: warning: subscript has type `char'
| 
| Uh huh.  Rules of the game are that a C char is implicitly promoted to int,
| and sizeof(char)<=sizeof(int) on *every* platform.  It can't be an issue
| unless the array has >127 elements.  

This is not the problem. The warning is valid and you can produce core-dumps
by it. A char > 127 turns negative, and then you are indexing before the
beginning of the array. Since you can't control the contents of the *inbuf
array to have values < 127 && >= 0, you can lose. The correct thing to do
is to always cast to (unsigned char) any use of char in the isfoo() function/
macros.

christos