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

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



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.”


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.


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


The literal sequence "&*E" is actually equivalent to E even when E is a null pointer. The spec explicitly points this out.


Why does the spec mandate support for useless bad code instead of banning it?


1. Probably backwards-compatibility.

2. While you wouldn't write &*E by hand, it can easily arise from a macro expansion.


`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.


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++.


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.


I believe C++ does special-case that, as *foo when foo is an empty lvalue and it’s trying to assign that to an rvalue that is undefined.


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


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)?


@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.


"The various forms of communication between humans are chock full of opportunities for error." Don't let it get you down.


Oh, it doesn't get me down at all, quite the opposite. It's not myself I'm worried about, it's broader mankind.

Take my suggestion at the end - does it not seem odd in the slightest that one of the highest concentrations of powerful minds on the internet seems to be more interested in complaining and pointing fingers, little different than any other social media site, rather than trying something new?

How bizarre do things have to get on this planet before a little curiosity starts to form about how we got where we are today, and if perhaps there's something HN could do to get us out?




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

Search: