How can a string by accidently modified?

[Chad]

Given the following code that achieves no useful purpose:

#include <string.h>
#include <stdio.h>
#include <string.h>

int manip(char *str) {

size_t len = strlen(str)-1;
if(len >= 3) {
str[0] = 'A';
str[1] = 'B';
printf("The length of the string is: %d\n", len);
}
else {
return -1;
}
}

int main(int argc, char **argv){

if(argc !=2){
fprintf(stderr,"Not enough arguements\n");
exit(1);
}

manip(argv[1]);
printf("The modified value is: %s\n",argv[1]);

argv[1] = NULL;
printf("The new modified value is: %s\n",argv[1]);

return 0;
}

I really don't know how to word this in any graceful way. Please bear
with this. How is it possible to accidently modify the string in
argv[1]? I can maybe see something like malloc() returning NULL, then
maybe like having this value be passed to manip(), but other than that,
really see this.

Thanks in advance
Chad

[Walter Roberson]

In article <11**********************@g49g2000cwa.googlegroups .com>,
Chad <cd*****@gmail.com> wrote:

argv[1] = NULL;
printf("The new modified value is: %s\n",argv[1]);

Passing a NULL pointer for a %s format has undefined results.
--
All is vanity. -- Ecclesiastes

[Chad]

Walter Roberson wrote:

In article <11**********************@g49g2000cwa.googlegroups .com>,
Chad <cd*****@gmail.com> wrote:

argv[1] = NULL;
printf("The new modified value is: %s\n",argv[1]);

Passing a NULL pointer for a %s format has undefined results.
--
All is vanity. -- Ecclesiastes

But still didn't answer the question.

[pemo]

"Chad" <cd*****@gmail.com> wrote in message
news:11**********************@g49g2000cwa.googlegr oups.com...

Given the following code that achieves no useful purpose:

#include <string.h>
#include <stdio.h>
#include <string.h>

int manip(char *str) {

size_t len = strlen(str)-1;
if(len >= 3) {
str[0] = 'A';
str[1] = 'B';
printf("The length of the string is: %d\n", len);
}
else {
return -1;
}
}

int main(int argc, char **argv){

if(argc !=2){
fprintf(stderr,"Not enough arguements\n");
exit(1);
}

manip(argv[1]);
printf("The modified value is: %s\n",argv[1]);

argv[1] = NULL;
printf("The new modified value is: %s\n",argv[1]);

return 0;
}

I really don't know how to word this in any graceful way. Please bear
with this. How is it possible to accidently modify the string in
argv[1]? I can maybe see something like malloc() returning NULL, then
maybe like having this value be passed to manip(), but other than that,
really see this.
Not sure what your question is? What do you expect this code to do?

What's the use of this ...?
argv[1] = NULL;
printf("The new modified value is: %s\n",argv[1]);

manip doesn't return [explicitly] a value if len >= 3. But, as you don't
use the function's returned value, I'm guessing that this is what's
surprising you?

[Vladimir S. Oka]

Chad wrote:

Walter Roberson wrote:

In article <11**********************@g49g2000cwa.googlegroups .com>,
Chad <cd*****@gmail.com> wrote:

argv[1] = NULL;
printf("The new modified value is: %s\n",argv[1]);

Passing a NULL pointer for a %s format has undefined results.
--
All is vanity. -- Ecclesiastes

But still didn't answer the question.

In a very c.l.c way, he did. Passing NULL pointer to printf() invokes
undefined behaviour or, in other words, _anything_ can happen
(including, but not limited to, demons flying out of your nose).

Cheers

Vladimir
--
My e-mail address is real, and I read it.

[Jordan Abel]

comp.std.c added

On 2006-01-15, Vladimir S. Oka <no****@btinternet.com> wrote:

Chad wrote:

Walter Roberson wrote:

In article <11**********************@g49g2000cwa.googlegroups .com>,
Chad <cd*****@gmail.com> wrote:

argv[1] = NULL;
printf("The new modified value is: %s\n",argv[1]);
Passing a NULL pointer for a %s format has undefined results.
--
All is vanity. -- Ecclesiastes

But still didn't answer the question.

