Re: 64-bit warnings for july 22 libpcap. no July 22 tcpdump-current?

[Guy Harris <guy () alum mit edu>]

On Jul 22, 2004, at 10:29 AM, Rick Jones wrote:

> cc: "pcap-dlpi.c", line 376: LP64 migration warning 720: Argument #3 
> may overflow integer.
>
>         }
>         ret = dlrawdatareq(p->send_fd, buf, size);
>
> I guess that one depends on how large size is likely to get.

...and changing the third argument to "dlrawdatareq()" to "size_t" 
would probably just postpone the warning, as the "len" field in a 
"struct strbuf" - which, as you note below, is an "int" - gets that 
value assigned to it.

> cc: "pcap-dlpi.c", line 378: LP64 migration warning 753: Argument #2 
> converts 32 bit integer to long

Yeah, a lot of "snprintf()" calls will probably yield those warnings.  
As that's a widening conversion, rather than a narrowing conversion, 
it's harmless.

> cc: "pcap-dlpi.c", line 463: LP64 migration warning 753: Argument #3 
> converts 32 bit integer to long

Same issue, but with "strlcpy()" (or, actually, with "strncpy()"), and 
same resolution.

> cc: "pcap-dlpi.c", line 476: LP64 migration warning 753: <= converts 
> 32 bit integer to long

Another harmless widening warning.

> cc: "pcap-dlpi.c", line 959: LP64 migration warning 720: Assignment 
> may overflow integer "unit".

A unit number is unlikely to be bigger than 2^31-1; I guess we could 
assign the value to a "long", and then supply the appropriate error 
message for overflow, values > what fits into an int, or negative 
values.

> cc: "pcap-dlpi.c", line 1060: LP64 migration warning 530: Casting from 
> loose to strict alignment: Resulting pointer may be misaligned.
>
> That one depends on the alignment of the buf field of a struct strbuf:
>
>
>         dlp = (union DL_primitives *) ctl.buf;
>         switch (dlp->dl_primitive) {
>
> In the HP-UX include file, the struct strbuf is defined as:
>
> struct  strbuf {
>         int     maxlen;         /* max buffer length */
>         int     len;            /* length of data */
>         char *  buf;            /* pointer to buffer */
> };
>
> So that depends on what we get out of malloc, or in this case, the 
> alignment of the bufp parm to recv_ack.

All the "dl.*ack(" routines pass a pointer to arrays of "bpf_u_int32", 
so they're at least 32-bit aligned.

> There are similar things in fad-gifc.c involving the argments to str* 
> routines, and then some loose to strict alignment warnings on casts:
>
> c: "fad-gifc.c", line 306: LP64 migration warning 530: Casting from 
> loose to strict alignment: Resulting pointer may be misaligned.

"malloc()" is supposed to return a pointer to a buffer suitably aligned 
for all data structures.

> similar cast warnings in inet.c:
>
> cc: "inet.c", line 550: LP64 migration warning 530: Casting from loose 
> to strict alignment: Resulting pointer may be misaligned.
>         }
>         sin = (struct sockaddr_in *)&ifr.ifr_addr;
>         *netp = sin->sin_addr.s_addr;

"struct sockaddr" and "struct sockaddr_in" should have the same 
alignments, and "ifr_addr" *should* be a "struct sockaddr" (or a 
#define that expands to the member name of a "struct sockaddr").

> another loose to strict warning in savefile.c for the assignment to f 
> here:
>
> void
> pcap_dump(u_char *user, const struct pcap_pkthdr *h, const u_char *sp)
> {
>         register FILE *f;
>         struct pcap_sf_pkthdr sf_hdr;
>
>         f = (FILE *)user;

Yeah, that's because "pcap_dump()" is given a signature appropriate for 
use as a callback routine for "pcap_dispatch()" and "pcap_loop()".

> and the cast here:
>
> FILE *
> pcap_dump_file(pcap_dumper_t *p)
> {
>         return ((FILE *)p);
> }

A "pcap_dumper_t" is, at least currently, just a "FILE" for the file to 
which the packets are being dumped.

> looks like the FILE structure has pointers in it, which forces 8-byte 
> alignment, and I'm guessing pcap_dumper_t has no pointers or longs in 
> it so is only 4-byte alignment required.

"pcap_dumper_t" is just "struct pcap_dumper", which is never actually 
defined, so it's an incomplete definition or whatever the ANSI C term 
for that is.  As per the above, in practice it's just a name, and the 
pointer is really just a pointer to a "FILE".  The intent was 
presumably to allow that to change in the future without requiring that 
applications using libpcap change.

-
This is the tcpdump-workers list.
Visit https://lists.sandelman.ca/ to unsubscribe.