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

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

Passing an integer to a function that accepts a void pointer

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

Contents

  Passing an integer to a function that accepts a void pointer pozz <pozzugno@gmail.com> - 2011-05-11 03:01 -0700
    Re: Passing an integer to a function that accepts a void pointer Tom St Denis <tom@iahu.ca> - 2011-05-11 03:52 -0700
      Re: Passing an integer to a function that accepts a void pointer pete <pfiland@mindspring.com> - 2011-05-11 08:10 -0400
      Re: Passing an integer to a function that accepts a void pointer pozz <pozzugno@gmail.com> - 2011-05-11 18:28 +0200
        Re: Passing an integer to a function that accepts a void pointer Shao Miller <sha0.miller@gmail.com> - 2011-05-11 22:10 -0500
          Re: Passing an integer to a function that accepts a void pointer pozz <pozzugno@gmail.com> - 2011-05-12 19:44 +0200
            Re: Passing an integer to a function that accepts a void pointer Shao Miller <sha0.miller@gmail.com> - 2011-05-12 14:16 -0400
              Re: Passing an integer to a function that accepts a void pointer pozz <pozzugno@gmail.com> - 2011-05-12 21:21 +0200
                Re: Passing an integer to a function that accepts a void pointer Shao Miller <sha0.miller@gmail.com> - 2011-05-12 16:05 -0400
                  Re: Passing an integer to a function that accepts a void pointer pozz <pozzugno@gmail.com> - 2011-05-13 23:39 +0200
                    Re: Passing an integer to a function that accepts a void pointer Dr Nick <3-nospam@temporary-address.org.uk> - 2011-05-14 09:41 +0100
            Re: Passing an integer to a function that accepts a void pointer Eric Sosman <esosman@ieee-dot-org.invalid> - 2011-05-12 22:07 -0400
              Re: Passing an integer to a function that accepts a void pointer pozz <pozzugno@gmail.com> - 2011-05-13 23:12 +0200
                Re: Passing an integer to a function that accepts a void pointer Eric Sosman <esosman@ieee-dot-org.invalid> - 2011-05-13 23:30 -0400
    Re: Passing an integer to a function that accepts a void pointer Columbus sailed the ocean China Blue <chine.bleu@yahoo.com> - 2011-05-11 04:03 -0700
      Re: Passing an integer to a function that accepts a void pointer Heikki Kallasjoki <see@end.of.message.invalid> - 2011-05-11 13:03 +0000
        Re: Passing an integer to a function that accepts a void pointer Columbus sailed the ocean China Blue <chine.bleu@yahoo.com> - 2011-05-11 06:46 -0700
          Re: Passing an integer to a function that accepts a void pointer Keith Thompson <kst-u@mib.org> - 2011-05-11 08:24 -0700
            Re: Passing an integer to a function that accepts a void pointer Columbus sailed the ocean China Blue <chine.bleu@yahoo.com> - 2011-05-11 08:44 -0700
              Re: Passing an integer to a function that accepts a void pointer Keith Thompson <kst-u@mib.org> - 2011-05-11 08:58 -0700
                Re: Passing an integer to a function that accepts a void pointer gazelle@shell.xmission.com (Kenny McCormack) - 2011-05-11 17:38 +0000
                  Re: Passing an integer to a function that accepts a void pointer Kenneth Brody <kenbrody@spamcop.net> - 2011-05-11 14:57 -0400
                  Re: Passing an integer to a function that accepts a void pointer Paul N <gw7rib@aol.com> - 2011-05-11 14:06 -0700
                    Re: Passing an integer to a function that accepts a void pointer Michael Press <rubrum@pacbell.net> - 2011-05-12 13:59 -0700
                      Re: Passing an integer to a function that accepts a void pointer Keith Thompson <kst-u@mib.org> - 2011-05-12 14:12 -0700
                        Re: Passing an integer to a function that accepts a void pointer Columbus sailed the ocean China Blue <chine.bleu@yahoo.com> - 2011-05-12 15:27 -0700
                          Re: Passing an integer to a function that accepts a void pointer Seebs <usenet-nospam@seebs.net> - 2011-05-12 22:37 +0000
                            Re: Passing an integer to a function that accepts a void pointer Ian Collins <ian-news@hotmail.com> - 2011-05-13 10:41 +1200
                              Re: Passing an integer to a function that accepts a void pointer Shao Miller <sha0.miller@gmail.com> - 2011-05-12 17:57 -0500
                                Re: Passing an integer to a function that accepts a void pointer Ian Collins <ian-news@hotmail.com> - 2011-05-13 11:05 +1200
                                  Re: Passing an integer to a function that accepts a void pointer Seebs <usenet-nospam@seebs.net> - 2011-05-12 23:19 +0000
                                    Re: Passing an integer to a function that accepts a void pointer Keith Thompson <kst-u@mib.org> - 2011-05-12 16:32 -0700
                                      Re: Passing an integer to a function that accepts a void pointer Shao Miller <sha0.miller@gmail.com> - 2011-05-12 19:13 -0500
                                        Re: Passing an integer to a function that accepts a void pointer Keith Thompson <kst-u@mib.org> - 2011-05-12 18:18 -0700
                                Re: Passing an integer to a function that accepts a void pointer Keith Thompson <kst-u@mib.org> - 2011-05-12 16:18 -0700
                                  Re: Passing an integer to a function that accepts a void pointer Tobias Blass <tobiasblass@gmx.net> - 2011-05-13 08:24 +0000
                                    Re: Passing an integer to a function that accepts a void pointer Columbus sailed the ocean China Blue <chine.bleu@yahoo.com> - 2011-05-13 01:33 -0700
                                      Re: Passing an integer to a function that accepts a void pointer Seebs <usenet-nospam@seebs.net> - 2011-05-13 08:36 +0000
                                        Re: Passing an integer to a function that accepts a void pointer "madamemandm@yahoo.com" <madamemandm@yahoo.com> - 2011-05-13 07:08 -0700
                          Re: Passing an integer to a function that accepts a void pointer Keith Thompson <kst-u@mib.org> - 2011-05-12 15:59 -0700
              Re: Passing an integer to a function that accepts a void pointer Seebs <usenet-nospam@seebs.net> - 2011-05-11 21:46 +0000
                Re: Passing an integer to a function that accepts a void pointer Columbus sailed the ocean China Blue <chine.bleu@yahoo.com> - 2011-05-12 00:56 -0700
                  Re: Passing an integer to a function that accepts a void pointer Ian Collins <ian-news@hotmail.com> - 2011-05-12 20:06 +1200
                    Re: Passing an integer to a function that accepts a void pointer Heikki Kallasjoki <see@end.of.message.invalid> - 2011-05-12 08:59 +0000
                      Re: Passing an integer to a function that accepts a void pointer Ian Collins <ian-news@hotmail.com> - 2011-05-13 10:39 +1200
          Re: Passing an integer to a function that accepts a void pointer Eric Sosman <esosman@ieee-dot-org.invalid> - 2011-05-12 06:51 -0400
            Re: Passing an integer to a function that accepts a void pointer Columbus sailed the ocean China Blue <chine.bleu@yahoo.com> - 2011-05-12 04:08 -0700
              Re: Passing an integer to a function that accepts a void pointer Eric Sosman <esosman@ieee-dot-org.invalid> - 2011-05-12 07:33 -0400
              Re: Passing an integer to a function that accepts a void pointer Keith Thompson <kst-u@mib.org> - 2011-05-12 07:58 -0700
                Re: Passing an integer to a function that accepts a void pointer gazelle@shell.xmission.com (Kenny McCormack) - 2011-05-12 15:23 +0000
                Re: Passing an integer to a function that accepts a void pointer Shao Miller <sha0.miller@gmail.com> - 2011-05-12 13:36 -0400
                  Re: Passing an integer to a function that accepts a void pointer Keith Thompson <kst-u@mib.org> - 2011-05-12 12:03 -0700
              Re: Passing an integer to a function that accepts a void pointer Seebs <usenet-nospam@seebs.net> - 2011-05-12 15:57 +0000
            Re: Passing an integer to a function that accepts a void pointer Michael Press <rubrum@pacbell.net> - 2011-05-12 14:14 -0700
              Re: Passing an integer to a function that accepts a void pointer Eric Sosman <esosman@ieee-dot-org.invalid> - 2011-05-12 22:20 -0400
                Re: Passing an integer to a function that accepts a void pointer Ben Bacarisse <ben.usenet@bsb.me.uk> - 2011-05-14 02:39 +0100
    Re: Passing an integer to a function that accepts a void pointer Eric Sosman <esosman@ieee-dot-org.invalid> - 2011-05-11 07:37 -0400
    Re: Passing an integer to a function that accepts a void pointer James Kuyper <jameskuyper@verizon.net> - 2011-05-11 09:42 -0400
    Re: Passing an integer to a function that accepts a void pointer Datesfat Chicks <datesfat.chicks@gmail.com> - 2011-05-11 11:53 -0400
      Re: Passing an integer to a function that accepts a void pointer Fred <fred.l.kleinschmidt@boeing.com> - 2011-05-11 10:44 -0700
        Re: Passing an integer to a function that accepts a void pointer Datesfat Chicks <datesfat.chicks@gmail.com> - 2011-05-12 07:58 -0400
      Re: Passing an integer to a function that accepts a void pointer Dr Nick <3-nospam@temporary-address.org.uk> - 2011-05-11 21:27 +0100

