"bneha69" <[EMAIL PROTECTED]> wrote:
>
> /*here I am trying to return an integer pointer even
> when the return
> type of the function is int and it works ,just gives
> warning*/
Saying it works is like saying people with narcolepsy
have no problem sleeping.
> void main()
This is the wrong return type for a C program, main
should return an int.
> {
> int fun1(),*ip;
> clrscr();
> ip=fun1();//warning-non-portable pointer conversion
It's a warning, but it's a very important warning.
The code violates a constraint of the C language. As
such, a conforming compiler is required to issue
a diagnostic.
Compilers typically issue warnings and errors. The C
language doesn't recognise a distinction and compilers
are free to diagnose the problem, even serious ones
like this, as either a warning or an error, or a small
beep, or a quick flash of the screen, or anything that
the compiler classifies as a diagnostic, apart from
doing nothing.
> printf("\nip=%u",ip);
You do not appear to have included <stdio.h>. If that
is so, then your compiler has likely declared printf
implicitly as int printf(). This is the wrong
declaration as printf is a variadic function. The
function types are not compatible.
Unfortunately, the code is not a constraint violation.
So no diagnostic, warning or otherwise, is required.
It also wouldn't hurt for you to end each line of
(text) output with a newline.
> getch();
Like clrscr() above, getch() is not a standard function
and there's no obvious reason why you're using it.
[I know why you're using it, but I'm still going to
tell you there's no reason to use it.]
> }
> int fun1()
> {
> int a;
> return &a;//warning-non-portable pointer conversion
> }
Again, this suitable as the required diagnostic.
Converting pointers to integers and vice versa is
allowed in certain circumstances. However, implicit
conversion of them (i.e. without a cast) violates
a constraint.
Even if you actually do use a cast, there is no
guarantee that the program won't crash on return
when you assign it back to a pointer because there is
no guarantee that the conversion makes sense.
Consider an implementation that uses 32-bit pointers,
but only 16-bit ints. If you can have more than 65536
pointers in your program, then there's no possible way
the conversion would work for any pointer.
The latest C standard (C99) allows C implementations to
(optionally) provide a type called intptr_t (and a
corresponding uintptr_t). If available, that type will
have useful properties. [I use the word 'useful'
advisedly.]
<snip>
> char fun1()
> {
> char a;
> return &a;//error-non-portable pointer conversion
> }
Again, a required diagnostic has been issued. That's all
a compiler is required to do.
Why is one an error and the is a warning is something
you could take up with the compiler vendour, but then,
why bother?
<snip>
> I want to ask that if we return a pointer to int when
> the function's return type is int. It works.
No. Sticking a fork into a live toaster may work on
many occasions. It is not required to work forever.
However long it works for won't change the fact that
it is a silly thing to do and even trying it is a
waste of time when there are more fruitful endeavors
to spend your life on. ;)
> It does not give any error.But in case
> of others' data type ,it gives error.
> Why and how does it happen?
You're trying to analyse the behaviour of broken programs.
This has great curiosity value, but very little practical
value from the point of view of becoming a sound
programmer of quality C (or C++) programs.
Learn what not to do and avoid it. Don't make studying
the behaviour of programs that shouldn't be doing what
they're doing your major priority.
--
Peter
