Where the code trouble is?

[mikelinyoho]

Regards:

Where the code trouble is?
#include <windows.h>
#include <stdio.h>
#include <stdlib.h>
#include <string.h>

int main(){

char *name;
char *title;
printf( "Enter your name:");
scanf( "%s", name );
title = strcat(name,"th e Great");
printf( "Hello, %s\n", title );
return(0);
}

--------------------------------------------

thank you
may goodness be with you all

[Richard Bos]

"Bart C" <[e-mail] m> wrote:

"mikelinyoh o" <mi*********@gm ail.com> wrote in message
news:11******** *************@z 14g2000cwz.goog legroups.com...

char *name;
char *title;
printf( "Enter your name:");
scanf( "%s", name );
The compiler might give a warning that 'name' is not initialised.

Not necessarily.
I would have expected scanf() to give an error when 'name' was (as I
assumed) null.

It fact on my test compiler 'name' has some arbitrary value (the program
worked),
No, it didn't. It merely appeared to.
So ideally, there should be (1) a warning (2) 'name' is best set to null
when not initialised, to avoid undefined action, and

Writing through a null pointer is no more defined than writing through a
wild pointer.

title = strcat(name,"th e Great");

A space might help

A space would not make the code any more correct. The real problem on
this line is similar to the one above.

Richard

[Bart C]

"Richard Bos" <rl*@hoekstra-uitgeverij.nl> wrote in message
news:43******** ********@news.x s4all.nl...
....

So ideally, there should be (1) a warning (2) 'name' is best set to null
when not initialised, to avoid undefined action, and

Writing through a null pointer is no more defined than writing through a
wild pointer.

Maybe, but an error is more or less guaranteed with a null pointer and makes
it easy to check for. An arbitrary wild pointer is difficult to check for
and leads to code that works on test then fails unexpectedly.

Bart.

[Walter Roberson]

In article <43******@212.6 7.96.135>, Bart C <[e-mail] m> wrote:

"Richard Bos" <rl*@hoekstra-uitgeverij.nl> wrote in message
news:43******* *********@news. xs4all.nl...

Writing through a null pointer is no more defined than writing through a
wild pointer.

Maybe, but an error is more or less guaranteed with a null pointer and makes
it easy to check for.

I know of at least two architectures in which NULL is all-zero-bits
but in which writing at (or near that location, such as a[3] when
a is NULL) would NOT result in a trap, because the architectures happen
to have memory at that location.
--
"[...] it's all part of one's right to be publicly stupid." -- Dave Smey

[Bryan Donlan]

Walter Roberson wrote:

In article <43******@212.6 7.96.135>, Bart C <[e-mail] m> wrote:

"Richard Bos" <rl*@hoekstra-uitgeverij.nl> wrote in message
news:43****** **********@news .xs4all.nl...

Writing through a null pointer is no more defined than writing through a
wild pointer.

Maybe, but an error is more or less guaranteed with a null pointer and
makes it easy to check for.

I know of at least two architectures in which NULL is all-zero-bits
but in which writing at (or near that location, such as a[3] when
a is NULL) would NOT result in a trap, because the architectures happen
to have memory at that location.

The vast majority of machines in use have NULL as a trap location. Richard's
development system likely does so as well. Although *NULL might well not
trap, it's in general more likely to, which can help with debugging.

This will not catch all such errors of course, but it doesn't hurt anything,
except for causing a tiny (probably imperceptible) performance hit, and may
help with debugging.

--
λz.λi.i(i((λ n.λm.λz.λi.n z(λq.mqi))((λ n.λz.λi.n(nzi )i)(λz.λi.i(( (λn.λz.λi.n
(nzi)i)(λz.λi .i(iz)))zi)))(( λn.λz.λi.n(n zi)i)(λz.λi.i (iz)))zi))

[Flash Gordon]

Bryan Donlan wrote:

Walter Roberson wrote:

In article <43******@212.6 7.96.135>, Bart C <[e-mail] m> wrote:

"Richard Bos" <rl*@hoekstra-uitgeverij.nl> wrote in message
news:43***** ***********@new s.xs4all.nl...

Writing through a null pointer is no more defined than writing through a
wild pointer.

Maybe, but an error is more or less guaranteed with a null pointer and
makes it easy to check for.

I know of at least two architectures in which NULL is all-zero-bits
but in which writing at (or near that location, such as a[3] when
a is NULL) would NOT result in a trap, because the architectures happen
to have memory at that location.

