Passing an integer to a function that accepts a void pointer

[Tobias Blass]

[snip]
In some blatantly non-portable manner.

There's probably some way to get the current "break" value as
a void*. Given that value, you can add to it (by any of several
methods) and pass the result to brk(). Or you can use sbrk(), which
takes care of most of the bookkeeping for you. (Or, as the man
page recommends rather strongly, use malloc() to allocate memory.)

If you call sbrk(0) it returns the current location of the
"program break", that is the end of the process's data segment.
Source: sbrk manpage

 

[Seebs]

Unless sbrk fails and returns an error.

None of this changes that brk() is not an example of a function which
is defined to, or expected to, take arbitrary integer values converted
to pointers, or indeed, any integer values converted to pointers.

-s

 

[madamemandm]

None of this changes that brk() is not an example of a function which
is defined to, or expected to, take arbitrary integer values converted
to pointers, or indeed, any integer values converted to pointers.

Unfortunately, I can give an example. In the Windows API (it would
have to be Windows), a number of functions that take constant strings
can also take an ATOM. The definition of ATOM is

typedef WORD ATOM;

where WORD is a typedef for unsigned short.

In particular, check the lpClassName parameter to CreateWindowEx.

Martin Shobe

 

[Ben Bacarisse]

As for "will be abandoned," I'm not at all sure you're right.
C *is* loaded with dozens of little inconveniences, yet it is (my
guess) the third longest-surviving language in general use today,
behind Fortran and COBOL, languages if anything even more loaded
with inconveniences than C.

I'd say fourth-oldest because of LISP.

 

[Eric Sosman]

Il 13/05/2011 04:07, Eric Sosman ha scritto:

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.

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

 

[Dr Nick]

Il 12/05/2011 22:05, Shao Miller ha scritto:

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.