Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

The truth about C and Unix history

rutschle.net

Post reply on HN
Print view View original

21–30 of 78 posts

Re: The truth about C and Unix history

#21

Post by caf »

pjmlp wrote: post #17
Yacoby wrote: 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.

It's been defined ever since the original ANSI C, which said this in the definition of free():

  If ptr is a null pointer, no action occurs.

Re: The truth about C and Unix history

#22

Post by caf »

thaumaturgy wrote: post #6

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…

Pascal sort of lives on in Oracle's PL/SQL, which if not a lineal descendent is definitely at least a cousin.

Re: The truth about C and Unix history

#23

Post by masklinn »

pjc50 wrote: post #19
pjmlp wrote: post #17

Earlier quoted context omitted.

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.

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

Which does not matter because all of them clearly define the behavior of free(NULL). The language has been the same since C89[0]:

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

I'm guessing pjmlp confused free(NULL) which is defined and double free which is UB:

> if the argument does not match a pointer earlier returned by the calloc , malloc , or realloc function, or if the space has been deallocated by a call to free or realloc , the behavior is undefined.

and didn't "bother to read the ANSI C specification" because he was so certain of what he misremembered.

[0] http://port70.net/~nsz/c/c89/c89-draft.html#4.10.3.2

Re: The truth about C and Unix history

#24

Post by anatoly »

cbd1984 wrote: post #15
doctorwho wrote: post #12

Earlier quoted context omitted.

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 o…

That's an amazing story, thanks! This is the place where it catches the fault: http://minnie.tuhs.org/cgi-bin/utree.pl?file=V7/usr/src/cmd/...

Re: The truth about C and Unix history

#25

Post by thret »

pjc50 wrote: post #18
mojuba wrote: post #10

Earlier quoted context omitted.

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.

I've been using mainly Python lately and I still find it weird. I miss my {} and ;.

Re: The truth about C and Unix history

#26

Post by copsarebastards »

mojuba wrote: post #10
thaumaturgy wrote: post #6

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…

> The proof being that none of the more or less serious languages created in the past few decades dared to adopt e.g. begin ... end again.

facepalm Except Ruby, OCaml, Erlang, Lua, etc.

Frankly, if verbosity is a significant limiting factor on your creativity, a) C is not the solution to your problem, and b) you weren't trying to solve any hard problems anyway.

Seriously, if you're doing anything really hard, stuff like thread management and algorithmic complexity is a way bigger limiting factor than minor syntactic differences.

Re: The truth about C and Unix history

#29

Post by pjmlp »

masklinn wrote: post #23
pjc50 wrote: post #19

Earlier quoted context omitted.

Wrong, it's defined: http://stackoverflow.com/questions/6084218/is-it-good-practi... You didn't say which version of the ANSI C specification.

> You didn't say which version of the ANSI C specification. Which does not matter because all of them clearly define the behavior of free(NULL). The language has been the same since C89[0]: > 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. I'm guessing pjmlp confused free(NULL) which is defined and doub…

> and didn't "bother to read the ANSI C specification" because he was so certain of what he misremembered.

Yes, it appears my recollections of ANSI C have faded away.

Re: The truth about C and Unix history

#30

Post by mojuba »

merrua wrote: post #13
mojuba wrote: post #10

Earlier quoted context omitted.

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.

Essentially Ruby does only `end` and so does e.g. the Unix shell. I still prefer { } because it stands out in the text better.

I should have mentioned verbosity in declarations too, it's not just begin ... end.

And I do miss a few of Pascal's neat features, such as using an enum type as an array index type.

Post reply on HN