Page 1 of 4  [1] 2 3 4  Next page →

#3732 — Passing an integer to a function that accepts a void pointer

What do you think about this code?

int foo(const void *Args) {
  printf("%d\n", (const int)Args);
  return 0;
}

int main(int argc, char *argv[]) {
  foo((void *)10);
  return 0;
}

It seems work and it should be nice if it is a sufficient portable way
to pass integers as pointers.

Why don't I declare foo() to directly accept int? Because it is a
callback of a library I can't change and the prototype of the callback
is well defined by the library to accept void pointer.

[toc] | [next] | [standalone]

#3736

On May 11, 6:01 am, pozz <pozzu...@gmail.com> wrote:
> What do you think about this code?
>
> int foo(const void *Args) {
>   printf("%d\n", (const int)Args);
>   return 0;
>
> }
>
> int main(int argc, char *argv[]) {
>   foo((void *)10);
>   return 0;
>
> }
>
> It seems work and it should be nice if it is a sufficient portable way
> to pass integers as pointers.
>
> Why don't I declare foo() to directly accept int? Because it is a
> callback of a library I can't change and the prototype of the callback
> is well defined by the library to accept void pointer.

Why not just do this

int bar = 10;
foo(&bar);

And inside foo do

printf("%d\n", *((int *)Args));

