Date: Mon, 05 May 1997 14:47:55 -0700 From: "Jordan K. Hubbard" <jkh@time.cdrom.com> To: Bruce Evans <bde@zeta.org.au> Cc: hackers@FreeBSD.ORG, nadav@barcode.co.il Subject: Re: /usr/include/ftpio.h is not C++ safe Message-ID: <7923.862868875@time.cdrom.com> In-Reply-To: Your message of "Tue, 06 May 1997 07:29:39 %2B1000." <199705052129.HAA11715@godzilla.zeta.org.au>
next in thread | previous in thread | raw e-mail | index | archive | help
> I thought we agreed on not using __P in our new code (mainly in the > kernel). This means that it is no longer a bug for libftpio to be > implemented in ANSI C, but it doesn't mean that everything that > wants to use it must be implemented in ANSI C. Well, I really don't think it's worth an entire subthread here but just to make the point again that I hardly see this as a problem in libftpio's case. It's got a deeply incestuous relationship with stdio which makes it highly non-portable and the further strike against it of having *mutated* from a completely stand-alone library into something of this nature, meaning that if the end-goals of what libftpio eventually became had been understood up-front, it would have (and should have) been designed differently. I'd re-write it before I'd port it to a new OS. Now you might respond "ah, but I was speaking in generalities - I didn't mean libftpio specifically so much as I meant any library with headers in /usr/include", In which case I could only put my head in my hands at the thought of going through all those libraries and adding ANSI-variant prototypes, much less making them all C++ safe. I think it's a slippery slope you're trying to negotiate there, Bruce; watch your footing. ;-) Jordan
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?7923.862868875>