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 3 of 4 — ← Prev page 1 2 [3] 4  Next page →

#3777

On 2011-05-11, Columbus sailed the ocean China Blue <chine.bleu@yahoo.com> wrote:
> 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.

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

I never saw any need to take the extra risk.

-s
-- 
Copyright 2011, all wrongs reversed.  Peter Seebach / usenet-nospam@seebs.net
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.

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

#3790

In article <slrnism04g.bnl.usenet-nospam@guild.seebs.net>,
 Seebs <usenet-nospam@seebs.net> wrote:

> On 2011-05-11, Columbus sailed the ocean China Blue <chine.bleu@yahoo.com> 
> wrote:
> > 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.
> 
> 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.

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

#3791

On 05/12/11 07:56 PM, Columbus sailed the ocean China Blue wrote:
> In article<slrnism04g.bnl.usenet-nospam@guild.seebs.net>,
>   Seebs<usenet-nospam@seebs.net>  wrote:
>
>> On 2011-05-11, Columbus sailed the ocean China Blue<chine.bleu@yahoo.com>
>> wrote:
>>> 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.
>>
>> 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

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

#3792

On 2011-05-12, Ian Collins <ian-news@hotmail.com> 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

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

#3850

On 05/12/11 08:59 PM, Heikki Kallasjoki wrote:
> On 2011-05-12, Ian Collins<ian-news@hotmail.com>  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

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

#3793

On 5/11/2011 9:46 AM, Columbus sailed the ocean China Blue wrote:
> In article<slrnisl271.p2s.fis@iris.zem.fi>,
>   Heikki Kallasjoki<see@end.of.message.invalid>  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
esosman@ieee-dot-org.invalid

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

#3794

In article <iqge5d$h58$1@dont-email.me>,
 Eric Sosman <esosman@ieee-dot-org.invalid> wrote:

> On 5/11/2011 9:46 AM, Columbus sailed the ocean China Blue wrote:
> > In article<slrnisl271.p2s.fis@iris.zem.fi>,
> >   Heikki Kallasjoki<see@end.of.message.invalid>  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.

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.

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

#3795

On 5/12/2011 7:08 AM, Columbus sailed the ocean China Blue wrote:
> In article<iqge5d$h58$1@dont-email.me>,
>   Eric Sosman<esosman@ieee-dot-org.invalid>  wrote:
>
>> On 5/11/2011 9:46 AM, Columbus sailed the ocean China Blue wrote:
>>> In article<slrnisl271.p2s.fis@iris.zem.fi>,
>>>    Heikki Kallasjoki<see@end.of.message.invalid>   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
esosman@ieee-dot-org.invalid

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

#3806

Columbus sailed the ocean China Blue <chine.bleu@yahoo.com> writes:
> In article <iqge5d$h58$1@dont-email.me>,
>  Eric Sosman <esosman@ieee-dot-org.invalid> wrote:
>> On 5/11/2011 9:46 AM, Columbus sailed the ocean China Blue wrote:
>> > In article<slrnisl271.p2s.fis@iris.zem.fi>,
>> >   Heikki Kallasjoki<see@end.of.message.invalid>  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-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]

#3809

In article <lnzkmsj781.fsf@nuthaus.mib.org>,
Keith "Kiki" Thompson  <kiki@mib.org> 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/jonathan.deboynepollard/FGA/questions-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...

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

#3816

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/library/ff550671%28VS.85%29.aspx

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

#3827

Shao Miller <sha0.miller@gmail.com> 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/library/ff550671%28VS.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-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]

#3811

On 2011-05-12, Columbus sailed the ocean China Blue <chine.bleu@yahoo.com> wrote:
> In article <iqge5d$h58$1@dont-email.me>,
>  Eric Sosman <esosman@ieee-dot-org.invalid> 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-nospam@seebs.net
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.

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

#3834

In article <iqge5d$h58$1@dont-email.me>,
 Eric Sosman <esosman@ieee-dot-org.invalid> wrote:

