Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.c > #22691 > unrolled thread

Different sizes of data and function pointers on a machine -- void* return type of malloc, calloc, and realloc

Back to article view | Back to comp.lang.c

Contents

  Different sizes of data and function pointers on a machine -- void* return type of malloc, calloc, and realloc Myth__Buster <raghavanil4m@gmail.com> - 2012-06-25 09:08 -0700
    Re: Different sizes of data and function pointers on a machine -- void* return type of malloc, calloc, and realloc "christian.bau" <christian.bau@cbau.wanadoo.co.uk> - 2012-06-25 09:16 -0700
      Re: Different sizes of data and function pointers on a machine -- void* return type of malloc, calloc, and realloc Myth__Buster <raghavanil4m@gmail.com> - 2012-06-25 12:08 -0700
        Re: Different sizes of data and function pointers on a machine -- void* return type of malloc, calloc, and realloc James Kuyper <jameskuyper@verizon.net> - 2012-06-25 15:27 -0400
        Re: Different sizes of data and function pointers on a machine -- void* return type of malloc, calloc, and realloc Eric Sosman <esosman@ieee-dot-org.invalid> - 2012-06-25 15:30 -0400
          Re: Different sizes of data and function pointers on a machine -- void* return type of malloc, calloc, and realloc Myth__Buster <raghavanil4m@gmail.com> - 2012-06-25 12:47 -0700
            Re: Different sizes of data and function pointers on a machine -- void* return type of malloc, calloc, and realloc Eric Sosman <esosman@ieee-dot-org.invalid> - 2012-06-25 16:10 -0400
        Re: Different sizes of data and function pointers on a machine -- void* return type of malloc, calloc, and realloc Ben Bacarisse <ben.usenet@bsb.me.uk> - 2012-06-25 20:42 +0100
          Re: Different sizes of data and function pointers on a machine -- void* return type of malloc, calloc, and realloc Myth__Buster <raghavanil4m@gmail.com> - 2012-06-25 13:14 -0700
            Re: Different sizes of data and function pointers on a machine --   void* return type of malloc, calloc, and realloc Ian Collins <ian-news@hotmail.com> - 2012-06-26 08:30 +1200
              Re: Different sizes of data and function pointers on a machine -- void* return type of malloc, calloc, and realloc Myth__Buster <raghavanil4m@gmail.com> - 2012-06-25 13:53 -0700
                Re: Different sizes of data and function pointers on a machine --   void* return type of malloc, calloc, and realloc Ian Collins <ian-news@hotmail.com> - 2012-06-26 09:00 +1200
                Re: Different sizes of data and function pointers on a machine -- void* return type of malloc, calloc, and realloc James Kuyper <jameskuyper@verizon.net> - 2012-06-25 17:13 -0400
                Re: Different sizes of data and function pointers on a machine -- void* return type of malloc, calloc, and realloc Myth__Buster <raghavanil4m@gmail.com> - 2012-06-25 13:58 -0700
                  Re: Different sizes of data and function pointers on a machine -- void* return type of malloc, calloc, and realloc Owen Jacobson <angrybaldguy@gmail.com> - 2012-06-26 00:03 -0400
            Re: Different sizes of data and function pointers on a machine -- void* return type of malloc, calloc, and realloc James Kuyper <jameskuyper@verizon.net> - 2012-06-25 16:47 -0400
            Re: Different sizes of data and function pointers on a machine -- void* return type of malloc, calloc, and realloc gordonb.vk4xa@burditt.org (Gordon Burditt) - 2012-06-25 16:06 -0500
            Re: Different sizes of data and function pointers on a machine -- void* return type of malloc, calloc, and realloc Keith Thompson <kst-u@mib.org> - 2012-06-25 14:17 -0700
            Re: Different sizes of data and function pointers on a machine -- void* return type of malloc, calloc, and realloc Eric Sosman <esosman@ieee-dot-org.invalid> - 2012-06-25 17:24 -0400
    Re: Different sizes of data and function pointers on a machine -- void* return type of malloc, calloc, and realloc James Kuyper <jameskuyper@verizon.net> - 2012-06-25 12:52 -0400
      Re: Different sizes of data and function pointers on a machine -- void* return type of malloc, calloc, and realloc Myth__Buster <raghavanil4m@gmail.com> - 2012-06-25 12:28 -0700
        Re: Different sizes of data and function pointers on a machine -- void* return type of malloc, calloc, and realloc James Kuyper <jameskuyper@verizon.net> - 2012-06-25 15:59 -0400
        Re: Different sizes of data and function pointers on a machine -- void* return type of malloc, calloc, and realloc Keith Thompson <kst-u@mib.org> - 2012-06-25 14:08 -0700
        Re: Different sizes of data and function pointers on a machine -- void* return type of malloc, calloc, and realloc Nobody <nobody@nowhere.com> - 2012-06-26 21:29 +0100
    Re: Different sizes of data and function pointers on a machine -- void* return type of malloc, calloc, and realloc Keith Thompson <kst-u@mib.org> - 2012-06-25 13:13 -0700
    Re: Different sizes of data and function pointers on a machine -- void* return type of malloc, calloc, and realloc Paul N <gw7rib@aol.com> - 2012-06-25 13:17 -0700

