Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss

Dennis Ritchie, RIP

63 views
Skip to first unread message

Derek M. Jones

unread,
Oct 13, 2011, 7:51:10 AM10/13/11
to
All,

Dennis Ritchie, the inventor of C and author of
"The C programming language" died over the weekend.

http://www.theregister.co.uk/2011/10/13/dennis_ritchie/

Geoff Clare

unread,
Oct 13, 2011, 8:31:20 AM10/13/11
to
Derek M. Jones wrote:

I kept one of his posts to this group that tickled me.
Here it is for those who weren't around back then (1999) or
who don't remember it:

| From: Dennis Ritchie <dmr@.........>
| Newsgroups: comp.std.c
| Subject: Re: Integer Sizes?
| Date: Thu, 02 Dec 1999 03:19:41 +0000
|
| Someone (well, OK, Nick) wrote:
|
| > ... No, that is not the issue. You clearly have not thought of the
| > problem of handling external data formats, which was the rationale
| > for introducing the exact-width data types in the first place.
| >
| > A device driver or external file data object of 32 bits long will
| > contain those bits in a certain order. There is no requirement for
| > that to be the same order that is used by C...
| >
| > The matter of byte ordering is too well-known to go into details;
| > it is common for the external value 1 when loaded as a uint32_t
| > to be 16777216. I have used systems where both big-endian and
| > little-endian bit orders WITHIN A BYTE were possible....
|
| Maybe by the time of the C0X standard, things will be pinned
| down well enough that it will become possible actually to
| write a TCP/IP stack, or conceivably an entire operating
| system in C. One might even imagine that it runs on several
| different machine architectures. A hope for the new milennium.
|
| Dennis

--
Geoff Clare <net...@gclare.org.uk>

Keith Thompson

unread,
Oct 13, 2011, 1:04:16 PM10/13/11
to

Something similar, posted here in 1998:

| > You are right. It was nice back in the days when things like
| >
| > #if (sizeof(int) == 8)
| >
| > actually worked (on some compilers).
|
| Must have been before my time.
|
| Dennis

--
Keith Thompson (The_Other_Keith) ks...@mib.org <http://www.ghoti.net/~kst>
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"

James Kuyper

unread,
Oct 13, 2011, 6:16:41 PM10/13/11
to

A number of mainstream media web sites have this story by now, but I
found that many of the articles describe him as the original author of
the "hello, world" program. I've no personal knowledge of the truth of
this, but Wikipedia's article
<http://en.wikipedia.org/wiki/Hello,_world> credits Brian Kernighan. It
also shows a rather scary predecessor of that program, from a 1972
tutorial for B:

main( ) {
extrn a, b, c;
putchar(a); putchar(b); putchar(c); putchar('!*n');
}
a 'hell';
b 'o, w';
c 'orld';

I have several questions about this code.

The reliance upon implicit int is clear, at least to those of us who
started programing C well before the ANSI standard. Is 'extrn' a typo,
or was the keyword spelled differently in B? Was '*n' was a predecessor
to '\n'? Apparently initialization of a variable did not require an '='?
Character constants containing multiple characters are permitted even in
modern C, though the meaning is implementation-defined. What did they
mean in B?

In modern C, no matter what value is passed to putchar(), no more than a
single character would be written; the above code seems to be written
with the expectation that four putchar() calls would produce output
containing 14 characters (including the newline character). How did that
work?

Ben Bacarisse

unread,
Oct 13, 2011, 10:36:27 PM10/13/11
to
James Kuyper <james...@verizon.net> writes:

> On 10/13/2011 07:51 AM, Derek M. Jones wrote:
>> All,
>>
>> Dennis Ritchie, the inventor of C and author of
>> "The C programming language" died over the weekend.
>>
>> http://www.theregister.co.uk/2011/10/13/dennis_ritchie/
>
> A number of mainstream media web sites have this story by now, but I
> found that many of the articles describe him as the original author of
> the "hello, world" program. I've no personal knowledge of the truth of
> this, but Wikipedia's article
> <http://en.wikipedia.org/wiki/Hello,_world> credits Brian Kernighan. It
> also shows a rather scary predecessor of that program, from a 1972
> tutorial for B:
>
> main( ) {
> extrn a, b, c;
> putchar(a); putchar(b); putchar(c); putchar('!*n');
> }
> a 'hell';
> b 'o, w';
> c 'orld';
>
> I have several questions about this code.
>
> The reliance upon implicit int is clear, at least to those of us who
> started programing C well before the ANSI standard.

B is (was?) typeless so there is no implicit int. Everything is a
machine word.

> Is 'extrn' a typo,
> or was the keyword spelled differently in B?

No, that's how it was spelt.

> Was '*n' was a predecessor
> to '\n'?

Yes. That comes directly from BCPL.

> Apparently initialization of a variable did not require an '='?

Yup. In fact = was not permitted in extrn initialisations.

> Character constants containing multiple characters are permitted even in
> modern C, though the meaning is implementation-defined. What did they
> mean in B?

They were reasonably well-defined. putchar('abcd'); had to print an 'a'
and then a 'b' and so on. The number of permitted characters in one
word obviously depended on the machine, and that determined how many
characters you can have in a character constant.

> In modern C, no matter what value is passed to putchar(), no more than a
> single character would be written; the above code seems to be written
> with the expectation that four putchar() calls would produce output
> containing 14 characters (including the newline character). How did that
> work?

putchar does not print zero bytes. The bytes are right-aligned, so the
call putchar('!*n'); is the same as putchar('*0*0!*n'); but putchar
always ignores zero bytes so you'd get the same output from
putchar('!*0*n*0'); for example. putchar also ignores ASCII EOT which
it used to terminate strings in B (EOT is written *e).

--
Ben.

0 new messages