That way the program is actually portable.

Tom

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

#3745

Tom St Denis wrote:
> 
> On May 11, 6:01 am, pozz <pozzu...@gmail.com> wrote:
> > What do you think about this code?
> >
> > int foo(const void *Args) {
> >   printf("%d\n", (const int)Args);
> >   return 0;
> >
> > }
> >
> > int main(int argc, char *argv[]) {
> >   foo((void *)10);
> >   return 0;
> >
> > }
> >
> > It seems work and it should be nice if it is a sufficient portable way
> > to pass integers as pointers.
> >
> > Why don't I declare foo() to directly accept int? Because it is a
> > callback of a library I can't change and the prototype of the callback
> > is well defined by the library to accept void pointer.
> 
> Why not just do this
> 
> int bar = 10;
> foo(&bar);
> 
> And inside foo do
> 
> printf("%d\n", *((int *)Args));
> 
> That way the program is actually portable.

That's what I was thinking too.

-- 
pete

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

#3766

Il 11/05/2011 12:52, Tom St Denis ha scritto:
> Why not just do this
>
> int bar = 10;
> foo(&bar);
>
> And inside foo do
>
> printf("%d\n", *((int *)Args));
>
> That way the program is actually portable.

Oh yes, this is another solution I considered and surely it is the most 
portable way.

In my case, I have a long list of const struct initialized with callback 
and argument pointers, like this:

const struct {
   int (*fn)(const void *Args);
   const void *Args;
} array[] = {
   { callback, (void *)1 },
   { callback, (void *)2 },
   ..
   { callback, (void *)10 },
};

If I have to define an object for each element of the array, I would write:

const int num[0] = { 0, 1, 2, 3, 4, 5, 6, 7, 8, 9, 10 };
const struct {
   int (*fn)(const void *Args);
   const void *Args;
} array[] = {
   { callback, &num[1] },
   { callback, &num[2] },
   ..
   { callback, &num[10] },
};

Two little drawbacks: a small amount of additional space (the num array) 
and a longer piece of code.

Anyway, if my solution isn't correct, I have to turn to this approach.

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

#3786

