How can a string by accidently modified?

[Richard Heathfield]

Gordon Burditt said:

I presume this programmer also ends his functions like this:

return x;
return x;
return x;

Or just:

quit:
return x;
return x;
goto quit;

This will eventually slow the program down enough that it will notice the
return statement.

Um, I wish I were joking. I think it was Wilf Hey, in PC Plus magazine a few
(or a few dozen?) years ago, who related the time when a colleague of his
did exactly this kind of "HALT : HALT : GOTO TOP" thing, and for this very
reason. I don't think Wilf was making it up.

 

[Chuck F.]

.... snip ...

Um, I wish I were joking. I think it was Wilf Hey, in PC Plus
magazine a few (or a few dozen?) years ago, who related the time
when a colleague of his did exactly this kind of "HALT : HALT :
GOTO TOP" thing, and for this very reason. I don't think Wilf
was making it up.

Quite reasonable. The system has a push button, marked 'continue',
or the equivalent. This will force the operator to push it at
least twice before carrying on.

--
"If you want to post a followup via groups.google.com, don't use
the broken "Reply" link at the bottom of the article. Click on
"show options" at the top of the article, then click on the
"Reply" at the bottom of the article headers." - Keith Thompson
More details at: <http://cfaj.freeshell.org/google/>

 

[Chuck F.]

I have tried the NULL pointer for the parameter of printf("%s",
s) on both HP-UX 11 and Win2k and the results are different:

You are invoking undefined behaviour. There is absolutely no
reason to expect them to act the same. The system could launch
Arnold wielding a scimitar to cut off your head, or other
quasi-important body parts.

--
"If you want to post a followup via groups.google.com, don't use
the broken "Reply" link at the bottom of the article. Click on
"show options" at the top of the article, then click on the
"Reply" at the bottom of the article headers." - Keith Thompson
More details at: <http://cfaj.freeshell.org/google/>

 

[lovecreatesbeauty]

You are invoking undefined behaviour. There is absolutely no
reason to expect them to act the same. The system could launch
Arnold wielding a scimitar to cut off your head, or other
quasi-important body parts.

Thanks for your kind reminding me. I made it for an example.

 

[Niklas Matthies]

You are invoking undefined behaviour. There is absolutely no
reason to expect them to act the same. The system could launch
Arnold wielding a scimitar to cut off your head, or other
quasi-important body parts.

I think the standard should mandate this useful behavior.

-- Niklas Matthies

 

[Mark McIntyre]

On Tue, 17 Jan 2006 07:12:28 +0000 (UTC), in comp.lang.c , Richard

(of always initialising auto variables)

Well, ok, but...

A: ensure that, no matter what mistakes might be made in the rest of the
function, the behaviour of the program (with respect to this object at
least) will be determinate.

It was determinate before. It only becomes indeterminate if some
maintenance droid uses the object without initalising it. Which will
be detected by the compiler options you're using, right? Right?

B: who knows what the maintenance guys will do here?

But one never knows this. The droids could for instance create a new
scope, move the loop inside it, lazily add a new uninitialised
identically named variable in it and voila, the carefully constructed
paper tiger is blown away.

C: ensure that, no matter what the maintenance guys did in section B,
WellChosenObjectName has the right value at the start of this loop.

This bit I agree with.

Mark McIntyre

 

[Mark McIntyre]

On 2006-01-17 08:11, Chuck F. wrote:

I think the standard should mandate this useful behavior.

Actually, its documented here, about half way down. Search for NULL.

http://dspace.dial.pipex.com/town/green/gfd34/art/bloopers.html

Mark McIntyre

 

[Gordon Burditt]

Um, I wish I were joking. I think it was Wilf Hey, in PC Plus magazine a few

(or a few dozen?) years ago, who related the time when a colleague of his
did exactly this kind of "HALT : HALT : GOTO TOP" thing, and for this very
reason. I don't think Wilf was making it up.

Depending on the machine, a HALT instruction may drop through to
the next instruction after an interrupt which returns to the HALT
instruction. It might also drop through if someone presses a
CONTINUE or SINGLE STEP switch on the front panel (remember those?)

This is unlike the C statement "return", which isn't ever supposed
to drop through (but might anyway due to rampant overclocking of
CPUs).

