Date: Mon, 27 Aug 2001 00:28:06 -0700 From: Justin C.Walker <justin@mac.com> To: net@freebsd.org Cc: users@ipv6.org, core@kame.net Subject: Re: IPV6/KAME/protosw integration cleanup Message-ID: <20010827072807.UVLM3082.femail41.sdc1.sfba.home.com@grinch> In-Reply-To: <3B89EA84.62FA4422@elischer.org>
next in thread | previous in thread | raw e-mail | index | archive | help
FWIW, sadly, Mac OS X does flirt with varargs. These seem to have
crept in via the Mach back door. I don't believe that they are
actually used anywhere, but the varargs headers are there. Our
version of the KAME stack must have pre-dated the intro of this,
because the 'bsd' side of the code is varargs-free (so far, at any
rate).
Regards,
Justin
On Sunday, August 26, 2001, at 11:36 PM, Julian Elischer wrote:
> Jun-ichiro itojun Hagino wrote:
>>
>>> I have still not heard any reason for the varargs here..
>>> except "it's needed for portability"..
>>> portability with WHO?
>>
>> portability with other *BSD projects (NetBSD, OpenBSD,
>> BSD/OS, MacOSX
>> maybe).
>
> are you suggesting that BSD/OS and MacOS/X have varargs?
> Varargs are inherrently incompatible with switch tables
> unless there is a format key (e.g. as in printf())
> (I think NetBSD must have been crazy when they did it)
>
>>
>>> BSD4.4 certainly didn't have varargs there....
>>
>> 4.4BSD did not have prototype in protosw.h, there's no
>> varargs either.
>> freebsd added prototype on its own, and thus change/broke
>> some of the
>> existing xx{in,out}put prototypes. netbsd/openbsd added
>> varargs, to
>> keep existing practices in 4.4BSD.
>
> they were too lazy to fix the problems.
>
> I agree that we should fix protosw if it is deficient, but not
> with varargs.!
>
>> see it for yourself.
>
>> http://www.freebsd.org/cgi/cvsweb.cgi/src/sys/sys/protosw.h
>> http://www.openbsd.org/cgi-bin/cvsweb/src/sys/sys/protosw.h
>> http://cvsweb.netbsd.org/bsdweb.cgi/syssrc/sys/sys/protosw.h
>
>
>
> so what's wrong with adding a
>
> #ifdef USE_VARARGS
> xxx_input(struct mbuf *m, va_alist)
> #else
> xxx_input(struct mbuf *m, int offset)
> #endif
>
> at least we'd get rid of the d*mned warning messages!
> Are you not aware that most of the warning messages for a normal
> kernel compile come from the KAME code? I am on compile number 157
> for the KSE code. (in 3 weeks)
>
> I must look at those messages EVERY compile to check that they are
> not hiding a
> real
> problem there when I change things.
>
> It is damaging to your reputation, and it certainly hurts my
> professional
> reputation to have people say "yes but FreeBSD kernel has lived for
> over a year with the same warning messages in a simple kernel compile".
> I HAVE had people say something like this to me.
>
> (The second worst module is acpi from intel)
>
>
>> itojun
>
> --
> +------------------------------------+ ______ _ __
> | __--_|\ Julian Elischer | \ U \/ / hard at
> work in
> | / \ julian@elischer.org +------>x USA \ a very
> strange
> | ( OZ ) \___ ___ | country !
> +- X_.---._/ presently in San Francisco \_/ \\
> v
>
> To Unsubscribe: send mail to majordomo@FreeBSD.org
> with "unsubscribe freebsd-net" in the body of the message
---
Justin C. Walker, Curmudgeon-At-Large *
Institute for General Semantics |
Director of Technology | When LuteFisk is outlawed
Nexsi Systems Corp. | Only outlaws will have
1959 Concourse Drive | LuteFisk
San Jose, CA 95131 |
*--------------------------------------*-------------------------------*
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-net" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20010827072807.UVLM3082.femail41.sdc1.sfba.home.com>