Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.c > #5477 > unrolled thread

Reference counting

Back to article view | Back to comp.lang.c

Contents

  Reference counting daknok <radekslupik@gmail.com> - 2011-06-05 12:52 +0200
    Re: Reference counting Angel <angel+news@spamcop.net> - 2011-06-05 11:17 +0000
      Re: Reference counting Gene <gene.ressler@gmail.com> - 2011-06-06 20:07 -0700
        Multiple Inheritance (Was Re: Reference counting) Shao Miller <sha0.miller@gmail.com> - 2011-06-11 03:57 -0500
          Re: Multiple Inheritance (Was Re: Reference counting) Dr Nick <3-nospam@temporary-address.org.uk> - 2011-06-12 07:22 +0100
    Re: Reference counting China Blue Angels <chine.bleu@yahoo.com> - 2011-06-05 05:07 -0700
    Re: Reference counting "BartC" <bc@freeuk.com> - 2011-06-05 13:14 +0100
      Re: Reference counting daknok <daknok@example.com> - 2011-06-05 14:22 +0200
        Re: Reference counting "BartC" <bc@freeuk.com> - 2011-06-05 14:45 +0100
          Re: Reference counting daknok <daknok@example.com> - 2011-06-05 17:01 +0200
            Re: Reference counting Eric Sosman <esosman@ieee-dot-org.invalid> - 2011-06-05 18:06 -0400
            Re: Reference counting Dr Nick <3-nospam@temporary-address.org.uk> - 2011-06-12 07:25 +0100
    Re: Reference counting daknok <daknok@example.com> - 2011-06-05 15:29 +0200
    Re: Reference counting Shao Miller <sha0.miller@gmail.com> - 2011-06-05 12:17 -0500
    Re: Reference counting cri@tiac.net (Richard Harter) - 2011-06-05 17:11 +0000
    Re: Reference counting ImpalerCore <jadill33@gmail.com> - 2011-06-10 11:30 -0700
      Re: Reference counting Shao Miller <sha0.miller@gmail.com> - 2011-06-10 16:04 -0400
      Re: Reference counting James Kuyper <jameskuyper@verizon.net> - 2011-06-10 22:56 -0400
        Re: Reference counting ImpalerCore <jadill33@gmail.com> - 2011-06-11 12:36 -0700
          Re: Reference counting Shao Miller <sha0.miller@gmail.com> - 2011-06-11 17:23 -0500
            Re: Reference counting luser- -droog <mijoryx@yahoo.com> - 2011-06-12 15:15 -0700
              Re: Reference counting Shao Miller <sha0.miller@gmail.com> - 2011-06-12 21:13 -0500
                Re: Reference counting "Chris M. Thomasson" <cristom@charter.net> - 2011-06-13 12:37 -0700
                  Re: Reference counting "Chris M. Thomasson" <cristom@charter.net> - 2011-06-13 12:54 -0700
                  Re: Reference counting Shao Miller <sha0.miller@gmail.com> - 2011-06-13 16:40 -0500
            Re: Reference counting ImpalerCore <jadill33@gmail.com> - 2011-06-13 07:34 -0700
              Re: Reference counting Shao Miller <sha0.miller@gmail.com> - 2011-06-13 14:26 -0500
                Re: Reference counting ImpalerCore <jadill33@gmail.com> - 2011-06-13 12:47 -0700
                  Re: Reference counting Shao Miller <sha0.miller@gmail.com> - 2011-06-13 17:33 -0500
                    Re: Reference counting ImpalerCore <jadill33@gmail.com> - 2011-06-14 12:14 -0700
                      Re: Reference counting Shao Miller <sha0.miller@gmail.com> - 2011-06-15 02:16 -0500
                    Re: Reference counting "Chris M. Thomasson" <cristom@charter.net> - 2011-06-15 15:34 -0700
                      Re: Reference counting "Chris M. Thomasson" <cristom@charter.net> - 2011-06-15 15:42 -0700
                        Re: Reference counting "Chris M. Thomasson" <cristom@charter.net> - 2011-06-16 13:45 -0700
                          Re: Reference counting Shao Miller <sha0.miller@gmail.com> - 2011-06-16 17:02 -0500
                            Re: Reference counting "Chris M. Thomasson" <cristom@charter.net> - 2011-06-16 15:18 -0700
                              Re: Reference counting "Chris M. Thomasson" <cristom@charter.net> - 2011-06-16 16:01 -0700
                                Re: Reference counting Shao Miller <sha0.miller@gmail.com> - 2011-06-16 18:44 -0500
                                  Re: Reference counting "Chris M. Thomasson" <cristom@charter.net> - 2011-06-16 17:11 -0700
                          Re: Reference counting Shao Miller <sha0.miller@gmail.com> - 2011-06-16 18:39 -0500
          Re: Reference counting "Chris M. Thomasson" <cristom@charter.net> - 2011-06-11 16:51 -0700
            Re: Reference counting "Chris M. Thomasson" <cristom@charter.net> - 2011-06-11 18:28 -0700
              Re: Reference counting Shao Miller <sha0.miller@gmail.com> - 2011-06-12 16:10 -0500
              Re: Reference counting ImpalerCore <jadill33@gmail.com> - 2011-06-13 07:36 -0700
        Re: Reference counting Tim Rentsch <txr@alumni.caltech.edu> - 2011-06-14 15:00 -0700
    Re: Reference counting luser- -droog <mijoryx@yahoo.com> - 2011-06-13 21:46 -0700
      Re: Reference counting Shao Miller <sha0.miller@gmail.com> - 2011-06-14 03:19 -0500
        Re: Reference counting Angel <angel+news@spamcop.net> - 2011-06-14 07:31 +0000
          Re: Reference counting Shao Miller <sha0.miller@gmail.com> - 2011-06-14 05:02 -0500
          Re: Reference counting Keith Thompson <kst-u@mib.org> - 2011-06-14 09:03 -0700
            Re: Reference counting luser- -droog <mijoryx@yahoo.com> - 2011-06-14 10:23 -0700
              Re: Reference counting Shao Miller <sha0.miller@gmail.com> - 2011-06-14 13:46 -0500
            Re: Reference counting Tim Rentsch <txr@alumni.caltech.edu> - 2011-06-14 15:05 -0700
              Re: Reference counting Keith Thompson <kst-u@mib.org> - 2011-06-14 16:44 -0700
                Re: Reference counting Tim Rentsch <txr@alumni.caltech.edu> - 2011-06-15 06:54 -0700
                  Re: Reference counting Keith Thompson <kst-u@mib.org> - 2011-06-15 08:46 -0700
                    Re: Reference counting pete <pfiland@mindspring.com> - 2011-06-15 22:19 -0400
                      Re: Reference counting James Kuyper <jameskuyper@verizon.net> - 2011-06-15 23:03 -0400
                    Re: Reference counting Tim Rentsch <txr@alumni.caltech.edu> - 2011-06-19 14:48 -0700
          Re: Reference counting Seebs <usenet-nospam@seebs.net> - 2011-06-14 17:16 +0000
      Re: Reference counting luser- -droog <mijoryx@yahoo.com> - 2011-06-14 20:53 -0700
        Re: Reference counting Shao Miller <sha0.miller@gmail.com> - 2011-06-16 18:49 -0500
    Re: Reference counting "io_x" <a@b.c.invalid> - 2011-06-14 08:30 +0200
      Re: Reference counting "io_x" <a@b.c.invalid> - 2011-06-14 09:15 +0200
        Re: Reference counting Shao Miller <sha0.miller@gmail.com> - 2011-06-14 04:21 -0500
        Re: Reference counting "io_x" <a@b.c.invalid> - 2011-06-16 10:35 +0200
          Re: Reference counting Ian Collins <ian-news@hotmail.com> - 2011-06-16 20:36 +1200
          Re: Reference counting "io_x" <a@b.c.invalid> - 2011-06-16 11:21 +0200
            Re: Reference counting "io_x" <a@b.c.invalid> - 2011-06-19 17:57 +0200
            Re: Reference counting "io_x" <a@b.c.invalid> - 2011-06-19 20:01 +0200
              Re: Reference counting Keith Thompson <kst-u@mib.org> - 2011-06-19 11:07 -0700
              Re: Reference counting Shao Miller <sha0.miller@gmail.com> - 2011-06-19 23:15 -0500
                Re: Reference counting "io_x" <a@b.c.invalid> - 2011-06-20 08:21 +0200
          Re: Reference counting Shao Miller <sha0.miller@gmail.com> - 2011-06-16 19:05 -0500
            Re: Reference counting Ian Collins <ian-news@hotmail.com> - 2011-06-17 12:09 +1200
    Re: Reference counting luser- -droog <mijoryx@yahoo.com> - 2011-06-15 08:40 -0700
    Re: Reference counting "christian.bau" <christian.bau@cbau.wanadoo.co.uk> - 2011-06-16 11:08 -0700
      Re: Reference counting Shao Miller <sha0.miller@gmail.com> - 2011-06-16 14:42 -0400

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