Gordon L. Burditt

 

[Douglas A. Gwyn]

... snip about printf("%s", NULL) ...
You are looking at it solely from a debugging viewpoint. On the
other hand, it is highly preferable to save volatile data than to
crash because some meaningless display had no data with which to
update. The "(null)" display can also serve as a debugging aid.

This debate recurs in many contexts.
Both sides have valid points.
Personally I come down on the side of,
"the library is not responsible for correcting bugs".

 

[Gordon Burditt]

... snip about printf("%s", NULL) ...

This debate recurs in many contexts.
Both sides have valid points.
Personally I come down on the side of,
"the library is not responsible for correcting bugs".

I come down on the side of "the library is responsible for embarassing
the author of code like printf("%s", NULL)". Or getting him fired
or killed.

Although the requirements are locale-specific, in the USA the output
should include all 7 of the FCC's Seven Deadly Words, preferably
repeated an infinite number of times. In Iraq under Saddam, it
should probably make some nasty comments about Saddam's mother and
a camel - and mail the comments directly to Saddam.

Gordon L. Burditt

 

[Richard Heathfield]

Mark McIntyre said:

On Tue, 17 Jan 2006 07:12:28 +0000 (UTC), in comp.lang.c , Richard

(of always initialising auto variables)

Well, ok, but...


It was determinate before. It only becomes indeterminate if some
maintenance droid uses the object without initalising it. Which will
be detected by the compiler options you're using, right? Right?

Not necessarily. It depends on the compiler. Not all compilers are as
obliging as we'd like them to be in this regard.

But one never knows this.

Indeed. So one takes reasonable precautions, and perhaps just one or two
unreasonable precautions. To prevent every maintenance-introduced bug is
impossible, but this doesn't mean we shouldn't try to prevent the ones that
are easy to prevent.

 

[Mark McIntyre]

Mark McIntyre said:


Not necessarily. It depends on the compiler. Not all compilers are as
obliging as we'd like them to be in this regard.

Richard, you're clutching at straws now, and you know it

Its only UB if you access the uninitialised object.

Mark McIntyre

 

[Richard Heathfield]

Mark McIntyre said:

Richard, you're clutching at straws now, and you know it

No, sir. We just operate in different environments.

Its only UB if you access the uninitialised object.

Yes, and I've seen that happen. Twice. On neither occasion was it caught by
testing. On each occasion it failed in production.

Never again.

 

[Richard Bos]

If a bug in your program causes it to generate a null pointer where a null
pointer wasn't expected, there's a good chance that you'll end up saving
garbage and overwriting some good data. Or perhaps a lot of good data,
especially if the "(null)" output is going to a file rather than to the
display. And even more so if it's treated as an empty string rather than
"(null)". A crash might prevent that or at least minimize the damage.

In addition, an empty string is quite likely to go unnoticed until it's
too late. "(null)" is better, because it's unlikely to be normal data
and will therefore be noticed earlier. Just do _not_ ask me about users
who notice unusual data _and_don't_bloody_tell_me_. Argh.

Richard

 

[kuyper]

You trimmed Richard's quotation of your own previous message, removing
the following sentence:

The trimming you did gives the impression that the following response
referred to your first sentence. However, I believe he was actually
responding to your second sentence, the one that you trimmed.

Richard, you're clutching at straws now, and you know it

Are you suggesting that there's no one, anywhere, who's stuck using a
compiler that fails to perform such checking? As I read Richard's
comments, he's claiming that he, at least, is indeed stuck with such a
compiler, and I know of no reason to disbelieve him.

 

[Richard Heathfield]

(e-mail address removed) said:

Are you suggesting that there's no one, anywhere, who's stuck using a
compiler that fails to perform such checking? As I read Richard's
comments, he's claiming that he, at least, is indeed stuck with such a
compiler, and I know of no reason to disbelieve him.

I am /sometimes/ stuck with such compilers, yes. Not always, thank heaven.
But because I am /sometimes/ stuck with such compilers (and also because I
sometimes don't know, when writing code, which compiler(s) will be used to
compile it), I adopt defensive coding strategies as a matter of course, on
the principle that it takes me less effort to think about these things when
I have to, if I adopt them as habits even when I don't have to. This frees
up a useful quantity of cluons for other purposes.