Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!swrinde!mips!samsung!munnari.oz.au!goanna!ok From: ok@goanna.cs.rmit.oz.au (Richard A. O'Keefe) Newsgroups: comp.std.c Subject: Re: call to revolt Message-ID: <6551@goanna.cs.rmit.oz.au> Date: 28 Jun 91 10:32:18 GMT References: <992@baby.and.nl> <782@taumet.com> <998@baby.and.nl> Organization: Comp Sci, RMIT, Melbourne, Australia Lines: 42 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.