smuggling data in and out of alarm handlers and the like

[David Mathog]

Every so often I find a need to move data in or out of functions which
are not called directly. For instance, alarm handlers or the compare
function used by qsort. In these cases there is no possibility of
passing the data as a function parameter, so it needs to be "smuggled"
in.

Is there a better way of doing this than the three methods described below?

1. use global variables. This is fine for small monolithic programs
but isn't great in larger programs using lots of code in separate
files and/or shared libraries.

2. create a function like this:

SOME_STRUCT *smuggle_pointe r(SOME_STRUCT *pointer){
static SOME_STRUCT *hold_pointer;
if(pointer)hold _pointer = pointer;
return(hold_poi nter);
}

and load it with data before any possible calls to the
problem functions. The target function contains:

SOME_STRUCT *pointer;
pointer = smuggle_pointer (NULL);

which gives that function access to this data.

3. use setenv/getenv. This is not part of ANSI C, but is
usually available. Only useful for one or two simple
values.
Is there a better way?

Thanks,

David Mathog

[Ben Pfaff]

David Mathog <ma****@caltech .eduwrites:

Every so often I find a need to move data in or out of functions which
are not called directly. For instance, alarm handlers or the compare
function used by qsort. In these cases there is no possibility of
passing the data as a function parameter, so it needs to be "smuggled"
in.

For qsort and bsearch, I use replacements that take an extra void
* parameter and pass it to the comparison function. The void *
can be used to pass arbitrary data. (There's really no excuse
for these functions failing to provide any way to pass auxiliary
data. They are badly designed in my opinion.)
--
"Your correction is 100% correct and 0% helpful. Well done!"
--Richard Heathfield

[pete]

David Mathog wrote:

>
Every so often I find a need to move data in or out of functions which
are not called directly. For instance, alarm handlers or the compare
function used by qsort. In these cases there is no possibility of
passing the data as a function parameter, so it needs to be "smuggled"
in.

When there's only a small number of values
that your variable can have:

For example,
if you had an array of pointers
to strings of a few columns,
and you wanted to qsort the strings
based on an arbitrary column,

then you could define an array of pointers to
different compar functions,
which you would also have to write,
and then a variable indexing the array of function pointers
would be part of the qsort call.

--
pete

[Robert Latest]

David Mathog wrote:

Every so often I find a need to move data in or out of functions which
are not called directly. For instance, alarm handlers or the compare
function used by qsort.

Such functions are typically called "callback functions". Just to clarify.

In these cases there is no possibility of
passing the data as a function parameter, so it needs to be "smuggled"
in.

Yeah, that's a botch. For the qsort() callback you can at least pass in an
array of pointers to structs that have an additional member which points to
your "smuggled" data, which is clumsy because it eats memory and
performance.

When I started programmming GUIs using GTK+ (which revolves around callback
functions), it at first struck me as odd that each and every callback had
some curious "void *user_data" parameter which seemed useless. Boy, is it
not, as I realized after about 10 minutes. It's odd that the designers of
the C (and other) libraries didn't think of this mecessity.

robert

[SM Ryan]

Robert Latest <bo*******@yaho o.comwrote:

# When I started programmming GUIs using GTK+ (which revolves around callback
# functions), it at first struck me as odd that each and every callback had
# some curious "void *user_data" parameter which seemed useless. Boy, is it
# not, as I realized after about 10 minutes. It's odd that the designers of
# the C (and other) libraries didn't think of this mecessity.

This is a primitive way of doing closures. The full notion of a closure
came after the beginning of C and Unix. Proper implementation of closures
requires garbage collection which many in C are still reluctant to use.

--
SM Ryan http://www.rawbw.com/~wyrmwif/
I love the smell of commerce in the morning.

[Paul Hsieh]

On Dec 14, 9:03 am, David Mathog <mat...@caltech .eduwrote:

Every so often I find a need to move data in or out of functions which
are not called directly. For instance, alarm handlers or the compare
function used by qsort. In these cases there is no possibility of
passing the data as a function parameter, so it needs to be "smuggled"
in.

Is there a better way of doing this than the three methods described below?