#5872

"ImpalerCore" <jadill33@gmail.com> wrote in message 
news:52c902de-0f66-4bb0-b787-8c440c2405db@hg8g2000vbb.googlegroups.com...

[...]

> Unfortunately I do not know how
> to manually find a platform's ALIGN_MAX.  I've seen some incantations
> with unions and offsetof, and autoconf has their AC_CHECK_ALIGNOF, but
> I don't know how to use it.

read all of these:


http://groups.google.com/group/comp.lang.c.moderated/msg/eab267b936d91c7e

http://groups.google.com/group/comp.lang.c.moderated/msg/0bf610f1573455c1

http://groups.google.com/group/comp.lang.c.moderated/msg/9f34b8ed765cb32b


the `ALIGN_OF()' function macro should always give you a "sufficient" 
alignment for a given type. 

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

#5875

"Chris M. Thomasson" <cristom@charter.net> wrote in message 
news:8cTIp.4134$SG4.3519@newsfe03.iad...
> "ImpalerCore" <jadill33@gmail.com> wrote in message 
> news:52c902de-0f66-4bb0-b787-8c440c2405db@hg8g2000vbb.googlegroups.com...
>
> [...]
>
>> Unfortunately I do not know how
>> to manually find a platform's ALIGN_MAX.  I've seen some incantations
>> with unions and offsetof, and autoconf has their AC_CHECK_ALIGNOF, but
>> I don't know how to use it.
>
> read all of these:
[...]

>
> the `ALIGN_OF()' function macro should always give you a "sufficient" 
> alignment for a given type.

