What is the expected output for this char pointer function in Turbo C++?

[Raghav Gupta]

Homework Statement

This is the code on Turbo C++

char * disp()
{  
       int a [ ] = {49,15,50,34} ;
       char c [ ] ="1234" ;
       for (int i= 0; i<3 ; i++)
         c[i] =a[i] + c[i];
       cout<<c;
       return c;
}

void main()
{
      clrscr();
      cout<<" ,"<<disp()<<endl;
      getch();
}

What will be the output for this:
1. bAe4, undefined
2. bAe4, bAe4

Homework Equations

The Attempt at a Solution

I ran the program on turbo c++ and it was giving me the 1st option as output (undefined here I guess means random symbols like smilies which were appearing on my screen).
I thought it should be the 2nd one.
I know how we are getting bAe4 which is related to ASCII manipulation.
The thing is that when we are returning the c, it would be holding the same characters.
So, in the cout statement of main(), we should get bAe4 once again.
Why is that not true?

 

[Mark44]

Homework Statement

This is the code on Turbo C++

char * disp()
{
       int a [ ] = {49,15,50,34} ;
       char c [ ] ="1234" ;
       for (int i= 0; i<3 ; i++)
         c[i] =a[i] + c[i];
       cout<<c;
       return c;
}

void main()
{
      clrscr();
      cout<<" ,"<<disp()<<endl;
      getch();
}

What will be the output for this:
1. bAe4, undefined
2. bAe4, bAe4

Homework Equations

The Attempt at a Solution

I ran the program on turbo c++ and it was giving me the 1st option as output (undefined here I guess means random symbols like smilies which were appearing on my screen).
I thought it should be the 2nd one.
I know how we are getting bAe4 which is related to ASCII manipulation.
The thing is that when we are returning the c, it would be holding the same characters.
So, in the cout statement of main(), we should get bAe4 once again.
Why is that not true?

The array named c is a local variable in your disp() function. The scope of c is only within disp(), so the call to cout within disp() works as expected, but c ceases to exist after the return from disp(). In Visual Studio, which I'm running, the compiler resets the memory that the c array was using after the return from disp(), so the call to cout in main() results in uninitialized garbage.

 

[Raghav Gupta]

The array named c is a local variable in your disp() function. The scope of c is only within disp(), so the call to cout within disp() works as expected, but c ceases to exist after the return from disp(). In Visual Studio, which I'm running, the compiler resets the memory that the c array was using after the return from disp(), so the call to cout in main() results in uninitialized garbage.

But why the output for this is 8 instead of garbage then, x also have scope to fact() only ?

#include<iostream.h>
#include<conio.h>
int fact()
{
    int x=8;
    return x;
}

void main()
{
   clrscr();
   cout<<fact();
   getch();
}

 

[Merlin3189]

Perhaps because it is an integer value which is returned on the stack. The storage for x is reset, but the value is on the stack.
In your first example the returned value is a pointer to an array which no longer exists. You get a pointer on the stack, but where it points is no longer valid.

 

[Mark44]

But why the output for this is 8 instead of garbage then, x also have scope to fact() only ?

#include<iostream.h>
#include<conio.h>
int fact()
{
    int x=8;
    return x;
}

void main()
{
   clrscr();
   cout<<fact();
   getch();
}

In the earlier example of this thread, your disp() function returned an address, so the actual value returned was correct, but this was the address of a local variable, and the memory at that address was reinitialized just after the disp() function returned. This caused garbage to be displayed in main().

Perhaps because it is an integer value which is returned on the stack.

Since the value being returned is an int, it's more likely that it is being returned in a register, especially if the machine is one with an x86 architecture.

 

[Raghav Gupta]

In the earlier example of this thread, your disp() function returned an address, so the actual value returned was correct, but this was the address of a local variable, and the memory at that address was reinitialized just after the disp() function returned. This caused garbage to be displayed in main().

So the return is useful for int, double and other data types except char in this type of architecture?
Edit: It works for char also, also char* but not char[ ]

 

[Mark44]

So the return is useful for int, double and other data types except char in this type of architecture?
Edit: It works for char also, also char* but not char[ ]

Right (including your edit comment). You can return a scalar (i.e, char, short, int, long, float, double, etc), but if you return a pointer, the contents of the memory at that location will be garbage if what is pointed to is of local scope.

 

[Raghav Gupta]

Right (including your edit comment). You can return a scalar (i.e, char, short, int, long, float, double, etc), but if you return a pointer, the contents of the memory at that location will be garbage if what is pointed to is of local scope.

Ok but it is correct I think in case of int pointer. Only char pointers have problem?
Also after a scope ends, memory is reinitialized and since pointer points to memory its contents gets changed but in case of returning a scalar what is happening?
Why scalar memory also not changes and therefore its value?

 

[Mark44]

Ok but it is correct I think in case of int pointer. Only char pointers have problem?

No, it doesn't really have to do with the type of data that is pointed to, but it does seem to be that char arrays get reinitialized when they go out of scope, and other arrays don't have this happen (based on my installation of Visual Studio). Nevertheless, it's a bad idea to return a pointer to a local variable of a function. There's no guarantee that what's at that address won't have changed.

Also after a scope ends, memory is reinitialized and since pointer points to memory its contents gets changed but in case of returning a scalar what is happening?
Why scalar memory also not changes and therefore its value?

Whatever you return gets copied somewhere, likely to one of the CPU registers. If you return a pointer to some type, that address gets copied with no problem, but what's at the address may or may not be valid if the thing pointed to is a local variable that's now out of scope.

 

[NascentOxygen]

So if this statement char c [ ] ="1234" ; were moved into main() then the program should execute as hoped?

 

[Mark44]

So if this statement char c [ ] ="1234" ; were moved into main() then the program should execute as hoped?

No.
Here's the change you described:

char * disp()
{
       int a [ ] = {49,15,50,34} ;
     
       for (int i= 0; i<3 ; i++)
         c[i] =a[i] + c[i];
       cout<<c;
       return c;
}

void main()
{
      clrscr();
      char c [ ] ="1234" ;
       cout<<" ,"<<disp()<<endl;
      getch();
}

The code above won't compile, as the identifier c isn't known to or accessible by the disp() function. Here the scope of the identifier c is just main().

You could get around this by declaring c outside of all functions, making it a global variable, like so:

char * disp();   // Declaration of disp() function
char c [ ] ="1234" ;  // Array c is now global, accessible by both main() and disp()

int main()
{
    cout<<" ,"<<disp()<<endl;
    return 0;
}

char * disp()
{
   int a [ ] = {49,15,50,34} ;
      
   for (int i= 0; i<3 ; i++)
         c[i] =a[i] + c[i];
   cout<<c;
   return c;
}

Note that I have modified the original code somewhat, by moving main() to the top (my preference), and removing some nonessential lines of code. Also, this isn't complete code, as it doesn't either include the necessary header files or have the proper using statement.
This workaround is not an ideal solution, as global variables are discouraged, for the most part.

Here is a better solution, and one that is a complete, working program.

using std::cout;
using std::endl;

char * disp(char *);   // Declaration of disp() function
 
int main()
{
    char c [ ] ="1234" ;
    cout << " ," << disp() << endl;
    return 0;
}

char * disp(char * c)
{
   char a [ ] = {49, 15, 50, 34} ;
      
   for (int i = 0; i < 3 ; i++)   // Note that only c[0], c[1], and c[2] are modified
         c[i] = a[i] + c[i];
   cout << c;
   return c;
}

Output is bAe4 , bAe4, same as 2nd answer in the original post.

 

[Raghav Gupta]

Nevertheless, it's a bad idea to return a pointer to a local variable of a function. There's no guarantee that what's at that address won't have changed.

In linked list we usually do that -returning head node.
Eg:
Linkedlist * Linkedlist::del (int val, Linkedlist* head){
...
...
return head;}
Here head does not get reinitialized.
Is it only the problem with char arrays?

 

[Mark44]

In linked list we usually do that -returning head node.
Eg:
Linkedlist * Linkedlist::del (int val, Linkedlist* head){
...
...
return head;}
Here head does not get reinitialized.
Is it only the problem with char arrays?

but it does seem to be that char arrays get reinitialized when they go out of scope, and other arrays don't have this happen (based on my installation of Visual Studio).

 

[Raghav Gupta]

So, it depends on the type of software which you have and compilers? As apart from visual studio this also happens on turbo c++

 

[Mark44]

So, it depends on the type of software which you have and compilers? As apart from visual studio this also happens on turbo c++

It is probably implementation-dependent. As far as I know, there is nothing in how the language is defined that causes this to happen.

 

[Raghav Gupta]

It is probably implementation-dependent. As far as I know, there is nothing in how the language is defined that causes this to happen.

So in general, we should not return pointers by the definition of language. It was only chance or implementation dependent that I was getting correct value for integer arrays?

 

[Mark44]

So in general, we should not return pointers by the definition of language.

It has nothing to do with how the language is defined. If a variable is defined inside a function, it is local to that function. The function should not return a pointer to that variable, because there's no guarantee that the memory being pointed to won't get re-used for some other purpose (hence, have its value changed).

It was only chance or implementation dependent that I was getting correct value for integer arrays?

That's what I think.

 

[Raghav Gupta]

Thanks for solving queries.