Skip site navigation (1)Skip section navigation (2)
Date:      Tue, 2 May 95 11:21:10 MDT
From:      terry@cs.weber.edu (Terry Lambert)
To:        nate@trout.sri.MT.net (Nate Williams)
Cc:        julian@freefall.cdrom.com, hackers@freefall.cdrom.com
Subject:   Re: policy with sources imported..
Message-ID:  <9505021721.AA07795@cs.weber.edu>
In-Reply-To: <199505020327.VAA04068@trout.sri.MT.net> from "Nate Williams" at May 1, 95 09:27:05 pm

next in thread | previous in thread | raw e-mail | index | archive | help
> > 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.



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?9505021721.AA07795>