: ck_ssl.c: In function 'tls_load_certs':
: ck_ssl.c:1171: warning: cast from pointer to integer of different size
: ck_ssl.c:1172: warning: cast from pointer to integer of different size
:
: This is being compiled on Debian GNU/Linux unstable on a Pentium II machine.
:
I'm told that these are nothing to worry about either. We've always had
tons of warnings when building with the security libraries and header files,
yet the features still work OK when used. Still, it would be nice avoid the
warnings.

A more serious issue has to do with the total replacement of DES functions
in OpenSSL in recent Fedora issues.

Anybody with knowledge in these areas who might want to lend a hand is
most welcome!

In article <slrng52q33.cri.fdc@panix2.panix.com>,
Frank da Cruz <fdc@columbia.edu> wrote:[color=blue]
>On 2008-06-04, Arthur Marsh <arthur.marsh@internode.on.net> wrote:
>: I don't know if this is worth checking:
>:
>: gcc-4.3 -O3 -march=pentium2 -funsigned-char -pipe -DPOSIX -DLINUX
>: -DNOCOTFMC -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64
>: -DCK_AUTHENTICATION -DCK_SSL -DCK_PAM -DZLIB -DCK_CURSES -DCK_POSIX_SIG
>: -DTCPSOCKET -DLINUXFSSTND -DHAVE_CRYPT_H -DFNFLOAT -DCK_SHADOW
>: -I/usr/include/openssl -DOPENSSL_097
>: -DKTARGET=\"linux+openssl+zlib+shadow+pam\" -c ckuusx.c
>: ckuusx.c: In function 'ck_termset':
>: ckuusx.c:6181: warning: cast from pointer to integer of different size
>: ckuusx.c:6188: warning: cast from pointer to integer of different size
>: ckuusx.c:6195: warning: cast from pointer to integer of different size
>:
>This is something in the termcap / termlib / ncurses library. I'd say
>if the file-transfer display still works OK (which is really the only
>things that uses curses, except a few commands like CLEAR SCREEN), then
>it's nothing to worry about.
>
>: ck_ssl.c: In function 'tls_load_certs':
>: ck_ssl.c:1171: warning: cast from pointer to integer of different size
>: ck_ssl.c:1172: warning: cast from pointer to integer of different size
>:
>: This is being compiled on Debian GNU/Linux unstable on a Pentium II machine.
>:
>I'm told that these are nothing to worry about either. We've always had
>tons of warnings when building with the security libraries and header files,
>yet the features still work OK when used. Still, it would be nice avoid the
>warnings.[/color]

_ALL_ these statements are invocations of the 'debug()' macro. 'debug()'
expands to a function where the 4th parameter is defined as a CK_OFF_T.

The offending invocations all have a 4th parameter that is a "pointer to
something". Which *VIOLATES* the specification of the dodebug() routine
(in ckuusx.c, line 4849) that the debug() macro expands to.

Anyway, the result is a "size mis-match" in these circumstances
between a (void *) and a CK_OFF_T.

CK_OFF_T is specced as a type big enough to hold a _file_ offset, and
since it's being compiled with _LARGEFILESOURCE this is a 64-bit qty.
_APPARENTLY_, the compilation options only use a 32-bit _program_ address-
space, thus generating the mis-match.

FIX:
ckuusx.c -- change the last parameter of debug() from "" to 0 on all 3 lines.

ck_ssl.c -- no obvious foolproof fix here. Explicitly casting the last
param of the macro to an 32-bit qty -- e.g. "debug(..((int32)ctx))"
should work, as long as there is a defined 'int32' type.
`
[ I'm assuming that sooner or later somebody _will_ try to compile ]
[ C-Kermit on a machine with 32-bit pointers, but only 16-bit ints. ]
[ If one decides that it is 'safe' to ignore that case, then a simple ]
[ ((int)ctx) would work. ]

Robert Bonomi wrote, on 2008-06-20 10:52:[color=blue]
> In article <slrng52q33.cri.fdc@panix2.panix.com>,
> Frank da Cruz <fdc@columbia.edu> wrote:[color=green]
>> On 2008-06-04, Arthur Marsh <arthur.marsh@internode.on.net> wrote:
>> : I don't know if this is worth checking:
>> :
>> : gcc-4.3 -O3 -march=pentium2 -funsigned-char -pipe -DPOSIX -DLINUX
>> : -DNOCOTFMC -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64
>> : -DCK_AUTHENTICATION -DCK_SSL -DCK_PAM -DZLIB -DCK_CURSES -DCK_POSIX_SIG
>> : -DTCPSOCKET -DLINUXFSSTND -DHAVE_CRYPT_H -DFNFLOAT -DCK_SHADOW
>> : -I/usr/include/openssl -DOPENSSL_097
>> : -DKTARGET=\"linux+openssl+zlib+shadow+pam\" -c ckuusx.c
>> : ckuusx.c: In function 'ck_termset':
>> : ckuusx.c:6181: warning: cast from pointer to integer of different size
>> : ckuusx.c:6188: warning: cast from pointer to integer of different size
>> : ckuusx.c:6195: warning: cast from pointer to integer of different size
>> :
>> This is something in the termcap / termlib / ncurses library. I'd say
>> if the file-transfer display still works OK (which is really the only
>> things that uses curses, except a few commands like CLEAR SCREEN), then
>> it's nothing to worry about.
>>
>> : ck_ssl.c: In function 'tls_load_certs':
>> : ck_ssl.c:1171: warning: cast from pointer to integer of different size
>> : ck_ssl.c:1172: warning: cast from pointer to integer of different size
>> :
>> : This is being compiled on Debian GNU/Linux unstable on a Pentium II machine.
>> :
>> I'm told that these are nothing to worry about either. We've always had
>> tons of warnings when building with the security libraries and header files,
>> yet the features still work OK when used. Still, it would be nice avoid the
>> warnings.[/color]
>
>
> _ALL_ these statements are invocations of the 'debug()' macro. 'debug()'
> expands to a function where the 4th parameter is defined as a CK_OFF_T.
>
> The offending invocations all have a 4th parameter that is a "pointer to
> something". Which *VIOLATES* the specification of the dodebug() routine
> (in ckuusx.c, line 4849) that the debug() macro expands to.
>
> Anyway, the result is a "size mis-match" in these circumstances
> between a (void *) and a CK_OFF_T.
>
> CK_OFF_T is specced as a type big enough to hold a _file_ offset, and
> since it's being compiled with _LARGEFILESOURCE this is a 64-bit qty.
> _APPARENTLY_, the compilation options only use a 32-bit _program_ address-
> space, thus generating the mis-match.
>
> FIX:
> ckuusx.c -- change the last parameter of debug() from "" to 0 on all 3 lines.[/color]

Done, and working thanks!
[color=blue]
>
> ck_ssl.c -- no obvious foolproof fix here. Explicitly casting the last
> param of the macro to an 32-bit qty -- e.g. "debug(..((int32)ctx))"
> should work, as long as there is a defined 'int32' type.
> `
> [ I'm assuming that sooner or later somebody _will_ try to compile ]
> [ C-Kermit on a machine with 32-bit pointers, but only 16-bit ints. ]
> [ If one decides that it is 'safe' to ignore that case, then a simple ]
> [ ((int)ctx) would work. ]
>
>[/color]