In a very c.l.c way, he did. Passing NULL pointer to printf() invokes
undefined behaviour or, in other words, _anything_ can happen
(including, but not limited to, demons flying out of your nose).

Anyone know why the behavior of printing "(null)" for this never got
standardized, considering that it dates back to unix v7?

[Jack Klein]

On 16 Jan 2006 01:09:29 GMT, Jordan Abel <ra*******@gmail.com> wrote
in comp.lang.c:

comp.std.c added

On 2006-01-15, Vladimir S. Oka <no****@btinternet.com> wrote:

Chad wrote:

Walter Roberson wrote:
In article <11**********************@g49g2000cwa.googlegroups .com>,
Chad <cd*****@gmail.com> wrote:

> argv[1] = NULL;
> printf("The new modified value is: %s\n",argv[1]);
Passing a NULL pointer for a %s format has undefined results.
--
All is vanity. -- Ecclesiastes

But still didn't answer the question.

In a very c.l.c way, he did. Passing NULL pointer to printf() invokes
undefined behaviour or, in other words, _anything_ can happen
(including, but not limited to, demons flying out of your nose).

Anyone know why the behavior of printing "(null)" for this never got
standardized, considering that it dates back to unix v7?

That would be an absolutely, horrible, hideous idea. It is an error,
pure and simple, and the likely undefined behavior on platforms with
memory management hardware is much like less likely to be overlooked
than something like this.

Why should it be?

--
Jack Klein
Home: http://JK-Technology.Com
FAQs for
comp.lang.c http://c-faq.com/
comp.lang.c++ http://www.parashift.com/c++-faq-lite/
alt.comp.lang.learn.c-c++
http://www.contrib.andrew.cmu.edu/~a...FAQ-acllc.html

[lovecreatesbeauty]

/*

modify a (constant) character string is an undefined behavior. see:
`K&R C, 2nd', §5.5,
`H&S C: A reference manual, 5th', §2.7.4

*/

#include <stdio.h>
#include <string.h>

void manip(char *s)
{
if (s != NULL && strlen(s) >= 2)
{
s[0] = 'A';
s[1] = 'B';
}
}

int main(int argc, char *argv[])
{
char *s = "hello";
printf("argv: %s\n", argv[1]);
printf("constant character string: %s\n", s);
printf("--- --- ---\n");

/* works on both Win32 and HP-UX for this argv[1]*/
manip(argv[1]); /* line */
printf("argv modified: %s\n", argv[1]);

/* runtime error on Win32 but works on hp-ux 11 for this compiling
time constant string */
manip(s); /* line */
printf("constant character string modified: %s\n", s);

return 0;
}
Chad wrote:

Given the following code that achieves no useful purpose:

#include <string.h>
#include <stdio.h>
#include <string.h>

int manip(char *str) {

size_t len = strlen(str)-1;
if(len >= 3) {
str[0] = 'A';
str[1] = 'B';
printf("The length of the string is: %d\n", len);
}
else {
return -1;
}
}

int main(int argc, char **argv){

if(argc !=2){
fprintf(stderr,"Not enough arguements\n");
exit(1);
}

manip(argv[1]);
printf("The modified value is: %s\n",argv[1]);

argv[1] = NULL;
printf("The new modified value is: %s\n",argv[1]);

return 0;
}

I really don't know how to word this in any graceful way. Please bear
with this. How is it possible to accidently modify the string in
argv[1]? I can maybe see something like malloc() returning NULL, then
maybe like having this value be passed to manip(), but other than that,
really see this.

Thanks in advance
Chad

[lovecreatesbeauty]

Perpahs I'm wrong on the previous reply, the argv[1] is not a string
literal.

You can declare the function as: void manip(const char *s) to prevent
the string parameter from being modified.

lovecreatesbeauty wrote:

/*

modify a (constant) character string is an undefined behavior. see:
`K&R C, 2nd', §5.5,
`H&S C: A reference manual, 5th', §2.7.4

*/

#include <stdio.h>
#include <string.h>

void manip(char *s)
{
if (s != NULL && strlen(s) >= 2)
{
s[0] = 'A';
s[1] = 'B';
}
}

int main(int argc, char *argv[])
{
char *s = "hello";
printf("argv: %s\n", argv[1]);
printf("constant character string: %s\n", s);
printf("--- --- ---\n");

/* works on both Win32 and HP-UX for this argv[1]*/
manip(argv[1]); /* line */
printf("argv modified: %s\n", argv[1]);

/* runtime error on Win32 but works on hp-ux 11 for this compiling
time constant string */
manip(s); /* line */
printf("constant character string modified: %s\n", s);

return 0;
}
Chad wrote:

Given the following code that achieves no useful purpose:

#include <string.h>
#include <stdio.h>
#include <string.h>

int manip(char *str) {

size_t len = strlen(str)-1;
if(len >= 3) {
str[0] = 'A';
str[1] = 'B';
printf("The length of the string is: %d\n", len);
}
else {
return -1;
}
}

int main(int argc, char **argv){

if(argc !=2){
fprintf(stderr,"Not enough arguements\n");
exit(1);
}

manip(argv[1]);
printf("The modified value is: %s\n",argv[1]);

argv[1] = NULL;
printf("The new modified value is: %s\n",argv[1]);

return 0;
}

I really don't know how to word this in any graceful way. Please bear
with this. How is it possible to accidently modify the string in
argv[1]? I can maybe see something like malloc() returning NULL, then
maybe like having this value be passed to manip(), but other than that,
really see this.

Thanks in advance
Chad

[kuyper]

Jordan Abel wrote:

comp.std.c added

On 2006-01-15, Vladimir S. Oka <no****@btinternet.com> wrote:

Chad wrote:

Walter Roberson wrote:
In article <11**********************@g49g2000cwa.googlegroups .com>,
Chad <cd*****@gmail.com> wrote:

> argv[1] = NULL;
> printf("The new modified value is: %s\n",argv[1]);
Passing a NULL pointer for a %s format has undefined results.
--
All is vanity. -- Ecclesiastes

But still didn't answer the question.

In a very c.l.c way, he did. Passing NULL pointer to printf() invokes
undefined behaviour or, in other words, _anything_ can happen
(including, but not limited to, demons flying out of your nose).

Anyone know why the behavior of printing "(null)" for this never got
standardized, considering that it dates back to unix v7?

I can't answer that, since I've never been involved in the decision
making. However, I can see a couple of problems with that option.
Firstly, that makes printf("%s\n", (char*)NULL) indistinguisheable from
printf("%s\n", "(null)"). That kind of problem is inherent with any
defined behavior that involves printing a particular output string when
a NULL is passed. If the standard ever mandated the behavior of such
code, I'd prefer the mandatory behavior to include the generation of a
diagnostic. Handling null pointers is something that only "%p" should
have to do, not "%s".

However, if you insist that it be treated as if it were a reasonable
thing to do, I'd prefer a null pointer to be handled by "%s" the same
way as a 0-length null-terminated string. Historically, that's
precisely what would have happened on some systems, because those
sytems were deliberately set up with a block of 0s at the beginning of
memory, so that *(T*)0 == 0, where T is any scalar type (on those
machines, all-bits 0 was a representation of a value equivalent to 0
for all such types). Some people were actually proud of how clever it
was to set things up that way, as a "safety" feature. As a result, I've
had to clean up code that actually assumed that dereferencing a null
pointer was not merely safe, but guaranteed (!?) to return a result
equivalent to 0.

[Chuck F.]

Jack Klein wrote:

Jordan Abel <ra*******@gmail.com> wrote:

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

Anyone know why the behavior of printing "(null)" for this
never got standardized, considering that it dates back to unix
v7?

That would be an absolutely, horrible, hideous idea. It is an
error, pure and simple, and the likely undefined behavior on
platforms with memory management hardware is much like less
likely to be overlooked than something like this.

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.

I am firmly in the camp that believes functions should interpret
illegal parameters in a sensible way if possible. Treating NULL as
an empty source string certainly qualifies.

--
"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/>

[Wojtek Lerch]

"Chuck F. " <cb********@yahoo.com> wrote in message
news:AJ******************************@maineline.ne t...

Jack Klein wrote:

That would be an absolutely, horrible, hideous idea. It is an
error, pure and simple, and the likely undefined behavior on
platforms with memory management hardware is much like less
likely to be overlooked than something like this.
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.

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.
I am firmly in the camp that believes functions should interpret illegal
parameters in a sensible way if possible. Treating NULL as an empty
source string certainly qualifies.

Does your camp apply the same reasoning to all functions, for instance to
strcmp() and memcpy()? What about code that dereferences a null pointer
directly, rather than by passing it to a function? What about bad pointers,
such as uninitialized pointer variables or pointers to memory that has been
freed?

Do you think that merely allowing implementations to handle those situations
your way is not enough, and that the C standard should actually forbid
implementations to cater to the camp that believes that a crash producing a
core dump is a better way of handling bugs in programs?

[Richard Tobin]

In article <43*************@individual.net>,
Wojtek Lerch <Wo******@yahoo.ca> wrote:

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.

In most circumstances the old contents of the file will already have
been lost before the null pointer passed to printf() causes an error.

-- Richard

[Wojtek Lerch]

"Richard Tobin" <ri*****@cogsci.ed.ac.uk> wrote in message
news:dq***********@pc-news.cogsci.ed.ac.uk...

In article <43*************@individual.net>,
Wojtek Lerch <Wo******@yahoo.ca> wrote:

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.

In most circumstances the old contents of the file will already have
been lost before the null pointer passed to printf() causes an error.

If we're only talking about printf(), then you're probably right; but if the
policy of pretending that a null pointer points to "(null)" or to "" were
applied to most other functions, including sprintf() or strcpy(), then I
imagine the statistics might be different. Besides, if a piece of software
is designed in such a way that it a crash or abort for any reason causes you
to lose all your data, its author probably assumed that the data will be
backed up or that it's not a big deal if they're lost; and if you only keep
a backup copy of the most recent successfully created data set, it's still
wiser for bugs in the program to cause it to crash than to replace good data
with "(null)" in your files without giving you any indications of a problem.

[Chuck F.]

Wojtek Lerch wrote:

.... snip ...
If we're only talking about printf(), then you're probably
right; but if the policy of pretending that a null pointer
points to "(null)" or to "" were applied to most other
functions, including sprintf() or strcpy(), then I imagine the
statistics might be different. Besides, if a piece of software
is designed in such a way that it a crash or abort for any
reason causes you to lose all your data, its author probably
assumed that the data will be backed up or that it's not a big
deal if they're lost; and if you only keep a backup copy of the
most recent successfully created data set, it's still wiser for
bugs in the program to cause it to crash than to replace good
data with "(null)" in your files without giving you any
indications of a problem.

This all has to do with the robustness of a program. With C, all
sorts of evil things can happen as a result of sloppiness or other
gremlins. The aim is to get rid of all those in advance, but that
is not provable. My hashlib package returns the following error
codes in a status record:

/* Possible error returns, powers of 2 */
enum hsherr {hshOK = 0, hshNOMEM, hshTBLFULL, hshINTERR = 4};

and I assume that hshINTERR will never appear. However I have code
that can generate it if some internal checks fail. A possible
cause is memory data loss due to cosmic rays and failure to install
ecc memory.

The user should be told that any such error appearing should be
reported, and that it indicates either a bug or something like the
cosmic ray event posited above.

--
"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/>

[Wojtek Lerch]

"Chuck F. " <cb********@yahoo.com> wrote in message
news:w5********************@maineline.net...
....

and I assume that hshINTERR will never appear. However I have code that
can generate it if some internal checks fail. A possible cause is memory
data loss due to cosmic rays and failure to install ecc memory.

I once knew a programmer who had a habit of initializing a variable to zero,
then assigning zero to it, and then assigning zero again, just in case the
first two times didn't work. Perhaps he was trying to account for cosmic
rays, too? ;-)

