From owner-freebsd-hackers  Tue May  2 10:27:54 1995
Return-Path: hackers-owner
Received: (from majordom@localhost)
          by freefall.cdrom.com (8.6.10/8.6.6) id KAA10536
          for hackers-outgoing; Tue, 2 May 1995 10:27:54 -0700
Received: from cs.weber.edu (cs.weber.edu [137.190.16.16])
          by freefall.cdrom.com (8.6.10/8.6.6) with SMTP id KAA10530
          ; Tue, 2 May 1995 10:27:50 -0700
Received: by cs.weber.edu (4.1/SMI-4.1.1)
	id AA07795; Tue, 2 May 95 11:21:10 MDT
From: terry@cs.weber.edu (Terry Lambert)
Message-Id: <9505021721.AA07795@cs.weber.edu>
Subject: Re: policy with sources imported..
To: nate@trout.sri.MT.net (Nate Williams)
Date: Tue, 2 May 95 11:21:10 MDT
Cc: julian@freefall.cdrom.com, hackers@freefall.cdrom.com
In-Reply-To: <199505020327.VAA04068@trout.sri.MT.net> from "Nate Williams" at May 1, 95 09:27:05 pm
X-Mailer: ELM [version 2.4dev PL52]
Sender: hackers-owner@FreeBSD.org
Precedence: bulk

> > I did notice a distinct lack of portability for things like tcsh
> > and telnetd, though; I would think it would be a goal to make sure
> > that the code didn't get "deportablized" as it was imported
> 
> I don't think that's a worthy goal.  I think it's more important to make
> sure that the sources are readable and maintainable on the BSD box that
> it's used for than to shoot for spaghetti code full of #ifdefs which
> make it compile under every other OS.

This is probably true for sources maintained by the FreeBSD Project.

I would claim that it's *not* true of sources imported from external
maintainers on a vendor branch (well, they *should* be on a vendor
branch).

> >-- I
> > was really suprised at some of the things that wouldn't build for SunOS.
> 
> After using Ultrix for years, and then FreeBSD, I find that it is
> difficult to compile code for SunOS simply because the stock compiler
> doesn't support prototypes, and when you use something like gcc which
> does support prototypes there are *way* too many missing and/or bogus
> prototypes.

I was using acc; however, I have argued for prototype protection but
not declaration of functions using __STDC__ to wrapper the prototypes
to get around the problem you are complaining about (and VOLATILE instead
of volatile and CONST instead of const, and a couple of rather minor
sets of #defines for cdefs.h for varargs).

Clearly the best argument for prototyping is C++ compilation of C code.
I guess that the desirability of this is related to whether or not you
believe that C++ will be the successor to C.  8-).

> I'm trying to do C++ development on my SunOS box, and I'm having a heck
> of a time getting things to work because everything under the Sun (gag)
> is screwed up.  I could use a really old version of Lucid-C which
> provides prototyped include files, but it's fairly buggy so I'm trying
> to stick with gcc.

The C++ compiler on Sun from SunSoft and the CFront translator from
AT&T both work fine on Sun.  The CFront code actually can output non
protoype K&R style code, which is then portable to other machines.

I think the problems you ae having are probably all header file
related, and that only because the gcc/g++ header file rewriting
hasn't been adequately maintained.

Oh, the Oregon Software C++ works fine, too.


					Terry Lambert
					terry@cs.weber.edu
---
Any opinions in this posting are my own and not those of my present
or previous employers.