Skip site navigation (1)Skip section navigation (2)
Date:      Wed, 30 Jan 2002 19:40:02 -0800
From:      Terry Lambert <tlambert2@mindspring.com>
To:        Peter Wemm <peter@wemm.org>
Cc:        Garance A Drosihn <drosih@rpi.edu>, Alfred Perlstein <bright@mu.org>, Poul-Henning Kamp <phk@critter.freebsd.dk>, Jordan Hubbard <jkh@winston.freebsd.org>, Dallas De Atley <deatley@apple.com>, arch@FreeBSD.ORG
Subject:   Re: __P macro question
Message-ID:  <3C58BC92.44F5ED37@mindspring.com>
References:  <20020131025121.308C13A9A@overcee.wemm.org>

next in thread | previous in thread | raw e-mail | index | archive | help
Peter Wemm wrote:
> > 1)    You risk becoming the compiler maintainer for 2
> >       years, in order to comply with the license.
> 
> Nope.  Nobody says you have to maintain it.  Besides, FreeBSD isn't going
> to run on any system so obscure that it wont have some sort of ansi
> compiler available any time in the forseeable future.

Oops; three years, not two.  Please read section 3(b) of the GPL
at:

	http://www.gnu.org/licenses/gpl.html

> > 2)    It is another barrier to using BSD code.
> 
> So?

So it is a barrier to contributing to a BSD project as a means
of promoting progress in the art and science, and, in general,
for betterment of the human condition.

> versus what? GNU code which is also ANSI?

Versus anything.  The GNU code is already irrelevent, in that
it classifies some people as being less deserving than others,
and so it is not in the same category, since it has little or
no utility as a reference implementation for other than
interoperability testing.


> > 3)    The GCC compiler is sub-par on many architectures.
> 
> It tends to work better on older platforms than newer ones.

How will this get the same P4 instruction pipelining optimization
performance that the native Intel supplied compiler has?

> If eliminating the use of __P() in our code means that we dont need to spend
> developer-weeks of time every 6 months, then it is damn well worth it.

I don't understand this statement.  I don't see how time is
being saved by having this discussion in the first place.


> > For example, taking the TCP/IP stack by itself, with all
> > the DOS attack hardening and other hardenening, and using
> > it in a system other than FreeBSD.
> 
> I hope you noticed that all that code is nearly pure ANSI.

Yes, I had noticed that the syncache code used unprotected
prototypes.  This is not inconsistent with my first posting
in this thread, which noted the current stated FreeBSD policy
with regard to new code.


> *Bad* example!

Your choice of the syncache/syncookie code was a bad example;
for the most part, it does not fall into the "hardeneing"
category.  If you want to discuss the architectural issues
with this code, we should start a different thread.

-- Terry

To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-arch" in the body of the message




Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?3C58BC92.44F5ED37>