Page 1 of 2  [1] 2  Next page →

#22691 — Different sizes of data and function pointers on a machine -- void* return type of malloc, calloc, and realloc

In reference with the below code,

#include <stdlib.h>
#include <stdio.h>

int f(void)
{
    printf("\n In f . . . \n");
}

int main(void)
{
    int (*p)(void) = malloc(sizeof(int (*)(void)));
    
    return 0;     
}

I would like to question about the return type of malloc(calloc, and realloc).

Assume that the above code runs on a machine wherein the data pointers and function pointers are of different sizes. Then, what malloc returns is a function pointer but after casting it to void* while returning(Or, after assigning it to a void* variable internally and returning its value).

Now, isn't malloc giving us the truncated address in the above context? Consider the same question applicable to calloc and realloc when used in such a context.

Cheers,
Raghavan Santhanam





 

[toc] | [next] | [standalone]

#22693

On Jun 25, 5:08 pm, Myth__Buster <raghavani...@gmail.com> wrote:

> Assume that the above code runs on a machine wherein the data pointers and function pointers are of different sizes. Then, what malloc returns is a function pointer but after casting it to void* while returning(Or, after assigning it to a void* variable internally and returning its value).
>
> Now, isn't malloc giving us the truncated address in the above context? Consider the same question applicable to calloc and realloc when used in such a context.

malloc always returns a data pointer. You can ask it to return a data
pointer to some memory area that is big enough to hold a function
pointer, but it will still be a data pointer.

Maybe the situation would be less confusing to you if you first
declare a struct with a single member that is a function pointer, then
use malloc to return a data pointer pointing to one such struct.

[toc] | [prev] | [next] | [standalone]

#22701

On Monday, June 25, 2012 9:16:07 AM UTC-7, christian.bau wrote:
> On Jun 25, 5:08 pm, Myth__Buster <raghavani...@gmail.com> wrote:
> 
> > Assume that the above code runs on a machine wherein the data pointers and function pointers are of different sizes. Then, what malloc returns is a function pointer but after casting it to void* while returning(Or, after assigning it to a void* variable internally and returning its value).
> >
> > Now, isn't malloc giving us the truncated address in the above context? Consider the same question applicable to calloc and realloc when used in such a context.
> 
> malloc always returns a data pointer. You can ask it to return a data
> pointer to some memory area that is big enough to hold a function
> pointer, but it will still be a data pointer.
> 
> Maybe the situation would be less confusing to you if you first
> declare a struct with a single member that is a function pointer, then
> use malloc to return a data pointer pointing to one such struct.

Yeah, had thought of it earlier(struct-approach being feasible due to data pointer involvement). But, wanted to accomplish the same with a malloc call by passing the sizeof a function pointer. So, malloc's documentation should include a note on this, isn't it?

[toc] | [prev] | [next] | [standalone]

#22702

On 06/25/2012 03:08 PM, Myth__Buster wrote:
> On Monday, June 25, 2012 9:16:07 AM UTC-7, christian.bau wrote:
>> On Jun 25, 5:08 pm, Myth__Buster <raghavani...@gmail.com> wrote:
>>
>>> Assume that the above code runs on a machine wherein the data pointers and function pointers are of different sizes. Then, what malloc returns is a function pointer but after casting it to void* while returning(Or, after assigning it to a void* variable internally and returning its value).
>>>
>>> Now, isn't malloc giving us the truncated address in the above context? Consider the same question applicable to calloc and realloc when used in such a context.
>>
>> malloc always returns a data pointer. You can ask it to return a data
>> pointer to some memory area that is big enough to hold a function
>> pointer, but it will still be a data pointer.
>>
>> Maybe the situation would be less confusing to you if you first
>> declare a struct with a single member that is a function pointer, then
>> use malloc to return a data pointer pointing to one such struct.
> 
> Yeah, had thought of it earlier(struct-approach being feasible due to data pointer involvement). But, wanted to accomplish the same with a malloc call by passing the sizeof a function pointer. So, malloc's documentation should include a note on this, isn't it?

I think you've got some confusion about something, possibly about levels
of indirection. Could you give an example of what you wanted to do with
such a pointer? I noticed that your original message contained a
definition for a function named f, which was not used in any way within
your code - I suspect that has something to do with your question, but
I'm not sure what.