The vast majority of machines in use have NULL as a trap location. Richard's
development system likely does so as well. Although *NULL might well not
trap, it's in general more likely to, which can help with debugging.

This will not catch all such errors of course, but it doesn't hurt anything,
except for causing a tiny (probably imperceptible) performance hit, and may
help with debugging.

Agreed.

I would also say that even on systems where writing to *NULL does not
trap, it is still likely (but not guaranteed) to give reproduceable
results which can be debugged.

For similar reasons on embedded systems I have changed the startup code
so that all RAM was initialised to all bits 0. I did not check on the
system whether NULL was all bits 0 or whether float or double 0 where
all bits 0, but it did meen the software was more predictable and easier
to debug when accessing uninitialised data. On another system they
initialised all RAM to 0x55 for the similar reason (I used all bits 0
because static variables without an initialiser where *not* set to 0).

IMHO the first stage in trying to debug a problem is always to reproduce
it, since if you can't reliably reproduce it you will never know if you
have fixed what caused the original bug report or something else that
you think might have caused it but did not.
--
Flash Gordon
Living in interesting times.
Although my email address says spam, it is real and I read it.

[Richard Bos]

Bryan Donlan <bd*****@gmail. com> wrote:

Walter Roberson wrote:

In article <43******@212.6 7.96.135>, Bart C <[e-mail] m> wrote:

"Richard Bos" <rl*@hoekstra-uitgeverij.nl> wrote in message
news:43****** **********@news .xs4all.nl...

Writing through a null pointer is no more defined than writing through a
wild pointer.

Maybe, but an error is more or less guaranteed with a null pointer and
makes it easy to check for.

I know of at least two architectures in which NULL is all-zero-bits
but in which writing at (or near that location, such as a[3] when
a is NULL) would NOT result in a trap, because the architectures happen
to have memory at that location.

The vast majority of machines in use have NULL as a trap location. Richard's
development system likely does so as well. Although *NULL might well not
trap, it's in general more likely to, which can help with debugging.

This will not catch all such errors of course, but it doesn't hurt anything,
except for causing a tiny (probably imperceptible) performance hit, and may
help with debugging.

On the contrary, it _will_ hurt. The programmer will start relying on
the assumption that he has either a null pointer, or a valid one. This
assumption is going to turn around and bite him sooner or later, and
then you try and find where it broke down.

Richard

[Anand]

Flash Gordon wrote:

Bryan Donlan wrote:

Walter Roberson wrote:

In article <43******@212.6 7.96.135>, Bart C <[e-mail] m> wrote:

"Richard Bos" <rl*@hoekstra-uitgeverij.nl> wrote in message
news:43******** ********@news.x s4all.nl...
> Writing through a null pointer is no more defined than writing
> through a
> wild pointer.
Maybe, but an error is more or less guaranteed with a null pointer and
makes it easy to check for.
I know of at least two architectures in which NULL is all-zero-bits
but in which writing at (or near that location, such as a[3] when
a is NULL) would NOT result in a trap, because the architectures happen
to have memory at that location.

The vast majority of machines in use have NULL as a trap location.
Richard's
development system likely does so as well. Although *NULL might well not
trap, it's in general more likely to, which can help with debugging.

This will not catch all such errors of course, but it doesn't hurt
anything,
except for causing a tiny (probably imperceptible) performance hit,
and may
help with debugging.

Agreed.

I would also say that even on systems where writing to *NULL does not
trap, it is still likely (but not guaranteed) to give reproduceable
results which can be debugged.

For similar reasons on embedded systems I have changed the startup code
so that all RAM was initialised to all bits 0. I did not check on the
system whether NULL was all bits 0 or whether float or double 0 where
all bits 0, but it did meen the software was more predictable and easier
to debug when accessing uninitialised data. On another system they
initialised all RAM to 0x55 for the similar reason (I used all bits 0
because static variables without an initialiser where *not* set to 0).

IMHO the first stage in trying to debug a problem is always to reproduce
it, since if you can't reliably reproduce it you will never know if you
have fixed what caused the original bug report or something else that
you think might have caused it but did not.

Right.
0x99 (or any with MSBit 1) is a "*_tad_*" (and only) little better..
See Eric SosMan's reply in recent thread of "How to choose between
malloc and calloc"
http://groups.google.com/group/comp....706ab502cce81f

Anand
PS: Is there a better way to point to another thread (not the long
google link way?