What about some crazy hacked shi% like this crap:

http://codepad.org/A65Noc37

lol... 

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

#5918

On 6/11/2011 8:28 PM, Chris M. Thomasson wrote:
> "Chris M. Thomasson"<cristom@charter.net>  wrote in message
> news:8cTIp.4134$SG4.3519@newsfe03.iad...
>> "ImpalerCore"<jadill33@gmail.com>  wrote in message
>> news:52c902de-0f66-4bb0-b787-8c440c2405db@hg8g2000vbb.googlegroups.com...
>>
>> [...]
>>
>>> Unfortunately I do not know how
>>> to manually find a platform's ALIGN_MAX.  I've seen some incantations
>>> with unions and offsetof, and autoconf has their AC_CHECK_ALIGNOF, but
>>> I don't know how to use it.
>>
>> read all of these:
> [...]
>
>>
>> the `ALIGN_OF()' function macro should always give you a "sufficient"
>> alignment for a given type.
>

To pull it into this thread, your macro is:

   #define ALIGN_OF(mp_type) \
       offsetof( \
           struct \
           { \
                 char pad_ALIGN_OF; \
                 mp_type type_ALIGN_OF; \
           }, \
           type_ALIGN_OF \
       )

Your macro is quite nice for C89 & C99 in that:
- it expands to a meaningful alignment suggestion
- it should be an integer constant expression

One possible disadvantage for C99 is that you cannot use it with a 
variably-modified type.

> What about [...]
>
> http://codepad.org/A65Noc37
>
> lol...
>

In my opinion, the "union of many types" approach:
- can waste space
- is not a guaranteed maximum alignment requirement because it mightn't 
include all types
- requires that any types used for members be in scope (some might need 
to be #included)
- is likely to work anyway

'ref_count_acquire', 'ref_count_release' and 'main' might benefit from 
checking for null pointers, but I doubt you were asking for that kind of 
criticism. ;)

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

#5975

On Jun 11, 9:28 pm, "Chris M. Thomasson" <cris...@charter.net> wrote:
> "Chris M. Thomasson" <cris...@charter.net> wrote in messagenews:8cTIp.4134$SG4.3519@newsfe03.iad...> "ImpalerCore" <jadil...@gmail.com> wrote in message
> >news:52c902de-0f66-4bb0-b787-8c440c2405db@hg8g2000vbb.googlegroups.com...
>
> > [...]
>
> >> Unfortunately I do not know how
> >> to manually find a platform's ALIGN_MAX.  I've seen some incantations
> >> with unions and offsetof, and autoconf has their AC_CHECK_ALIGNOF, but
> >> I don't know how to use it.
>
> > read all of these:
>
> [...]
>
>
>
> > the `ALIGN_OF()' function macro should always give you a "sufficient"
> > alignment for a given type.
>
> What about some crazy hacked shi% like this crap:
>
> http://codepad.org/A65Noc37
>
> lol...

Thanks for the sample and thread references, I will give it some study
in my free time.

Best regards,
John D.

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

#6081

James Kuyper <jameskuyper@verizon.net> writes:

> On 06/10/2011 02:30 PM, ImpalerCore wrote:
> ...
>> One option is to abstract the reference count out of the structure and
>> piggyback it onto a raw allocated pointer.  The same trick used to
>> make debugging allocators could apply to a reference counted pointer.
>> I've never done it before, but it's something to ponder.  Here's my
>> first pass.
>> 
>> \code snippet
>> #define PTR_HEADER_SIZE (sizeof (int))
>> 
>> void* rc_malloc( size_t size )
>> {
>>   void* mem = NULL;
>>   void* p = NULL;
>> 
>>   p = malloc( size + PTR_HEADER_SIZE );
>> 
>>   if ( p )
>>   {
>>     /* Set the reference count to 1. */
>>     *((int*)p) = 1;
>> 
>>     mem = (unsigned char*)p + PTR_HEADER_SIZE;
>>   }
>> 
>>   return mem;
>> }
>
> The value stored in 'p' is guaranteed to be correctly aligned for all
> types. However, the only thing portably guaranteed about alignment off
> the value stored in 'mem' is that it is suitable for 'int', it need not
> be suitably aligned for any type with a size greater than 1 that is
> different from that of 'int'.  [snip]

