modifying stack variable

[Uenal Mutlu]

Why is f() giving access violation when called from tf1() or tf2() ?
Is this a compiler and/or language bug?

void f(char* psz)
{
*psz = 0;
}

void tf1()
{
char* p = "test";
f(p);
}

void tf2()
{
f("test");
}

 

[Uenal Mutlu]

Why is f() giving access violation when called from tf1() or tf2() ?
Is this a compiler and/or language bug?

No, string literals are of type const char*, the conversion to char* is
provided for C compatibility, but deprecated. When you modify the
pointed-to string literal, that invokes undefined behaviour (which
usually manifests itself in an A/V in this case, but anything could happen).

void f(char* psz)
{
*psz = 0;

here ^^

}

void tf1()
{
char* p = "test"; char p[] = "test";
f(p);
}

What compiler are you using? It should have warned you about this.

Microsoft's VS6. No, it does not give a warning, even if using the highest
warning level (4).

 

[Uenal Mutlu]

"Malte Starostik" wrote

If it's not too much work for you could you tell me where in the standards
this is stated? Where should I look (book, paragraph etc.)?

void f(char* psz)
{
*psz = 0;

here ^^

}

void tf1()
{
char* p = "test"; char p[] = "test";
f(p);
}

What compiler are you using? It should have warned you about this.

Microsoft's VS6. No, it does not give a warning, even if using the highest
warning level (4).

 

[Uenal Mutlu]

happen).

If it's not too much work for you could you tell me where in the standards
this is stated? Where should I look (book, paragraph etc.)?

Ok, found a workaround, and a reference:

//#############################################################
PRB: Use of /ZI May Cause Access Violation
Q198477
--------------------------------------------------------------------------------
The information in this article applies to:
a.. Microsoft Visual C++, 32-bit Editions, version 6.0
--------------------------------------------------------------------------------
SYMPTOMS
Use of the compiler switch /ZI (Program Data Base for Edit and Continue) may
cause an access violation if you try to modify a text string.

RESOLUTION
Use one of the following workarounds:
a.. In the sample below, change "char * ptr" to "char ptr[]".
b.. Do not use the /ZI switch.

STATUS
As per C++ Standard (2.13.4.2) the effect of attempting to modify a string
literal is undefined.

MORE INFORMATION
By default the compiler switch /ZI (Program Data Base for Edit and Continue) uses
the compiler switch /GF.

The /GF option enables the compiler to pool strings and place them in read-only
memory. By placing the strings in read-only memory, the operating system does not
need to swap that portion of memory. Instead, it can read the strings back from
the image file. It is a good idea to do this as it saves pages of memory from
being written to and therefore reduces the working set used by the application.
In addition, it allows those pages to be shared between multiple instances of the
process that use that image file (.exe or .dll file), further reducing total
memory usage in the entire system. Strings placed in read-only memory cannot be
modified; if you try to modify them, you will see an Application Error dialog
box.

The following code when executed after compile produces an access violation.
Sample Code

// Test.cpp
// Compile with: cl /ZI /Od test.cpp

int main ()
{
char* ptr = "Hello World";
ptr[3] = 'Q'; //Access violation
return 0;
}

Since /ZI is used for debugging with Edit and Continue, the above code works
fine in the Release build, where the /ZI switch is not used.


REFERENCES
Additional query words: string strings arrays initialize initialise aggregate
access violation

Keywords : kbCompiler kbVC600
Issue type : kbprb
Technology :
//#############################################################

 

[Malte Starostik]

Why is f() giving access violation when called from tf1() or tf2() ?
Is this a compiler and/or language bug?

No, string literals are of type const char*, the conversion to char* is
provided for C compatibility, but deprecated. When you modify the
pointed-to string literal, that invokes undefined behaviour (which
usually manifests itself in an A/V in this case, but anything could happen).

void f(char* psz)
{
*psz = 0;

here ^^

}

void tf1()
{
char* p = "test"; char p[] = "test";
f(p);
}

What compiler are you using? It should have warned you about this.

Cheers,
Malte

 

[Malte Starostik]

[string literal to char* conversion]

Microsoft's VS6. No, it does not give a warning, even if using the highest
warning level (4).

That's a pity. Many warnings are indeed bogus, I can't imagine where
this one would be undue.
Anyway, just remember: don't assign a string literal to a non-const
char* variable. Either use:

void f(char* p);

const char* p = "test";
f(p);

This is only safe as long as you absolutely know f() will
never modify p. This should only ever be needed if
f() is a C function that doesn't declare its argument const

or, if you want a non-const char array that you can write to:
char p[] = "test";
f(p);

This one is safe as long as you know f will not write past
the array's end.
Whenever possible, use std::string instead of (const or not) char*, it
saves a lot of headaches.

Cheers,
Malte

 

[Malte Starostik]

If it's not too much work for you could you tell me where in the standards
this is stated? Where should I look (book, paragraph etc.)?

section 4.2 "Array-to-pointer conversion", paragraph 2 defines the
conversion, Annex D.4 deprecates it.

2.3.4, paragraph 2 makes the modification of a string literal undefined

HTH,
Malte