Seriously though, there's nothing wrong with checking for situations that
should be impossible (except when it detracts you from more important
things); the question is what you do when you do detect them. In many
cases, aborting the program is the best thing to do; in other cases,
aborting may cause much worse problems than logging the problem and then
carefully trying to recover and keep running. But I wouldn't say that
substituting an error message for the missing string and then carrying on as
if nothing happened qualifies as "carefully trying to recover". In most
situations, I'd qualify it as "carelessly ignoring the problem".

[Gordon Burditt]

>> and I assume that hshINTERR will never appear. However I have code that

can generate it if some internal checks fail. A possible cause is memory
data loss due to cosmic rays and failure to install ecc memory.
I once knew a programmer who had a habit of initializing a variable to zero,
then assigning zero to it, and then assigning zero again, just in case the
first two times didn't work. Perhaps he was trying to account for cosmic
rays, too? ;-)

I presume this programmer also ends his functions like this:

return x;
return x;
return x;
}

OR

while (1) {
while (1) {
exit(EXIT_SUCCESS);
}
}

just in case a runaway program crashes through an unconditional branch.
Seriously though, there's nothing wrong with checking for situations that
should be impossible (except when it detracts you from more important
things); the question is what you do when you do detect them. In many

One of the bad things to do:

int errmsg(char *s)
{
int ret;

do {
ret = printf("Error: %s\n", s);
if (ret < 0) {
/* some evil versions put a fork() call here */
errmsg("Error writing error message to stdout");
}
} while (ret < 0);
return ret;
}

Notice that if you run out of disk space for stdout, this thing is
infinitely recursive, and it tries to make sure that if you run out
of disk space, you STAY out of disk space.
Gordon L. Burditt

[lovecreatesbeauty]

Chuck F. wrote:

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.

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:

Win2k:

C:\ type stringmodified.c
#include <stdio.h>
#include <string.h>

int main(void)
{
char *str = NULL;
printf("argv: %s\n", str);

return 0;
}

C:\ gcc stringmodified.c -ostringmodified

C:\ stringmodified
argv: (null)

C:\
HP-UX 11:

$ cat "stringmodify.c"
#include <stdio.h>
#include <string.h>

int main(void)
{
char *str = NULL;
printf("argv: %s\n", str);

return 0;
}
$ cc +DAportable "stringmodify.c" -ostringmodify
$ stringmodify
argv:
$

[Keith Thompson]

"lovecreatesbeauty" <lo***************@gmail.com> writes:

Chuck F. wrote:

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.

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:

That's not the least bit surprising, since it's undefined behavior.

--
Keith Thompson (The_Other_Keith) ks***@mib.org <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <*> <http://users.sdsc.edu/~kst>
We must do something. This is something. Therefore, we must do this.

[Richard Heathfield]

Wojtek Lerch said:

I once knew a programmer who had a habit of initializing a variable to
zero, then assigning zero to it, and then assigning zero again, just in
case the
first two times didn't work. Perhaps he was trying to account for cosmic
rays, too? ;-)

This reminds me of me. :-) But no, I'm not worried about cosmic rays. Well,
not terribly worried, anyway. No, what I'm worried about is maintenance.

int WellChosenObjectName = 0; /* A */

... /* B */

for(WellChosenObjectName = 0; /* C */
WellChosenObjectName < lim;
++WellChosenObjectName)
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.

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

C: ensure that, no matter what the maintenance guys did in section B,
WellChosenObjectName has the right value at the start of this loop.
--
Richard Heathfield
"Usenet is a strange place" - dmr 29/7/1999
http://www.cpax.org.uk
email: rjh at above domain (but drop the www, obviously)

[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.

--
Richard Heathfield
"Usenet is a strange place" - dmr 29/7/1999
http://www.cpax.org.uk
email: rjh at above domain (but drop the www, obviously)

[Chuck F.]

Richard Heathfield wrote:

.... 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.]

lovecreatesbeauty wrote:

Chuck F. wrote:

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.

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]

Chuck F. wrote:

lovecreatesbeauty wrote:

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.

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

[Mark McIntyre]

On Tue, 17 Jan 2006 07:12:28 +0000 (UTC), in comp.lang.c , Richard
Heathfield <in*****@invalid.invalid> wrote:

