[comp.sys.mac] LightSpeed C 2.15 putchar fix,

dorner@uxc.cso.uiuc.edu (02/24/88)

My apologies to the uninterested; this discussion probably belongs in
comp.lang.C, but I don't like the spread of misinformation in comp.sys.mac.

>Nontheless, I think it's very important that this usage and the reasons 
>be well understood, not glossed over with the 'most C compilers promote
                         ^^^^^^^^^^^^           ^^^^^^^^^^^^^^^^
>passed char arguments to ints anyway'.  VERY bad practice to depend on
                                         ^^^^^^^^^^^^^^^^^
>anything of the sort; it's the sort of foolishness that makes people
>hate C and its programmers.  And it's completely un-necessary.  
>Makes a lot more sense just to do things right.

As I pointed out before, this is *HOGWASH*.  K&R specifically guarantee the
behavior, and not as a quirk, but as in integral part of the language.
All chars in expressions are widened to ints!  As K&R point out, this
is marvellous behavior.  Since function arguments (like just about
everything else in C) are expressions, chars in them are widened to ints.

>When you get to C++, the world changes again, and though some
>promotions remain, and others are added, there is a real mire pit
>waiting if you try to make things work by such 'inner' details.
>Trust me on this one.

Since I don't use C++, I'll have to trust you.  But if it is different
from C in such a fundamental manner, I'm not sure I will ever use C++.

>Declare and use data types consistently, is an easy and enjoyable way.

No argument there.

>Clive Steward
----
Steve Dorner, U of Illinois Computing Services Office
Internet: dorner@uxc.cso.uiuc.edu  UUCP: ihnp4!uiucuxc!dorner
IfUMust:  (217) 333-3339

clive@drutx.ATT.COM (Clive Steward) (02/29/88)

From article <174400103@uxc.cso.uiuc.edu>, by dorner@uxc.cso.uiuc.edu:
> 
> ..., but I don't like the spread of misinformation in comp.sys.mac.
> 
Dear Mr. Dorner.

You are very correct.  K&R does say that chars are promoted to ints.

However, correctness by itself, in the real world, doesn't often seem too 
close to whatever godliness may be.

As a fact, this condition is true.  As principle, it's a not a good one.
Except it was convenient.  Personal opinion, as the article you answered 
was labelled.  I'll support this now, then move on.

It's quite so that in the example -- putc (the_char_or_int), the 
conversion happens.  I'm sure you understand that it won't work in the 
reverse direction at all -- the_char_or_int = getc () is a failure waiting 
to happen, and one I have had to teach novices about for about 10 years. 
(For those who don't know about this, getc returns an int, so that the 
result can represent either a char value or a non-char-valued flag (EOF) 
if the read fails.  You check this, then use the result as a char if it'
s valid.  It would be nice if this were all there was to worry about.)

This is the main point I was trying to get across, for the benefit of
those to whom C and the Unix stdio interface are new.  I guess I don't
particularly appreciate the usefulness of perpetrating unclear principles,
when there's an easier way.  There may be some, though.

As you may be aware, the original (and some through S5V2) Unix and its 
accessories (cpp is a glaring example which comes to mind) contained
numerous non-too-sanitary programming practices.  Among them the
infamous playing fast and loose between pointers and integers.  Quite
possibly, the (good) programmers of this time weren't used yet to the
concepts, and used older ones.  As, a memory location is a memory
location.  Isn't it?  But unfortunately, the 'promotion' concept
doesn't work at all for long <-> int, or int <-> pointer.

It seems we all have benefited greatly from (moderated doses) of clearer
principles, and languages which can express (C, C++), yet don't force
(Pascal) them.

Let me assure that C++, as an upward compatible maturing of C, continues to 
support the promotional behaviour.  So anyone will be protected, as long as 
they like to work that way.

However, C++ also allows one to construct sensible rules of one's own, 
based on actual data (object) types.  Inside the objects, one can take
care of all nasty problems, and present a clean interface, regardless
of what the underlying situation is.  It does work, and it's
surprisingly fun.

It might be well to express clearly that I have nothing to do with C++
except to use it, with pleasure and often, as a consultant to a completely
different area of the company on whose premises it is being developed.
This only because I can't erase the ATT.COM from my return signature.

I'm very sure I'm not a computer scientist in any good standing either.

Should I go on.  Not the least from the British Isles, despite my name.
A long time from college, enough to take pleasure in being neither old
nor young.  The most fun seems learning, and what can be done with it.


Clive Steward