JG> I can't say for sure if it was in the *final* draft of the C
JG> specs.  but according to Kerrnigan (or was it Ritchie?) it most
JG> certainly was in the *original* draft.

JG> The information I received was in a book, in which either K or R
JG> was being interviewed about what was then a new programming
JG> language.  At the time of the interview they were apparently
JG> preparing the original draft.  The book was borrowed from the local
JG> (Croydon, Vic.) library, although I couldn't even begin to guess
JG> what either the title or author are.  While I realise that's not
JG> what would generally be though of as a convincing argument it's the
JG> only one I have.  (Standards aside, *I* think all compilers,
JG> regardless of language, *should* allow inline assembly anyway.)

The standard started off by taking the base document (K&R 1) and then
modifying it to include common practice.  It is possible that they decided
that inline assembly was common practice, and put it in, then took it out
again, but I would put my money on it having never gone in.  Either way,
it's pretty irrelevant.  It certainly didn't go into the final spec, so it
isn't standard C.

JG> The way I view these things is quite simple: Later standards, in
JG> this case ANSI and ISO, should only refine and add to the original
JG> specs, NOT alter them beyond recognition.

PE> With a statement like that, "beyond recognition" and

PE> "barstardized" I presume you are able to quote 5-10 instances where
PE> the ISO C standard has completely broken K&R C code.  Could you

JG> I can do very much better than that.  Take a peice of source
JG> written in K&R C. Now see what happens if you try to compile it
JG> (unaltered) with an ANSI or ISO compiler.  

Works fine.  Every single time.

JG> If the language is the
JG> same the compiler should not issue any errors or warnings.  

It issues warnings.  Even ISO C programs have warnings issued, for all
sorts of things, on different compilers.  A common one is if you go:

if (c = 0) printf("xyz");

It's legitimate ISO-C code, but most compilers will issue a warning that
the "c = 0" is suspicious.

Warnings are a red herring.  Errors are not, but you won't find too much
K&R code coming up with errors, unless your K&R code wasn't
conforming to K&R in the first place, and you were just getting away
with it.  In which case, that's more a case of not having a very good (or
technically possible) K&R compiler.  Nothing to do with ISO.

JG> Now
JG> take a peice of recent code and try to compile it with a K&R
JG> compiler.  

Of course that doesn't work.  The ANSI standard has been around since 1989.
 If you don't have access to a conforming C compiler, it's because you're
on a dead system.

JG> Quite simply, it takes a lot of work to adapt most recent
JG> source code so that it will compile with a K&R compiler.  I think
JG> that well justifies my description.

Sure, although besides the new-sytle-prototyping of functions, I don't
think there's even that much difference going backwards. But that's not the
issue.  The fact is, if you have an ISO compiler, you can write code for
it, and stick to the K&R subset, if you wish to maintain compatibility
with dead systems, and it will compile fine on both systems.

JG> I must say that I came on a bit stronger in the original message
JG> than I normally do.  I must admit that "beyond recognition" may have
JG> been stretching it a *bit* far.  I'll bet I wrote it just after
JG> trying to compile some ANSI or ISO code.

On a non-ISO (ie dead) compiler.

JG> I further believe that ISO should stick to
JG> checking the calibration of kitchen scales.  They have no business
JG> sticking their weights and measures noses into programming language
JG> specifications.  (There!  I said it!)

PE> Which bit of the ISO C standard don't you like.  I reckon they've done
PE> an absolutely brilliant job.  Actually, I think ANSI did most of the
PE> work, ISO is basically a copy of the ANSI one.

JG> It isn't so much that I have a dislike for anything specific
JG> that ISO has done.  I simply feel that a weights and measures
JG> organisation has no place interfering with the finer arts, such as
JG> programming languages.  

If you have no evidence to support that comment, then it is specious. The
proof of the pudding is in the eating, and the ISO C standard is wonderful.

JG> ANSI, on the other hand, have had an
JG> extremely close relationship with computers as far back as I can
JG> remember.  For what it's worth, I'm now looking for an ANSI
JG> compliant compiler to replace PCC (K&R), partly because I've
JG> surrendered to the inevitable.

It was inevitable in 1989.

PE> That won't compile on MSDOS or OS/2 as-is, you need RZSZPE.ZIP for
PE> that.

JG> For me that isn't much of a problem, I just want to write a
JG> Zmodem routine for Commodore 8 bit machines (C64, Plus/4 and C16).
JG> It will be rewritten in assembler anyway so I really just need the
JG> algorithms.  I wouldn't even consider trying to match routines with
JG> what's already available for the PC.

Ah, interesting!  I am doing work on PDPZM at the moment, and I have gone
to a lot of effort to keep the core Zmodem routines all using 100%
conforming C code, so that it can be ported.

Why do you need to rewrite that C code in assembler?  Does the compiler
produce really lousy code on (e.g.) PDPZM?  Can you show me that?

JG> If only FREQing
JG> was available to most of us. Unfortunately it's not. :(

PE> It is.  Dial 02-9436-1785 and download DEVIL*.* from file area 1.

JG> I have (did have?) the Devil program but the few attempts I've
JG> made to FREQ have been prevented because the systems would only
JG> allow it from node listed addresses.  

Well, I did say that you could FREQ RZSZPE and PDPZM from 3:711/934, which
DOES allow FREQs from unlisted systems, which means you CAN FREQ.

JG> Perhaps I just got unlucky
JG> with the systems I chose to call but there's no way I'm going to
JG> make more long distance calls only to find I won't get access to the
JG> files I'm after.  

STD phone calls are cheaper than local calls if they are less than 1 minute
in offpeak.

JG> Obviously this wouldn't be a problem if I was a sysop.

Or you didn't have any morals and went and changed the name + address in
your FREQ program to make it look like a nodelisted system.  :-)  Or if you
did have morals, and decided to use the 1:xxx/999 addresses that are in the
nodelist and set up for "new points".  Or just ask people when
they say it is available for FREQ, whether they accept FREQs from unlisted
systems.

BFN.  Paul.
@EOT:

---