(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
--

----== Posted via Newsfeeds.Com - Unlimited-Unrestricted-Secure Usenet News==----
http://www.newsfeeds.com The #1 Newsgroup Service in the World! 120,000+ Newsgroups
----= East and West-Coast Server Farms - Total Privacy via Encryption =----

[Mark McIntyre]

On 17 Jan 2006 10:28:34 GMT, in comp.lang.c , Niklas Matthies
<us***********@nmhq.net> wrote:

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

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.

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

http://dspace.dial.pipex.com/town/gr.../bloopers.html

Mark McIntyre
--

----== Posted via Newsfeeds.Com - Unlimited-Unrestricted-Secure Usenet News==----
http://www.newsfeeds.com The #1 Newsgroup Service in the World! 120,000+ Newsgroups
----= East and West-Coast Server Farms - Total Privacy via Encryption =----

[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]

"Chuck F." wrote:

Jack Klein wrote:

Jordan Abel <ra*******@gmail.com> wrote:

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

Anyone know why the behavior of printing "(null)" for this
never got standardized, ...?

That would be an absolutely, horrible, hideous idea. It is an
error, pure and simple, and the likely undefined behavior on
platforms with memory management hardware is much like less
likely to be overlooked than something like this.

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) ...

>> Anyone know why the behavior of printing "(null)" for this
>> never got standardized, ...?
> That would be an absolutely, horrible, hideous idea. It is an
> error, pure and simple, and the likely undefined behavior on
> platforms with memory management hardware is much like less
> likely to be overlooked than something like this.

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".

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
Heathfield <in*****@invalid.invalid> wrote:

(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?

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

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

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.

--
Richard Heathfield
"Usenet is a strange place" - dmr 29/7/1999
http://www.cpax.org.uk
email: rjh at above domain (but drop the www, obviously)

[Mark McIntyre]

On Tue, 17 Jan 2006 22:36:41 +0000 (UTC), in comp.lang.c , Richard
Heathfield <in*****@invalid.invalid> wrote:

Mark McIntyre said:

It only becomes indeterminate if some
maintenance droid uses the object without initalising it.

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
--

----== Posted via Newsfeeds.Com - Unlimited-Unrestricted-Secure Usenet News==----
http://www.newsfeeds.com The #1 Newsgroup Service in the World! 120,000+ Newsgroups
----= East and West-Coast Server Farms - Total Privacy via Encryption =----

[Richard Heathfield]

Mark McIntyre said:

On Tue, 17 Jan 2006 22:36:41 +0000 (UTC), in comp.lang.c , Richard
Heathfield <in*****@invalid.invalid> wrote:

Mark McIntyre said:

It only becomes indeterminate if some
maintenance droid uses the object without initalising it.
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 :-)

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 Heathfield
"Usenet is a strange place" - dmr 29/7/1999
http://www.cpax.org.uk
email: rjh at above domain (but drop the www, obviously)

[Richard Bos]

"Wojtek Lerch" <Wo******@yahoo.ca> wrote:

"Chuck F. " <cb********@yahoo.com> wrote in message
news:AJ******************************@maineline.ne t...

Jack Klein wrote:

That would be an absolutely, horrible, hideous idea. It is an
error, pure and simple, and the likely undefined behavior on
platforms with memory management hardware is much like less
likely to be overlooked than something like this.

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.

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]

Mark McIntyre wrote:

On Tue, 17 Jan 2006 22:36:41 +0000 (UTC), in comp.lang.c , Richard
Heathfield <in*****@invalid.invalid> wrote:

Mark McIntyre said:

It only becomes indeterminate if some
maintenance droid uses the object without initalising it.
You trimmed Richard's quotation of your own previous message, removing
the following sentence:
Which will be detected by the compiler options you're using, right? Right?

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.
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 :-)

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]

ku****@wizard.net said:

Mark McIntyre wrote:

On Tue, 17 Jan 2006 22:36:41 +0000 (UTC), in comp.lang.c , Richard
Heathfield <in*****@invalid.invalid> wrote:

>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 :-)

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.

--
Richard Heathfield
"Usenet is a strange place" - dmr 29/7/1999
http://www.cpax.org.uk
email: rjh at above domain (but drop the www, obviously)