Unless one considers the type 'unsigned int' to be a type
different from that of 'int'.

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

#6012

An external table would avoid all the alignment-guessing for pre-C1X.
I'm too lazy to finish coding this, but what about a simple open-
addressed
hash-table?

#define MAX 100

typedef struct ref_ {
    void *ptr;
    int count;
    void (*final)(void *ptr);
} ref_;

ref_ ref_tab_[2*MAX+1];

void *ref_malloc(size_t sz) { }

void ref_inc(void *ptr) { }

void ref_dec(void *ptr) { }

void ref_set_final(void *ptr, void (*final)(void *ptr)) { }

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

#6043

On 6/13/2011 11:46 PM, luser- -droog wrote:
> An external table would avoid all the alignment-guessing for pre-C1X.
> I'm too lazy to finish coding this, but what about a simple open-
> addressed
> hash-table?
>
> #define MAX 100
>
> typedef struct ref_ {
>      void *ptr;
>      int count;
>      void (*final)(void *ptr);
> } ref_;
>
> ref_ ref_tab_[2*MAX+1];
>
> void *ref_malloc(size_t sz) { }
>
> void ref_inc(void *ptr) { }
>
> void ref_dec(void *ptr) { }
>
> void ref_set_final(void *ptr, void (*final)(void *ptr)) { }
>

For hashing, is the object representation of a 'void *' guaranteed to be 
the same any time a 'void *' points to the same object?  Is it likely? 
(I think so.) :)

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

#6045

On 2011-06-14, Shao Miller <sha0.miller@gmail.com> wrote:
>
> For hashing, is the object representation of a 'void *' guaranteed to be 
> the same any time a 'void *' points to the same object?  Is it likely? 
> (I think so.) :)

The standard only says pointers are represented in an
implementation-defined manner. But as long as the pointer value doesn't
change, I doubt the representation will. On most implementations, a
pointer is really just a 32- or 64-bit unsigned number, indicating a
certain spot in virtual memory.


-- 
"C provides a programmer with more than enough rope to hang himself.
C++ provides a firing squad, blindfold and last cigarette."
- seen in comp.lang.c

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

#6052

On 6/14/2011 2:31 AM, Angel wrote:
> On 2011-06-14, Shao Miller<sha0.miller@gmail.com>  wrote:
>>
>> For hashing, is the object representation of a 'void *' guaranteed to be
>> the same any time a 'void *' points to the same object?  Is it likely?
>> (I think so.) :)
>
> The standard only says pointers are represented in an
> implementation-defined manner. But as long as the pointer value doesn't
> change, I doubt the representation will. On most implementations, a
> pointer is really just a 32- or 64-bit unsigned number, indicating a
> certain spot in virtual memory.
>

The strategy would then seem to be hopefully portable just as 
alignment-guessing is also hopefully portable.

What are the odds that a given pointer to a reference-counted object 
would have the same, simple XOR "hash" of all of its bytes in common 
with another such pointer?

   unsigned char ptr_hash(void * ptr) {
       unsigned char
         * pos = &ptr,
         * end = pos + sizeof ptr,
         result = 0;
       while (pos < end)
         result ^= *pos++;
       return result;
     }

   /* pete says UB when 'sizeof (int) == 1' */
   static xxx ptr_hash_table[1 << CHAR_BIT];

Maybe 'xxx' is a pointer type to a hopefully short list of pointers 
which can be tested with '=='.  Such a short list could be 'realloc'd. 
But then 'ptr_hash_table' is 'sizeof (xxx) * (1 << CHAR_BIT)' bytes large.

Maybe 'xxx' is an integer type for an index into another array which is 
itself 'realloc'd.

(Insert more hashing strategies here.)

Interesting. :)

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

#6067

Angel <angel+news@spamcop.net> writes:
> On 2011-06-14, Shao Miller <sha0.miller@gmail.com> wrote:
>> For hashing, is the object representation of a 'void *' guaranteed to be 
>> the same any time a 'void *' points to the same object?  Is it likely? 
>> (I think so.) :)
>
> The standard only says pointers are represented in an
> implementation-defined manner. But as long as the pointer value doesn't
> change, I doubt the representation will. On most implementations, a
> pointer is really just a 32- or 64-bit unsigned number, indicating a
> certain spot in virtual memory.

