   Lifetime of strings
  Hi,In C and/or C++, if I create a string as:void someFunc() { char *str = "some text";}is the memory pointed to by str guaranteed to be valid for the lifetime of the program, after the method in which it is declared has returned?I ask because I use it when sending text headers using WinSock.When sending with WSASend one can pass it one or more buffers, each which will be sent in turn during a non-blocking operation. The memory isn't copied before the method returns. Simply giving it such a string as above works fine for me, however I don't know if this is guaranteed.   
Quote:Original post by Erik RufeltIn C and/or C++, if I create a string as:void someFunc() { char *str = "some text";}is the memory pointed to by str guaranteed to be valid for the lifetime of the program, after the method in which it is declared has returned?String literals typically are stored in the static data section of the executable, so they will persist for the lifetime of the application.However, since you mention C++, you should really be passing around (and returning) std::strings instead. It is especially painful if you are passing around literals, and then try to pass the result of strcat(), or snprintf() by mistake.   ;Quote:Original post by Erik Rufeltis the memory pointed to by str guaranteed to be valid for the lifetime of the programYes, string constants (strings produced by string literals) have static storage class.Quote:K&R A2.6A string literal, also called a string constant, is a sequence of characters surrouned by double quotes, as in "...". A string has type "array of characters" and storage class static and is initialized with the given characters. Wether identical string literals are distinct is implementation-defined, and the behavior of a program that attempts to alter a string literal is undefined.So it is good practice to writeconst char *p = "some string";instead ofchar *p = "some string";to prevent yourself from trying to alter a string literal.Note that the following is a completely different thing:char s[] = "somestring";While p was a pointer to the first character of an array of characters, s IS an array of characters which will cease to exist when s goes out of scope. So you should NEVER do something like this:char *function(int a, int b){    char s[] = "test00";    s[4] = '0' + a;    s[5] = '0' + b;    return s; // s decays into a pointer which points to something that is going to die... NOW};  Thanks for the replies!Seems I'm good to go then =)swiftcoder you mention string objects, however I don't think they will work well in my scenario. Any recommendations about the method I'm using, as explained below?When using the WSASend function for overlapped sends the buffers given to the function are owned by the system until the operation is complete, according to http://msdn.microsoft.com/en-us/library/ms742203(VS.85).aspxQuote:Each WSABUF structure contains a pointer to a buffer and the length, in bytes, of the buffer. For a Winsock application, once the WSASend function is called, the system owns these buffers and the application may not access them. This array must remain valid for the duration of the send operation.My application is built with I/O completion ports, such that some thread posts a WSASend operation with some databuffers, and then continues with different tasks. At a later time some thread (the same or another) receives a completion notification of the send operation, when it is completed (the data is sent, or copied and buffered by WinSock).At this time that thread must free the memorybuffers, or use them for something else, or save them for later or whatever, so that I don't get memory leaks.Using string constants seems to work very well with this. In this case I can simply ignore the completion notification, since no memory needs to be freed.Example, for sending a HTTP request for a file:void sendGET(char *path) { WSABUF buffers[3];  buffers[0].buf = "GET "; buffers[0].len = strlen(buffers[0].buf); buffers[1].buf = path; buffers[1].len = strlen(buffers[1].buf); buffers[2].buf = " HTTP/1.1\r\nHost: www.something.com\r\n\r\n"; buffers[2].len = strlen(buffers[2].buf);  WSASend(..., buffers, 3, ...);}This allows for quick and easy sending, provided that the 'path' variable passed to the function points to memory that will remain untouched for the duration of the send, for example another string constant.For this case this method seems very fitting to me.The WSABUF.buf is not constant however.. but I don't think that WinSock would ever try and change it for a send operation, it's probably just because the same structure is used with WSARecv.   ;  I am confused here.Wont the string only be in memory until the function ends?Wont it then go out of scope?   ;Quote:Original post by lonewolffWont the string only be in memory until the function ends?Wont it then go out of scope?Let's discuss the two versions again. Version 1:char *function1(){    char *p = "hello world!"; // p points to "hello world!"    return p;}p is a local variable, so it will go out of scope when the function ends. But that is not a problem, since p is only a pointer to a string constant (and string constants have static memory storage). We return a copy of that pointer. The pointee (the string itself) persists for the complete runtime of the program. Look again at the language specification for string constants:Quote:K&R A2.6A string literal, also called a string constant, is a sequence of characters surrouned by double quotes, as in "...". A string has type "array of characters" and storage class static and is initialized with the given characters. Wether identical string literals are distinct is implementation-defined, and the behavior of a program that attempts to alter a string literal is undefined.Version 2:char *function2(){    char s[] = "hello world!"; // s is a copy of "hello world!"    return s;}s is a local variable, so it will go out of scope when the function ends. This is a serious problem, since s IS the string itself. The first line of the function effectively copies the 13 characters from the string constant to the local variable s. sizeof(s) == 13. In the second line, s decays into a pointer to its first element, so we return a pointer to an object with automatic storage - it won't exist anymore once the function ends. This is BAD, and any decent compiler should warn you about this.Clear?   