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

41–50 of 175 posts

Re: Some dark corners of C

#41

Post by mjn »

Sharlin wrote: post #28
gjulianm wrote: post #3

#define struct union #define else That's evil. I have to do it in someone's code some day just to have some fun. But, apart from that, it's a really nice compilation. I didn't know about the compile time checks of array sizes, but I have a doubt. What if I pass to a method declared int foo(int x[static 10]) this pointer int* x = (int*) calloc(20, sizeof(int)); Does the compiler skip the check? Does it give me a warni…

Isn't re-#defining language keywords disallowed by the C standard? It's just that most compilers don't complain about it.

The C++ standard has a clause prohibiting macros that re-#define keywords if the translation unit also #includes a standard header. I guess this is to clarify whether the standard-library functionality is expected to still work even in the face of such a #define, by specifying that implementors don't need to worry about that situation.

I don't believe C has any such restrictions, though.

Re: Some dark corners of C

#42

Post by dakimov »

lttlrck wrote: post #36
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.

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.

Re: Some dark corners of C

#43

Post by caf »

gjulianm wrote: post #3

#define struct union #define else That's evil. I have to do it in someone's code some day just to have some fun. But, apart from that, it's a really nice compilation. I didn't know about the compile time checks of array sizes, but I have a doubt. What if I pass to a method declared int foo(int x[static 10]) this pointer int* x = (int*) calloc(20, sizeof(int)); Does the compiler skip the check? Does it give me a warni…

The purpose of

  int foo(int x[static 10])
is not to produce a warning - that's just a nice possible side-effect (and only in some cases).

The real purpose is to allow the compiler to optimise the compilation of the foo() function itself, under the assumption that x will always point to the first element of an array of at least 10 elements.

Re: Some dark corners of C

#44

Post by shaneeb »

Just like everything else programming languages have evolved. From Assembly to Fortran to C to Java/C# (just saying, no exact sequence implied). I dont think the languages we have now, far from perfection they may be, would have been possible without the "dark corners" in the older languages. We learnt from them and made better languages. So I say show respect to the old languages, learn from them and keep improving languages/tools... Everybody is happy.

Re: Some dark corners of C

#45

Post by caf »

lttlrck wrote: post #34
grn wrote: post #29

It's also worth pointing out that buffers passed to strcpy, memcpy, etc. must not overlap. Otherwise it results in undefined behavior .

That's stdlib though, not the language.

The standard library is part of the language - all hosted implementations must provide it.

This allows, for example, compilers to replace a `memcpy()` call that has a constant size argument with direct loads/stores.

Re: Some dark corners of C

#46

Post by norswap »

rwmj wrote: post #16
hamidr wrote: post #11

That's fun. Cause I remember this "x+++y;" as a question in one of my university entrance exams!

That sounds like a university to avoid.

It's necessarily a bad question, it makes you think about how parsers work.

But for an entrance exam, it's slightly hardcore :)

Re: Some dark corners of C

#47

Post by shaneeb »

jfim wrote: post #30
Eisk45 wrote: post #26

Earlier quoted context omitted.

Could someone explain to us newbies what the #define code does?...

It replaces the first word with what comes after. For example, #define foo bar is roughly equivalent to s/foo/bar/g, so #define else would just remove all else keywords. I'll let you guess what it does to a program.

Not to forget #define struct union which will pack all struct members together. Gives me chills even to think about it...

Re: Some dark corners of C

#48

Post by geon »

gngeal wrote: post #40
tobinfricke wrote: post #8

Earlier quoted context omitted.

The most egregious example in common usage: PHP. http://me.veekun.com/blog/2012/04/09/php-a-fractal-of-bad-de...

Hah, a nice article. :-) My favourite sentence from the PHP documentation: string create_function ( string $args , string $code ) "Creates an anonymous function from the parameters passed, and returns a unique name for it ." So there you are. Of course you can choose to be an anonymous value, but you'll get a name assigned by the state, for free. :-) Fascinating logic, captain.

In this case it isn't so weird, since PHP pre 5.3 didn't have first class functions. To pass a function around, you would use a variable containing a string of it's name.

create_function was a way to

A) not having to define a function separately

B) not getting problems with the function being re-defined, since each call would create a new function

C) fake closures by generating code.

All this should be moot points by now, since PHP has real anonymous functions with closures,

Re: Some dark corners of C

#49

Post by Sharlin »

matthiasv wrote: post #31
Sharlin wrote: post #28

Earlier quoted context omitted.

Isn't re-#defining language keywords disallowed by the C standard? It's just that most compilers don't complain about it.

The pre-processor is independent and a macro expanded before the C compiler sees it.

The preprocessor is a part of the standardized translation process, and if the standard says that certain things are not allowed in a well-formed C program, it does not matter at which stage the compiler is.

Re: Some dark corners of C

#50

Post by pilgrim689 »

shaneeb wrote: post #44

Just like everything else programming languages have evolved. From Assembly to Fortran to C to Java/C# (just saying, no exact sequence implied). I dont think the languages we have now, far from perfection they may be, would have been possible without the "dark corners" in the older languages. We learnt from them and made better languages. So I say show respect to the old languages, learn from them and keep improving…

We haven't all learned... https://www.destroyallsoftware.com/talks/wat :P
Post reply on HN