Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

Here is a link to the several times this has appeared here: https://news.ycombinator.com/from?site=jroweboy.github.io

I find these "hey there is this language called C and you can do some really weird stuff in it!" articles humorous because from the beginning of time there have been people who are fascinated by this aspect of the C language and gave rise to the whole obfuscated C contest thing.

The idea that a symbol references an address and its type is only a convenience in the source code always messes people up. When I've taught C to people there is always that one person who says "What if you cast a string pointer to a function and called it! Huh?" and I explain that is perfectly legal C and has been exploited for years and you can practically see their brain change conceptual planes in mid-air :-)



I like to start with the assembler, then just tell people that high level languages are fancy assemblers. Some of them restrict you to using the designer's favourite macros, some of them allow you to build on highly general tools at approximately the lowest level, but ultimately all computer programming languages are fancy macro assembler syntaxes.


This is an OK mental model until a wholly compliant C or C++ compiler blows it all to smithereens with an optimization exploiting UB.

You gotta write C or C++ for the abstract machine defined by the standards. Thinking about C in terms of some concrete assembly language or architecture can be problematic.


> "What if you cast a string pointer to a function and called it! Huh?" and I explain that is perfectly legal C

I would argue that it's less than "perfectly" legal: The C standard lists it as a "common extension":

  J.5.7 Function pointer casts 
  A pointer to an object or to void may be cast to a pointer to 
  a function, allowing data to be invoked as a function
And on a practical level, it seems to me that the increasing proliferation of NX enforcement is cramping the acceptance of this extension.


That's a good point, but the long running (although shrinking) gap between what the standard recommends, vs. what you can do with real compilers is one of the reasons that coding in C can be so error-prone.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: