6 ms·

The trouble is often the listener thinks the speaker is pedantic when the speaker thinks there's a very legitimate problem the listener is ignoring. Since we're

The trouble is often the listener thinks the speaker is pedantic when the speaker thinks there's a very legitimate problem the listener is ignoring. Since we're using C(/C++) as an example, I'll take a bite out of the other page that just got re-posted today. [1] Is it "pedantic" to point out that &*p is undefined behavior if p is NULL? Or is it "pedantic" to point out that uint8_t isn't a substitute for unsigned char? Lots of people who see C as something resembling high-level assembly view arguments like this as pointless pedantry, often since they haven't really across cases where the distinction has mattered. Meanwhile those on the other side of the debate feel like they're not being heard and pull their hair out trying to get people to stick to the spec of the abstract machine rather than that of their hardware, because they think (rightly or wrongly) the next compiler version will likely break their code if the existing ones already haven't. [1] https://news.ycombinator.com/item?id=22848423 https://news.ycombinator.com/item?id=22848423

specialist 7y ago
Ya. Your example makes me think of error tolerances, uncertainty, fuzz factors. Sometimes precision really matters. FWIW, If you were reviewing my code, I'd readily adopt your method, if only to expedite convergence on a common understanding, and to signal I appreciate the input.
projektfu 7y ago
You’re on the other side of the table from the pedant in OP. You’d be responding to someone saying “It’s easy to avoid UB in C.” Meanwhile, you grep a couple popular projects and show trivially that accidental UB is extremely common in most codebases. The pedant in OP is saying, “you don’t need the guarantees provided in Rust because a careful C programmer can avoid UB, memory errors, etc.”
ludamad 7y ago
Is it possible they would be served by a different standard where C is a high-level assembly? Although admittedly, "&*p" to me reads as 'load p' and therefore undefined behaviour
- edflsafoiewq 7y ago
  The literal sequence "&*E" is actually equivalent to E even when E is a null pointer. The spec explicitly points this out.
  - lonelappde 7y ago
    Why does the spec mandate support for useless bad code instead of banning it?
    - majewsky 7y ago
      1. Probably backwards-compatibility. 2. While you wouldn't write &*E by hand, it can easily arise from a macro expansion.
    - Ericson2314 7y ago
      `E` is an lvalue --- a location that only becomes a load/store when it is converted to an rvalue or assigned to. `&` takes an lvalue and gives a pointer to that location, so `E` is eliminated without being converted to an rvalue or assigned to, so no harm done. The real question if why have "lvalues" at all. If assignment always had to have a pointer on the left hand: &a := ..., b := ... rather than: a = ..., , *b = ... then this problem goes away.
  - mehrdadn 7y ago
    Oh man, I wrote that as a shorthand for something like int& v = *p; foo(&v)... is there a difference in that case (C++ I guess)? I thought it was always illegal to dereference null pointers regardless of the specific token sequence or whether it's C or C++.
    - edflsafoiewq 7y ago
      Yeah, I thought that's what you meant. C++ doesn't special case &٭. C didn't before C99 either I think. It's not the exact token sequence actually; &(٭E) does the same thing.
mannykannot 7y ago
I love the way this would be just as good an example for the original article as those actualy given.
- mistermann 7y ago
  To me, this demonstrates how one can completely understand something at the abstract level, but so easily "forget" when working at the object level, even when the object level discussions are related to an article about the abstract concept. The various forms of communication between humans are chock full of opportunities for error, and I doubt there's many people that would deny it, but when a conversation is occurring at the object/instance level, and an instance of one of these abstract errors occur, enthusiasm for acknowledging it generally seems to have diminished significantly. I think it would be incredibly useful if we could find a way to overcome this issue, kind of like error correction in TCP, but for human communication, or even discuss the notion. Might it be interesting and fun, and maybe even yield practically useful ideas, if now and then HN was to experiment with taking an instance of one of these abstract problems we discuss every day (this one, nuclear power, climate change, wealth disparity, political polarization, etc), and rather than having our normal casual conversations (the contents of which often appear in thread after thread), instead approach it from an engineering perspective, crowdsourcing various ideas for both the diagnosis/analysis of the problem, as well as solutions (including implementation, where possible)?
  - mistermann 7y ago
    @dang -2, again. Is this not getting a little bit ridiculous? Pray tell, what guidelines have I violated this time, while everyone else is behaving perfectly fine? Shall we continue to ignore the elephant in the room? It's fine by me, I actually get a kick out of it.
    - btrask 7y ago
      "The various forms of communication between humans are chock full of opportunities for error." Don't let it get you down.

specialist 7y ago

Ya. Your example makes me think of error tolerances, uncertainty, fuzz factors. Sometimes precision really matters. FWIW, If you were reviewing my code, I'd readily adopt your method, if only to expedite convergence on a common understanding, and to signal I appreciate the input.

projektfu 7y ago

You’re on the other side of the table from the pedant in OP. You’d be responding to someone saying “It’s easy to avoid UB in C.” Meanwhile, you grep a couple popular projects and show trivially that accidental UB is extremely common in most codebases. The pedant in OP is saying, “you don’t need the guarantees provided in Rust because a careful C programmer can avoid UB, memory errors, etc.”

ludamad 7y ago

Is it possible they would be served by a different standard where C is a high-level assembly? Although admittedly, "&*p" to me reads as 'load p' and therefore undefined behaviour

edflsafoiewq 7y ago
The literal sequence "&*E" is actually equivalent to E even when E is a null pointer. The spec explicitly points this out.
- lonelappde 7y ago
  Why does the spec mandate support for useless bad code instead of banning it?
  - majewsky 7y ago
    1. Probably backwards-compatibility. 2. While you wouldn't write &*E by hand, it can easily arise from a macro expansion.
  - Ericson2314 7y ago
    `E` is an lvalue --- a location that only becomes a load/store when it is converted to an rvalue or assigned to. `&` takes an lvalue and gives a pointer to that location, so `E` is eliminated without being converted to an rvalue or assigned to, so no harm done. The real question if why have "lvalues" at all. If assignment always had to have a pointer on the left hand: &a := ..., b := ... rather than: a = ..., , *b = ... then this problem goes away.
- mehrdadn 7y ago
  Oh man, I wrote that as a shorthand for something like int& v = *p; foo(&v)... is there a difference in that case (C++ I guess)? I thought it was always illegal to dereference null pointers regardless of the specific token sequence or whether it's C or C++.
  - edflsafoiewq 7y ago
    Yeah, I thought that's what you meant. C++ doesn't special case &٭. C didn't before C99 either I think. It's not the exact token sequence actually; &(٭E) does the same thing.

mannykannot 7y ago

I love the way this would be just as good an example for the original article as those actualy given.

mistermann 7y ago
To me, this demonstrates how one can completely understand something at the abstract level, but so easily "forget" when working at the object level, even when the object level discussions are related to an article about the abstract concept. The various forms of communication between humans are chock full of opportunities for error, and I doubt there's many people that would deny it, but when a conversation is occurring at the object/instance level, and an instance of one of these abstract errors occur, enthusiasm for acknowledging it generally seems to have diminished significantly. I think it would be incredibly useful if we could find a way to overcome this issue, kind of like error correction in TCP, but for human communication, or even discuss the notion. Might it be interesting and fun, and maybe even yield practically useful ideas, if now and then HN was to experiment with taking an instance of one of these abstract problems we discuss every day (this one, nuclear power, climate change, wealth disparity, political polarization, etc), and rather than having our normal casual conversations (the contents of which often appear in thread after thread), instead approach it from an engineering perspective, crowdsourcing various ideas for both the diagnosis/analysis of the problem, as well as solutions (including implementation, where possible)?
- mistermann 7y ago
  @dang -2, again. Is this not getting a little bit ridiculous? Pray tell, what guidelines have I violated this time, while everyone else is behaving perfectly fine? Shall we continue to ignore the elephant in the room? It's fine by me, I actually get a kick out of it.
  - btrask 7y ago
    "The various forms of communication between humans are chock full of opportunities for error." Don't let it get you down.