On 5/11/2011 11:28 AM, pozz wrote:
> Il 11/05/2011 12:52, Tom St Denis ha scritto:
>> Why not just do this
>>
>> int bar = 10;
>> foo(&bar);
>>
>> And inside foo do
>>
>> printf("%d\n", *((int *)Args));
>>
>> That way the program is actually portable.
>
> Oh yes, this is another solution I considered and surely it is the most
> portable way.
>
> In my case, I have a long list of const struct initialized with callback
> and argument pointers, like this:
>...

In your example code, you are using the same call-back for every 
different number.  If you are going to be using the same call-back, is 
there a reason why you cannot pass a 'void *' context that points 
directly to an element of an array of 'int'?  As in:
---
   #include <stdlib.h>
   #include <stdio.h>

   /*** Constants */
   /* None */

   /*** Object type declarations */
   typedef unsigned char byte;

   /*** Function types */
   typedef int f_callback(const void *);
   typedef int f_intfunc(int);

   /*** Structure type definitions */
   /* None */

   /*** Function declarations */
   static f_callback my_callback;
   static f_intfunc some_func;

   /* This one doesn't belong to you and comes from a header */
   extern int SomeApiPerformCallback(f_callback *, const void *);

   /*** Objects */
   static int my_ints[] = {0, 1, 2, 3, 4, 5, 6, 7, 8, 9, 10};

   /*** Function definitions */

   /**
    * This callback will call 'some_func' with the 'int' value
    * context that is associated with it.
    */
   static int my_callback(const void * context) {
       const int * int_ptr;

       int_ptr = context;
       if (!int_ptr)
         return -1;

       printf("my_callback() context: %p\n", context);
       return some_func(*int_ptr);
     }

   /**
    * This quite simply returns the 'int' that is passed
    */
   static int some_func(int int_param) {
       printf("some_func() got: %d\n", int_param);
       return int_param;
     }

   /**
    * The program entry-point
    */
   int main(void) {
       int result;

       result = SomeApiPerformCallback(my_callback, my_ints + 5);
       if (result == -1)
         return EXIT_FAILURE;
       printf("Result: %d\n", result);

       result = SomeApiPerformCallback(my_callback, my_ints + 7);
       if (result == -1)
         return EXIT_FAILURE;
       printf("Result: %d\n", result);

       result = SomeApiPerformCallback(my_callback, my_ints + 3);
       if (result == -1)
         return EXIT_FAILURE;
       printf("Result: %d\n", result);

       return EXIT_SUCCESS;
     }

   /* This one doesn't belong to you and is just a demo */
   int SomeApiPerformCallback(f_callback * callback, const void * context) {
       if (!callback)
         return -1;

       return callback(context);
     }

---

I would expect that unlike this simple code, you are registering a 
call-back which will be executed asynchronously relative to the function 
which registers it.  In that case, unless you wish to wait for the 
call-back to complete, I can understand why you wouldn't want to do:

   void blah(void) {
       int i;

       /* ... */
       i = 5;
       SomeApiRegisterCallback(my_callback, &i);
       return;
     }

because the lifetime of 'i' will end pretty well immediately after 
you've registered your call-back. :)  But...  That's what malloc() and 
the other memory allocation functions are for...

   void blah(void) {
       int *i;

       i = malloc(sizeof *i);
       if (!i) {
           /* Note an error */
           return;
         }

       *i = 5;
       SomeApiRegisterCallback(my_callback, i);
       return;
     }

Remember to free() the pointer once you've finished with it. :)

Any pointer type which points to a complete or incomplete object type 
can be converted to 'void *' (and back again), if I recall correctly. 
So that includes 'int *' -->> 'void *'.

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

#3820

Il 12/05/2011 05:10, Shao Miller ha scritto:
> In your example code, you are using the same call-back for every
> different number. If you are going to be using the same call-back, is
> there a reason why you cannot pass a 'void *' context that points
> directly to an element of an array of 'int'? As in:

Oh yes, it is exactly what I wrote in the previous post. The approach is 
good, but two small drawbacks I posted.

> I would expect that unlike this simple code, you are registering a
> call-back which will be executed asynchronously relative to the function
> which registers it. In that case, unless you wish to wait for the
> call-back to complete, I can understand why you wouldn't want to do:
>
> void blah(void) {
> int i;
>
> /* ... */
> i = 5;
> SomeApiRegisterCallback(my_callback, &i);
> return;
> }
>
> because the lifetime of 'i' will end pretty well immediately after
> you've registered your call-back. :)

