Skip site navigation (1)Skip section navigation (2)
Date:      Fri, 23 Jun 1995 22:23:44 -0700
From:      Matt Dillon <dillon@best.com>
To:        Bruce Evans <bde@zeta.org.au>
Cc:        bugs@FreeBSD.org
Subject:   Re: connect() bug found and fixed (uninitialized pointer)
Message-ID:  <199506240523.WAA26119@shell1.best.com>

next in thread | raw e-mail | index | archive | help
:>      couple of other programs.  As best as I can tell,
:>      something gets confused and the parameter offsets
:>      get skewed, causing corruption when a bad pointer
:>      (due to the skew) is dereferenced.
:
:Runtime problems are most likely caused by %d or %ld format specifiers
:mismatched with quad_t arguments, e.g., off_t's.  quad_t's should be
:printed in format %qd.  Casts shouldn't normally be used except for
:pointers.  Pointer types should be cast to (void *) and printed in
:format %p.  -Wall finds most mismatches to give you some chance of
:detecting int vs. long mismatches but it is sloppy about pointers.
:
:Bruce

    Yes, I finally figured that out.  I think there is a serious problem
    though, because MOST third party programs do not put -Wall in
    their Makefile, and without -Wall you get not a single warning
    about possible quad_t conflicts... everything appears to compile
    and link just fine, except the resulting binary does weird things.

    Now, for us... obviously we will be putting -Wall in everything we
    compile from now on, but I think you will find a lot of people having 
    serious problems with this quad_t change... rightly, new procedure
    names should have been chosen for the relatively few system calls
    that need quad_t's (lseek, ftruncate could become lqseek, fqtruncate).

    You may wish to consider turning -Wall or, at least, the warning
    regarding unprototyped procedure calls, ON by default in gcc.  Personally,
    I think keeping the same naming conventions was ill-considered.

					-Matt

    Matthew Dillon   VP Engineering, BEST Internet Communications, Inc.
		    <dillon@best.com>, <dillon@apollo.west.oic.com>
    [always include a portion of the original email in any response!]



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199506240523.WAA26119>