Is this correct?

[Elliot Marks]

The pointer p is initialized to point to the first character of the
unnamed array of characters holding the string literal.

In C++, the type of this array is array of constant char. In C the
language does not specify whether the string literal is constant or
not. But in both languages, it is undefined behavior is you try to
modify the string literal.

#include <stdio.h>
void func(char * p);

int main(void)
{
char * p = "abcdefg";
printf("%s\n", p);
func(p);

return 0;
}

void func(char * p)
{
*(p + 2) = 'z';
printf("%s\n", p);
}

This "seems" to work. The string literal is modified. Is this
undefined behaviour? If so, can I take advantage of it if the
code runs only on platform x with implementation y? That is, is
the behaviour consistent for a particular platform and
implementation, albeit undefined?

 

[Ben Pfaff]

#include <stdio.h>
void func(char * p);

int main(void)
{
char * p = "abcdefg";
printf("%s\n", p);
func(p);

return 0;
}

void func(char * p)
{
*(p + 2) = 'z';

p[2] is more straightforward.

printf("%s\n", p);
}

This "seems" to work. The string literal is modified. Is this
undefined behaviour?
Yes.

If so, can I take advantage of it if the code runs only on
platform x with implementation y? That is, is the behaviour
consistent for a particular platform and implementation, albeit
undefined?

If an implementation provides a definition of some form of
undefined behavior, then you can depend on it when you use that
implementation (only).

 

[Keith Thompson]

I didn't want to do this manually, so I modified the scripts which are run
before suspending and after resuming to switch to a text console and back.
Unfortunately, the `main' function of the program to switch virtual
terminals returned `void'. The undefined behaviour in this case had the
effect that the program incorrectly reported unsuccessful execution after
switching virtual terminals. This in turn caused the script to terminate
immediately and report unsuccessful execution to its own parent process,
the power management daemon.

So the effect wasn't caused by a corruption of the stack (i.e.,
leaving the stack pointer pointing to an incorrect location), just by
main() returning an arbitrary value that the caller assumed was
meaningful. I suspect the same thing would have happened if main()
had been properly declared to return int, but without a return or
exit().

I know that corrupting the stack (by failing to return a value) is one
plausible consequence of void main(), but I don't think I've ever
heard of a system where it actually happens. On many systems, an int
result is returned in a register; a void function just leaves garbage
in that register. On most other systems, I think, either the caller
leaves room for a result regardless of the declaration, or the calling
code restores the stack pointer correctly regardless of what the
called function does with it.

It's still a great example, of course.

 

[Flash Gordon]

#include <stdio.h>
void func(char * p);

int main(void)
{
char * p = "abcdefg";
printf("%s\n", p);
func(p);

return 0;
}

void func(char * p)
{
*(p + 2) = 'z';
printf("%s\n", p);
}

This "seems" to work. The string literal is modified. Is this
undefined behaviour?

Yes, it is undefined behaviour.

If so, can I take advantage of it if the
code runs only on platform x with implementation y? That is, is
the behaviour consistent for a particular platform and
implementation, albeit undefined?

Undefined means that it is undefined. Therefor anything can happen,
including it doing exactly what you expect unless you run it on a Sunday
in which case it invokes the Wrath Of God and you get struck by
lightning.

In other words, don't do that.

 

[Elliot Marks]

Therefor anything can happen,
including it doing exactly what you expect unless you run it on a Sunday
in which case it invokes the Wrath Of God and you get struck by
lightning.

It would have to be on a Saturday. I'm Jewish.

EM

 

[Mark McIntyre]

Nope, it is equivalent to the first example. Const pointer
to char would be:

char * const p;

oops, you're right. My mistake. I expect Dan P has heaped contumely on
me in another thread... too bad.

Nope. Again, as above, const pointer to const char.

Again you could be right - my compiler barfed at it, possibly because
its an abhomination...

 

[CBFalconer]

.... snip ...

oops, you're right. My mistake. I expect Dan P has heaped contumely
on me in another thread... too bad.

Not yet. Maybe he is ill, or there was a comms glitch

 

[glen herrmannsfeldt]

glen herrmannsfeldt <[email protected]> spoke thus:

K&R2, p194:
"...the behavior of a program that attempts to alter a string
literal is undefined."

I assume by K&R C you're speaking of pre-ANSI...?

Maybe it should be called K&R1 to avoid confusion.

Yes, pre-ANSI.

-- glen