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

Some dark corners of C

docs.google.com

Post reply on HN
Print view View original

121–130 of 175 posts

Re: Some dark corners of C

#121

Post by Flimm »

pooriaazimi wrote: post #81
eliben wrote: post #37

Most of these "dark corners" have been in C for at least 25 years and have been repeated over an over for at least 20. My main take-away from this is that Google Drive seems like a nice way to put presentations online :-)

> My main take-away from this is that Google Drive seems like a nice way to put presentations online :-) Don't. I've been trying to access the presentation for 10 minutes and it won't allow me: Wow, this file is really popular! Some tools might be unavailable until the crowd clears. and then I get redirected to https://support.google.com/accounts/bin/answer.py?hl=en&... (which is stupid, because there's nothing cache…

For me, it works, but it makes each slide an entry in my browser's history, which I hate.

Re: Some dark corners of C

#122

Post by brigade »

arihant wrote: post #106

I am almost certain the pointer aliasing thing could be fixed by providing the proper optimization tag at compile time. I remember back in introductory systems classes, we saw mind boggling optimizations from GCC at O3 - the pointer example is so trivial it must be optimized by the compiler!

It isn't; there are very few flags that allow the compiler to perform optimizations not allowed by the language standard. Aliasing is not one of them for any compiler I know of. In fact, there are usually flags to go the opposite direction and assume all pointers alias because so many people write code that violates the standard (and results in GCC optimizing the code to behave differently than the author intended.)

Re: Some dark corners of C

#123

Post by taralx »

gsg wrote: post #99
tobinfricke wrote: post #38

Earlier quoted context omitted.

whoah - I find that construction astonishing. My gcc compiles it with only this warning: foo.c:2:6: warning: ‘main’ is usually a function [-Wmain] hah!

It won't execute though: [23] .got.plt PROGBITS 0804954c 00054c 000014 04 WA 0 0 4 [24] .data PROGBITS 08049560 000560 000010 00 WA 0 0 4 The main symbol is a relocation in .data, not .text. Which is as you would expect given that declaration. You might be able to get around that by doing something like unsigned char code[] = { 0xf0, 0x0f, 0xc7, 0xc8, 0xc3 }; int main(void) { ((void (*)())code)(); return 0; } But the…

Works if you add this line:

char main[] __attribute__((section(".text")));

(You get a warning from the assembler.)

Re: Some dark corners of C

#124

Post by qznc »

Flimm wrote: post #121
pooriaazimi wrote: post #81

Earlier quoted context omitted.

> My main take-away from this is that Google Drive seems like a nice way to put presentations online :-) Don't. I've been trying to access the presentation for 10 minutes and it won't allow me: Wow, this file is really popular! Some tools might be unavailable until the crowd clears. and then I get redirected to https://support.google.com/accounts/bin/answer.py?hl=en&... (which is stupid, because there's nothing cache…

For me, it works, but it makes each slide an entry in my browser's history, which I hate.

You can link to certain slides this way. I would consider this a good thing.

Re: Some dark corners of C

#125

Post by dakimov »

McUsr wrote: post #110
dakimov wrote: post #27

I don't get it. What will happen if you violate the language semantics? They call it 'dark corners'? If you hit your head against a wall, it will hurt. Is it a 'dark corner' of life? Overall, the presentation is very weak, like from a yesterday's graduate.

I am glad we all aren't experts like you then, some of the stuff I knew from before, some were really relieving. So I am glad it was posted, it helped, me, and this comment page was also, something to both smile/laugh and learn something from. Thanks

I see this site is read mainly by dumb ignorant children.

Screw this 'community'. It sucks ass.

Also, the design of this site is awful. And the engineering skills of the Mr. PG The Greatest apparently suck as well.

Re: Some dark corners of C

#126

Post by copx »

pcwalton wrote: post #75
copx wrote: post #2

It is telling that these "dark corners" all seem harmless compared to what you can find in certain other languages which shall not be named.

I'm not sure about that. Not using "restrict" properly can lead to extremely hard-to-diagnose errors which can only be resolved by reading the generated assembler. I've seen several C programs that use "restrict" everywhere as a magic "go faster" device without understanding what it means... The automatic conversions in JavaScript and PHP seem pretty harmless by comparison.

