0

Basically, I am trying to increment the int value of port. This should be easy but I am a little stuck.

It compile fine, but I got this error when I run it: Access violation writing location 0x001f5834 

#include "stdafx.h"
#include "iostream"

using namespace std;
#define TESTING "5002"
int main()
{
    char* port = TESTING;
    int portint;
    sscanf ( port, "%d", &portint );
    portint++;
    cout << portint << endl; // it works fine up to here, it prints 5003
    sprintf ( port, "%d", portint);
    return 0;
}
Samer
  • 1,923
  • 3
  • 34
  • 54
  • 3
    Because "5002" creates a `const char[]` decaying to `const char*` which are read only. Do `char[] x = TESTING; char* port = x`; – GoldRoger Apr 17 '14 at 20:22
  • Is there anyway around this? I have to use this line: char* port = TESTING; – Samer Apr 17 '14 at 20:25
  • @WhozCraig: That's a C question, this is C++ code. Not a duplicate. Or rather, we can find a better duplicate. – Ben Voigt Apr 17 '14 at 20:32
  • @Zan: same complaint as to Whoz – Ben Voigt Apr 17 '14 at 20:32
  • @BenVoigt: Although I'd say since his code is using almost all C, let's replace his cout with printf and relabel it C. – Zan Lynx Apr 17 '14 at 20:33
  • 1
    @Zan: No, no no. It's still C++ since he's using a C++ compiler. The C rules simply do not apply. Even if you replace `std::cout` with `printf`, the correct tag is still `c++`, not `c`. – Ben Voigt Apr 17 '14 at 20:33
  • @BenVoigt: Since C is incorporated into C++ by reference, most of the rules do apply. – Zan Lynx Apr 17 '14 at 20:34
  • 1
    @ZanLynx: I'm talking about this particular scenario. Completely different rules apply to string literals in C++. Also, no the C language isn't incorporated by reference. Only functions from the C standard library. – Ben Voigt Apr 17 '14 at 20:35
  • @BenVoigt were it not for the tags on the question, I would not have linked it. (and will neither rescind my close-vote for said-same). – WhozCraig Apr 17 '14 at 20:35
  • @BenVoigt: As far as I can tell, the rules are exactly the same up until c++11. – Zan Lynx Apr 17 '14 at 20:40
  • @Zan: C++98, C++03, and C++11 may have the same rules regarding narrow string literals as each other, but not the same as C89, C90, and C11. – Ben Voigt Apr 17 '14 at 20:42
  • @BenVoigt: I'd be interested in finding out what you're thinking here: http://stackoverflow.com/questions/23145793/string-literal-differences-between-c-and-c – Zan Lynx Apr 18 '14 at 00:54

3 Answers3

2

By default, compiler treats string literals as immutable, and an attempt to modify the contents of one results in an access violation error at run time because these strings are put into code segment, and it's read only. In your case, TESTING is a string literal, you can't not change its values. Try: 

 char port[] = "5002";

Meanwhile, the compiler should have warning on this: when you assign a const char* type to a char* type.

MS C++ compiler has a compiler option regards this: Zc:strictStrings.

Matt
  • 6,010
  • 25
  • 36
0

You are trying to write "5003" back into "5002". "5002" is a string literal and cannot be written to.

I'll try to find a good duplicate for this question, because it has been asked in many ways, many times.

Zan Lynx
  • 53,022
  • 10
  • 79
  • 131
0

In your usage, "5002" becomes a static array of characters and as such can not be modified. I believe K&R address this, but I don't have the book in front of me right now. Behavior would be different if you had declared an array.

cdkMoose
  • 1,646
  • 19
  • 21
  • This is C++, so the relevant rule is the one which sets the type of a string literal to `const char[N]`. It's a `const` object, and const objects cannot be modified. – Ben Voigt Apr 17 '14 at 20:31
  • Question was also tagged as "C". Also, I think my english "static array of characters" compiles to "const char[N]". – cdkMoose Apr 17 '14 at 20:37
  • And aren't you proud. I would understand your insistence if I gave a code example that was wrong, but I don't see anything wrong with my english explanation, which I believe actually conveys a better explanation than just the correct line of code. – cdkMoose Apr 17 '14 at 20:53
  • I didn't say there was anything wrong with your explanation. I'm just giving a more technical version, for readers who want that. (Although you are wrong to suggest looking at K&R for this) – Ben Voigt Apr 17 '14 at 20:55