Yes, correct.


> But... That's what malloc() and the
> other memory allocation functions are for...
>
> void blah(void) {
> int *i;
>
> i = malloc(sizeof *i);
> if (!i) {
> /* Note an error */
> return;
> }
>
> *i = 5;
> SomeApiRegisterCallback(my_callback, i);
> return;
> }
>
> Remember to free() the pointer once you've finished with it. :)

malloc() and free() are not present in my embedded system. I have to use 
only static allocation.

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

#3822

On 5/12/2011 13:44, pozz wrote:
> Il 12/05/2011 05:10, Shao Miller ha scritto:
>> In your example code, you are using the same call-back for every
>> different number. If you are going to be using the same call-back, is
>> there a reason why you cannot pass a 'void *' context that points
>> directly to an element of an array of 'int'? As in:
>
> Oh yes, it is exactly what I wrote in the previous post. The approach is
> good, but two small drawbacks I posted.
>

So if you are using the same call-back function no matter which element 
is being used, would it make sense to remove the redundant '.fn' member 
and simply pass a context which points directly to an element of an 
array of 'int'?

>
>> But... That's what malloc() and the
>> other memory allocation functions are for...
>>
>> void blah(void) {
>> int *i;
>>
>> i = malloc(sizeof *i);
>> if (!i) {
>> /* Note an error */
>> return;
>> }
>>
>> *i = 5;
>> SomeApiRegisterCallback(my_callback, i);
>> return;
>> }
>>
>> Remember to free() the pointer once you've finished with it. :)
>
> malloc() and free() are not present in my embedded system. I have to use
> only static allocation.

That detail seems like a good idea to share when discussing your 
scenario. :)

Can your function which registers the call-back wait for the call-back 
to be completed?

If not, is the call-back one which will be called repeatedly, but should 
always use the same context?

Do you have thread synchronization functions available to you?

Could you have a dedicated thread whose sole purpose is to provide for 
non-static storage?  Such a thread could "abuse" recursion in order to 
"allocate" more memory in the form of automatic objects.  The memory 
could run out, obviously, but could save you from having a large array 
with static duration and having every possible number in it.  Or is 
having such a large array not an issue?

Or could you have a thread to "wrap" each context?  A thread for "3", a 
thread for "5", etc.?  That'd seem _quite_ wasteful, but maybe that's an 
option!

In my opinion, if you are targeting a particular environment (which 
doesn't have malloc() and free() ), then perhaps you needn't be overly 
concerned about portability!  If the environment is documented as 
allowing for an 'int' to be cast to 'void *' and back again, then that's 
that.  (But maybe avoid expecting such code to be portable, in a 
standard sense.)

Have a pleasant day. :)

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

#3828

Il 12/05/2011 20:16, Shao Miller ha scritto:
> So if you are using the same call-back function no matter which element
> is being used, would it make sense to remove the redundant '.fn' member
> and simply pass a context which points directly to an element of an
> array of 'int'?

In the array of struct, many callback are the same, but other aren't. 
They aren't ALL the same.


> Can your function which registers the call-back wait for the call-back
> to be completed?

No, the callback will be asincronously called automatically by the 
library (when deterministic events occurs).


> If not, is the call-back one which will be called repeatedly, but should
> always use the same context?

I have many callback functions I'd like to register. Some of them can be 
called with different contexts.


> Do you have thread synchronization functions available to you?

No.


> In my opinion, if you are targeting a particular environment (which
> doesn't have malloc() and free() ), then perhaps you needn't be overly
> concerned about portability!

What is the reason I couldn't expect a piece of code without malloc/free 
to be portable?

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

#3829

On 5/12/2011 15:21, pozz wrote:
> Il 12/05/2011 20:16, Shao Miller ha scritto:
>> So if you are using the same call-back function no matter which element
>> is being used, would it make sense to remove the redundant '.fn' member
>> and simply pass a context which points directly to an element of an
>> array of 'int'?
>
> In the array of struct, many callback are the same, but other aren't.
> They aren't ALL the same.
>

Ok, I misunderstood your post before.  Sorry about that. :)

