christos@nyc.deshaw.com (Christos Zoulas) writes:

  > In article <199705271522.RAA24951@kurt.tools.de> ws@kurt.tools.de (Wolfgang Solfrank) writes:
  >>> Any new NetBSD port is likely to make more use of gcc and
  >>> cross-compiling than it is to use a native compiler, no?
  >>> And any counterexample that comes up is more than likely to have an
  >>> ANSI-capable compiler as the native one by now...
  >> 
  >> What about people that pick pieces from the code and use it in different
  >> environments?  Like e.g. using the networking code to fix bugs in legacy
  >> machines' tcp/ip implementations.
  >> 
  >> In a word, I'd hate this to happen.
  >> 
  >> BTW, long long isn't a good argument, as it is (or should be?) used only in
  >> port-specific code, or by the way of a typedef (like int64_t).

  > I totally agree here. I am using pieces of the tree on machines where the
  > native compiler is not ansi [SunOS].

It seems to me that the aim of NetBSD is to develop a free modern
portable unix with a BSD flavour. Providing a code base which can be
cannibalized for other purposes is at best a secondary objective. More
important should be the ease of importing code from other projects into
NetBSD.

In either case, the choice of ANSI or K&R is at best a two edged
sword. The current style may indeed ease using NetBSD code in legacy
systems, but if I want to use NetBSD code in another modern project, I
need to de-uglify it. Ditto with the importing of code.

However, since I can't imagine there is much K&R style code we would
want to import (and which has not already been imported) and since I
see importing code as a much higher priority than exporting code, I
think the balance is very much on the side of moving to ANSI style
code.

Personally, I find the current style an impediment to
contributing. Typically I develop using ANSI style function
definitions and then have to make an extra effort to convert it to
release it.

As I understand it (I'm sure I will be corrected if I am wrong), the
current practice of having an ANSI style declaration and a K&R style
definition is relying on a quirk of gcc. If you don't have gcc you
lose the protection of type checking function arguments. In my view,
that is a major argument in favour of ANSI definitions.

By way of anecdote, when I first built mach for the pc532, I did it by
cross compiling on a sparc using gcc and binutils. This was before
there was support for cross compilation in binutils, so I had to add
that myself. It wasn't a trivial exercise, but neither was it all that
bad and the pc532 has to be one of the more obscure machines around!

It seems to me that in porting NetBSD to a new architecture either a
satisfactory compiler exists or you are going to have to port gcc to
it. If the latter, you may as well do the compiler port first.

I understand the argument about using NetBSD code in other systems, I
just don't think that should be high on our priority list.  My vote,
(if I had one) would be to gradually (as people feel like doing the
work) transition to ANSI.

Ian