 |
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Darren New <dne### [at] san rrcom> 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
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On 7/24/2011 3:22, Warp wrote:
> 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".
Probably.
--
Darren New, San Diego CA, USA (PST)
"Coding without comments is like
driving without turn signals."
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On 7/24/2011 3:22, Warp wrote:
> We are probably using a slightly different meaning for "surprised".
Actually, I'm more thinking this:
http://en.wikipedia.org/wiki/Principle_of_least_astonishment
--
Darren New, San Diego CA, USA (PST)
"Coding without comments is like
driving without turn signals."
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
> I said it's something someone who knows the hardware might […]
If you make assumptions about the hardware your program is running on
you're out of scope of C language.
Either you realy _know_ what your hardware _and_ your compiler do in the
current and will do in all future versions, or you better rely only on
the C language standard.
It is your choice. I prefere almost always the latter, except I have to
wirte platform-dependend code/optimizations etc.
L.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On 23/07/2011 06:13 PM, Darren New 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.)
More to the point, according to the C spec, NULL is not /required/ to
trap. Ever. The compiler is 100% free to make it do whatever it likes.
Which isn't especially surprising. The surprising thing is that you've
got code there explicitly to check for a null pointer, and the optimiser
may or may not end up removing it for you.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
> More to the point, according to the C spec, NULL is not /required/ to
> trap. Ever. The compiler is 100% free to make it do whatever it likes.
>
> Which isn't especially surprising. The surprising thing is that you've
> got code there explicitly to check for a null pointer, and the optimiser
> may or may not end up removing it for you.
It is not surprising if you _know_ C.
i.o.w. if it is surprising for you, your C knowledge are incomplete. ^^
L.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On 8/1/2011 4:13, Lars R. wrote:
> It is not surprising if you _know_ C.
> i.o.w. if it is surprising for you, your C knowledge are incomplete. ^^
Sure. It's also surprising when your leg disappears, simply because while
you know you're in a minefield, your knowledge of that minefield is incomplete.
That doesn't mean it's a *good* thing. Yes, it can be surprising even to
those who know C well enough to write an operating system kernel in it. The
whole "it's only surprising if you don't know it'll happen" tautology is
silly. The problem is that composing two perfectly valid statements makes an
invalid program that behaves completely differently than how you would
expect from each of those two statements separately.
--
Darren New, San Diego CA, USA (PST)
How come I never get only one kudo?
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Darren New <dne### [at] sanrrcom> wrote:
> That doesn't mean it's a *good* thing.
Nobody claimed it is. It's just something you have to live with if you
program in C (or its close variants).
> The problem is that composing two perfectly valid statements makes an
> invalid program that behaves completely differently than how you would
> expect from each of those two statements separately.
But you *can't* expect something specific to happen if you dereference
null (even if you do it "separately"). If you dereference null, *anything*
can happen (including the following code doing something completely different
than what you expect).
If you want derefercing null to do something special (which cannot be
written in C itself), you'll have to use some custom extension of the
programming language.
--
- Warp
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
