[[ Here it is!  Maybe local mail delivery is only slow!  ;-) ]]

[ On Tue, December 13, 1994 at 07:42:28 (-0500), der Mouse wrote: ]
> Subject: Re: Problems with gdb under NetBSD 1.0
>
> 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.)

Ah, but then they ignored the advice I'm re-iterating when the second
arg was changed to be of "off_t"!

Mabye I'm not making my point clear (and perhaps I'm making the same
mistake I did the last time I tried to debate this issue to folks
on/near the ANSI C committee).

Using lseek(2) as an example here is a bit of a mistake.  Think instead
of a 5-million line, 100,000 function, application, where an interface
change is necessary in several 1000 of the most commonly used functions
so that the application can deal with 64-bit values instead of "int"s.
Either we can fix them all once to use a pseudo-type that is
appropriately declared for each platform, or we can put prototypes in
the appropriate scopes, and pretend nothing else really changes.  Now I
see a variable "off", declared as an int, and it's passed to a function
taking a quad, but there's no explicit cast.  Now what's going to break?
If I simply change the declaration of the variable to be "quad_t" or
some such, then everything should continue to work right!

BTW, I'm not even that comfortable with C's type coercion rules for
arithmetic expressions, esp. after having fought with several stupid
compilers that had them implemented incorrectly.

My point is that once off_t was invented, and made the type of the
second argument to lseek(), it should have been treated as an entirely
new type (ala the original change from seek(2) to lseek(2)), and all
code that required casts should have been fixed then.  Perhaps we should
have made the "off_t" version be called as pseek(2), or something!

Now we have a hopless mess where all these interface changes can be
hopelessly mired in a twisty maze of hidden automatic type coercions.

I thought that's why we started using mnemonic pseudo types in the first
place!

IMHO, we should have left prototypes over in C++, and kept lint for the
"normal" C community!  0.001 ;-)

-- 
						Greg A. Woods

+1 416 443-1734			VE3TCP		robohack!woods
Planix, Inc. <woods@planix.com>; UniForum Canada <woods@uniforum.ca>