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

[Rick Jones <rick.jones2 () hp com>]

As promised, I grabbed *current* and compiled libpcap with +DD64.  It appears to 
have been OK.  I went to compile tcpdump, but tcpdump-current.tar.gz unpacks to 
2004-07-21, not 22.  I simplisticly took that to mean it didn't update bits from 
before.

On a lark, I added a "+M0" to turn-on migration warnings and re-did the libpcap 
stuff.  That generated a number of warnings, some of which may actually be 
issues in libpcap, but many of which I suspect are issues for HP to deal with. 
There are about 2100 lines of output in all, I suspect I shouldn't dump that 
onto the mailing list :)

here are the warnings from pcap-dlpi.c: (July 22 version)

cc: "pcap-dlpi.c", line 245: LP64 migration warning 733: + between pointer and 
32 bit integer.
cc: "pcap-dlpi.c", line 278: LP64 migration warning 753: <= converts 32 bit 
integer to long
cc: "pcap-dlpi.c", line 278: LP64 migration warning 732: Different types treated 
as unsigned for <=.
cc: "pcap-dlpi.c", line 278: LP64 migration warning 753: - converts 32 bit 
integer to long
cc: "pcap-dlpi.c", line 284: LP64 migration warning 733: + between pointer and 
32 bit integer.
cc: "pcap-dlpi.c", line 290: LP64 migration warning 733: + between pointer and 
32 bit integer.
cc: "pcap-dlpi.c", line 329: LP64 migration warning 733: + between pointer and 
32 bit integer.

Those above look mostly harmless.

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

I'm guessing this one is harmless as ep and bp are unlikely to get 2GB or more 
apart right?-)

                        if (++n >= cnt && cnt >= 0) {
                >>>>                p->cc = ep - bp;
                                p->bp = bp;
                                return (n);
                        }

cc: "pcap-dlpi.c", line 372: LP64 migration warning 753: Argument #2 converts 32 
bit integer to long
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.

cc: "pcap-dlpi.c", line 378: LP64 migration warning 753: Argument #2 converts 32 
bit integer to long
cc: "pcap-dlpi.c", line 463: LP64 migration warning 753: Argument #3 converts 32 
bit integer to long
cc: "pcap-dlpi.c", line 476: LP64 migration warning 753: <= converts 32 bit 
integer to long
cc: "pcap-dlpi.c", line 476: LP64 migration warning 732: Different types treated 
as unsigned for <=.
cc: "pcap-dlpi.c", line 476: LP64 migration warning 753: - converts 32 bit 
integer to long
cc: "pcap-dlpi.c", line 478: LP64 migration warning 733: + between pointer and 
32 bit integer.
cc: "pcap-dlpi.c", line 478: LP64 migration warning 753: <= converts 32 bit 
integer to long
cc: "pcap-dlpi.c", line 478: LP64 migration warning 732: Different types treated 
as unsigned for <=.
cc: "pcap-dlpi.c", line 478: LP64 migration warning 753: - converts 32 bit 
integer to long
cc: "pcap-dlpi.c", line 478: LP64 migration warning 733: + between pointer and 
32 bit integer.
cc: "pcap-dlpi.c", line 502: LP64 migration warning 753: Argument #2 converts 32 
bit integer to long
cc: "pcap-dlpi.c", line 769: LP64 migration warning 753: * converts 32 bit 
integer to long
cc: "pcap-dlpi.c", line 801: LP64 migration warning 753: Argument #2 converts 32 
bit integer to long
cc: "pcap-dlpi.c", line 802: LP64 migration warning 753: Cast converts 32 bit 
integer to long
cc: "pcap-dlpi.c", line 887: LP64 migration warning 753: Argument #2 converts 32 
bit integer to long
cc: "pcap-dlpi.c", line 893: LP64 migration warning 753: * converts 32 bit 
integer to long
cc: "pcap-dlpi.c", line 894: LP64 migration warning 753: Argument #1 converts 32 
bit integer to long
cc: "pcap-dlpi.c", line 896: LP64 migration warning 753: Argument #3 converts 32 
bit integer to long
cc: "pcap-dlpi.c", line 948: LP64 migration warning 733: - between pointer and 
32 bit integer.
cc: "pcap-dlpi.c", line 950: LP64 migration warning 753: Argument #2 converts 32 
bit integer to long
cc: "pcap-dlpi.c", line 956: LP64 migration warning 733: - between pointer and 
32 bit integer.
cc: "pcap-dlpi.c", line 956: LP64 migration warning 733: - between pointer and 
32 bit integer.
cc: "pcap-dlpi.c", line 956: LP64 migration warning 733: - between pointer and 
32 bit integer.
cc: "pcap-dlpi.c", line 959: LP64 migration warning 720: Assignment may overflow 
integer "unit".
cc: "pcap-dlpi.c", line 961: LP64 migration warning 753: Argument #2 converts 32 
bit integer to long
cc: "pcap-dlpi.c", line 1034: LP64 migration warning 753: Argument #2 converts 
32 bit integer to long
cc: "pcap-dlpi.c", line 1055: LP64 migration warning 753: Argument #2 converts 
32 bit integer to long

