🚀 go-pugleaf

RetroBBS NetNews Server

Inspired by RockSolid Light RIP Retro Guy

Article View: comp.sys.mac
Article #25772

Re: LightSpeed C 2.15 putchar fix,

#25772
From: Clive Steward
Date: Sun, 28 Feb 1988 23:36
65 lines
3597 bytes
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
Technical Details
Message-ID: <6852@drutx.ATT.COM>
Path: arc1-ca.pugleaf.net!utzoo!mnetor!uunet!lll-winken!lll-lcc!ames!hao!oddjob!gargoyle!ihnp4!homxb!mtuxo!mtgzz!drutx!clive
References: <174400103@uxc.cso.uiuc.edu>

Show Full Headers
Complete Article Headers
Path: arc1-ca.pugleaf.net!utzoo!mnetor!uunet!lll-winken!lll-lcc!ames!hao!oddjob!gargoyle!ihnp4!homxb!mtuxo!mtgzz!drutx!clive
From: clive@drutx.ATT.COM (Clive Steward)
Newsgroups: comp.sys.mac
Subject: Re: LightSpeed C 2.15 putchar fix,
Message-ID: <6852@drutx.ATT.COM>
Date: 28 Feb 88 23:36:01 GMT
References: <174400103@uxc.cso.uiuc.edu>
Organization: resident visitor
Lines: 64