«

On May 11, 6:38*pm, gaze...@shell.xmission.com (Kenny McCormack)
wrote:
> In article <lnd3jpkz4z....@nuthaus.mib.org>,
> Keith Thompson *<ks...@mib.org> wrote:
> >Can you provide a concrete example?
>
> Yes. *He can.
>
> http://homepage.ntlworld.com/jonatha...A/questions-wi...

Pah! That's only one step from actually asking the intended question.

Consider the following, actually said by my mother:

"I don't know whether you want to help your father."

How many steps does it take to get from that to the actual meaning?

On 2011-05-11, Columbus sailed the ocean China Blue <> wrote:
> In article <>, Keith Thompson <kst->
> 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.

I've never seen that be a requirement of the interface. If you want to
pass an integer in, you pass its address. Otherwise you are exposing
yourself to Unknown Bad ****.

I never saw any need to take the extra risk.

-s
--
Copyright 2011, all wrongs reversed. Peter Seebach / usenet-
http://www.seebs.net/log/ <-- lawsuits, religion, and funny pictures
http://en.wikipedia.org/wiki/Fair_Game_(Scientology) <-- get educated!
I am not speaking for my employer, although they do rent some of my opinions.

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

On 05/12/11 07:56 PM, Columbus sailed the ocean China Blue wrote:
> In article<slrnism04g.bnl.usenet->,
> Seebs<usenet-> wrote:
>
>> On 2011-05-11, Columbus sailed the ocean China Blue<>
>> wrote:
>>> In article<>, Keith Thompson<kst->
>>> 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.
>>
>> I've never seen that be a requirement of the interface. If you want to
>
> Then you haven't seen any libraries that pass through a callerData to a callback
> function. These libraries advertise that can be a data pointer or small enough
> integer. Or unix signal interface. Or Tcl file handle interface.

Well I've seen plenty and none of them made that claim. They either
take an integer (signal callbacks) or a (typically void*) pointer.
Anything else is a hack.

--
Ian Collins

On 2011-05-12, Ian Collins <ian-> wrote:
> On 05/12/11 07:56 PM, Columbus sailed the ocean China Blue wrote:
>> Then you haven't seen any libraries that pass through a callerData to
>> a callback function. These libraries advertise that can be a data
>> pointer or small enough integer. Or unix signal interface. Or Tcl
>> file handle interface.
>
> Well I've seen plenty and none of them made that claim. They either
> take an integer (signal callbacks) or a (typically void*) pointer.
> Anything else is a hack.

The POSIX signal interface accepts the user-provided "signal value"
(when sending signals with sigqueue(2)) as an integer-pointer union,

union sigval {
int sival_int;
void *sival_ptr;
};

Sending such union values around is of course a safe way to pass either
a pointer or an integer. (Assuming the handler knows which type of
value to expect.)

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

On 5/11/2011 9:46 AM, Columbus sailed the ocean China Blue wrote:
> In article<>,
> Heikki Kallasjoki<> wrote:
>> [...]
>> 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.

This is how bad code hurts better code. Suppose you're a compiler
writer, and you've figured out a nifty little optimization that reduces
the time for pointer operations by X% but makes pointer/integer
conversion pretty much meaningless. Do you implement the optimization
and let the existing bad code fail, or do you suppress it to keep the
bad code running -- and run good code X% slower?

Oh, yes, it happens. The X's may be small, but they are numerous.
Remember, this is a newsgroup where people will fret endlessly about
whether `++i' or `i++' is faster ...

--
Eric Sosman
d

On 5/12/2011 7:08 AM, Columbus sailed the ocean China Blue wrote:
> In article<iqge5d$h58$>,
> Eric Sosman<> wrote:
>
>> On 5/11/2011 9:46 AM, Columbus sailed the ocean China Blue wrote:
>>> In article<>,
>>> Heikki Kallasjoki<> wrote:
>>>> [...]
>>>> 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.
>>
>> This is how bad code hurts better code. Suppose you're a compiler
>> writer, and you've figured out a nifty little optimization that reduces
>> the time for pointer operations by X% but makes pointer/integer
>
> Because this is irrelevant. Interfaces that allow integers to be passed through
> as (void*) also promise they make no changes to the void pointers, that they are
> passed through unchanged.