>
>> Can your function which registers the call-back wait for the call-back
>> to be completed?
>
> No, the callback will be asincronously called automatically by the
> library (when deterministic events occurs).
>

I had to ask.  Heheh.

>
>> If not, is the call-back one which will be called repeatedly, but should
>> always use the same context?
>
> I have many callback functions I'd like to register. Some of them can be
> called with different contexts.
>

I had to ask that, too.  Heheh.

>
>> Do you have thread synchronization functions available to you?
>
> No.
>

Well that's too bad.  Do you at least have a function which will cause a 
thread to sleep and provide an opportunity for another thread (such as 
one that invokes your call-back) to execute?

Or is this the type of scenario where you are expected to register 
call-backs and then yield control back to a higher-level function that 
is not your own, effectively ending your program until a call-back is 
invoked?

>
>> In my opinion, if you are targeting a particular environment (which
>> doesn't have malloc() and free() ), then perhaps you needn't be overly
>> concerned about portability!
>
> What is the reason I couldn't expect a piece of code without malloc/free
> to be portable?

That's not what I meant.  I meant, as has been expressed by other 
respondents in your thread here, that casting an 'int' to a 'void *' is 
not portable in a standard sense, according to the n1256.pdf draft's 
section 6.3.2.3, point 5.  An implementation might define it as 
unsupported, if I'm not mistaken.

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

#3920

Il 12/05/2011 22:05, Shao Miller ha scritto:
> Well that's too bad. Do you at least have a function which will cause a
> thread to sleep and provide an opportunity for another thread (such as
> one that invokes your call-back) to execute?
>
> Or is this the type of scenario where you are expected to register
> call-backs and then yield control back to a higher-level function that
> is not your own, effectively ending your program until a call-back is
> invoked?

In my application I have a software with cooperative multitasking. Each 
task is a function that is responsible to exit in a short time to give 
other threads/functions the possibility to run.

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

#3934

pozz <pozzugno@gmail.com> writes:

> Il 12/05/2011 22:05, Shao Miller ha scritto:
>> Well that's too bad. Do you at least have a function which will cause a
>> thread to sleep and provide an opportunity for another thread (such as
>> one that invokes your call-back) to execute?
>>
>> Or is this the type of scenario where you are expected to register
>> call-backs and then yield control back to a higher-level function that
>> is not your own, effectively ending your program until a call-back is
>> invoked?
>
> In my application I have a software with cooperative
> multitasking. Each task is a function that is responsible to exit in a
> short time to give other threads/functions the possibility to run.

Which is, irritatingly, the one time when you would benefit from a nice
way to pass the integers through the void pointers without having to
have global (or very nearly global) variables holding constants hanging
around for them to point back to.

So I think we've exhausted it: either use the integers cast to pointers
and accept that this may well work on a variety of platforms but is
definitely non-portable (and there certainly are/have been platforms it
could well give problems on: those with a segmented architecture for
example) or end up with a global array of constants to point at.

Sad but true.
-- 
Online waterways route planner            | http://canalplan.eu
Plan trips, see photos, check facilities  | http://canalplan.org.uk

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

#3884

On 5/12/2011 1:44 PM, pozz wrote:
> [...]
> malloc() and free() are not present in my embedded system. I have to use
> only static allocation.

     malloc() is absent but printf() is present?  It's possible,
certainly, but seems unlikely if not downright perverse.

     Anyhow, implementing a quick-and-dirty malloc() work-alike
based on a static array shouldn't take anyone more than an hour.

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

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

#3918

Il 13/05/2011 04:07, Eric Sosman ha scritto:
>> malloc() and free() are not present in my embedded system. I have to use
>> only static allocation.
>
> malloc() is absent but printf() is present? It's possible,
> certainly, but seems unlikely if not downright perverse.

Hmmm..., I haven't a big experience in C programming on embedded 
systems, but I worked on some environments. Except some (and not all) 
8-bit microcontrollers, they had sprintf() but not dynamical allocation 
mechanisms.


> Anyhow, implementing a quick-and-dirty malloc() work-alike
> based on a static array shouldn't take anyone more than an hour.

Maybe it is possible (indeed I'm interested to have a look to some 
working implementations), but I think static allocation in embedded 
systems could be sufficient for most of all the work.

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

#3931

On 5/13/2011 5:12 PM, pozz wrote:
> Il 13/05/2011 04:07, Eric Sosman ha scritto:
>>> malloc() and free() are not present in my embedded system. I have to use
>>> only static allocation.
>>
>> malloc() is absent but printf() is present? It's possible,
>> certainly, but seems unlikely if not downright perverse.
>
> Hmmm..., I haven't a big experience in C programming on embedded
> systems, but I worked on some environments. Except some (and not all)
> 8-bit microcontrollers, they had sprintf() but not dynamical allocation
> mechanisms.

     I'm not disputing your observation, just remarking that it
seems an odd choice on the implementor's part.  The *printf() suite
usually turns out to be a rather large amount of code, even if it's
limited just to sprintf() and doesn't do actual output.  The malloc()
package is quite small by comparison, and it seems weird that an
implementor would do all the hard work of providing *printf() but
shy away from the much simpler malloc().

     Hmm: One reason to omit malloc() might be that the embedded
system has its own un-malloc()-like memory management API.  If so,
perhaps you could use it instead.

>> Anyhow, implementing a quick-and-dirty malloc() work-alike
>> based on a static array shouldn't take anyone more than an hour.
>
> Maybe it is possible (indeed I'm interested to have a look to some
> working implementations), but I think static allocation in embedded
> systems could be sufficient for most of all the work.

     Maybe I misread you somewhere along the line, but I thought you
were worried about the lifetime of the data item referenced by the
callback function's pointer argument.  If static allocation works for
your scenario, fine.  But if you've got a variable and hard-to-predict
number of these callbacks being registered at run-time, you'll very
likely find yourself in need of an allocation whose lifetime is neither
infinite (static) nor tied to a scope (auto).

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

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

#3737

In article <80905e4d-6b11-4843-b4e7-96f0c7db8b23@l18g2000yql.googlegroups.com>,
 pozz <pozzugno@gmail.com> wrote:

> What do you think about this code?

stdint.h defines a type name intptr_t which is an integer that can be converted 
to a pointer and back again:
    void *p = ...; intptr_t a = ...;

    a is an integer variable and you can use << >> % etc with it.
    
    (void*)(intptr_t)p == p
    (intptr_t)(void*)a == a

    p = (void*)a;

    (intptr_t)p == a
    p == (void*)a


> int foo(const void *Args) {
>   printf("%d\n", (const int)Args);
>   return 0;
> }
> 
> int main(int argc, char *argv[]) {
>   foo((void *)10);
>   return 0;
> }
> 
> It seems work and it should be nice if it is a sufficient portable way
> to pass integers as pointers.
> 
> Why don't I declare foo() to directly accept int? Because it is a
> callback of a library I can't change and the prototype of the callback
> is well defined by the library to accept void pointer.

-- 
Damn the living - It's a lovely life.           I'm whoever you want me to be.
Silver silverware - Where is the love?       At least I can stay in character.
Oval swimming pool - Where is the love?    Annoying Usenet one post at a time.
Damn the living - It's a lovely life.                              In 1492....

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

#3748

On 2011-05-11, Columbus sailed the ocean China Blue <chine.bleu@yahoo.com> wrote:
> In article <80905e4d-6b11-4843-b4e7-96f0c7db8b23@l18g2000yql.googlegroups.com>,
>  pozz <pozzugno@gmail.com> wrote:
>
>> What do you think about this code?
>
> stdint.h defines a type name intptr_t which is an integer that can be converted 
> to a pointer and back again:
>     void *p = ...; intptr_t a = ...;
>
>     a is an integer variable and you can use << >> % etc with it.
>     
>     (void*)(intptr_t)p == p
>     (intptr_t)(void*)a == a

The above is not entirely true.  The intptr_t and uintptr_t types, if
they exist (they are optional), are capable of holding any valid
pointer-to-void value, but not the other way around.  To quote the
C99 draft,

"The following type [intptr_t] designates a signed integer type with the
property that any valid pointer to void can be converted to this type,
then converted back to pointer to void, and the result will compare
equal to the original pointer"

In other words, the conversion to intptr_t and back is safe only for
valid pointers.  Arbitrary integer values, even if they are stored in an
intptr_t object, are not guaranteed to be safely convertible to
pointers.

-- 
Heikki Kallasjoki
email: echo 'zfs+es_t_i@n_u.zf' | tr zen_muftis fuze_mints

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

#3753

In article <slrnisl271.p2s.fis@iris.zem.fi>,
 Heikki Kallasjoki <see@end.of.message.invalid> wrote:

> On 2011-05-11, Columbus sailed the ocean China Blue <chine.bleu@yahoo.com> 
> wrote:
> > In article 
> > <80905e4d-6b11-4843-b4e7-96f0c7db8b23@l18g2000yql.googlegroups.com>,
> >  pozz <pozzugno@gmail.com> wrote:
> >
> >> What do you think about this code?
> >
> > stdint.h defines a type name intptr_t which is an integer that can be 
> > converted 
> > to a pointer and back again:
> >     void *p = ...; intptr_t a = ...;
> >
> >     a is an integer variable and you can use << >> % etc with it.
> >     
> >     (void*)(intptr_t)p == p
> >     (intptr_t)(void*)a == a
> 
> The above is not entirely true.  The intptr_t and uintptr_t types, if
> they exist (they are optional), are capable of holding any valid
> pointer-to-void value, but not the other way around.  To quote the
> C99 draft,
> 
> "The following type [intptr_t] designates a signed integer type with the
> property that any valid pointer to void can be converted to this type,
> then converted back to pointer to void, and the result will compare
> equal to the original pointer"
> 
> In other words, the conversion to intptr_t and back is safe only for
> valid pointers.  Arbitrary integer values, even if they are stored in an
> intptr_t object, are not guaranteed to be safely convertible to
> pointers.

That's nice. Any compiler that screws this up will break so much software that 
it will be rejected.

-- 
Damn the living - It's a lovely life.           I'm whoever you want me to be.
Silver silverware - Where is the love?       At least I can stay in character.
Oval swimming pool - Where is the love?    Annoying Usenet one post at a time.
Damn the living - It's a lovely life.                              In 1492....

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

#3760

Columbus sailed the ocean China Blue <chine.bleu@yahoo.com> writes:
> In article <slrnisl271.p2s.fis@iris.zem.fi>,
>  Heikki Kallasjoki <see@end.of.message.invalid> wrote:
[...]
>> The above is not entirely true.  The intptr_t and uintptr_t types, if
>> they exist (they are optional), are capable of holding any valid
>> pointer-to-void value, but not the other way around.  To quote the
>> C99 draft,
>> 
>> "The following type [intptr_t] designates a signed integer type with the
>> property that any valid pointer to void can be converted to this type,
>> then converted back to pointer to void, and the result will compare
>> equal to the original pointer"
>> 
>> In other words, the conversion to intptr_t and back is safe only for
>> valid pointers.  Arbitrary integer values, even if they are stored in an
>> intptr_t object, are not guaranteed to be safely convertible to
>> pointers.
>
> That's nice. Any compiler that screws this up will break so much
> software that it will be rejected.

I'm sure there's plenty of software that assumes it can safely
convert integers to pointers.  Much of it probably does so
unnecessarily, and much of it makes non-portable assumptions about
the relative sizes of integer and pointer types, and is likely to
break on 64-bit systems.  I suspect that most programmers who are
aware of the existence of intptr_t and uintptr_t are experienced
enough to know that they're rarely the right solution.

But how much software depends on being able to convert arbitrary
integer values to pointers?  Why would you even want to do that?

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

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

#3761

In article <lnhb91l0p9.fsf@nuthaus.mib.org>, Keith Thompson <kst-u@mib.org> 
wrote:

> But how much software depends on being able to convert arbitrary
> integer values to pointers?  Why would you even want to do that?

Most callback interfaces designed in the last dozens of years depend on that.

-- 
Damn the living - It's a lovely life.           I'm whoever you want me to be.
Silver silverware - Where is the love?       At least I can stay in character.
Oval swimming pool - Where is the love?    Annoying Usenet one post at a time.
Damn the living - It's a lovely life.                              In 1492....

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

#3765

Columbus sailed the ocean China Blue <chine.bleu@yahoo.com> writes:
> In article <lnhb91l0p9.fsf@nuthaus.mib.org>, Keith Thompson <kst-u@mib.org> 
> wrote:
>> But how much software depends on being able to convert arbitrary
>> integer values to pointers?  Why would you even want to do that?
>
> Most callback interfaces designed in the last dozens of years depend on that.

Can you provide a concrete example?

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

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

Page 1 of 4  [1] 2 3 4  Next page →

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

csiph-web