Subject: Re: Is there a new tcsh source
To: None <ghudson@MIT.EDU>
From: der Mouse <mouse@Collatz.McRCIM.McGill.EDU>
Date: 10/10/1994 13:11:38
>> In my case, at least, it's simply that there is no header file I can
>> count on to declare such things for me, so it's either use them
>> undeclared (which works in only a few instances) or declare them
> This is what standards are for.
Ah, but there are so many standards! Which one should I use?
> Generally, your code should assume a POSIX.1-compliant system
Why should I pick POSIX.1 as my standard-of-choice, rather than (say)
traditional BSD, or traditional SysV? For that matter, where can I
fetch a description of what "POSIX.1-compliant" means?
>> Take sys_errlist, for example. [...]
> In this case, your code shouldn't be using sys_errlist at all
Well yes; since I discovered strerror(), I've hardly touched
sys_errlist. I picked it because it was mentioned in the message and
thus was at ready hand as an example.
> ...programs...which used Gnu autoconf...
I _loathe_ autoconfiguration scripts; in my experience, they invariably
get something wrong (for example, anything I build on our Suns will
have strerror() available, even though it's basically SunOS), and
figuring out what to tweak to get it right is a major mess.
Well, most autoconfiguration scripts, that is. I have met a couple
that made guesses, but prompted to allow me to override each one. Even
those, though, usually have problems; I recall one in particular that
refused to believe me when I told it where the C preprocessor was.
>> ...because I can't find an include file that declares them
>> everywhere I need to have the code build?
> The trap here is thinking only about "everywhere I need to have the
> code build," and not, "everywhere I might need to build the code in
> the future."
The latter includes most of the world, and I'm not about to try to make
my code build on DOS, VM, NetBSD, SVR4, VMS, and ghod-only-knows what
all else, especially when I don't have instances of most of them
available for testing. I try to write portably, and I think I mostly
manage it...but when it comes to the type for the second, third, and
fourth arguments to select(), I will happily write off any system that
neither has nor can be patched up to have an fd_set type. For example.
Until and unless I have occasion to want the program on such a system,
this is not a problem, and if and when I do, I consider it porting to
an alien system, different only in degree from porting to a system with
no select() at all...or with no C compiler at all.