typedef struct abc_ *abc;
static abc param;
abc fun(void)
{
float *a = NULL;
a = (float *)malloc(sizeof(float));
if (a) {
return ((abc)(a));
}
return NULL;
}
int main()
{
param = fun();
printf("test_bandwidth_alloc: %x\n", param);
free(param);
}
a has type (float *). abc is alias for (struct abc_ *).
These two types can have different representation and size.
> }
> return NULL;
> }
>
> int main()
> {
> param = fun();
> printf("test_bandwidth_alloc: %x\n", param);
Here you pass a (struct abc_ *) where printf expects unsigned int, and
you invoke undefined behavior.
> free(param);
>
> }
But there is no structure(abc) defined in the whole code then what it
is aliasing?
> But there is no structure(abc) defined in the whole code then what it
> is aliasing?
All pointers to struct have the same size and representation. The
compiler doesn't need to know what struct abc_ is in order to have a
pointer to it; The compiler just needs to know it's a struct.
But memory pointed to by the pointer must be known at least If I do
perform any pointer arithmetic then by what size it gets incremented
and point to next memory?
You can't. It's a pointer to incomplete type.
You also can't perform arithmetic operations on pointers such as:
int (*foo)[];
et cetera.
We can increment the pointers and decrement and subtract.., And I said
pointer arithmetic not arithmetic operations on pointers.,
> The Code is compiling without Error/Bug/Exception..,
> What are the possibilities for this behaviour?
> //***************************************************************
> #include<stdio.h>
>
> typedef struct abc_ *abc;
>
> static abc param;
>
> abc fun(void)
> {
> float *a = NULL;
> a = (float *)malloc(sizeof(float));
Because you failed to #include <stdlib.h> you have failed to provide a
declaration for malloc.
Because there is no declaration for malloc, the compiler is obliged to
assume that malloc returns int, even though we all know it really returns
void *.
Implementations can legitimately generate code that can retrieve an int
return value from a different register than a pointer return value. So,
for example, malloc could place its pointer in a given register, but the
calling code - generated on the we-know-it's-false but obligatory
assumption that malloc returns int - could fetch the value from a
different register, with hilarious results. (That's just one scenario of
how things can go wrong here - there are others.)
Because of this danger, the compiler is obliged to issue a diagnostic
message when you screw up types this badly - but if you explicitly insist
(via the cast) that the compiler should just do it, the obligation to warn
you is removed.
From this point on, the behaviour of the code is undefined, and anything
can happen. And that may well be why you are getting the behaviour you
observe. Or, of course, it may not. That's what is so exciting about
undefined behaviour.
--
Richard Heathfield <http://www.cpax.org.uk>
Email: -http://www. +rjh@
Google users: <http://www.cpax.org.uk/prg/writings/googly.php>
"Usenet is a strange place" - dmr 29 July 1999
No, you can't - not without defining struct abc_
typedef struct foo *my_type;
my_type pointer= WHATEVER; /* is allowed */
pointer+= 4; /* is NOT allowed */
struct bar {
int a;
char b;
};
typedef struct bar *other_type;
other_type other_pointer= WHATEVER; /* is allowed */
other_pointer+= 4; /* is allowed */
What behavior were you expecting? Why?
I have cleaned up your code a little. Note that the return statement in
fun() is not illegal, just stupid.
#include<stdio.h>
#include <stdlib.h> /* mha: added, otherwise malloc is
assumed to return an int, which it
does not do. */
typedef struct abc_ *abc;
static abc param;
abc fun(void)
{
float *a = NULL;
a = malloc(sizeof *a); /* mha: removed stupid cast and fixed
poor style in the argment */
if (a)
return (abc) a; /* mha: note that this is very stupid */
return NULL;
}
int main()
{
param = fun();
/* mha: fixed printf specifier _and_ argument below */
printf("test_bandwidth_alloc: %p\n", (void *) param);
free(param);
}
I didn't get..., Why it would compile in the first place if this is
the problem? And also it is not possible to overload the functions in
C, In same header file declaration, And from where did it get its
declaration? and according to C standard malloc return a generic
pointer to the requested size of bytes memory.
(I am using DevC++ compiler for testing)
> On Sep 5, 12:45 pm, Richard Heathfield <r...@see.sig.invalid> wrote:
<snip>
>>
>> From this point on, the behaviour of the code is undefined, and anything
>> can happen. And that may well be why you are getting the behaviour you
>> observe. Or, of course, it may not. That's what is so exciting about
>> undefined behaviour.
>>
>
> I didn't get..., Why it would compile in the first place if this is
> the problem?
It isn't *the* problem, merely *a* problem. We often find that our code has
more faults in it than we would like to imagine.
Firstly, there are several ways in which a program can be wrong, but very
few circumstances in which a compiler *must* refuse to translate the
program. If the program contains any syntax errors or constraint
violations, the compiler (or interpreter, of course - I use the term
"compiler" in a very broad sense here) is required to issue at least one
diagnostic message, but it is still allowed to translate the program. In
any case, as far as I can recall, your program did not violate any
constraints or syntax rules. But that doesn't mean it's a correct program!
> And also it is not possible to overload the functions in
> C,
Well, it would be more correct to say that to attempt to do so results in
an incorrect program.
> In same header file declaration, And from where did it get its
> declaration?
The compiler *didn't* get a declaration! That's why it was forced to make
one up, according to rules which don't cope well with the situation that
your code introduced. In the absence of a function declaration for a
function that your program calls, the compiler (as I explained earlier) is
obliged to assume that the function in question returns int, even if we
know that it doesn't really - and that is the problem here.
> and according to C standard malloc return a generic
> pointer to the requested size of bytes memory.
Right (if the call succeeds) - but your failure to declare malloc (by
failing to include <stdlib.h>) means that the compiler doesn't actually
know this.
> (I am using DevC++ compiler for testing)
It doesn't matter - C is C. (I assume, perhaps wrongly, that you are
invoking the compiler in C mode, not C++ mode.)
ITYM
#include <stdio.h>
#include <stdlib.h> /* Required for malloc() and free() */
typedef struct abc_ *abc;
static abc param;
abc fun(void)
{
/* Don't cast malloc, don't give types to sizeof */
float *a = malloc(sizeof *a);
if(a)
return (abc) a; /* Cleaned up, this is very suspicious.. */
return NULL;
}
int main(void)
{
param = fun();
/* You used %x, which you can't pass a pointer to. Use %p instead: */
printf("test_bandwidth_alloc: %p\n", (void *) param);
free(param);
}
--
Andrew Poelstra <apoe...@wpsoftware.com>
To email me, change .net to .com in the above address.
I just realized my reader isn't hiding my real address...
Why The Above line also did not generate exception?
That line is equivalent to
static struct abc_ *param;
As several people have tried to explain, it's perfectly legal to
declare a pointer to an incomplete struct type. All pointers to
structs have the same size, regardless of the size of the struct type
itself, so you can create a pointer to a struct before you know the
struct definition.
> Sorry I got the BUG..., It is specifically related to compiler..,
Given the "quality" of the code you've posted here, I would not blame
any compiler at this point, if I were you.
Richard
Even compilers get frustrated?
Brian