Live data from Hacker News

The truth about C and Unix history

rutschle.net

11–20 of 78 posts

Re: The truth about C and Unix history

#11
post #2

I must confess that for a moment you got me there. https://www.gnu.org/fun/jokes/unix-hoax.html

It seems that the GNU version slightly differs from the OP. It includes a joke on IBM RS-6000 and their virtual machine, and have different spellings (Nichlaus vs. Niklaus, AT&&T vs. AT&T). I wonder which one precedes.

Re: The truth about C and Unix history

#12

This particular April Fool's joke goes back at least 30 years. I remember getting a chuckle out of it a long time ago. For context for younger readers, it might be worth pointing out that there was for a while a sort of rivalry between C and Pascal adherents. C was the more "modern" and "professional" language, while Pascal was a "teaching" language (or so some of the arguments went). Windows was coded in C, while Ma…

All the Pascal fanboys did this (and worse) before they gave in and finally converted :)

#define begin {

#define end }

Re: The truth about C and Unix history

#13
post #10

This particular April Fool's joke goes back at least 30 years. I remember getting a chuckle out of it a long time ago. For context for younger readers, it might be worth pointing out that there was for a while a sort of rivalry between C and Pascal adherents. C was the more "modern" and "professional" language, while Pascal was a "teaching" language (or so some of the arguments went). Windows was coded in C, while Ma…

You could have called me a "Pascal devotee" back then, but I had eventually come to realize verbosity kills creativity and dumped Pascal for good. This { int a[10]; ... } wins over this begin var A: array[0..9] of Integer; ... end; quite simply because the latter takes longer to both read and write. The proof being that none of the more or less serious languages created in the past few decades dared to adopt e.g. beg…

ruby does begin, end. But maybe you were joking? ruby does ommit where it can though.

Re: The truth about C and Unix history

#14

This particular April Fool's joke goes back at least 30 years. I remember getting a chuckle out of it a long time ago. For context for younger readers, it might be worth pointing out that there was for a while a sort of rivalry between C and Pascal adherents. C was the more "modern" and "professional" language, while Pascal was a "teaching" language (or so some of the arguments went). Windows was coded in C, while Ma…

All the Pascal fanboys did this (and worse) before they gave in and finally converted :) #define begin { #define end }

By worse do you mean?

    #define new(x) (malloc(sizeof(x)))
    #define dispose(x) { if((x) != NULL) { free(x); } }
C was so primitive already when compared against Turbo Pascal 6.0

Re: The truth about C and Unix history

#15

This particular April Fool's joke goes back at least 30 years. I remember getting a chuckle out of it a long time ago. For context for younger readers, it might be worth pointing out that there was for a while a sort of rivalry between C and Pascal adherents. C was the more "modern" and "professional" language, while Pascal was a "teaching" language (or so some of the arguments went). Windows was coded in C, while Ma…

All the Pascal fanboys did this (and worse) before they gave in and finally converted :) #define begin { #define end }

The source code to the original Bourne shell did that and a lot worse. It became one of the inspirations for the IOCCC (International Obfuscated C Code Competition).

http://www.ioccc.org/faq.html

(What that FAQ doesn't mention is the real reason the Bourne shell deserved to be in the IOCCC: The way it allocated memory. It trapped SIGSEGV (the signal the kernel sends you when you've provoked a segmentation violation or segfault by trying to access memory you don't own) so it would know when to request more RAM from the OS. This later became a problem for people looking to port the Bourne shell, for example to the Motorola 68000 CPUs which powered the first generation of Unix workstations.

http://www.in-ulm.de/~mascheck/bourne/segv.html )

Re: The truth about C and Unix history

#16
post #14

Earlier quoted context omitted.

All the Pascal fanboys did this (and worse) before they gave in and finally converted :) #define begin { #define end }

By worse do you mean? #define new(x) (malloc(sizeof(x))) #define dispose(x) { if((x) != NULL) { free(x); } } C was so primitive already when compared against Turbo Pascal 6.0

Totally worse. free(NULL) preforms no action so there is no requirement for the if statement. ;)

Re: The truth about C and Unix history

#17
post #16
post #14

Earlier quoted context omitted.

By worse do you mean? #define new(x) (malloc(sizeof(x))) #define dispose(x) { if((x) != NULL) { free(x); } } C was so primitive already when compared against Turbo Pascal 6.0

Totally worse. free(NULL) preforms no action so there is no requirement for the if statement. ;)

Except free(NULL) behavior is undefined.

Have you ever bothered to read ANSI C specification?

EDIT: Well it appears my recollections of ANSI C have faded away and free(NULL) was actually defined in ANSI C89.

Re: The truth about C and Unix history

#18
post #10

This particular April Fool's joke goes back at least 30 years. I remember getting a chuckle out of it a long time ago. For context for younger readers, it might be worth pointing out that there was for a while a sort of rivalry between C and Pascal adherents. C was the more "modern" and "professional" language, while Pascal was a "teaching" language (or so some of the arguments went). Windows was coded in C, while Ma…

You could have called me a "Pascal devotee" back then, but I had eventually come to realize verbosity kills creativity and dumped Pascal for good. This { int a[10]; ... } wins over this begin var A: array[0..9] of Integer; ... end; quite simply because the latter takes longer to both read and write. The proof being that none of the more or less serious languages created in the past few decades dared to adopt e.g. beg…

And Python dumped even the { }; you can now pile any number of scope closings into a single newline.

Re: The truth about C and Unix history

#19
post #17
post #16

Earlier quoted context omitted.

Totally worse. free(NULL) preforms no action so there is no requirement for the if statement. ;)

Except free(NULL) behavior is undefined. Have you ever bothered to read ANSI C specification? EDIT: Well it appears my recollections of ANSI C have faded away and free(NULL) was actually defined in ANSI C89.

Wrong, it's defined: http://stackoverflow.com/questions/6084218/is-it-good-practi...

You didn't say which version of the ANSI C specification.

Re: The truth about C and Unix history

#20
post #17
post #16

Earlier quoted context omitted.

Totally worse. free(NULL) preforms no action so there is no requirement for the if statement. ;)

Except free(NULL) behavior is undefined. Have you ever bothered to read ANSI C specification? EDIT: Well it appears my recollections of ANSI C have faded away and free(NULL) was actually defined in ANSI C89.

> Except free(NULL) behavior is undefined.

> Have you ever bothered to read ANSI C specification?

You mean the one that states

> The free function causes the space pointed to by ptr to be deallocated, that is, made available for further allocation. If ptr is a null pointer, no action occurs.

?

Post reply on HN