🚀 go-pugleaf

In article <998@baby.and.nl>, jos@and.nl (J. Horsmeier) writes:
> And I won't die either ... but, currently I am working on an interface
> between *very* old C code and loads of FORTRAN stuff and I want to finish
> this project asap. To plough through all this f*ckin' code makes my
> mind go nuts, and invites one to fiddle/diddle these dirty tricks.

The ANSI committee has done *nothing* to stop you.

> I know it's all *absolutely* non-portable, it's dirty and should not be done,
> but I don't care in this particular case, I just want the thing up and running
> on just one type of machine, and these kinda tricks allow me to hack things
> together. 

The ANSI committee has done *nothing* to stop you.

What's really tragic about this, of course, is that the examples I've
seen so far were all things that could have been written portably in the
first place.

> I like it, if I deserve non-portability, I want to get non-portability. 
> It's my own choice. I don't want any committee to forbid things like that 
> in any language.

The ANSI committee has done *nothing* to stop you.
We're talking here about a feature which was always illegal according
to K&R1, but some compilers let you do it anyway.  So it wasn't portable.
We're talking about a feature which is not explicitly permitted by ANSI.
Has the ANSI committee *forbidden* any vendor to implement L-value casts?
*NO*!  Any vendor that wants to can implement L-value casts.  (I keep
trying to write that as "L-value costs".  Too apt.)  And then your program
can use them.  And it won't be portable.

In short, nothing has changed.

Remember, all that a standard does is say to a programmer "this is all
that you can rely on" and to a vendor "this is all you are obliged to
provide".  Standards don't, and can't, say to programmers "this is
all that you are allowed to use in any implementation" or to a vendor
"you may not provide more than this".  Don't accuse ANSI of forbidding
an unnecessary extension when all they did was refrain from requiring it!
-- 
I agree with Jim Giles about many of the deficiencies of present UNIX.