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,"the Great");
printf( "Hello, %s\n", title );
return(0);
}

 

[manoj1978]

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

Name is a pointer with no memory associated.Scanf dont allocate
memory.
Change char * name to an array.Use fgets instead of scanf to avoid
overflow issues.

 

[Alexander Fleck]

Do you get compiler errors or what?
Can you be more specific?

Alex.

 

[Suman]

Regards:

Where the code trouble is?


#include <windows.h>

non standard header

#include <stdio.h>
#include <stdlib.h>

Do you really need this?

#include <string.h>

#define MAXMUNCH ... /* some size big enough for you */

int main(){

int main(void){

is a tad bit better.

char *name;
char *title;
printf( "Enter your name:");
scanf( "%s", name );

Not allocated enough (any) memory -- so you're
dead hereon.

Do name = malloc( sizeof *name * MAXMUNCH );

title = strcat(name,"the Great");

... and to add insult to injury.

 

[Martin Ambuhl]

Regards:

Where the code trouble is?

The same as in the last 4000 posts with pointers-to-nowhere from
clueless people who refuse to check the FAQ or follow the newsgroup
before posting.

 

[CBFalconer]

Where the code trouble is?

#include <windows.h>

No such standard header, eliminate it.

#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,"the Great");
printf( "Hello, %s\n", title );
return(0);
}

Don't use scanf for interactive input. Do fflush of the prompt.
Do read the action of strcat. Do assign memory space to fill. eg:

#include <stdio.h>
#include <string.h>
#define BUFSIZE 80
#define CAPTION " the Great"

int main(void) {
char name[BUFSIZE + 1 + strlen(CAPTION)];
char *p;

printf("Enter your name;
fflush(stdout);
fgets(name, BUFSIZE, stdin);
if (p = strchr(name, '\n') *p = '\0';
strcat(name, CAPTION");
printf("Hello, %s\n", name);
return(0);
} /* not tested */

Note the test for a final \n in the input and stripping of it.

 

[Bart C]

Regards:

Where the code trouble is?
....
char *name;
char *title;
printf( "Enter your name:");
scanf( "%s", name );

The compiler might give a warning that 'name' is not initialised.

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), and not zero.

So ideally, there should be (1) a warning (2) 'name' is best set to null
when not initialised, to avoid undefined action, and (3) scanf() should at
very least not assign to a null pointer!

title = strcat(name,"the Great");

A space might help

Bartthe Great

 

[Anton Petrusevich]

#define BUFSIZE 80
#define CAPTION " the Great"

int main(void) {
char name[BUFSIZE + 1 + strlen(CAPTION)];

Excuse my ignorance, but does it really work? Well, I tried it with gcc and
I see that it really works, but since when?

 

[Keith Thompson]

#define BUFSIZE 80
#define CAPTION " the Great"

int main(void) {
char name[BUFSIZE + 1 + strlen(CAPTION)];

Excuse my ignorance, but does it really work? Well, I tried it with gcc and
I see that it really works, but since when?

Variable length arrays (VLAs) are a new feature in C99, not supported
in C90. gcc has supported them (or something very similar) as an
extension for some time. It won't work with a strict C90 compiler.

<OT>
I'm a little surprised to see that gcc doesn't complain about it, even
with "-ansi -pedantic -Wall -W".
</OT>

 

[CBFalconer]

#define BUFSIZE 80
#define CAPTION " the Great"

int main(void) {
char name[BUFSIZE + 1 + strlen(CAPTION)];

Excuse my ignorance, but does it really work? Well, I tried it with gcc and
I see that it really works, but since when?

That should really have been sizeof(CAPTION) to be portable to
C90. Then it doesn't need the +1 either.

 

[Richard Bos]

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.

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]

....

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]

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.

 

[Bryan Donlan]

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.

 

[Flash Gordon]

news:[email protected]...

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.

 

[Richard Bos]

news:[email protected]...

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]

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...t&q=0x99+calloc&rnum=1&hl=en#83706ab502cce81f

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