most of those 32-bit ints to longs as args are str* calls...

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.

cc: "pcap-dlpi.c", line 1076: LP64 migration warning 753: Argument #2 converts 
32 bit integer to long
cc: "pcap-dlpi.c", line 1082: LP64 migration warning 753: Argument #2 converts 
32 bit integer to long
cc: "pcap-dlpi.c", line 1089: LP64 migration warning 753: Argument #2 converts 
32 bit integer to long
cc: "pcap-dlpi.c", line 1096: LP64 migration warning 753: Argument #2 converts 
32 bit integer to long
cc: "pcap-dlpi.c", line 1551: LP64 migration warning 753: Argument #2 converts 
32 bit integer to long
cc: "pcap-dlpi.c", line 1556: LP64 migration warning 530: Casting from loose to 
strict alignment: Resulting pointer may be misaligned.

That one above is a similar strbuf.buf kind of thing:


        dlp = (dl_hp_ppa_ack_t *)ctl.buf;
        if (dlp->dl_primitive != DL_HP_PPA_ACK) {

cc: "pcap-dlpi.c", line 1558: LP64 migration warning 753: Argument #2 converts 
32 bit integer to long
cc: "pcap-dlpi.c", line 1564: LP64 migration warning 753: < converts 32 bit 
integer to long
cc: "pcap-dlpi.c", line 1564: LP64 migration warning 732: Different types 
treated as unsigned for <.
cc: "pcap-dlpi.c", line 1565: LP64 migration warning 753: Argument #2 converts 
32 bit integer to long
cc: "pcap-dlpi.c", line 1572: LP64 migration warning 753: Argument #1 converts 
32 bit integer to long
cc: "pcap-dlpi.c", line 1573: LP64 migration warning 753: Argument #2 converts 
32 bit integer to long
cc: "pcap-dlpi.c", line 1582: LP64 migration warning 753: Argument #2 converts 
32 bit integer to long
cc: "pcap-dlpi.c", line 1588: LP64 migration warning 753: Argument #2 converts 
32 bit integer to long
cc: "pcap-dlpi.c", line 1595: LP64 migration warning 530: Casting from loose to 
strict alignment: Resulting pointer may be misaligned.
cc: "pcap-dlpi.c", line 1596: LP64 migration warning 530: Casting from loose to 
strict alignment: Resulting pointer may be misaligned.

variations on the theme...

cc: "pcap-dlpi.c", line 1619: LP64 migration warning 733: + between pointer and 
32 bit integer.
cc: "pcap-dlpi.c", line 1619: LP64 migration warning 530: Casting from loose to 
strict alignment: Resulting pointer may be misaligned.

again :)

cc: "pcap-dlpi.c", line 1647: LP64 migration warning 753: Argument #2 converts 
32 bit integer to long
cc: "pcap-dlpi.c", line 1651: LP64 migration warning 753: Assignment converts 32 
bit integer to long
cc: "pcap-dlpi.c", line 1656: LP64 migration warning 753: == converts 32 bit 
integer to long
cc: "pcap-dlpi.c", line 1660: LP64 migration warning 733: + between pointer and 
32 bit integer.
cc: "pcap-dlpi.c", line 1660: LP64 migration warning 530: Casting from loose to 
strict alignment: Resulting pointer may be misaligned.
cc: "pcap-dlpi.c", line 1664: LP64 migration warning 753: Argument #2 converts 
32 bit integer to long
cc: "pcap-dlpi.c", line 1669: LP64 migration warning 753: Argument #2 converts 
32 bit integer to long

Most of them look mostly harmless.  However, the loose to strict alignment stuff 
is a triffle worrying.

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.
cc: "fad-gifc.c", line 307: LP64 migration warning 733: + between pointer and 32 
bit integer.
cc: "fad-gifc.c", line 307: LP64 migration warning 530: Casting from loose to 
strict alignment: Resulting pointer may be misaligned.

        ifrp = (struct ifreq *)buf;
        ifend = (struct ifreq *)(buf + ifc.ifc_len);

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;

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;


and the cast here:

FILE *
pcap_dump_file(pcap_dumper_t *p)
{
        return ((FILE *)p);
}

and here:

int
pcap_dump_flush(pcap_dumper_t *p)
{

        if (fflush((FILE *)p) == EOF)
                return (-1);
        else
                return (0);
}

and finally here:

void
pcap_dump_close(pcap_dumper_t *p)
{

#ifdef notyet
        if (ferror((FILE *)p))
                return-an-error;
        /* XXX should check return from fclose() too */
#endif
        (void)fclose((FILE *)p);


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.

there were _boatloads_ of warnings about "+" between pointer and 32 bit integer 
in scanner.c, and a few in grammar.y

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