Date: Wed, 06 Nov 2002 16:21:22 -0800 From: Terry Lambert <tlambert2@mindspring.com> To: Marc Olzheim <marcolz@stack.nl> Cc: hackers@FreeBSD.ORG Subject: Re: /usr/src/ed/bin/re.c:99 Message-ID: <3DC9B202.A94F8C1F@mindspring.com> References: <20021106164653.GA95733@stack.nl> <3DC9811E.35657731@mindspring.com> <20021106213000.GA42483@stack.nl>
next in thread | previous in thread | raw e-mail | index | archive | help
Marc Olzheim wrote:
> > In any case, your fears are unfounded, for the most part, since
> > the FAQ entry you are referencing is not analogous to the construct
> > you are trying to apply it to, anyway, and the FAQ fails to deal
> > with many of these portability issues, too, since it assumes that
> > the compiler is to spec..
>
> If not in this FAQ, where else are things like this documented ? There
> are also porgrammers who _do_ want to do it the portable/right way, but
> if the documentation is nowhere to be found...
>
> Any pointers ?
>
> Thanks for the info,
It's generally not well documented, except in the minds of people
who have had to deal with porting software to many platforms, over
time. Really, you are unlikely to need these skills, since unless
you are working for a software vendor that has to run on what your
customers have available, you won't encounter most of the issues
(not really a problem, since no one writes for more than one OS these
days).
At one point in time, I wrote a small book called "C for Race Car
Drivers" (it was a good title at the time), that tried to teach you
how to code for speed (things like using "for(;;)" instead of
"while(1)" to avoid the extra compare inside the loop, etc.), and
for speed of porting to different UNIX platforms (do not use
structure assignments, do not use unions, do not use bit fields, do
not assume the sign of "char", where to use the "register" keyword,
etc.).
Optimizing compilers killed most of the utility of the book, which
was mostly about "how to write C source code so that the compilers
on these 40 platforms won't make a mistake, and so that the assembly
code that's emitted is fast".
If you are really interested in boundary conditions, ou would do
well to get access to some rather different compilers, and compile
up a lot of software, and see what doesn't compile, as well as what
breaks outright.
I don't know of any tools that will, for example, take the reference
implementation for SLPv2, as written by Sun, and complain "sockaddr_in
used without bzero/memset", or take the ACAP source code and complain
"use of '::' construct without guard spaces will not compile in GCC
prior to version 2.9.5", or "Space between 'while' and '(' will not
compile on Wizard C on CTOS and BTOS platforms", or "Declaration of
stack variable 'foo' in statement block not at top of function may
scribble on registers in SAS (Lattice) C compiler", or the OpenSSL
engine code and complain "Use of array index instead of pointer for
descriptor entry references costs 48 out of 232 instructions in the
common case, please recode", etc., if that's what you're asking.
If you are just starting out, it's worthwhile to learn assembly
language, and spend some time figuring out what assembly language
will be emitted for certain types of source code: if a high level
language user knows what their code is going to do, they will be
able to write much better code.
-- Terry
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-hackers" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?3DC9B202.A94F8C1F>