> On 5/11/2011 9:46 AM, Columbus sailed the ocean China Blue wrote:
> > In article<slrnisl271.p2s.fis@iris.zem.fi>,
> >   Heikki Kallasjoki<see@end.of.message.invalid>  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

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

#3885

On 5/12/2011 5:14 PM, Michael Press wrote:
> In article<iqge5d$h58$1@dont-email.me>,
>   Eric Sosman<esosman@ieee-dot-org.invalid>  wrote:
>
>> On 5/11/2011 9:46 AM, Columbus sailed the ocean China Blue wrote:
>>> In article<slrnisl271.p2s.fis@iris.zem.fi>,
>>>    Heikki Kallasjoki<see@end.of.message.invalid>   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.

     That's what makes the Standard-as-contract valuable: It describes
the freedoms of both the user-programmer and the implementor.  Have
you heard the maxim "Code to the interface, not the implementation?"
The Standard's job is to codify the interface; everybody benefits when
user-programmer and implementor stay on their own sides of the border.

     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.  Language longevity seems not so strongly
influenced by aesthetics as you appear to suppose.

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

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

#3925

Eric Sosman <esosman@ieee-dot-org.invalid> writes:
<snip>
>     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.

>  Language longevity seems not so strongly
> influenced by aesthetics as you appear to suppose.

-- 
Ben.

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

#3738

On 5/11/2011 6:01 AM, pozz wrote:
> What do you think about this code?

     Nothing good.

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

     It's not portable.  Both the integer-to-pointer conversion in
the call and the pointer-to-integer conversion in the function are
implementation-defined, and the implementation is not required to
define them as inverses of each other.  Many will so define them,
but it's not guaranteed.  I've run into implementations that swizzle
the values on some integer/pointer/integer conversions, although to
be truthful I've only seen it with things like double* pointers, not
with void*.

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

     Pthreads, perhaps?  No matter: take Tom St Denis' advice and pass
a pointer to an int variable holding the desired value.

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

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

#3752

On 05/11/2011 06:01 AM, pozz 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.

It isn't portable.  For the cast to void*: "... the result is
implementation-defined, ... and might be a trap representation."
(6.3.2.3p5). For the conversion back to int: "... the result is
implementation-defined. If the result cannot be represented in the
integer type, the behavior is undefined. The result need not be in the
range of values of any integer type." (6.3.2.3p6)

Note that the best you can hope for, as a result of either conversion,
is an implementation-defined result; there's nothing guaranteeing that
the implementation will define those results in such a way as to produce
a value of 10 (though it's not particularly unusual for them to do so -
that is why your defective code appears to be working).

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

Just create an object containing the value 10, and then pass a pointer
to that object. That's how the pointer parameter of the callback
function is intended to be used.
-- 
James Kuyper

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

#3764

On Wed, 11 May 2011 03:01:49 -0700 (PDT), pozz <pozzugno@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.

I must be missing something.

What library callback are you referring to?

DFC

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

#3769

On May 11, 8:53 am, Datesfat Chicks <datesfat.chi...@gmail.com> wrote:
> On Wed, 11 May 2011 03:01:49 -0700 (PDT), 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.
>
> I must be missing something.
>
> What library callback are you referring to?
>

One example might be the XtCallback on Unix:

void CallbackProc( Widget w, XtPointer clientData, XtPointer
callData )

where XtPointer is defined as a "void *".

The app registers the callback using:
XtAddCallback( myWidget, XtXxxxCallback, CallbackProc, clientData );

where clientData was often some integer flag. Passing a pointer to
an integer would require that integer to remain in scope globally,
since the registration code and the callback code might be in
different compilation units.

Many of the examples in the Flannagan's O'Reilly series of
manuals do this sort of thing.

This type of coding, of course, should not be recommended, and
can cause a lot of headaches when porting to a 64-bit platform
where int and pointer are different sizes.
--
Fred K

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

Page 3 of 4 — ← Prev page 1 2 [3] 4  Next page →

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

csiph-web