Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss

Please Explain This behaviour...,

0 views
Skip to first unread message

Pranav

unread,
Sep 5, 2008, 2:50:12 AM9/5/08
to
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));
if (a) {
return ((abc)(a));
}
return NULL;
}

int main()
{
param = fun();
printf("test_bandwidth_alloc: %x\n", param);
free(param);
}

vipp...@gmail.com

unread,
Sep 5, 2008, 2:59:19 AM9/5/08
to
On Sep 5, 9:50 am, Pranav <pranav...@gmail.com> wrote:
> 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));
> if (a) {
> return ((abc)(a));

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);
>
> }

Pranav

unread,
Sep 5, 2008, 3:03:23 AM9/5/08
to

But there is no structure(abc) defined in the whole code then what it
is aliasing?

vipp...@gmail.com

unread,
Sep 5, 2008, 3:04:39 AM9/5/08
to
On Sep 5, 10:03 am, Pranav <pranav...@gmail.com> wrote:
<snip>

> 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.

Pranav

unread,
Sep 5, 2008, 3:09:52 AM9/5/08
to

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?

vipp...@gmail.com

unread,
Sep 5, 2008, 3:17:42 AM9/5/08
to

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.

Pranav

unread,
Sep 5, 2008, 3:22:53 AM9/5/08
to

We can increment the pointers and decrement and subtract.., And I said
pointer arithmetic not arithmetic operations on pointers.,

Richard Heathfield

unread,
Sep 5, 2008, 3:45:31 AM9/5/08
to
Pranav said:

> 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

viza

unread,
Sep 5, 2008, 3:51:22 AM9/5/08
to

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 */

Martin Ambuhl

unread,
Sep 5, 2008, 3:57:58 AM9/5/08
to
Pranav wrote:
> The Code is compiling without Error/Bug/Exception..,
> What are the possibilities for this behaviour?

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);
}

Pranav

unread,
Sep 5, 2008, 4:44:39 AM9/5/08
to

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)

Richard Heathfield

unread,
Sep 5, 2008, 5:58:32 AM9/5/08
to
Pranav said:

> 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.)

Andrew Poelstra

unread,
Sep 5, 2008, 8:23:52 AM9/5/08
to

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...

Pranav

unread,
Sep 5, 2008, 8:50:05 AM9/5/08
to
static abc param;

Why The Above line also did not generate exception?

Pranav

unread,
Sep 5, 2008, 9:16:52 AM9/5/08
to

Sorry I got the BUG..., It is specifically related to compiler..,

John Bode

unread,
Sep 5, 2008, 4:14:22 PM9/5/08
to
On Sep 5, 7:50 am, Pranav <pranav...@gmail.com> wrote:
> static abc param;
>
> 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.

Richard Bos

unread,
Sep 8, 2008, 10:08:37 AM9/8/08
to
Pranav <pran...@gmail.com> wrote:

> 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

Default User

unread,
Sep 8, 2008, 1:59:01 PM9/8/08
to
Richard Bos wrote:

Even compilers get frustrated?


Brian

0 new messages