-=> On 19 Sep 96  04:52:00 <=-
-=> Paul Edwards was heard to tell John Gardeniers <=-

    Hi Paul,

 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");


 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.

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

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

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

 JG> One thing I've noticed in the C echos, which I've never come
 JG> across elsewhere, is the way the standards are virtually a religion
 JG> for some (a few) of you.  I'm sure glad nothing like that has ever

 PE> The result people like me are after, is to be able to write programs,
 PE> without being tied down to one platform.  Right at the moment I am
 PE> using OS/2.  I used to be using MSDOS.  Soon I will probably be using
 PE> Linux.  I also use the Amiga and C64.  At work, I use Unix (SunOS),
 PE> but have also used MVS, VMS, VM.  Most of my programs will port to any
 PE> of these environments.  I turn up to a job will all my tools.

    I recognise the importance of portability but also recognise
it's problems.  Essentially, most cases a program written with the
emphasis on portability will not be as efficient as one written
specifically for the target machine.  I must say that this may not
generally be all that significant these days, which faster CPUs,
more memory and larger hard drives, but all those years with 8 bit
computers has left me with a very different approach to programming
than what is taught these days.  I *still* spend time to trim the
odd byte here and there.

 JG> There are a number of factors to consider here.  The fact that I
 JG> don't have a C compiler (any variant) for the Commodores seems to be
 JG> a fairly important point :) On the Commodores, especially the C64,

 PE> Can't you scrounge one up from somewhere?  Surely you want one?

    At this late stage (as far as the Commodores are concerned) I
really doubt that it's worth the trouble.  Besides, I am far more
comfortable with my assembler on those machines.  By writting the
machine specific routines seperately to the common code it'll be
easy enough to assemble the various version of the program.

 PE> What you are talking about above is your comms routines, not the
 PE> Zmodem routines.  I want to know why you would rewrite the Zmodem
 PE> routines in assembler.

    The run-time overheads of a high level language are just too
much for something like the C64.  The best I've been able to acheive
(reliably) so far is 2400bps by using new IRQ routines (not my own).
Bearing in mind that in my application the data being transfered
must be either read from, or written to, disk (1541) by the time the
protocol overheads are taken into account there's just no time left
to spare.

 JG> As I'm getting way off topic here I'm wondering two things.  Who
 JG> is the moderator of this echo and when were the rules last posted?

 PE> There is no moderator that anyone has ever heard of.  The rules are:
    Runs remarkably well for an unmoderated echo.

 PE> 1. Everyone should write ISO-conforming code or get told off.
    But, but but...

 PE> 2. No-one should criticize ISO.
    Oops!

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

 JG> I can't recall seeing the rules at all, although I've only been
 JG> reading this echo for about eight months ;)

 PE> You're meant to read between the lines.
    Now I've got you!  On *my* BW reader I notice some rather
interesting stuff about K&R while reading between the ANSI lines.  I
wonder if anyone has written K&R.SYS to replace ANSI.SYS?

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

        John

... Please write your complaint legibly in that box -->[].
--- FMail/386 1.02