Interfaces that make such promises are making promises that go
beyond the C language itself. This is perfectly legitimate, just like
interfaces that promise meaningful conversion between void* and function
pointers or interfaces that promise a 64-bit `long' or interfaces that
promise the existence of an third argument to main(). These promises
are valid IN THE DOMAIN OF THE PROMISOR, but are not binding on other
C implementations.

Besides, you're begging the question, which boils down to "Can an
int be converted to void* and back without change?" When you begin
your answer with "Interfaces that allow integers to be passed through
as (void*) ..." you have evaded the entire issue.

> It's becoming clear that a large group of 'C experts' have no experience how C
> is actually used. Feel free to whinge about this amongst yourself, but be aware
> you will have no effect on the rest of the world.

Can't speak for others, but my own ~3.5 decades of C experience
haven't enabled me to make much impact on the intentionally stupid.

--
Eric Sosman
d

Columbus sailed the ocean China Blue <> writes:
> In article <iqge5d$h58$>,
> Eric Sosman <> wrote:
>> On 5/11/2011 9:46 AM, Columbus sailed the ocean China Blue wrote:
>> > In article<>,
>> > Heikki Kallasjoki<> wrote:
>> >> [...]
>> >> 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.
>>
>> This is how bad code hurts better code. Suppose you're a compiler
>> writer, and you've figured out a nifty little optimization that reduces
>> the time for pointer operations by X% but makes pointer/integer
>
> Because this is irrelevant. Interfaces that allow integers to be
> passed through as (void*) also promise they make no changes to
> the void pointers, that they are passed through unchanged.

Do you have a concrete example of an interface that expects a void*
argument, and depends on the ability to convert an arbitrary integer
value to a pointer without loss of information?

> It's becoming clear that a large group of 'C experts' have no
> experience how C is actually used. Feel free to whinge about
> this amongst yourself, but be aware you will have no effect on
> the rest of the world.

This would be a lot clearer if you'd back up your specific claims.

--
Keith Thompson (The_Other_Keith) kst- <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"

In article <>,
Keith "Kiki" Thompson <> wrote:
....
>Do you have a concrete example of an interface that expects a void*
>argument, and depends on the ability to convert an arbitrary integer
>value to a pointer without loss of information?

Yes, he does.

http://homepage.ntlworld.com/jonatha...-with-yes-or-n
o-answers.html

>> It's becoming clear that a large group of 'C experts' have no
>> experience how C is actually used. Feel free to whinge about
>> this amongst yourself, but be aware you will have no effect on
>> the rest of the world.

Yes, that's the beauty of clc. Welcome & enjoy!

>This would be a lot clearer if you'd back up your specific claims.

The insanity of this latest from the Kikster absolutely boggles the mind.

--
(This discussion group is about C, ...)

Wrong. It is only OCCASIONALLY a discussion group
about C; mostly, like most "discussion" groups, it is
off-topic Rorsharch [sic] revelations of the childhood
traumas of the participants...

On 2011-05-12, Columbus sailed the ocean China Blue <> wrote:
> In article <iqge5d$h58$>,
> Eric Sosman <> wrote:
>> This is how bad code hurts better code. Suppose you're a compiler
>> writer, and you've figured out a nifty little optimization that reduces
>> the time for pointer operations by X% but makes pointer/integer

> Because this is irrelevant.

I don't think you are really understanding the claim...

> It's becoming clear that a large group of 'C experts' have no
> experience how C is actually used. Feel free to whinge about this
> amongst yourself, but be aware you will have no effect on the rest
> of the world.

I suspect we have rather a bit more experience how C is actually used than
you think, largely because, well... I know what some of these people do.

I have never, ever, seen an interface which takes a (void *) argument as
a callback parameter claim that anything other than (void *) is meaningful
or acceptable to it. I have also never seen anyone write code which uses
such an interface and doesn't pass it pointers. And if such code came near
me for code review, it would get NAKd, because my job is to make sure that
code will run reliably across about sixty processors and also on new
processors we haven't seen yet. That, it turns out, means not playing silly
buggers for no reason.

-s
--
Copyright 2011, all wrongs reversed. Peter Seebach / usenet-
http://www.seebs.net/log/ <-- lawsuits, religion, and funny pictures
http://en.wikipedia.org/wiki/Fair_Game_(Scientology) <-- get educated!
I am not speaking for my employer, although they do rent some of my opinions.