Seg fault + string manipulation

[kumarvis]

int main ()
{
char *str = *Aamit ;
*str='R' ;
printf("%s \n " ,str);
}

it's giving segfault
why ?????

 

[Joachim Schmitz]

int main ()
{
char *str = *Aamit ;
*str='R' ;
printf("%s \n " ,str);
}

it's giving segfault
why ?????

If you meant to write
char *str = "Aamit";

Then the
*str ="R";
possibly writes into read-only memory, but surely invokes undefined
behavoir.
segvault is one possible outcome of that.

Another fault (and causing undefined behavoir) is the lack of #include
<stdio.h> resp. the resulting lack of a prototype for the varadic function
printf().

Bye, Jojo

 

[Keith Thompson]

int main(void)
{
char *str = "Aamit" ;

*str = 'R' ;
puts(str);
return 0;
}

pete, what exactly was the point of your followup?

You corrected the OP's compilation error and presumably reproduced
something close to his actual code (which the OP should have posted
himself). Meanwhile, you haven't answered his actual question, or
said anything at all about it. You also forgot the required
"#include <stdio.h>" and replaced the OP's printf call with a puts
call, which subtly changed the behavior of the program.

 

[Keith Thompson]

int main ()
{
char *str = *Aamit ;
*str='R' ;
printf("%s \n " ,str);
}

it's giving segfault

No, it isn't. I'm sure the program you're actually running gives you
a seg fault, but the code you posted won't even compile.

Never re-type code when you post it here. Always copy-and-paste the
*exact* code that you're actually compiling.

You also have a few problems that your compiler might not warn you about:

If you're going to use printf, you *must* have "#include <stdio.h>".

"int main()" is ok, but "int main(void)" is better.

You should add a "return 0;" at the end of main. It's not required in
all circumstances, but it can't hurt.

The space after the "%s" in your printf format is fairly harmless, but
almost certainly useless. It causes an extra blank to be printed
after your string.

The way you format your code is odd and makes it more difficult to
read. The compiler doesn't care about whitespace between tokens, but
for the sake of your readers it's generally best to have a space after
each comma and surrounding binary operators like "=", and *not* to
have a blank preceding a semicolon or comma.

And see question 1.32 of the comp.lang.c FAQ, <http://www.c-faq.com/>.

 

[bert]

int main ()
{
   char *str = *Aamit ;
   *str='R' ;
    printf("%s \n " ,str);

}

it's giving segfault
why ?????

Apart from the problems other posters have
already pointed out, there is a major one
which they haven't :-

printf() expects its (str) argument to
point to a zero-terminated string. Your
code modifies the first character which
str is pointing at, but does nothing about
the following ones. If they are all non-zero
junk, and you have fixed the other problems,
it is quite possible for printf() to run off
the end of available memory looking for the
zero terminator.
--

 

[Chad]

Apart from the problems other posters have
already pointed out, there is a major one
which they haven't :-

printf() expects its (str) argument to
point to a zero-terminated string.  Your
code modifies the first character which
str is pointing at, but does nothing about
the following ones.  If they are all non-zero
junk, and you have fixed the other problems,
it is quite possible for printf() to run off
the end of available memory looking for the
zero terminator.
--

Maybe I'm not thinking this through enough, but I REALLY don't see the
difference between
m-net% more mod.c
#include <stdio.h>

int main (void)
{
char str[] = "Aamit";
*str='R';
printf("%s \n " ,str);
return 0;
}

m-net% gcc -g -Wall mod.c -o mod
m-net% ./mod
Ramit

%
m-net%


Versus something like
m-net% more mod.c
#include <stdio.h>

int main (void)
{
char str[] = "Aamit";
*str='R';
puts(str);
return 0;
}

m-net% gcc -g -Wall mod.c -o mod
m-net% ./mod
Ramit
m-net%

 

[Keith Thompson]

Apart from the problems other posters have
already pointed out, there is a major one
which they haven't :-

printf() expects its (str) argument to
point to a zero-terminated string. Your
code modifies the first character which
str is pointing at, but does nothing about
the following ones. If they are all non-zero
junk, and you have fixed the other problems,
it is quite possible for printf() to run off
the end of available memory looking for the
zero terminator.

The code as posted will not compile, so it clearly isn't the same code
that the OP actually compiled and ran. I think you're making a
different assumption than the rest of us about just how the posted
code differs from the real code.

Are you assuming that there's a declared object of type char** named
``Aamit''?

I think the rest of us assumed that ``*Aamit'' should have been the
string literal "Aamit". Given that assumption, *if* we ignore the
fact that modifying the contents of a string literal invokes undefined
behavior, then the array is already properly terminated with a '\0'.

Unfortunately, the original poster has not seen fit to clear this up
by posting his actual code. Until and unless he does so, I suggest
there's no point in pursuing this further.

 

[Joachim Schmitz]

... snip ...

Maybe I'm not thinking this through enough, but I REALLY don't
see the difference between
... snip ...

Versus something like

#include <stdio.h>
int main (void) {
char str[] = "Aamit";
*str='R';
puts(str);
return 0;
}

The difference is between:

char *str = "Aamit"; /* 1 */
and
char str[] = "Aamit"; /* 2 */

in /* 1 */ str is a char pointer to a non-modifiable string. In /*
2 */ str is a fully modifiable 6 char array, holding "Aamit\0".

Read again. Chad was using char str[] in both cases, his only difference was
printf vs. puts

Bye, Jojo

 

[Joachim Schmitz]

Maybe I'm not thinking this through enough, but I REALLY don't see the
difference between

Then look again.

m-net% more mod.c
#include <stdio.h>

int main (void)
{
char str[] = "Aamit";
*str='R';
printf("%s \n " ,str);
return 0;
}

m-net% gcc -g -Wall mod.c -o mod
m-net% ./mod
Ramit

See this linefeed?

%
m-net%


Versus something like
m-net% more mod.c
#include <stdio.h>

int main (void)
{
char str[] = "Aamit";
*str='R';
puts(str);
return 0;
}

m-net% gcc -g -Wall mod.c -o mod
m-net% ./mod
Ramit

Here it is not.

m-net%

On top you got a space before and anotzher one after the newline, but these
are 'invisible'.

Bye, Jojo

 

[Joachim Schmitz]

Chad wrote:

... snip ...

Maybe I'm not thinking this through enough, but I REALLY don't
see the difference between

... snip ...

Versus something like

#include <stdio.h>
int main (void) {
char str[] = "Aamit";
*str='R';
puts(str);
return 0;
}

The difference is between:

char *str = "Aamit"; /* 1 */
and
char str[] = "Aamit"; /* 2 */

in /* 1 */ str is a char pointer to a non-modifiable string. In /*
2 */ str is a fully modifiable 6 char array, holding "Aamit\0".

Read again. Chad was using char str[] in both cases, his only
difference was printf vs. puts

That was in his last manual copy of the original problem. The

char* = "constant";

was the actual problem.

the *OP's* actual problem, but not Chad's problem.

 

[Joachim Schmitz]

Chad wrote:

Maybe I'm not thinking this through enough, but I REALLY don't see
the difference between

Then look again.

m-net% more mod.c
#include <stdio.h>

int main (void)
{
char str[] = "Aamit";
*str='R';
printf("%s \n " ,str);
return 0;
}

m-net% gcc -g -Wall mod.c -o mod
m-net% ./mod
Ramit

See this linefeed?

%
m-net%


Versus something like
m-net% more mod.c
#include <stdio.h>

int main (void)
{
char str[] = "Aamit";
*str='R';
puts(str);
return 0;
}

m-net% gcc -g -Wall mod.c -o mod
m-net% ./mod
Ramit

Here it is not.

m-net%

On top you got a space before and anotzher one after the newline,
but these are 'invisible'.

I think the printf version is stylistically
a little bit worse than that.

N869
7.19.2 Streams

[#2]
Data read in from a text
stream will necessarily compare equal to the data that were
earlier written out to that stream only if: the data consist
only of printing characters and the control characters
horizontal tab and new-line; no new-line character is
immediately preceded by space characters; and the last
character is a new-line character.

Whether space characters
that are written out immediately before a new-line character
appear when read in is implementation-defined.

Guess that reply should have gone to Chad?

Bye, Jojo

 

[Chad]

Maybe I'm not thinking this through enough, but I REALLY don't see the
difference between Then look again.
m-net% more mod.c
#include <stdio.h>
int main (void)
{
char str[] = "Aamit";
*str='R';
printf("%s \n " ,str);
return 0;
}
m-net% gcc -g -Wall mod.c -o mod
m-net% ./mod
Ramit

See this linefeed?

%
m-net%
Versus something like
m-net% more mod.c
#include <stdio.h>
int main (void)
{
char str[] = "Aamit";
*str='R';
puts(str);
return 0;
}
m-net% gcc -g -Wall mod.c -o mod
m-net% ./mod
Ramit Here it is not.

m-net%

On top you got a space before and anotzher one after the newline, but these
are 'invisible'.

I think the printf version is stylistically
a little bit worse than that.

N869
7.19.2 Streams

[#2]
Data read in from a text
stream will necessarily compare equal to the data that were
earlier written out to that stream only if: the data consist
only of printing characters and the control characters
horizontal tab and new-line; no new-line character is
immediately preceded by space characters; and the last
character is a new-line character.

Whether space characters
that are written out immediately before a new-line character
appear when read in is implementation-defined.

It appears that I don't get undefined behavior when I remove the space
before and after '\n' in printf()

m-net% more mod.c
#include <stdio.h>

int main (void)
{
char str[] = "Aamit";
*str='R';
printf("%s\n" ,str);
return 0;
}

m-net% gcc -g -Wall mod.c -o mod
m-net% ./mod
Ramit
m-net%

 

[Keith Thompson]

It appears that I don't get undefined behavior when I remove the space
before and after '\n' in printf()

m-net% more mod.c
#include <stdio.h>

int main (void)
{
char str[] = "Aamit";
*str='R';
printf("%s\n" ,str);
return 0;
}

[...]

The space before or after '\n' has nothing to do with whether the
behavior is undefined.