[toc] | [prev] | [next] | [standalone]

#22704

On 6/25/2012 3:08 PM, Myth__Buster wrote:
> On Monday, June 25, 2012 9:16:07 AM UTC-7, christian.bau wrote:
>> On Jun 25, 5:08 pm, Myth__Buster <raghavani...@gmail.com> wrote:
>>
>>> Assume that the above code runs on a machine wherein the data pointers and function pointers are of different sizes. Then, what malloc returns is a function pointer but after casting it to void* while returning(Or, after assigning it to a void* variable internally and returning its value).
>>>
>>> Now, isn't malloc giving us the truncated address in the above context? Consider the same question applicable to calloc and realloc when used in such a context.
>>
>> malloc always returns a data pointer. You can ask it to return a data
>> pointer to some memory area that is big enough to hold a function
>> pointer, but it will still be a data pointer.
>>
>> Maybe the situation would be less confusing to you if you first
>> declare a struct with a single member that is a function pointer, then
>> use malloc to return a data pointer pointing to one such struct.
>
> Yeah, had thought of it earlier(struct-approach being feasible due to data pointer involvement). But, wanted to accomplish the same with a malloc call by passing the sizeof a function pointer. So, malloc's documentation should include a note on this, isn't it?

     Wouldn't that be sort of like "Warning: May Contain Nuts" on
a bag of peanuts?

     Aiming a function pointer at allocated memory (at any data object,
for that matter) is non-portable, as you've observed.  But filling the
allocated memory with something that can be called like a function is
also non-portable.  Seems to me that anyone playing such games already
needs a good deal of non-portable knowledge about the implementation:
He's purchased his packet of peanuts, on purpose.

-- 
Eric Sosman
esosman@ieee-dot-org.invalid

[toc] | [prev] | [next] | [standalone]

#22706

On Monday, June 25, 2012 12:30:12 PM UTC-7, Eric Sosman wrote:
> On 6/25/2012 3:08 PM, Myth__Buster wrote:
> > On Monday, June 25, 2012 9:16:07 AM UTC-7, christian.bau wrote:
> >> On Jun 25, 5:08 pm, Myth__Buster <raghavani...@gmail.com> wrote:
> >>
> >>> Assume that the above code runs on a machine wherein the data pointers and function pointers are of different sizes. Then, what malloc returns is a function pointer but after casting it to void* while returning(Or, after assigning it to a void* variable internally and returning its value).
> >>>
> >>> Now, isn't malloc giving us the truncated address in the above context? Consider the same question applicable to calloc and realloc when used in such a context.
> >>
> >> malloc always returns a data pointer. You can ask it to return a data
> >> pointer to some memory area that is big enough to hold a function
> >> pointer, but it will still be a data pointer.
> >>
> >> Maybe the situation would be less confusing to you if you first
> >> declare a struct with a single member that is a function pointer, then
> >> use malloc to return a data pointer pointing to one such struct.
> >
> > Yeah, had thought of it earlier(struct-approach being feasible due to data pointer involvement). But, wanted to accomplish the same with a malloc call by passing the sizeof a function pointer. So, malloc's documentation should include a note on this, isn't it?
> 
>      Wouldn't that be sort of like "Warning: May Contain Nuts" on
> a bag of peanuts?
> 
>      Aiming a function pointer at allocated memory (at any data object,
> for that matter) is non-portable, as you've observed.  But filling the
> allocated memory with something that can be called like a function is
> also non-portable.  Seems to me that anyone playing such games already
> needs a good deal of non-portable knowledge about the implementation:
> He's purchased his packet of peanuts, on purpose.
> 
> -- 
> Eric Sosman
> esosman@ieee-dot-org.invalid

The programmer might be well aware of this inability of malloc in returning a function pointer. However, shouldn't there be a relevant note under malloc's documentation for the sake of clarity and completeness of malloc's behavior?

Cheers,
Raghavan Santhanam

[toc] | [prev] | [next] | [standalone]

#22708

On 6/25/2012 3:47 PM, Myth__Buster wrote:
> On Monday, June 25, 2012 12:30:12 PM UTC-7, Eric Sosman wrote:
>> On 6/25/2012 3:08 PM, Myth__Buster wrote:
>>>[...]
>>> Yeah, had thought of it earlier(struct-approach being feasible due to data pointer involvement). But, wanted to accomplish the same with a malloc call by passing the sizeof a function pointer. So, malloc's documentation should include a note on this, isn't it?
>>
>>       Wouldn't that be sort of like "Warning: May Contain Nuts" on
>> a bag of peanuts?
>>
>>       Aiming a function pointer at allocated memory (at any data object,
>> for that matter) is non-portable, as you've observed.  But filling the
>> allocated memory with something that can be called like a function is
>> also non-portable.  Seems to me that anyone playing such games already
>> needs a good deal of non-portable knowledge about the implementation:
>> He's purchased his packet of peanuts, on purpose.
>
> The programmer might be well aware of this inability of malloc in returning a function pointer. However, shouldn't there be a relevant note under malloc's documentation for the sake of clarity and completeness of malloc's behavior?

     If the programmer is "well aware" that function pointers and data