Quibble: Pointer representation is unspecified, not
implementation-defined.  The difference is that an implementation
aren't required to document its pointer representation(s).

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

#6070

On Jun 14, 11:03 am, Keith Thompson <ks...@mib.org> wrote:
> Angel <angel+n...@spamcop.net> writes:
> > On 2011-06-14, Shao Miller <sha0.mil...@gmail.com> wrote:
> >> For hashing, is the object representation of a 'void *' guaranteed to be
> >> the same any time a 'void *' points to the same object?  Is it likely?
> >> (I think so.) :)
>
> > The standard only says pointers are represented in an
> > implementation-defined manner. But as long as the pointer value doesn't
> > change, I doubt the representation will. On most implementations, a
> > pointer is really just a 32- or 64-bit unsigned number, indicating a
> > certain spot in virtual memory.
>
> Quibble: Pointer representation is unspecified, not
> implementation-defined.  The difference is that an implementation
> aren't required to document its pointer representation(s).
>

Does that make it even more seat-of-the-pants than guessing alignment?

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

#6074

On 6/14/2011 12:23 PM, luser- -droog wrote:
> On Jun 14, 11:03 am, Keith Thompson<ks...@mib.org>  wrote:
>> Angel<angel+n...@spamcop.net>  writes:
>>> On 2011-06-14, Shao Miller<sha0.mil...@gmail.com>  wrote:
>>>> For hashing, is the object representation of a 'void *' guaranteed to be
>>>> the same any time a 'void *' points to the same object?  Is it likely?
>>>> (I think so.) :)
>>
>>> The standard only says pointers are represented in an
>>> implementation-defined manner. But as long as the pointer value doesn't
>>> change, I doubt the representation will. On most implementations, a
>>> pointer is really just a 32- or 64-bit unsigned number, indicating a
>>> certain spot in virtual memory.
>>
>> Quibble: Pointer representation is unspecified, not
>> implementation-defined.  The difference is that an implementation
>> aren't required to document its pointer representation(s).
>>
>
> Does that make it even more seat-of-the-pants than guessing alignment?
>

Well alignment-guessing seems straight-forward, at least.  N1570 
has[6.2.8p4] that "... Every valid alignment value shall be a 
nonnegative integral power of two."  Which 4 KiB satisfies, for 
example...  Plenty of room for a reference count, a 'size_t' for the 
object, a pointer to a handler function for OO "messages," a signature 
for the original allocator, a UUID, a doubly-linked-list entry, a 
'jmp_buf', some opcode bytes, a checksum of the header...

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

#6082

Keith Thompson <kst-u@mib.org> writes:

> Angel <angel+news@spamcop.net> writes:
>> On 2011-06-14, Shao Miller <sha0.miller@gmail.com> wrote:
>>> For hashing, is the object representation of a 'void *' guaranteed to be 
>>> the same any time a 'void *' points to the same object?  Is it likely? 
>>> (I think so.) :)
>>
>> The standard only says pointers are represented in an
>> implementation-defined manner. But as long as the pointer value doesn't
>> change, I doubt the representation will. On most implementations, a
>> pointer is really just a 32- or 64-bit unsigned number, indicating a
>> certain spot in virtual memory.
>
> Quibble: Pointer representation is unspecified, not
> implementation-defined.  [snip]

How do you reconcile this assertion with 6.2.6.1p2?  Certainly
it looks like the representation of any pointer value stored in
an object would be (at least) implementation-defined.

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

#6089

Tim Rentsch <txr@alumni.caltech.edu> writes:
> Keith Thompson <kst-u@mib.org> writes:
>
>> Angel <angel+news@spamcop.net> writes:
>>> On 2011-06-14, Shao Miller <sha0.miller@gmail.com> wrote:
>>>> For hashing, is the object representation of a 'void *' guaranteed to be 
>>>> the same any time a 'void *' points to the same object?  Is it likely? 
>>>> (I think so.) :)
>>>
>>> The standard only says pointers are represented in an
>>> implementation-defined manner. But as long as the pointer value doesn't
>>> change, I doubt the representation will. On most implementations, a
>>> pointer is really just a 32- or 64-bit unsigned number, indicating a
>>> certain spot in virtual memory.
>>
>> Quibble: Pointer representation is unspecified, not
>> implementation-defined.  [snip]
>
> How do you reconcile this assertion with 6.2.6.1p2?  Certainly
> it looks like the representation of any pointer value stored in
> an object would be (at least) implementation-defined.

Quite easily: by failing to read it carefully enough.  8-)}

But now that I have, I'm confused.  Here's what it says:

  1 The representations of all types are unspecified except as
    stated in this subclause.

  2 Except for bit-fields, objects are composed of contiguous
    sequences of one or more bytes, the number, order, and
    encoding of which are either explicitly specified or
    implementation-defined.

  3 Values stored in unsigned bit-fields and objects of type unsigned
    char shall be represented using a pure binary notation.

