ProgrammingThis forum is for all programming questions.
The question does not have to be directly related to Linux and any language is fair game.
Notices
Welcome to LinuxQuestions.org, a friendly and active Linux Community.
You are currently viewing LQ as a guest. By joining our community you will have the ability to post topics, receive our newsletter, use the advanced search, subscribe to threads and access many other special features. Registration is quick, simple and absolutely free. Join our community today!
Note that registered members see fewer ads, and ContentLink is completely disabled once you log in.
If you have any problems with the registration process or your account login, please contact us. If you need to reset your password, click here.
Having a problem logging in? Please visit this page to clear all LQ-related cookies.
Get a virtual cloud desktop with the Linux distro that you want in less than five minutes with Shells! With over 10 pre-installed distros to choose from, the worry-free installation life is here! Whether you are a digital nomad or just looking for flexibility, Shells can put your Linux machine on the device that you want to use.
Exclusive for LQ members, get up to 45% off per month. Click here for more info.
Compiler gives following warning: "warning: function returns address of local variable"
I could retrieve following information through debugging:
Content of the variable "file" at exit point (line 13) from functin menue: file = "myfilename\000\000\000\000"
file_name="myfilename" (at line 5)
file_name="\?p\205\004\210\" a very long number of uncommon characters (at line 6 right after printing "menue() ...done")
Isn't it strange that return value from function menue() seems to be fully okay and then suddenly change of values in file_name.
Automatic, local variables are placed on the stack. When the function begins to execute, the stack size is increased to create room for local variables in that function. When the function returns the stack size is returned to its previous size.
This means that your char file[20]="" is not guaranteed to exist when menue() returns. It's possible for the program to work okay, but it might not. To get around this you can declare file as static (i.e. static char file[20];. static variables are not placed on the stack and are guaranteed by the C standard to exist for the life of the program.
You're returning a pointer from an array that was defined locally in your function, hence the warning. My guess would be that once you return from the function, the memory reserved for the 'file' array is no longer reserved, and it is being overwritten.
Don't return a pointer to memory allocated on the local function stack. Very bad practice. You'll end up with dangling pointers.
Declaring it static would help in this case, be be warned that if you do that, whenever it is changed by calling that function, everything that is using the pointer returned from previous calls to that function is going to change as well...
A better solution would be to do something like what strcat, strcpy etc. do... Pass the pointer to an array into the function as a parameter and allocate it externally... Or, malloc the memory within the function and make sure when you are done with it you free it.
Originally posted by exvor yea you declared a constant then you inilized it with no information.
const char * file_name="";
when you did this you created an array with no elements that is a constant or read only.
as for the rest of your code i dont understand it or there is missing information.
You don't understand the bit you think you did, either!
He's declared a const char pointer which he's initialised with the address of a string containing only a terminating null byte, not "no elements". His problem is that the array he's passing out is on the stack and will be overwritten by the next function call, as has been noted by others above.
Originally posted by exvor const char * file_name="";
Yea i got that later looking at it again. Im not just used to seeing them done in that way
normally i use
const char *file_name;
So do I, the initial assignment is redundant. I find I have to study other people's code at least three times to get the hang of what they're doing. My own code often takes even longer.
As noted by other quite a few forum members, the string (char *file) was being destroyed after exiting the function menue().
I changed that variable to static and now it is working fine. SiliconBadger suggested another way of passing the string to menue() function and thus reading the name of the file into this string.
Well, I see this string passing is also done in other c library functions like char *fgets(char *s, ...). Do you think it is a better approach as compared to using static variables?
2. Question: Does it make sense to use const in this declaration of a string with 256 character length?
Code:
3 const char file_name[256];
(ref SiliconBadger suggestion)
3. Question: Exvor,Eddiebaby: Isn't initialization of variables a good practice? I mean why would you people not do the declaration combined with initialization?
For question 2, the const there is making the array unchangable. It has nothing to do with it being a constant length. If you try to change any element of the array when it is const, the compiler will complain. In the above example, I don't think const is really what is wanted as it makes the string you are trying to return unchangable.
For question 3. Initialization is definitely a GOOD THING! If you don't initialize your variables they will be in an unknown state and if you use them before they are assigned a value, you never know what will happen. It is not redundant at all to initialize it. In the above case if you DON'T initialize it, you will be left with a garbage string. And a const garbage string that you can't change, at that.
As a side note, with pointers you can have 2 different const attributes. The data the pointer points to can be const as in:
Code:
char szString[256];
const char* s = szString;
strcpy(s, "This is illegal!");
Or the pointer itself can be const meaning the data it points to can be changed, but the address of the pointer cannot, as in:
Code:
char szString[256];
char szString2[256];
char * const s = szString;
strcpy(s, "This is legal");
s = szString2; // This is not
Or, you can have both of them const, meaning you can't change the address or the value:
Code:
const char * const s = "This is unchangable!";
You probably won't see const pointers too often. Const data is much more common.
Also, if you ever write a threaded program, static variables are a huge no-no. They are not, by any means, thread-safe. This is the primary reason those functions take a pointer.
3. Question: Exvor,Eddiebaby: Isn't initialization of variables a good practice? I mean why would you people not do the declaration combined with initialization?
well you see char *somestring;
is not a variable its a pointer. its actually not even an array its a pointer of type char
you dont need to intilize this because its a pointer
consider the following code
Code:
char *ptr_string;
ptr_string = (char*) malloc (BUFF); // this will make ptr_string point to the
// memory that malloc allocated
char *static_string = "Voodoo"; // this will make an array with the elments
//Voodoo and then point to the array with
//*static_string
// note the above cannot be changed thus you cannot change the elements.
so when you do char *ptr_string = ""; the compiler is just ignoreing the = "" in actuallity its just making
your code harder to read.
and just for more info i have never seen this sort of declaration of a pointer even in a book
from 1994.
NOTE: the example or information on the second one may not be entirely correct but this
is due to a lack of depth of my understanding on pointers. It is indeed something that i need
to get more info on.
excvor, it's a good practice to initialize all values, including pointers. In the case of pointers, NULL is a good value to initialize them to. Just because you are going to be setting them immediately after they are declared doesn't mean it's still not a good practice to initialize them just like any other variable. If nothing else it is a good way to see if the value has been changed later on if you need to do any cleanup.
For example:
Code:
char* pString = NULL;
if (somethingIsTrue)
{
pString = new char[256];
// stuff
}
// stuff
if (pString)
{
delete [] pString;
}
And the compiler does NOT ignore the initialization. If you DON'T initialize it, your pointer will be pointing to some unknown memory location. Otherwise known as a dangling pointer. If you initialize a char* to "" it will be initialized to a location that it stored the constant string "" in. If you initialize it to NULL the address will be 0.
And in the comment on your third line example... that actually doesn't create an array with those values stored in it. At least not at the point of execution. At compile time string constants are generally assigned a location in the object code and then the initialization there just gives the pointer the address to that location.
Note: My examples have been C++ and the thread was asking about C, but the same basic memory ideals apply to C.
And the compiler does NOT ignore the initialization. If you DON'T initialize it, your pointer will be pointing to some unknown memory location. Otherwise known as a dangling pointer. If you initialize a char* to "" it will be initialized to a location that it stored the constant string "" in. If you initialize it to NULL the address will be 0.
forgive my ignorance here but why would you not initilize a pointer?
if i was going to point it to something right away why take up the resources to allocate it to a empty constant string
just seams kinda silly. i understand dangling pointers but if you have them in the first place it would be better to fix
them rather then have them doing nothing and taking up resources.
Actualy re reading the question above and learning more about pointers and stack with functions i
understand what happend as well. as i mentioned before im still learning anyway i guess the discussion above has nothing to do with the question so we should just drop it
LinuxQuestions.org is looking for people interested in writing
Editorials, Articles, Reviews, and more. If you'd like to contribute
content, let us know.