pointers are incommensurate, what purpose would the note serve?  How
would you word such a note?  "NOTE: You already know this?"

     Programs exist (I have maintained -- and debugged! -- a few)
that allocate memory, fill it with magic values, aim a function
pointer at it, and perform a call through the pointer.  I suggest
that anyone writing such code is already keenly aware that it is
non-portable, also keenly aware of specific characteristics of his
C implementation that are not part of the C language.  He already
knows whether his system's function pointers are bare addresses or
more structured "function descriptors," he knows about special
prologue and epilogue sequences that wrap the instructions, he
knows about cache-coherency incantations that must be performed
between filling the memory and calling its content, and so on, and
so on.

     But perhaps I'm missing something, some other purpose for aiming
a function pointer at data.  What do you intend to *do* with the data?

-- 
Eric Sosman
esosman@ieee-dot-org.invalid

[toc] | [prev] | [next] | [standalone]

#22705

Myth__Buster <raghavanil4m@gmail.com> writes:

> On Monday, June 25, 2012 9:16:07 AM UTC-7, christian.bau wrote:
>> On Jun 25, 5:08 pm, Myth__Buster <raghavani...@gmail.com> wrote:
>> 
>> > Assume that the above code runs on a machine wherein the data
>> > pointers and function pointers are of different sizes. Then, what
>> > malloc returns is a function pointer but after casting it to void*
>> > while returning(Or, after assigning it to a void* variable
>> > internally and returning its value).
>> >
>> > Now, isn't malloc giving us the truncated address in the above
>> > context? Consider the same question applicable to calloc and
>> > realloc when used in such a context.
>> 
>> malloc always returns a data pointer. You can ask it to return a data
>> pointer to some memory area that is big enough to hold a function
>> pointer, but it will still be a data pointer.
>> 
>> Maybe the situation would be less confusing to you if you first
>> declare a struct with a single member that is a function pointer, then
>> use malloc to return a data pointer pointing to one such struct.
>
> Yeah, had thought of it earlier(struct-approach being feasible due to
> data pointer involvement). But, wanted to accomplish the same with a
> malloc call by passing the sizeof a function pointer. So, malloc's
> documentation should include a note on this, isn't it?

No, there is no problem with what you say you want to do, just how you
are doing it.

  malloc(sizeof (int (*)(void)))

is fine.  It allocates enough room for a pointer to a function, but what
it returned is a pointer to that space.  I.e. the correct way to store
the result is either as a void * (which is not often that useful) or as
a pointer to a pointer to a function:

  int (**p)(void) = malloc(sizeof (int (*)(void)));

It's an mistake to try to convert what comes back from malloc into a
pointer to a function.  Even if you could so this safely (and you might
on some forgiving systems) the space you allocate should be for a
function, not a pointer to one.

So, if you want to allocate space for a pointer to a function, go right
ahead, as above.  If you want to allocate space for a function (and thus
get a pointer to one from malloc) you are out of luck in standard C.  It
might be possible to get round some of the problems on some systems, but
that's another matter.

Note that the comp.lang.c approved what to write malloc calls helps here
(like it helps inmost cases).  The patter being:

  T *p = malloc(sizeof *p);

You can write the allocation like this:

  int (**p)(void) = malloc(sizeof *p);

Had you tried to other possibility:

  int (*p)(void) = malloc(sizeof *p);

you should expect an error message -- something along the lines of:

  warning: invalid application of 'sizeof' to a function type

So, after all that, what do you want -- to allocate space for a function
pointer, or to allocate space for a function?

-- 
Ben.

[toc] | [prev] | [next] | [standalone]

#22711

