«

On 5/12/2011 10:58, Keith 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?
>

In Windows driver-land, there is an 'IO_STATUS_BLOCK'[1] structure type
which has a 'ULONG_PTR' member called 'Information'. Sometimes this is
populated with an integer value. Sometimes this is populated by casting
a pointer to 'ULONG_PTR'.

My understanding is that this is not portable in a standard sense, but I
just thought I'd offer it as a potentially related example. In this
case, it's the other way 'round than converting an integer to 'void *'.

[1] http://msdn.microsoft.com/en-us/libr...8VS.85%29.aspx

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.

Shao Miller <> writes:
> On 5/12/2011 10:58, Keith 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?
>>
>
> In Windows driver-land, there is an 'IO_STATUS_BLOCK'[1] structure type
> which has a 'ULONG_PTR' member called 'Information'. Sometimes this is
> populated with an integer value. Sometimes this is populated by casting
> a pointer to 'ULONG_PTR'.
>
> My understanding is that this is not portable in a standard sense, but I
> just thought I'd offer it as a potentially related example. In this
> case, it's the other way 'round than converting an integer to 'void *'.
>
> [1] http://msdn.microsoft.com/en-us/libr...8VS.85%29.aspx

ULONG_PTR is an unsigned integer type (I had assumed from the name that
it was a pointer type). According to
<http://msdn.microsoft.com/en-us/library/cc230394%28v=prot.10%29.aspx>:

A ULONG_PTR is an unsigned long type used for pointer
precision. It is used when casting a pointer to a long type to
perform pointer arithmetic.

This type is declared as follows:

typedef unsigned __int3264 ULONG_PTR;

where __int3264 is either 32 or 64 bits. So it seems to play a similar
role to standard C's uintptr_t.

(Of course, you don't need to cast a pointer to a long type to perform
pointer arithmetic; pointer arithmetic works on pointers.)

And as you say, it's not an example of what I was asking "Columbus
sailed the ocean China Blue" about.

--
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"

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.

In article
<9565b443-c6e3-4d63-9086->,
Paul N <> wrote:

> 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?

People seeking help can be helped by coaxing them
into asking precise questions. Often a problem
solves itself once the question is made sharp enough,
eliminating the need even to ask the question in a forum.
Do not underrate the benefit to the forum at large.
Helping people who ask imprecise or vague questions
is wearing. Answering well posed questions can be
interesting in itself---the opposite of wearing.

--
Michael Press

Michael Press <> writes:
> In article
> <9565b443-c6e3-4d63-9086->,
> Paul N <> wrote:
>
[...]
>> > In article <lnd3jpkz4z....@nuthaus.mib.org>,
>> > Keith Thompson Â*<ks...@mib.org> wrote:
>> > >Can you provide a concrete example?
>> >
[snip]
>>
>> 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?
>
> People seeking help can be helped by coaxing them
> into asking precise questions. Often a problem
> solves itself once the question is made sharp enough,
> eliminating the need even to ask the question in a forum.
> Do not underrate the benefit to the forum at large.
> Helping people who ask imprecise or vague questions
> is wearing. Answering well posed questions can be
> interesting in itself---the opposite of wearing.

I'm all for precise questions, but the implicit meaning of "Can
you provide a concrete example" is clear enough to anyone who's not
deliberately trying to be difficult (as one poster in this thread,
not quoted here, clearly is).

And if the person of whom I actually asked the question, someone
posting as "Columbus sailed the ocean China Blue", wanted to take
it literally and just say "Yes", there would at least be a basis
for further discussion.

My current working hypothesis, given the lack of an actual
response, is that there are no such concrete examples, or at least
no significant ones, and that a C compiler that didn't support
converting arbitrary integer values to pointers without loss of
information wouldn't break much existing code.

There are plenty of things whose behavior is undefined, but that
C compilers can't afford to break, but I'm not convinced that this
is one of them.

--
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 <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
> 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?

That works both ways. A language lumbered with dozens of
little inconveniences will be abandoned. When compiler
writers start to think the C programming language is
their own little sandbox, the language is in trouble.
Optimization always has its cost to weigh against its benefit;
and one of the costs is losing people who use the language.

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

--
Michael Press

On 2011-05-12, Columbus sailed the ocean China Blue <> wrote:
> In article <>, Keith Thompson <kst->
> wrote:
>> My current working hypothesis, given the lack of an actual
>> response, is that there are no such concrete examples, or at least
>> no significant ones, and that a C compiler that didn't support
>> converting arbitrary integer values to pointers without loss of
>> information wouldn't break much existing code.

> If you're finished digging yourself into a hole, you can start with
> man brk

Steeeeerike one!

brk()'s argument is a "void *" and is not an int, nor is it meaningful or
valid to pass an int to it. The one which takes integer arguments is
sbrk().

Care to try again?

-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 05/12/11 08:59 PM, Heikki Kallasjoki wrote:
> 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.)

Exactly the point, it uses a union to make the process safe.

--
Ian Collins

On 05/13/11 10:37 AM, Seebs wrote:
> On 2011-05-12, Columbus sailed the ocean China Blue<> wrote:
>> In article<>, Keith Thompson<kst->
>> wrote:
>>> My current working hypothesis, given the lack of an actual
>>> response, is that there are no such concrete examples, or at least
>>> no significant ones, and that a C compiler that didn't support
>>> converting arbitrary integer values to pointers without loss of
>>> information wouldn't break much existing code.
>
>> If you're finished digging yourself into a hole, you can start with
>> man brk
>
> Steeeeerike one!
>
> brk()'s argument is a "void *" and is not an int, nor is it meaningful or
> valid to pass an int to it. The one which takes integer arguments is
> sbrk().

Bugger, you beat me to it!

--
Ian Collins