As far as I can tell, *all* types have implementation-defined
representations; the section says so for non bit-fields and for
unsigned bit-fields, and I don't think there's enough wiggle room
to say that signed bit-fields have unspecified representations.

So why does paragraph 1 say "unspecified" rather than
"implementation-defined"?  "(Unspecified" is a subset of
"implementation-defined", so it's not wrong, but it seems needlessly
unspecific.

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

#6106

Keith Thompson <kst-u@mib.org> writes:

> Tim Rentsch <txr@alumni.caltech.edu> writes:
>> Keith Thompson <kst-u@mib.org> writes:
>>
>>> Angel <angel+news@spamcop.net> writes:
>>>> On 2011-06-14, Shao Miller <sha0.miller@gmail.com> wrote:
>>>>> For hashing, is the object representation of a 'void *' guaranteed to be 
>>>>> the same any time a 'void *' points to the same object?  Is it likely? 
>>>>> (I think so.) :)
>>>>
>>>> The standard only says pointers are represented in an
>>>> implementation-defined manner. But as long as the pointer value doesn't
>>>> change, I doubt the representation will. On most implementations, a
>>>> pointer is really just a 32- or 64-bit unsigned number, indicating a
>>>> certain spot in virtual memory.
>>>
>>> Quibble: Pointer representation is unspecified, not
>>> implementation-defined.  [snip]
>>
>> How do you reconcile this assertion with 6.2.6.1p2?  Certainly
>> it looks like the representation of any pointer value stored in
>> an object would be (at least) implementation-defined.
>
> Quite easily: by failing to read it carefully enough.  8-)}
>
> But now that I have, I'm confused.  Here's what it says:
>
>   1 The representations of all types are unspecified except as
>     stated in this subclause.
>
>   2 Except for bit-fields, objects are composed of contiguous
>     sequences of one or more bytes, the number, order, and
>     encoding of which are either explicitly specified or
>     implementation-defined.
>
>   3 Values stored in unsigned bit-fields and objects of type unsigned
>     char shall be represented using a pure binary notation.
>
> As far as I can tell, *all* types have implementation-defined
> representations; the section says so for non bit-fields and for
> unsigned bit-fields, and I don't think there's enough wiggle room
> to say that signed bit-fields have unspecified representations.
>
> So why does paragraph 1 say "unspecified" rather than
> "implementation-defined"?   [snip]

Here's a possible idea:  maybe paragraph 1 is talking about
representations generally (including, eg, registers), but
paragraph 2 is talking about representations specifically
only in objects.  So values of a type can be represented
outside of being stored in an object, but what those
representations might be is all "under the hood", with no
documentation required.  What do you think?  Does that make
sense?

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

#6111

Tim Rentsch <txr@alumni.caltech.edu> writes:
> Keith Thompson <kst-u@mib.org> writes:
>> Tim Rentsch <txr@alumni.caltech.edu> writes:
>>> Keith Thompson <kst-u@mib.org> writes:
>>>
>>>> Angel <angel+news@spamcop.net> writes:
>>>>> On 2011-06-14, Shao Miller <sha0.miller@gmail.com> wrote:
>>>>>> For hashing, is the object representation of a 'void *' guaranteed to be 
>>>>>> the same any time a 'void *' points to the same object?  Is it likely? 
>>>>>> (I think so.) :)
>>>>>
>>>>> The standard only says pointers are represented in an
>>>>> implementation-defined manner. But as long as the pointer value doesn't
>>>>> change, I doubt the representation will. On most implementations, a
>>>>> pointer is really just a 32- or 64-bit unsigned number, indicating a
>>>>> certain spot in virtual memory.
>>>>
>>>> Quibble: Pointer representation is unspecified, not
>>>> implementation-defined.  [snip]
>>>
>>> How do you reconcile this assertion with 6.2.6.1p2?  Certainly
>>> it looks like the representation of any pointer value stored in
>>> an object would be (at least) implementation-defined.
>>
>> Quite easily: by failing to read it carefully enough.  8-)}
>>
>> But now that I have, I'm confused.  Here's what it says:
>>
>>   1 The representations of all types are unspecified except as
>>     stated in this subclause.
>>
>>   2 Except for bit-fields, objects are composed of contiguous
>>     sequences of one or more bytes, the number, order, and
>>     encoding of which are either explicitly specified or
>>     implementation-defined.
>>
>>   3 Values stored in unsigned bit-fields and objects of type unsigned
>>     char shall be represented using a pure binary notation.
>>
>> As far as I can tell, *all* types have implementation-defined
>> representations; the section says so for non bit-fields and for
>> unsigned bit-fields, and I don't think there's enough wiggle room
>> to say that signed bit-fields have unspecified representations.
>>
>> So why does paragraph 1 say "unspecified" rather than
>> "implementation-defined"?   [snip]
>
> Here's a possible idea:  maybe paragraph 1 is talking about
> representations generally (including, eg, registers), but
> paragraph 2 is talking about representations specifically
> only in objects.  So values of a type can be represented
> outside of being stored in an object, but what those
> representations might be is all "under the hood", with no
> documentation required.  What do you think?  Does that make
> sense?

