Subject: Re: Problems with gdb under NetBSD 1.0
To: None <current-users@netbsd.org>
From: der Mouse <mouse@Collatz.McRCIM.McGill.EDU>
List: current-users
Date: 12/13/1994 07:42:28
>>> Never trust prototypes. Always cast. It's easier to read,
>>> maintain, and guaranteed to work and force it to do what you mean.
>> for a long time, the second arg to lseek() was a 'long', and people
>> would commonly cast it that way.
>> Well, now, every instance of code that does that is broken.
> Such code always was broken, right from the day off_t was devised.
> It should be fixed, not worked around.
Really, Greg, you mean you can't see cgd's point here? The point is
that everyone who wrote lseek(fd,(long)off,L_SET) was following your
advice! (Referring, of course, to code written for systems that did
type the second argument of lseek as long...which existed for a long
time after off_t was invented; indeed, there are probably still some
chugging away even today.)
If such people had, instead, brought in a prototype from the
appropriate system include file (assuming, that is, prototypes had
existed at the time), then the code would still be correct and would
continue to work now.
Provided you pull in the prototype from a system header file, I agree
with cgd: use those prototypes. (If you write the prototype yourself,
it's still better than littering your code with casts that will be out
of date next time someone thinks to change the type of some argument;
you have only one thing to change, rather than many, and it is - isn't
it? :-) - well isolated in the `porting' section of the code.)
Of course, that leaves the problem of what header file to include to
get the prototypes, and _that_ changes much more than the actual type
of the argument does. Among the systems I use, there often is no
system header file that prototypes (often, even declares) syscalls;
when there is, which file one `should' include, and which files it
works to include, vary widely. Somehow, this seems to be a step
backwards.
I've taken to writing a <syscalls.h> which I put in my private include
directory, and bash on for each system I have to migrate my code to.
That way at least all the necessary changes are well localized, and
fixing them once fixes them for all my code.
der Mouse
mouse@collatz.mcrcim.mcgill.edu