>Not using "restrict" properly can lead to extremely hard-to-diagnose errors

But "restrict" is a low-level micro-optimization, those tend to be tricky. I don't think a sane C programmer would sprinkle that keyword all across the source base, because as you have pointed out it can cause hard-to-diagnose errors.

In contrast, the automatic conversions in JavaScript and PHP are an "always on" feature you cannot avoid.

Re: Some dark corners of C

#127

Post by smackmybishop »

pooriaazimi wrote: post #81
eliben wrote: post #37

Most of these "dark corners" have been in C for at least 25 years and have been repeated over an over for at least 20. My main take-away from this is that Google Drive seems like a nice way to put presentations online :-)

> My main take-away from this is that Google Drive seems like a nice way to put presentations online :-) Don't. I've been trying to access the presentation for 10 minutes and it won't allow me: Wow, this file is really popular! Some tools might be unavailable until the crowd clears. and then I get redirected to https://support.google.com/accounts/bin/answer.py?hl=en&... (which is stupid, because there's nothing cache…

The right way to distribute slides is with the "published" presentation link, instead of a link to the editor.

Re: Some dark corners of C

#128

Post by Peaker »

dakimov wrote: post #42
lttlrck wrote: post #36

Earlier quoted context omitted.

Is banging your head against the wall violating the semantics of life?

Is my thought that complicated it needs additional explanation? By the way, I'm an expert C/C++ programmer, so my opinion matters.

A self-proclaimed expert, one must add.

Re: Some dark corners of C

#129

Post by graycat »

to3m wrote: post #96
graycat wrote: post #79

For "dark corners of C", when I was writing C code I had several serious concerns. Below I list eight such in roughly descending order on 'seriousness': First, what are malloc() and free() doing? That is, what are the details, all the details and exactly how they work? It was easy enough to read K&R, see how malloc() and free() were supposed to be used, and to use them, but even if they worked perfectly I was unsure…

I think C might make more sense if you are more familiar with assembly language. I learned C because real-mode x86 looked so fantastically ugly (looking back, a rare instance of youthful good taste). 0-terminated strings and stack allocation were quite familiar to me (though I never used stack allocation myself because it made the disassembly hard to read) and the overall model made perfect sense.

"I think C might make more sense if you are more familiar with assembly language."

I've written some assembler in the machine language of at least three different processors. On one machine I was surprised that my assembler code ran, whatever it was, 5-8 times faster than Fortran. Why? Because I made better use of the registers. Of course, that Fortran compiler was not very 'smart', and smarter compilers are quite good at 'optimizing' register usage. I will write some assembler again if I need it, e.g., for

R(n+1) = (A*R(n) + B) mod C

where A = 5^15, B = 1, and C = 2^47. Why that calculation? For random number generation. Why in assembler? Because basically want to take two 64 bit integers, accumulate in two registers the 128 bit product, then divide the contents of the two registers by a 64 bit integer and keep the 64 bit remainder. Due to the explicit usage of registers, usually need to do this in assembler.

But at one point I read a comment: For significantly long pieces of code, the code from a good compiler tends to be faster than the code from hand coded assembler. The explanation went: For longer pieces of code, good compilers do good things for reducing execution time that are mostly too difficult to program by hand which means that the assembler code tends to be using some inefficient techniques.

Re: Some dark corners of C

#130

Post by graycat »

scott_s wrote: post #120
graycat wrote: post #79

For "dark corners of C", when I was writing C code I had several serious concerns. Below I list eight such in roughly descending order on 'seriousness': First, what are malloc() and free() doing? That is, what are the details, all the details and exactly how they work? It was easy enough to read K&R, see how malloc() and free() were supposed to be used, and to use them, but even if they worked perfectly I was unsure…

If you ever program in C again, use valgrind to help debug your programs: http://valgrind.org/ It's particularly useful for bugs related to memory.

Thanks. I just made a note of that!

So, someone else dug into the details of how C manages memory and wrote some code to help people find problems; makes good sense.

Post reply on HN