 |
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
http://blog.llvm.org/2011/05/what-every-c-programmer-should-know.html
http://blog.llvm.org/2011/05/what-every-c-programmer-should-know_14.html
http://blog.llvm.org/2011/05/what-every-c-programmer-should-know_21.html
...OK, I'm scared. o_O
--
http://blog.orphi.me.uk/
http://www.zazzle.com/MathematicalOrchid*
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Orchid XP v8 <voi### [at] dev null> wrote:
> http://blog.llvm.org/2011/05/what-every-c-programmer-should-know.html
> http://blog.llvm.org/2011/05/what-every-c-programmer-should-know_14.html
> http://blog.llvm.org/2011/05/what-every-c-programmer-should-know_21.html
> ...OK, I'm scared. o_O
Why?
--
- Warp
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
>> ...OK, I'm scared. o_O
>
> Why?
A language where the language spec specifically allows you to optimise
away bounds checks, null checks and so forth in the name of performance?
Yeah, sounds fairly scary to me.
Not having these things automatically is one thing. Automatically
removing them when the programmer explicitly added them is another. And
apparently even the "experts" get surprised by this behaviour, so...
--
http://blog.orphi.me.uk/
http://www.zazzle.com/MathematicalOrchid*
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Orchid XP v8 <voi### [at] devnull> wrote:
> >> ...OK, I'm scared. o_O
> >
> > Why?
> A language where the language spec specifically allows you to optimise
> away bounds checks, null checks and so forth in the name of performance?
> Yeah, sounds fairly scary to me.
If you access first and check bounds afterwards, that's kind of a bit
late, don't you think? That's the whole point. If you access before making
the bounds check, then the compiler can assume that the checking is useless.
(The check won't do anything useful because the accessing has already been
made by that point, so the check won't retroactively make it work.)
If you make the check first, and only then access based on that, then the
compiler cannot make the assumption.
> Not having these things automatically is one thing. Automatically
> removing them when the programmer explicitly added them is another. And
> apparently even the "experts" get surprised by this behaviour, so...
Well, if the code is accessing out of boundaries, there's a bug. If there's
such a bug, the compiler is free to do whatever it likes. There's nothing
surprising about that.
--
- Warp
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On 7/23/2011 7:59, Warp wrote:
> If you access first and check bounds afterwards, that's kind of a bit
> late, don't you think?
In the first example, he reads, then checks, then writes, and it's not
unreasonable to think that he's ensuring the write isn't out of bounds
because the read is harmless. (Yes, there are still architectures where
*NULL does not trap.)
> Well, if the code is accessing out of boundaries, there's a bug. If there's
> such a bug, the compiler is free to do whatever it likes. There's nothing
> surprising about that.
It is to a large number of people who work with safe languages. :-) Even
more surprising to people who work with languages where having an index out
of bounds doesn't even make sense, let alone be "a bug".
--
Darren New, San Diego CA, USA (PST)
"Coding without comments is like
driving without turn signals."
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Darren New <dne### [at] sanrrcom> wrote:
> On 7/23/2011 7:59, Warp wrote:
> > If you access first and check bounds afterwards, that's kind of a bit
> > late, don't you think?
> In the first example, he reads, then checks, then writes, and it's not
> unreasonable to think that he's ensuring the write isn't out of bounds
> because the read is harmless. (Yes, there are still architectures where
> *NULL does not trap.)
But there are many architectures where dereferencing null will trap,
which is why the C standard does not want to force it either way (in
other words, it does not want to force compilers to add a check to each
dereferencing to see if it's dereferencing null, and then either cause
an abort() or some other defined behavior).
If dereferencing null is normal in a certain architecture, then compilers
made for that architecture should take that into account (which the standard
fully allows, obviously).
(As always, this is a compromise between efficiency and safety. If the
standard said "thou shalt not dereference null, or you'll be abort()ed",
then every single pointer and array access would become slower.)
> > Well, if the code is accessing out of boundaries, there's a bug. If there's
> > such a bug, the compiler is free to do whatever it likes. There's nothing
> > surprising about that.
> It is to a large number of people who work with safe languages. :-) Even
> more surprising to people who work with languages where having an index out
> of bounds doesn't even make sense, let alone be "a bug".
Then these people either have to learn C properly, or not use it.
It really is a case of "take it or leave it".
--
- Warp
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On 7/23/2011 10:36, Warp wrote:
> But there are many architectures where dereferencing null will trap,
Yes, I know that. :-)
> If dereferencing null is normal in a certain architecture,
I didn't say it's normal. I said it's something someone who knows the
hardware might expect and thus be surprised by the compiler deleting
completely different code.
If I compiled something like that first version for a Z-80, I can easily
believe I would be surprised if that code ever wrote to the interrupt
vector. I'm not criticizing C. I'm simply saying it's reasonable to be
surprised. :-)
> Then these people either have to learn C properly, or not use it.
> It really is a case of "take it or leave it".
Yes. I'm simply pointing out to people who know C very well why it would be
that people who don't know it very well might be surprised. Heck, code like
that wound up in the Linux kernel, so I think it's save to say "it sometimes
surprises even experts", yes?
--
Darren New, San Diego CA, USA (PST)
"Coding without comments is like
driving without turn signals."
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Darren New <dne### [at] sanrrcom> wrote:
> > Then these people either have to learn C properly, or not use it.
> > It really is a case of "take it or leave it".
> Yes. I'm simply pointing out to people who know C very well why it would be
> that people who don't know it very well might be surprised. Heck, code like
> that wound up in the Linux kernel, so I think it's save to say "it sometimes
> surprises even experts", yes?
But wasn't it a bug, rather than an intentional "trick" which the
programmers didn't realize would trigger undefined behavior?
--
- Warp
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On 7/23/2011 10:51, Warp wrote:
> Darren New<dne### [at] sanrrcom> wrote:
>>> Then these people either have to learn C properly, or not use it.
>>> It really is a case of "take it or leave it".
>
>> Yes. I'm simply pointing out to people who know C very well why it would be
>> that people who don't know it very well might be surprised. Heck, code like
>> that wound up in the Linux kernel, so I think it's save to say "it sometimes
>> surprises even experts", yes?
>
> But wasn't it a bug, rather than an intentional "trick" which the
> programmers didn't realize would trigger undefined behavior?
Yes. It was a bug caused by the programmer not knowing a null pointer check
would not wind up in the object code, because they accessed the pointer
first. I.e., it was pretty much exactly the contains_null_check code on the
second link.
I.e., I'm pretty sure anyone committing code to the Linux kernel "knows C
properly." It really is a surprising language. Saying "real programmers
never make this sort of mistake" is a no-true-scotsman argument.
I'm not saying anything is *wrong* with C or the decisions the standards
committee made. Just that expressing surprise that it's as tricky as it is
doesn't imply you're ignorant. "Real programmers think C isn't surprising,
because if you're surprised by C, it means you're not a real programmer."
--
Darren New, San Diego CA, USA (PST)
"Coding without comments is like
driving without turn signals."
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Darren New <dne### [at] sanrrcom> wrote:
> I'm not saying anything is *wrong* with C or the decisions the standards
> committee made. Just that expressing surprise that it's as tricky as it is
> doesn't imply you're ignorant. "Real programmers think C isn't surprising,
> because if you're surprised by C, it means you're not a real programmer."
We are probably using a slightly different meaning for "surprised".
Everybody makes errors, and sometimes those errors happen because you
don't know the language well enough. The error would be a surprise if you
make that latter kind of error, and you have never heard of that feature
before, so it catches you by surprise. It's not a surprise if you already
knew about that language feature, but didn't realize it comes into play in
a complex piece of code. (The difference would be that after you resolve
the situation you think "ah, true, it indeed is that language feature
kicking in", so it's doesn't surprise you, rather than "I didn't know that
feature even existed".)
--
- Warp
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
|
|