My impression is that the idea of representation applies only to
objects.  The representation of a value not stored in an object is
irrelevant until and unless it's stored in an object.

I think your idea makes some sense, but I don't think it's what
6.2.6.1 is referring to.

I have no particular support for this.

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

#6126

Keith Thompson wrote:
> 
> Tim Rentsch <txr@alumni.caltech.edu> writes:
> > Keith Thompson <kst-u@mib.org> writes:
> >> Tim Rentsch <txr@alumni.caltech.edu> writes:
> >>> Keith Thompson <kst-u@mib.org> writes:
> >>>
> >>>> Angel <angel+news@spamcop.net> writes:
> >>>>> On 2011-06-14, Shao Miller <sha0.miller@gmail.com> wrote:
> >>>>>> For hashing, is the object representation of a 'void *' guaranteed to be
> >>>>>> the same any time a 'void *' points to the same object?  Is it likely?
> >>>>>> (I think so.) :)
> >>>>>
> >>>>> The standard only says pointers are represented in an
> >>>>> implementation-defined manner. But as long as the pointer value doesn't
> >>>>> change, I doubt the representation will. On most implementations, a
> >>>>> pointer is really just a 32- or 64-bit unsigned number, indicating a
> >>>>> certain spot in virtual memory.
> >>>>
> >>>> Quibble: Pointer representation is unspecified, not
> >>>> implementation-defined.  [snip]
> >>>
> >>> How do you reconcile this assertion with 6.2.6.1p2?  Certainly
> >>> it looks like the representation of any pointer value stored in
> >>> an object would be (at least) implementation-defined.
> >>
> >> Quite easily: by failing to read it carefully enough.  8-)}
> >>
> >> But now that I have, I'm confused.  Here's what it says:
> >>
> >>   1 The representations of all types are unspecified except as
> >>     stated in this subclause.
> >>
> >>   2 Except for bit-fields, objects are composed of contiguous
> >>     sequences of one or more bytes, the number, order, and
> >>     encoding of which are either explicitly specified or
> >>     implementation-defined.
> >>
> >>   3 Values stored in unsigned bit-fields and objects of type unsigned
> >>     char shall be represented using a pure binary notation.
> >>
> >> As far as I can tell, *all* types have implementation-defined
> >> representations; the section says so for non bit-fields and for
> >> unsigned bit-fields, and I don't think there's enough wiggle room
> >> to say that signed bit-fields have unspecified representations.
> >>
> >> So why does paragraph 1 say "unspecified" rather than
> >> "implementation-defined"?   [snip]
> >
> > Here's a possible idea:  maybe paragraph 1 is talking about
> > representations generally (including, eg, registers), but
> > paragraph 2 is talking about representations specifically
> > only in objects.  So values of a type can be represented
> > outside of being stored in an object, but what those
> > representations might be is all "under the hood", with no
> > documentation required.  What do you think?  Does that make
> > sense?
> 
> My impression is that the idea of representation applies only to
> objects.  The representation of a value not stored in an object is
> irrelevant until and unless it's stored in an object.
> 
> I think your idea makes some sense, but I don't think it's what
> 6.2.6.1 is referring to.
> 
> I have no particular support for this.

Do you think that the value of (-1 & 3)
corresponds to the way that an implementation
represents negative integers?

Constants have object types.
In C89, the standard talks about the representation
of object types.
There's no mention of "object representation" in C89.
I think it was better that way.

-- 
pete

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

#6131

On 06/15/2011 10:19 PM, pete wrote:
> Keith Thompson wrote:
...
>> My impression is that the idea of representation applies only to
>> objects.  The representation of a value not stored in an object is
>> irrelevant until and unless it's stored in an object.
>>
>> I think your idea makes some sense, but I don't think it's what
>> 6.2.6.1 is referring to.
>>
>> I have no particular support for this.
> 
> Do you think that the value of (-1 & 3)
> corresponds to the way that an implementation
> represents negative integers?

The way that the bit-wise operators behave is defined in terms of the
bits, even though C operators only operate on values, and bits are a
feature of the corresponding representation. This is less than ideal, IMO.

The only exception is the bit-wise shift operators; but interestingly
enough, the result is at best implementation-defined, and at worst,
undefined, whenever a shift would otherwise seem to involve a sign bit
that is non-zero.

-- 
James Kuyper

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

