> 
> >>> 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.

This is not really true. It may be true in the case where two functions have
their arguments and return codes re-worked simultaneously. The rest of the
time there will be other dependencies in the code, variable definitions
and other assignments, and passing the value to other functions too. I don't
think that many argument type changes will go through in the future - I expect
more people to support adding new library functions. (Which may or may not
be a good solution)

I believe there are examples in both situations where the code will not be
transportable in a 'hands-off' way. The difference is that casts will break
on the call itself, and prototypes will break on the supporting code.

							David Maxwell