Yeah, the methods you describe are all basically "global" in one
fashion or another, which prevents re-entrancy. The right answer to
use interfaces that always carry a "user pointer" around with it --
something opaque to the calling mechanism, but known to the originator
and target function.

By this criteria, qsort() is basically broken since the cmp() function
has no simple way to gain access to the contextual state.
Fortunately, its fairly easy and straightforward to write your own
sort. (Probably *more* fortunately, being forced to do so will make
you realize that the sort function should be a macro, not a function
call. This allows your "cmp" to itself be a macro, and thus eliminate
the major cost of qsort(), and you can pass contextual parameters to
macros just as easily as to functions.)

Thus, if its possible, just make sure some extra pointer to your
context is passed, and received in your leaf functions and demand that
your interface/transport pass along those pointers. In the case of a
generic transport, you should make it a void *, otherwise if its
custom you can declare the pointer exactly.

If you are stuck with an interface that didn't see fit to pass along
that extra pointer, then you can try to hide your context in a data
pointer, but of course that doesn't work for something like qsort.
But again, we don't care about qsort, since you should never use it
anyways (its always slow, always algorithmically sub-optimal, and
always inflexible -- qsort is just one of many examples of where its
clear that the C-library was designed by amateurs.)

If you *have* to use global variables, then you are going to want to
shield it from re-entrancy or multiple threads with some sort of
mutex, then just use a global or static depending on your taste (but
its like waxing a beat-up jalopy).

--
Paul Hsieh
http://www.pobox.com/~qed/
http://bstring.sf.net/

[Robert Latest]

Paul Hsieh wrote:

But again, we don't care about qsort, since you should never use it
anyways (its always slow, always algorithmically sub-optimal, and
always inflexible -- qsort is just one of many examples of where its
clear that the C-library was designed by amateurs.)

I can't find the passage in the C standard that requires the qsort function
to be implemented in some way or another.

robert

[Eric Sosman]

Paul Hsieh wrote:

On Dec 14, 9:03 am, David Mathog <mat...@caltech .eduwrote:

>Every so often I find a need to move data in or out of functions which
are not called directly. For instance, alarm handlers or the compare
function used by qsort. In these cases there is no possibility of
passing the data as a function parameter, so it needs to be "smuggled"
in.

Is there a better way of doing this than the three methods described below?

Yeah, the methods you describe are all basically "global" in one
fashion or another, which prevents re-entrancy. [...]

If you *have* to use global variables, then you are going to want to
shield it from re-entrancy or multiple threads with some sort of
mutex, then just use a global or static depending on your taste (but
its like waxing a beat-up jalopy).

Note that qsort() itself is not guaranteed to be reentrant
(7.1.4p4), so the use or non-use of static variables doesn't
really change the picture. For a multi-threaded program, this
means you either need to rely on standards that go beyond C's,
or else use some kind of mutual exclusion as Paul suggests. Even
for single-threaded programs (the only kind C really understands),
this means that qsort()'s comparison function must not use a
subsidiary qsort(). Similarly, bsearch()'s comparator mustn't
use bsearch().

--
Eric Sosman
es*****@ieee-dot-org.invalid

[santosh]

Robert Latest wrote:

Paul Hsieh wrote:

>But again, we don't care about qsort, since you should never use it
anyways (its always slow, always algorithmically sub-optimal, and
always inflexible -- qsort is just one of many examples of where its
clear that the C-library was designed by amateurs.)

I can't find the passage in the C standard that requires the qsort
function to be implemented in some way or another.

robert

Nevertheless it's interface cannot be changed, which is what, I think,
Paul Hsieh was talking about.

[James Kuyper]

santosh wrote:

Robert Latest wrote:

>Paul Hsieh wrote:

>>But again, we don't care about qsort, since you should never use it
anyways (its always slow, always algorithmically sub-optimal, and
always inflexible -- qsort is just one of many examples of where its
clear that the C-library was designed by amateurs.)

I can't find the passage in the C standard that requires the qsort
function to be implemented in some way or another.

robert

Nevertheless it's interface cannot be changed, which is what, I think,
Paul Hsieh was talking about.

You can't derive the conclusion that qsort() is "... always slow, always
algorithmically sub-optimal, ..." from the interface specification, or
indeed from anything else that the standard says about qsort().