#6467

Keith Thompson <kst-u@mib.org> writes:

> Tim Rentsch <txr@alumni.caltech.edu> writes:
>> Keith Thompson <kst-u@mib.org> writes:
>>> Tim Rentsch <txr@alumni.caltech.edu> writes:
>>>> Keith Thompson <kst-u@mib.org> writes:
>>>>
>>>>> Angel <angel+news@spamcop.net> writes:
>>>>>> On 2011-06-14, Shao Miller <sha0.miller@gmail.com> wrote:
>>>>>>> For hashing, is the object representation of a 'void *' guaranteed to be 
>>>>>>> the same any time a 'void *' points to the same object?  Is it likely? 
>>>>>>> (I think so.) :)
>>>>>>
>>>>>> The standard only says pointers are represented in an
>>>>>> implementation-defined manner. But as long as the pointer value doesn't
>>>>>> change, I doubt the representation will. On most implementations, a
>>>>>> pointer is really just a 32- or 64-bit unsigned number, indicating a
>>>>>> certain spot in virtual memory.
>>>>>
>>>>> Quibble: Pointer representation is unspecified, not
>>>>> implementation-defined.  [snip]
>>>>
>>>> How do you reconcile this assertion with 6.2.6.1p2?  Certainly
>>>> it looks like the representation of any pointer value stored in
>>>> an object would be (at least) implementation-defined.
>>>
>>> Quite easily: by failing to read it carefully enough.  8-)}
>>>
>>> But now that I have, I'm confused.  Here's what it says:
>>>
>>>   1 The representations of all types are unspecified except as
>>>     stated in this subclause.
>>>
>>>   2 Except for bit-fields, objects are composed of contiguous
>>>     sequences of one or more bytes, the number, order, and
>>>     encoding of which are either explicitly specified or
>>>     implementation-defined.
>>>
>>>   3 Values stored in unsigned bit-fields and objects of type unsigned
>>>     char shall be represented using a pure binary notation.
>>>
>>> As far as I can tell, *all* types have implementation-defined
>>> representations; the section says so for non bit-fields and for
>>> unsigned bit-fields, and I don't think there's enough wiggle room
>>> to say that signed bit-fields have unspecified representations.
>>>
>>> So why does paragraph 1 say "unspecified" rather than
>>> "implementation-defined"?   [snip]
>>
>> Here's a possible idea:  maybe paragraph 1 is talking about
>> representations generally (including, eg, registers), but
>> paragraph 2 is talking about representations specifically
>> only in objects.  So values of a type can be represented
>> outside of being stored in an object, but what those
>> representations might be is all "under the hood", with no
>> documentation required.  What do you think?  Does that make
>> sense?
>
> My impression is that the idea of representation applies only to
> objects.  The representation of a value not stored in an object is
> irrelevant until and unless it's stored in an object.

Let me offer a counter-example, which is floating-point values.
In several places the Standard talks about floating-point operands
being represented with a greater range or precision than that of
the type (of the expression that would produce the operand value).
Certainly these operand values exist and have some representation
in an actual computer, but those representations aren't the same as
the operand's expression's type's object representation -- indeed,
the representation of a floating-point operand value may be different
than the object representation of any C floating-point type.

A similar description could hold for a (hypothetical) machine that
had only one kind of signed integer register, let's say 128 bits,
with all signed arithmetic being done using these big registers
(and with some way of storing part of a big register into a narrower
non-register memory location).  The register representation could
easily be different than the object representation of any C
signed integer type.  The representation of signed integer values
would be unspecified, only the representations of signed integers
stored in objects would be implementation-defined.


> I think your idea makes some sense, but I don't think it's what
> 6.2.6.1 is referring to.

I don't mean to advocate that it is, only that it might be (and
that I can't yet think of any better possibility).


> I have no particular support for this.

The word representation (in various forms) is used in quite
a few places in the Standard, applying to lots of different
circumstances.  If 6.2.6.1p1 isn't referring to things like
floating-point operands (ie, representations other than those
in objects), what is it talking about?

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

#6072

On 2011-06-14, Angel <angel+news@spamcop.net> wrote:
> On 2011-06-14, Shao Miller <sha0.miller@gmail.com> wrote:
>> For hashing, is the object representation of a 'void *' guaranteed to be 
>> the same any time a 'void *' points to the same object?  Is it likely? 
>> (I think so.) :)

> The standard only says pointers are represented in an
> implementation-defined manner. But as long as the pointer value doesn't
> change, I doubt the representation will. On most implementations, a
> pointer is really just a 32- or 64-bit unsigned number, indicating a
> certain spot in virtual memory.

On segmented architectures, it is possible for segments to overlap, meaning
that there are multiple pointer representations for the same address; on
such implementations, comparisons have to take that into account.

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

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

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

csiph-web