6 ms·

I would argue that C's problem is not that it's too strictly defined, but that it's too poorly defined. An in-depth look into all the cases of undefined behavio

I would argue that C's problem is not that it's too strictly defined, but that it's too poorly defined. An in-depth look into all the cases of undefined behavior in C will show what I mean. You want to really understand C? Read this[0]. John really understands C. [0] http://blog.regehr.org/ http://blog.regehr.org/

groby_b 14y ago
Can't upvote this enough. Well, except that I'd replace "poorly" with "vaguely". "Implementation-defined behavior" is there for very good reasons in every single case it's there. Sidenote: With John's name, I'd be tempted on a daily basis to change the last two letters of my name to a single 'x' ;)
- georgeorwell 14y ago
  You mean like this? $ whoami | sed 's/hr/xx/'
  - eru 14y ago
    No, he meant: $ whoami | sed 's/hr$/x/'
    - georgeorwell 14y ago
      I think you mean: $ echo "$PARENT" | sed 's_r/x_r$/_' P.S. It's a bit hard to believe I misread that... thanks.
      - eru 14y ago
        My sed knowledge isn't very advance. What is your invocation supposed to do?
        dbaupp 14y ago
        You can use any separator you want in an s/../../ expression, not just /, in this case the separator is _ (this technique allows you to use / without creating a "picket fence": s/r\/x/r$\//). So the regex just means replace "r/x" with "r$/".
      - dbaupp 14y ago
        Random tip: in Bash (at least), you can execute the previous command with some changes using ^..^..^, e.g. $ echo john regehr | sed s/hr/xx/ john regexx $ ^r/x^r$/^ echo john regehr | sed s/hr$/x/ john regex (The second last line is just bash printing the new command.)
    - groby_b 14y ago
      Minor nit: She meant :)
mikeash 14y ago
I'd argue that there's a big distinction between C as described in the standard and C as actually used in real-world code, and the latter has much stricter semantics and is harder to work with. A C compiler that follows the standard but not the implied conventions won't do well. For example, take NULL. Even on a machine with no concept of NULL, you could easily emulate it by allocating a small block of memory and having the pointer to that block be designated as "NULL". This would be perfectly compliant with the standard, but it will break all of the code out there that assumes that NULL is all zero bits (e.g. that calloc or memset(0) produce pointers whose values contain NULL). Which is a lot of code. I'm sure that many other examples can be found.

groby_b 14y ago

Can't upvote this enough. Well, except that I'd replace "poorly" with "vaguely". "Implementation-defined behavior" is there for very good reasons in every single case it's there. Sidenote: With John's name, I'd be tempted on a daily basis to change the last two letters of my name to a single 'x' ;)

georgeorwell 14y ago
You mean like this? $ whoami | sed 's/hr/xx/'
- eru 14y ago
  No, he meant: $ whoami | sed 's/hr$/x/'
  - georgeorwell 14y ago
    I think you mean: $ echo "$PARENT" | sed 's_r/x_r$/_' P.S. It's a bit hard to believe I misread that... thanks.
    - eru 14y ago
      My sed knowledge isn't very advance. What is your invocation supposed to do?
      - dbaupp 14y ago
        You can use any separator you want in an s/../../ expression, not just /, in this case the separator is _ (this technique allows you to use / without creating a "picket fence": s/r\/x/r$\//). So the regex just means replace "r/x" with "r$/".
    - dbaupp 14y ago
      Random tip: in Bash (at least), you can execute the previous command with some changes using ^..^..^, e.g. $ echo john regehr | sed s/hr/xx/ john regexx $ ^r/x^r$/^ echo john regehr | sed s/hr$/x/ john regex (The second last line is just bash printing the new command.)
  - groby_b 14y ago
    Minor nit: She meant :)

mikeash 14y ago

I'd argue that there's a big distinction between C as described in the standard and C as actually used in real-world code, and the latter has much stricter semantics and is harder to work with. A C compiler that follows the standard but not the implied conventions won't do well. For example, take NULL. Even on a machine with no concept of NULL, you could easily emulate it by allocating a small block of memory and having the pointer to that block be designated as "NULL". This would be perfectly compliant with the standard, but it will break all of the code out there that assumes that NULL is all zero bits (e.g. that calloc or memset(0) produce pointers whose values contain NULL). Which is a lot of code. I'm sure that many other examples can be found.