 |
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On 7/24/2011 3:22, Warp wrote:
> Darren New<dne### [at] san rrcom> 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
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On 8/1/2011 9:30, Warp wrote:
> Nobody claimed it is. It's just something you have to live with if you
> program in C (or its close variants).
Yes, I understand that.
> But you *can't* expect something specific to happen if you dereference
> null (even if you do it "separately").
I know that too. I really do completely understand the problem. It's exactly
why I'd say that maybe C or its close variants aren't good for a new user.
I'm merely pointing out that "it isn't surprising if you already know it's
going to happen" combined with "you should know it's going to happen because
you need to understand the detailed rules of every single operation possible
to write a program that silently doesn't do something good" combines to make
"I only know a little bit" a bad choice.
> If you dereference null, *anything*
> can happen (including the following code doing something completely different
> than what you expect).
And it's not just dereferencing null. It's any of the undefined behaviors
which can lead to the compiler doing very unintuitive things if you're not
aware of the rule.
--
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:
> > If you dereference null, *anything*
> > can happen (including the following code doing something completely different
> > than what you expect).
> And it's not just dereferencing null. It's any of the undefined behaviors
> which can lead to the compiler doing very unintuitive things if you're not
> aware of the rule.
OTOH "undefined behavior" also allows for the compiler to, for example,
add sanity checks and issue clear runtime errors when these kinds of errors
happen.
Some compilers actually do this with a bunch of undefined behavior
situations when compiling in debug mode. However, it's a rather curiously
rare thing to do. I have been wondering why C/C++ compilers don't have a
"super-debug mode" where *everything* that can possibly go wrong is checked
(if it can be physically checked), completely regardless of how slow the
program becomes. A bit like a "builtin valgrind" (but which adds even more
checks which the compiler can do because it can see the source code). Only
few C/C++ compilers have anything even resembling this, and usually in a
relatively limited form (ie. the debugging mode doesn't even do all the
same checks as valgrind does).
Maybe it's a question of complexity vs. demand, or something.
--
- Warp
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On 8/1/2011 10:50, Warp wrote:
> Maybe it's a question of complexity vs. demand, or something.
Also compatibility, I think. To check whether you're using a stray pointer,
you'd have to store more than the pointer, which means void* might change
size, which breaks anything precompiled you link to.
Interestingly, too, I read that Microsoft has an "Application Verifier" that
does things like intentionally initializing stack frames to random garbage
(rather than leaving whatever's there), and they find many people don't test
under the "application verifier" because it breaks too much of their code.
(For example, a lot of the "application compatibility shims" fix stuff the
application verifier would have detected had they used it.)
There used to be lint, which would seem to address the complaint that "it
would slow down the compiler." I guess it's easier to just make it flags
nowadays rather than maintain a separate program, tho.
I suspect 99% of the people writing code are writing code that doesn't get
used in any application but their own, so they write it, test it, it seems
to work well, they release the executable. It's a lot harder to get
libraries like boost or openssl or whatever working on every compiler in
every environment.
--
Darren New, San Diego CA, USA (PST)
How come I never get only one kudo?
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
