🗣 Things Our Customers Have Said About Discourse Thread
-
-
I don't always use Discourse
But when I do, I'm the only one to get a working User Story out of it.
-
This is really bad form, but fuck it:
http://what.thedailywtf.com/t/this-500-business-is-not-even-funny-anymore/47937/3?u=raceprouk
-
-
-
-
Fucking dicsauce Cooties ate my image upload .
<If you give a fox a wingsuit, does that make it a bat?
-
[quote=Codinghorror]
This was never intended to "work", so it would be a feature request.
[/quote]
-
-
TIL 0 == 1.
Sometimes, yes. The required conditions are extremely rare and unlikely, but suppose the code is comparing a 0 to some variable (which in our case, we'll suppose is storing a 1) somewhere that is not stored in the CPU's cache so it makes a RAM call. While that happens, a cosmic ray happens to hit the CPU at just the right point to alter the compare instruction's data from a 0 to a 1. Eventually it retrieves the variable 1 from RAM, does the comparison using the altered radioactive version of the original instruction, and it returns TRUE.
-
The required conditions are extremely rare and unlikely
Not as unlikely as you might think, especially as feature sizes are shrunk.
-
@nightware said:
Zero was never intended to mean zero.
TIL 0 == 1.
@nightware said:
Zero was never intended to mean zero.
TIL 0 == 1.
What, never worked with modulo 1 arithmetics?
-
Boomzilla risks memory-hole-ification.
-
I am crazy like that. No response yet, but it's still there.
-
-
I am crazy like that. No response yet, but it's still there.
It hasn't gone yet
<Also, you're welcome re: the ;)
-
It is, after all, a 'Nice Post.'
-
it was so nice that sam fixed zero after all.
-
-
-
Many people would hate C, but they just can't be bothered. It's too hard. And none of the hate libraries work cross-platform.
-
-
Would discourse be better or worse if written in C?
Neither, dischorse is not so much a code problem as it is a design problem.
I was referring to the NULL=0;
-
-
Thought you might - was more clarifying for those that might not know C, since your question redirected the train of thought to a decidedly less dischorsistent place.
-
I would hate to see a Markdown parser in pure C.
-
-
I was referring to the NULL=0;
Isn't that a platform dependant implementation detail?
-
Sort of; the null pointer constant is defined as zero, but the null pointer value is defined by the compiler; the compiler may target an architecture where zero isn't all zero bits.
-
And that's why you're not supposed to mix them...
-
Standards compliant, fast, secure markdown processing library in C
what standards? last time i checked there were about a bazillion standards
-
what standards? last time i checked there were about a bazillion standards
Any one you want that might be relevant.
-
And that's why you're not supposed to mix them...
Yeah, pretty much my point. I never, ever trust the assertion that
NULL == 0
. It probably is. It probably will be on every system I ever try it on. But still.Shit can get weird with that stuff. So I'll rather just use the constant and not rely on it's equality to anything but itself, thanks.
-
Yeah, pretty much my point. I never, ever trust the assertion that NULL == 0. It probably is. It probably will be on every system I ever try it on. But still.
In C (and C++) it's guaranteed to be true (in a pointer context).
What isn't is:
int* i; memset(&i, 0, sizeof i); if (i == 0 /* or NULL*/){ printf("This is not guaranteed to be printed\n"); }
i.e. when the compiler comes across 0 (in a pointer context) or NULL, it translates it into its own internal representation of what NULL is. Which, as the program snipped above is trying to demonstrate, may not be all-bits-zero.
However, using NULL when another type of zero (integer 0, floating point 0,
'\0'
) is required is unwise.
-
Which, as the program snipped above is trying to demonstrate, may not be all-bits-zero.
But you probably aren't using one of the machines where it is false. Seriously.
What's definitely varying substantially between systems is whether it is impossible to write to a NULL pointer. Desktop, mobile and server systems tend to enforce that sort of restriction, embedded much less likely.
-
But you probably aren't using one of the machines where it is false. Seriously.
Agreed, it's highly unlikely that this would ever be a problem.
Dunno, maybe it's years of PHP and JavaScript that make me paranoid about weird edge cases.
-
What's definitely varying substantially between systems is whether it is impossible to write to a NULL pointer.
Given that attempting to write to it is undefined behaviour, they're all technically correct.
Which I seem to remember someone round here saying is the best kind of correct....
-
Would he be the elderly gentleman with the mustache and the desk that flies?
-
Given that attempting to write to it is undefined behaviour
It's undefined in the C Standard. A particular platform ABI might well define it.
-
-
A particular platform ABI might well define it.
But it's still undefined in the C standard. If any part of your program exhibits undefined behaviour, the whole program is undefined, not just 'the little bit that did it.'
For example Raymond demonstrates how a compiler, when presented with - and knowledgable about - undefined behaviour, is perfectly within its rights to reduce the following code
void unwitting(bool door_is_open) { if (door_is_open) { walk_on_in(); } else { ring_bell(); // wait for the door to open using the fallback value fallback = value_or_fallback(nullptr); wait_for_door_to_open(fallback); } }
to
void unwitting(bool door_is_open) { walk_on_in(); }
That's long before the ABI, of which the C Standard knows nothing about.
Long post, short,
value_or_fallback()
induces undefined behaviour, thus it, and anything calling it, can be ignored.
-
Long post, short,
value_or_fallback()
induces undefined behaviour, thus it, and anything calling it, can be ignored.That may be a likely result for certain types of undefined behaviour, but certainly not the only allowable one.
-
But it's still undefined in the C standard.
The C standard has several different notions of what is permitted and what isn't. You're talking about the case where the system has deduced that a particular part of the code is unreachable. (Strictly, if it also knows that
ring_bell()
doesn't return, it wouldn't produce that reduction.) However, that a zero pointer is not correctly writable is something that is determined by the platform: if it is, the optimisation that you describe is itself unsafe, and it would be a compiler bug for it to be used.Whatever the C standard says, there are platforms where writing to a zero pointer is a required capability.
-
However, that a zero pointer is not correctly writable is something that is determined by the platform
Not if you're writing C code. Attempting to write to it is the UD here, not the ultimate result of the attempt.
BTW, the example given by Raymond is only one possibility by the way - don't get hung up on it being the only thing that could happen.
Another (more likely, of course) is that it'll simply try and do what you asked.
SIGSEGV
is a common response and the UD collapses into a broken program which the customers complain about.And is the situation you allude to in the bit I quoted above.
-
You're talking about the case where the system has deduced that a particular part of the code is unreachable
Or when the system has deduced that that code path involved UB and so the program is just as correct ignoring it as attempting to execute it. That's the point of undefined behaviour, the compiler can do WTF it wants
-
Or when the system has deduced that that code path involved UB and so the program is just as correct ignoring it as attempting to execute it.
But my point is that what is actually UB is platform-dependent, and must be so. Once you know what is UB given the C Standard and the target platform (which acts as a profile on the standard), you can determine what optimisations are safe to apply. (There are some that are always safe, but changing access-through-nullptr to unreachable isn't one of them.)
-
I got called a dick at work for using that phrase
-
-
-
@loopback0 said:
I got called a dick at work
That would be technically correct now, wouldn't it?
Back too OOP school for you: has-a vs is-a.