On Monday, June 25, 2012 12:42:45 PM UTC-7, Ben Bacarisse wrote:
> Myth__Buster <raghavanil4m@gmail.com> writes:
> 
> > On Monday, June 25, 2012 9:16:07 AM UTC-7, christian.bau wrote:
> >> On Jun 25, 5:08 pm, Myth__Buster <raghavani...@gmail.com> wrote:
> >> 
> >> > Assume that the above code runs on a machine wherein the data
> >> > pointers and function pointers are of different sizes. Then, what
> >> > malloc returns is a function pointer but after casting it to void*
> >> > while returning(Or, after assigning it to a void* variable
> >> > internally and returning its value).
> >> >
> >> > Now, isn't malloc giving us the truncated address in the above
> >> > context? Consider the same question applicable to calloc and
> >> > realloc when used in such a context.
> >> 
> >> malloc always returns a data pointer. You can ask it to return a data
> >> pointer to some memory area that is big enough to hold a function
> >> pointer, but it will still be a data pointer.
> >> 
> >> Maybe the situation would be less confusing to you if you first
> >> declare a struct with a single member that is a function pointer, then
> >> use malloc to return a data pointer pointing to one such struct.
> >
> > Yeah, had thought of it earlier(struct-approach being feasible due to
> > data pointer involvement). But, wanted to accomplish the same with a
> > malloc call by passing the sizeof a function pointer. So, malloc's
> > documentation should include a note on this, isn't it?
> 
> No, there is no problem with what you say you want to do, just how you
> are doing it.
> 
>   malloc(sizeof (int (*)(void)))
> 
> is fine.  It allocates enough room for a pointer to a function, but what
> it returned is a pointer to that space.  I.e. the correct way to store
> the result is either as a void * (which is not often that useful) or as
> a pointer to a pointer to a function:
> 
>   int (**p)(void) = malloc(sizeof (int (*)(void)));
> 
> It's an mistake to try to convert what comes back from malloc into a
> pointer to a function.  Even if you could so this safely (and you might
> on some forgiving systems) the space you allocate should be for a
> function, not a pointer to one.
> 
> So, if you want to allocate space for a pointer to a function, go right
> ahead, as above.  If you want to allocate space for a function (and thus
> get a pointer to one from malloc) you are out of luck in standard C.  It
> might be possible to get round some of the problems on some systems, but
> that's another matter.
> 
> Note that the comp.lang.c approved what to write malloc calls helps here
> (like it helps inmost cases).  The patter being:
> 
>   T *p = malloc(sizeof *p);
> 
> You can write the allocation like this:
> 
>   int (**p)(void) = malloc(sizeof *p);
> 
> Had you tried to other possibility:
> 
>   int (*p)(void) = malloc(sizeof *p);
> 
> you should expect an error message -- something along the lines of:
> 
>   warning: invalid application of 'sizeof' to a function type
> 
> So, after all that, what do you want -- to allocate space for a function
> pointer, or to allocate space for a function?
> 
> -- 
> Ben.

Well, 

Yeah, I know, that's the usual pattern - when we allocate a certain chunk of memory for an object of type T, we would be storing the respective malloc's return value in an object of type T*. No questions on that beginner's aspect. 

In my question being discussed, we are allocating space for a function pointer which might *not* be of same size as that of a data pointer on some machines. No questions on the allocation. It's fine and clear to me. But, the data pointer(void*) being returned by malloc will be improper to access the allocated space for the function pointer. And hence, I would like to see a relevant note under malloc's documentation.

Of course, I would like to allocate space for a function pointer using malloc without any dependency on any third-variable such as struct variable, etc, and use it thereafter(regarding the usage, that will be another story. I am interested in getting a proper pointer in the first place from malloc). And yeah, in the realms of C, allocating space for a function is meaningless as we know sizeof a function makes no sense. :)

Cheers,
Raghavan Santhanam

[toc] | [prev] | [next] | [standalone]

#22714 — Re: Different sizes of data and function pointers on a machine -- void* return type of malloc, calloc, and realloc

On 06/26/12 08:14 AM, Myth__Buster wrote:

Please wrap your lines!

> Well,
>
> Yeah, I know, that's the usual pattern - when we allocate a certain chunk of memory for an object of type T, we would be storing the respective malloc's return value in an object of type T*. No questions on that beginner's aspect.
>
> In my question being discussed, we are allocating space for a function pointer which might *not* be of same size as that of a data pointer on some machines. No questions on the allocation. It's fine and clear to me. But, the data pointer(void*) being returned by malloc will be improper to access the allocated space for the function pointer. And hence, I would like to see a relevant note under malloc's documentation.

What would that achieve?  malloc returns a void* and a void* is not 
compatible with a function pointer.  Would you add a note for every 
function that returns something incompatible with something else?

-- 
Ian Collins

[toc] | [prev] | [next] | [standalone]

#22720

> 
> What would that achieve?  malloc returns a void* and a void* is not 
> compatible with a function pointer.  Would you add a note for every 
> function that returns something incompatible with something else?
> 
> -- 
> Ian Collins

