[ntp:questions] Re: Issues w/ 4.2.0a, multicast, and porting 4.2.2 to Fedora Core

Harlan Stenn stenn at ntp.isc.org
Wed Sep 6 20:49:51 UTC 2006


>>> In article <44FEF4CC.7080104 at redfish-solutions.com>, philipp_subx at redfish-solutions.com (Philip Prindeville) writes:

Philip> Harlan Stenn wrote: why not just change the prototype of doquery(),
Philip> for instance?
>>
Philip> (As a side note, why would NULL ever need to be cast to (char *)?
Philip> (void *)0 is an untyped pointer, and hence implicitly casts to
Philip> whatever pointer the receiving parameter from the prototype takes...

I do not know the line in question, and whenever I added a cast it was
specifically to shut up a warning.

Philip> Unless this needs to work not just with ISO/ANSI compilers, but with
Philip> K&R as well...  is anyone still using pre-C99 compilers?)

And while I am hoping we will (very) soon drop the K&R requirement and go to
ANSI C, I suspect we are still talking about a base level that could be
simply ANSI C, as opposed to something like C99.

Philip> After a cursory stare (that's what that blinking thing was!) at the
Philip> code, I was wondering why there's some duplication of macros,
Philip> external declarations, and even function definitions (like
Philip> doquery()).

Probably leftover cruft.

Philip> I didn't have a chance yet to do a side-by-side comparison of the
Philip> two versions of the function, but I'm wondering if we might be
Philip> better off coming up with a library that provides both client and
Philip> server functionality and then just having both the server and the
Philip> utilities link against it.

Sometimes there was a slight difference between a function used by ntpd and
one used by ntpdc and/or ntpq (for example).

Yes, it would be Wonderful to simplify and fix these things.

Philip> Maybe moving declarations and macros (like P()) into a common header
Philip> as well.

Believe it or not, I made great strides in doing this very thing.  I suspect
the job was never finished as I'm sure I was presented with other problems
that were more important to fix.

Philip> I was trying to clean up some warnings with doquery(), and only hit
Philip> one of the places it was declared... which caused a conflicting
Philip> definition in the other place it was declared... Life is a lot
Philip> simpler when functions are declared in one and only one place, and
Philip> defined in one and only one place... especially when your compiler
Philip> doesn't have strict prototypes.

Agreed, and I would happily accept patches to fix these problems.  One of
the issues, however, is that there are a large number of compilers (and
system header files) out there, and there have been times before where
patches to "clean lint" on one version of an OS completely break the build
on some other OS.

Philip> I might try to compile with -std=c99 just for fun...

I'd be happy to work with you to see the code cleaned up.

H




More information about the questions mailing list