From owner-freebsd-hackers  Mon May  5 14:47:23 1997
Return-Path: <owner-hackers>
Received: (from root@localhost)
          by hub.freebsd.org (8.8.5/8.8.5) id OAA22808
          for hackers-outgoing; Mon, 5 May 1997 14:47:23 -0700 (PDT)
Received: from time.cdrom.com (time.cdrom.com [204.216.27.226])
          by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id OAA22802
          for <hackers@FreeBSD.ORG>; Mon, 5 May 1997 14:47:21 -0700 (PDT)
Received: from time.cdrom.com (localhost.cdrom.com [127.0.0.1]) by time.cdrom.com (8.8.5/8.6.9) with ESMTP id OAA07925; Mon, 5 May 1997 14:47:55 -0700 (PDT)
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 
In-reply-to: Your message of "Tue, 06 May 1997 07:29:39 +1000."
             <199705052129.HAA11715@godzilla.zeta.org.au> 
Date: Mon, 05 May 1997 14:47:55 -0700
Message-ID: <7923.862868875@time.cdrom.com>
From: "Jordan K. Hubbard" <jkh@time.cdrom.com>
Sender: owner-hackers@FreeBSD.ORG
X-Loop: FreeBSD.org
Precedence: bulk

> 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