PE> It issues warnings.  Even ISO C programs have warnings issued, for all
PE> sorts of things, on different compilers.  A common one is if you go:
PE> if (c = 0) printf("xyz");
JG> 

PE> Because most likely you meant "c == 0".  It is confusing
to the person
PE> reading your code too.  Normally you would go ((c = func()) == 0) to
PE> avoid the warning and make it obvious what you are doing.

JG> Slight confusion here.  You used the "if (c = 0)
printf("xyz");"
JG> as an example in your message, it didn't come from me :)

I know.  You were the one who was saying it's OK to write code like that,
and I was saying why it's OK for compilers to warn about it.

JG> 1989 is pretty recent when you stop to think about it.  I

PE> Not in terms of how long it takes vendors to get out compilers. You
PE> may notice that C compilers exist on any machine you can buy today
PE> (new).

JG> Let's face it, by the time they get most of the major bugs
JG> ironed out they are about the same age anyway.

If you write portable code, a bug in one compiler, is a non-issue in another.

JG> I recognise the importance of portability but also recognise
JG> it's problems.  Essentially, most cases a program written with the
JG> emphasis on portability will not be as efficient as one written
JG> specifically for the target machine.  I must say that this may not

Depends what you're talking about.  If you're writing straight C code doing
pointer manipulation etc, as is the case with the core zmodem stuff, then
you'll likely only get faster if you go to assembler, not alter your C
code.

JG> generally be all that significant these days, which faster CPUs,
JG> more memory and larger hard drives, but all those years with 8 bit
JG> computers has left me with a very different approach to programming
JG> than what is taught these days.  I *still* spend time to trim the
JG> odd byte here and there.

Well that is a situation where you don't actually have any choice. Assuming
you've inspected the code generated by the C compiler and determined it to
be inadequate.

JG> The run-time overheads of a high level language are just too
JG> much for something like the C64.  

You would probably find that the generated 6502 code is good enough.  You
just need to use the code, and forget about the runtime library stuff that
deals with opening files etc.

PE> 3. Everyone should quote from the ISO spec when making points.
JG> Is it just me, or do these "rules" appear just very slightly
JG> biased? :)

It's just you.  Everyone else thinks those rules are perfectly OK.

JG> I suppose I'm probably as devoted to efficient code (in this
JG> context meaning the maximum work from the smallest, fastest code) as
JG> you are to the ANSI (notice I won't say ISO?) standards.  Perhaps
JG> the world is even large enough to cope with both K&R *and* ANSI, so
JG> long as we don't try to turn one into another.  Remember, some
JG> people program in Basic and *they* don't get told off :)

I am also concerned with efficient code, but I always use a profiler first,
and then attempt to keep it in C all the way.  The bottleneck may or may
not be improved by changing from C to assembler, but if it can be, then
it's probably just a few lines of assembler required. Which of course, is
conditionally compiled in, so that people who don't have, or can't use, the
assembler you have, can still run the program. BFN.  Paul.
@EOT:

---