Achievement : Clarity and completeness of malloc's behavior in malloc's documentation. More appropriately, a word of caution similar to this - In C, malloc when used to directly allocate memory for function pointers(without any third-variable's allocation such as encompassing struct variable, etc) on machines wherein the data and function pointers are of different sizes, the return data pointer wouldn't be a proper pointer with which the entire memory allocated for function pointer would have been allocated. Hence, care should be exercised before the allocated memory could be used. (On similar lines, the applicable alternative approaches can be mentioned therein to accomplish the same and thereby help the reader/programmer).

Cheers,
Raghavan Santhanam

[toc] | [prev] | [next] | [standalone]

#22721 — Re: Different sizes of data and function pointers on a machine -- void* return type of malloc, calloc, and realloc

On 06/26/12 08:53 AM, Myth__Buster wrote:
>>
>> What would that achieve?  malloc returns a void* and a void* is not
>> compatible with a function pointer.  Would you add a note for every
>> function that returns something incompatible with something else?
>>
>> --
>> Ian Collins
>
> Achievement : Clarity and completeness of malloc's behavior in malloc's documentation.

Should it also caution that the return type of malloc is incompatible 
with int?  with char?  with ...

-- 
Ian Collins

[toc] | [prev] | [next] | [standalone]

#22727

On 06/25/2012 04:53 PM, Myth__Buster wrote:
...
> Achievement : Clarity and completeness of malloc's behavior in
> malloc's documentation. More appropriately, a word of caution similar
> to this - In C, malloc when used to directly allocate memory for
> function pointers(without any third-variable's allocation such as
> encompassing struct variable, etc) on machines wherein the data and
> function pointers are of different sizes, the return data pointer
> wouldn't be a proper pointer with which the entire memory allocated
> for function pointer would have been allocated.

I still don't understand why you think there's a problem, which
inherently implies that I don't understand what the problem is that you
think there is. However, that is not an accurate description of any
problem that malloc() actually possesses.

[toc] | [prev] | [next] | [standalone]

#22729

*Completed my sentences.

On Monday, June 25, 2012 1:53:10 PM UTC-7, Myth__Buster wrote:
> > 
> > What would that achieve?  malloc returns a void* and a void* is not 
> > compatible with a function pointer.  Would you add a note for every 
> > function that returns something incompatible with something else?
> > 
> > -- 
> > Ian Collins
> 
> Achievement : Clarity and completeness of malloc's behavior in malloc's documentation. More appropriately, a word of caution similar to this - In C, malloc when used to directly allocate memory for function pointers(without any third-variable's allocation such as encompassing struct variable, etc) on machines wherein the data and function pointers are of different sizes, the return data pointer wouldn't be a proper pointer with which the entire memory allocated for function pointer could be accessed. Hence, care should be exercised before the allocated memory could be used. (On similar lines, the applicable alternative approaches can be mentioned therein to accomplish the same and thereby help the reader/programmer).
> 
> Cheers,
> Raghavan Santhanam

[toc] | [prev] | [next] | [standalone]

#22754

On 2012-06-25 20:58:17 +0000, Myth__Buster said:
> 
> On Monday, June 25, 2012 1:53:10 PM UTC-7, Myth__Buster wrote:
>> 
>> What would that achieve?  malloc returns a void* and a void* is not> > 
>> compatible with a function pointer.  Would you add a note for every> > 
>> function that returns something incompatible with something else?
>> 
>> -- 
>> Ian Collins
> 
> Achievement : Clarity and completeness of malloc's behavior in malloc's 
> documentation. More appropriately, a word of caution similar to this - 
> In C, malloc when used to directly allocate memory for function 
> pointers(without any third-variable's allocation such as encompassing 
> struct variable, etc) on machines wherein the data and function 
> pointers are of different sizes, the return data pointer wouldn't be a 
> proper pointer with which the entire memory allocated for function 
> pointer could be accessed. Hence, care should be exercised before the 
> allocated memory could be used. (On similar lines, the applicable 
> alternative approaches can be mentioned therein to accomplish the same 
> and thereby help the reader/programmer).

Given the declaration
    int (*p)(void) = malloc(sizeof(int (*)(void)));
and reading it "for intent" rather than as written:
 - 'p' identifies a function pointer value.
 - malloc is being (mis-)used to allocate memory for a function, and is 
incorrectly being expected to return a pointer to that function.

The second thing is flatly nonsensical. Nothing malloc could reasonably 
do with the block of memory it allocates could make that block into a 
function, and C does not provide tools for composing functions in 
random blocks of memory, so there's no way subsequent code could turn 
the block into a legitimate function either.

I don't know how you've gotten to "malloc is allocating a function 
pointer" here. It's not: it's allocating a block of memory, then 
*returning* a (value) pointer to that block. Trying to interpret the 
pointed-to block as a function will at best crash your program, so the 
returned pointer cannot be interpreted as a pointer to a function. 
(Ignoring the case where malloc returns a null pointer.)

The only sensible values for function pointers (which 'p' already 
identifies, without any need for dynamic allocation of a pointer-sized 
block) are the values obtainable from the addresses of functions in 
your program:

	int random_number(void) {
		return 4; /* generated by fair die roll */
	}

	int main(void) {
		int (*p)(void) = random_number;
		/* and so on */
		return 0;
	}

It's completely unnecessary to note in the docs that malloc can't 
return a function pointer for the same reason that's unnecessary to 
mention that memcpy can't receive a function pointer as an argument: 
it's taken as given that if you use function pointers, you understand 
how they're different from value pointers, and how the pointed-to 
entities differ in both allocation and behaviour. Non-null function 
pointers are *never* compatible with value pointers, and vice versa, as 
far as I know.

If you really wanted to use malloc to "allocate a function pointer" 
(for whatever unlikely reason), you'd need to add another step of 
indirection, and declare 'p' as a pointer to a function pointer:

	int (**p)(void) = malloc(sizeof(*p));
	if (p != NULL) {
		*p = random_number;
		/* and so on */
	}

Here, malloc allocates a block at least the size of a function pointer, 
and returns a pointer *to* that block. I can't imagine why you'd write 
code this way, though.

-o

[toc] | [prev] | [next] | [standalone]

#22717

On 06/25/2012 04:14 PM, Myth__Buster wrote:
...
> In my question being discussed, we are allocating space for a
> function pointer which might *not* be of same size as that of a data
> pointer on some machines. No questions on the allocation. It's fine
> and clear to me. But, the data pointer(void*) being returned by
> malloc will be improper to access the allocated space for the
> function pointer. ...

The function pointer itself has an object type, and you've instructed
malloc() to allocate enough memory to hold it for you. The data pointer
returned by malloc() will be perfectly usable for accessing the memory
you've allocated for the function pointer. Why do you think otherwise?

...
> ... regarding the usage, that
> will be another story. I am interested in getting a proper pointer in
> the first place from malloc ...

Don't worry about getting a proper pointer in the first place from
malloc() - if what you're trying to do makes any sense, and if it makes
sense to use malloc() as part of the solution to your problem, then I
guarantee you that the pointer returned by malloc() will be proper.
Telling us what you want to do with this pointer after you've allocated
might help us figure out why you think otherwise.

[toc] | [prev] | [next] | [standalone]

#22723

> In my question being discussed, we are allocating space for a
>function pointer which might *not* be of same size as that of a
>data pointer on some machines. 

Note that I can allocate space for a long double, a char, or a
really big struct, or an array of many pointers, which also might
not be of the same size as that of a data pointer on some machines.
This is irrelevant.  malloc() returns a data pointer which is fine
for this.

>No questions on the allocation. It's
>fine and clear to me. 

>But, the data pointer(void*) being returned
>by malloc will be improper to access the allocated space for the
>function pointer. 

Incorrect.  It is improper to access a function pointer by indirecting
through a function pointer.  It is proper to access a function pointer
by indirecting through a data (object) pointer.

The allocated space contains a function pointer (not a function),
and a pointer to a function pointer is a *data* pointer to a function
pointer.

It is improper to access anything but functions (not function
pointers, just functions) with a function pointer.  You do this
by calling the function.

>And hence, I would like to see a relevant note
>under malloc's documentation.

If you could write code like this:

int main(int argc, char **argv)
{
	void *mainptr = malloc(sizeof(main));	/* allocate space */
	memcpy(mainptr, &main, sizeof(main));  /* make a copy of main() */
	return (*mainptr)(argc, argv);	/* call the copy */
}

it might make some sense, but you can't.  sizeof() doesn't work on
functions (function pointers, yes, not on functions).  memcpy()
doesn't accept function pointers.  A copy of a function is not
guaranteed to execute at all, or execute properly.  Plus, this example
generates infinite recursion.

[toc] | [prev] | [next] | [standalone]

#22728

Myth__Buster <raghavanil4m@gmail.com> writes:
[...]
> Yeah, I know, that's the usual pattern - when we allocate a certain
> chunk of memory for an object of type T, we would be storing the
> respective malloc's return value in an object of type T*. No questions
> on that beginner's aspect.
>
> In my question being discussed, we are allocating space for a function
> pointer which might *not* be of same size as that of a data pointer on
> some machines. No questions on the allocation. It's fine and clear to
> me. But, the data pointer(void*) being returned by malloc will be
> improper to access the allocated space for the function pointer. And
> hence, I would like to see a relevant note under malloc's
> documentation.
>
> Of course, I would like to allocate space for a function pointer using
> malloc without any dependency on any third-variable such as struct
> variable, etc, and use it thereafter(regarding the usage, that will be
> another story. I am interested in getting a proper pointer in the
> first place from malloc). And yeah, in the realms of C, allocating
> space for a function is meaningless as we know sizeof a function makes
> no sense. :)

It *doesn't matter* whether the object being allocated happens to
have the same size as a void*.

Suppose you're allocating a struct object rather than a
pointer-to-function object. Suppose void* is 4 bytes, and your
structure is 1024 bytes. The issues are exactly the same as in the
case you're looking at.

For struct allocation, you need to convert (probably implicitly)
the void* value returned by malloc() to a pointer to the struct.

For pointer-to-function allocation, you need to convert (probably
implicitly) the void* value returned by malloc() to a pointer to
the pointer-to-function.

Pay careful attention to the parallel construction of the two preceding
paragraphs.

I think the fact that the object you're allocating is a pointer is
causing you to confuse the pointer object being allocated with a
pointer *to* that pointer object.  They're at two different levels
of indirection, and their relative sizes are not relevant.

You're imagining a special case where there really isn't one.

-- 
Keith Thompson (The_Other_Keith) kst-u@mib.org  <http://www.ghoti.net/~kst>
    Will write code for food.
"We must do something.  This is something.  Therefore, we must do this."
    -- Antony Jay and Jonathan Lynn, "Yes Minister"

[toc] | [prev] | [next] | [standalone]

#22731

On 6/25/2012 4:14 PM, Myth__Buster wrote:
> [...]
> In my question being discussed, we are allocating space for a function pointer which might *not* be of same size as that of a data pointer on some machines. No questions on the allocation. It's fine and clear to me. But, the data pointer(void*) being returned by malloc will be improper to access the allocated space for the function pointer. And hence, I would like to see a relevant note under malloc's documentation.

     Thanks to Ben Bacarisse, I think I see what you're confused
about.  (It wasn't evident from the original erroneous code: Half
the respondents fixed the error by imagining a change to one side
of the assignment, and half chose to change the other.  That's a
fundamental problem with invalid code: There may be many different
correct codes at small "edit distances" from the original, with
each edit corresponding to a different idea of "the error.")

     Anyhow: A function pointer is a data type and has a sizeof, and
malloc() is perfectly capable of allocating space to hold objects
of that type.  The `void*' returned by malloc() is entirely proper
for accessing the allocated space; you can store function pointer
values in that space and retrieve them from it, and (if they're
valid values) you can make calls through them to actual functions.
A note saying "malloc() cannot allocate space for function pointers"
would not be a clarification, it would be incorrect.

     What malloc() cannot return is a pointer to memory capable of
holding a function.  Put another way, malloc() cannot return a
pointer to an actual, callable function, nor to memory that might
possibly hold such a thing.  (As far as C is concerned, functions
don't inhabit "memory" at all.)

     You seem hung up on the (possible) difference between the
sizeof a function pointer and sizeof(void*), but there's no reason
to be alarmed.  I'm sure you use malloc(sizeof(struct foo)) without
trouble, even when sizeof(struct foo) != sizeof(void*).  The size
of a pointed-at thing and the size of the pointer to it need not
be related at all -- and that's the case when the pointed-at thing
is a function pointer, too.

-- 
Eric Sosman
esosman@ieee-dot-org.invalid

[toc] | [prev] | [next] | [standalone]

#22696

On 06/25/2012 12:08 PM, Myth__Buster wrote:
> In reference with the below code,
> 
> #include <stdlib.h>
> #include <stdio.h>
> 
> int f(void)
> {
> printf("\n In f . . . \n");
> }
> 
> int main(void)
> {
> int (*p)(void) = malloc(sizeof(int (*)(void)));

"The pointer returned if the allocation succeeds is suitably aligned so
that it may be assigned to a pointer to any type of object ..."
(7.22.3p1). Note carefully that this only applies to pointers to object
types, not function types.

The code above converts a pointer to void into a pointer to a function
type. The behavior of this code is well-defined if malloc() fails,
because 6.3.6.2p4 says "Conversion of a null pointer to another pointer
type yields a null pointer of that type." However, the behavior of this
code is undefined if malloc() returns a non-null pointer "by omission of
any explicit definition of the behavior" (4p2). The only other
conversion defined by the standard that involves function pointer types
is the conversion from one function pointer type to another (6.3.6.3p8),
which doesn't apply here.

> return 0;
> }
> 
> I would like to question about the return type of malloc(calloc, and
> realloc).

All three functions behave the same, as far as the issue raided by your
message is concerned.

> Assume that the above code runs on a machine wherein the data
> pointers and function pointers are of different sizes. Then, what
> malloc returns is a function pointer ...

That's incorrect - what gave you that idea? The rest of your message
depends upon that misconception, so I'll just stop here.

[toc] | [prev] | [next] | [standalone]

Page 1 of 2  [1] 2  Next page →

Back to top | Article view | comp.lang.c

csiph-web