Date: Tue, 23 Dec 1997 21:03:03 +0100 (MET) From: j@uriah.heep.sax.de (J Wunsch) To: freebsd-current@freebsd.org Subject: Re: Bruce vandalism again Message-ID: <199712232003.VAA13846@uriah.heep.sax.de> References: <199712201434.JAA00329@dyson.iquest.net> <14545.882642903@time.cdrom.com> <19971221120534.43478@lemis.com> <199712211002.LAA00388@uriah.heep.sax.de> <19971222101914.28785@lemis.com>
next in thread | previous in thread | raw e-mail | index | archive | help
Greg Lehey <grog@lemis.com> wrote:
>> It's quite normal that if your definition is old-style, the
>> declaration would still be prototyped on a compiler that defines
>> __STDC__ (via __P()).
>
> If the programmer does the Right Thing. My understanding was that
> style(9) discourages __P().
style(9) discourages __P() for new code. Why don't you simply read
that page?
Use of the __P macro in new code is discouraged, although modifications
to existing files should be consistent with that file's conventions.
This way, iff you're using an ANSI compiler, there's always a
prototype in scope if you're doing it right, either directly or hidden
inside __P(). This will cause the same warnings, regardless of
whether your function _definition_ uses the ancient or the modern
style.
There are things that can only expressed using the modern style,
however, like passing `short' data types (char, float) directly.
That's a non-issue for the kernel: there's not much advantage of
passing a char to a function, the compiler will allocate a 32-bit
register anyway, but has to do additional masking. There will be some
real advantage for float vs. double, but the kernel doesn't use
floating point anyway.
--
cheers, J"org
joerg_wunsch@uriah.heep.sax.de -- http://www.sax.de/~joerg/ -- NIC: JW11-RIPE
Never trust an operating system you don't have sources for. ;-)
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199712232003.VAA13846>