Topic: pointer hash to int (was STL set flaw)


Author: Nathan Myers <ncm@cantrip.org>
Date: 1996/06/11
Raw View
Eric Gindrup wrote:
>
> James Kanze US/ESC 60/3/141 #40763 wrote:
> > In article <ww7mtmbznh.fsf@nellie.bby.com.au> Gregory Bond
> > <gnb@bby.com.au> writes:
> [... cast pointers to integrals and compare? ...]
> > > The above discussions imply no.  Why not?

> > What is the appropriate integral type.  Consider that there are, for
> > example, implementations in which a pointer is larger than any
> > integral type.  (I've worked on a system where pointers were 48 bits,
> > but long's only 32.  Obviously, on such a system, there is no way to
> > cast a pointer to an integer without some loss of information.)

> Unless I have failed to remember correctly, such a system would be
> incapable of supporting the type ptrdiff_t.  This type is (still) standard
> C, and I recall it being transplanted into standard C++ (still).  ptrdiff_t
> would also seem to address the original question.

ptrdiff_t need only be big enough to represent differences within a single
array; but an implementation might have a 48-bit pointer, but only permit
arrays of size 2^32 -- or in the extreme case (:-) a 20-bit pointer, and
allow arrays of only 2^16.

It might also have a 64-bit int, and a 48-bit pointer, so converting from
pointer to int leaves 16 bits of random garbage in the int, and two equal
pointers don't compare equal as ints.  (The 68000 had 32-bit int and 24-bit
pointers, with a potential for the same problem; Apple actually used that,
and encoded extra data in their pointers -- to their later chagrin.)

Nathan Myers
ncm@cantrip.org
---
[ comp.std.c++ is moderated.  To submit articles: Try just posting with your
                newsreader.  If that fails, use mailto:std-c++@ncar.ucar.edu
  comp.std.c++ FAQ: http://reality.sgi.com/austern/std-c++/faq.html
  Moderation policy: http://reality.sgi.com/austern/std-c++/policy.html
  Comments? mailto:std-c++-request@ncar.ucar.edu
]





Author: kanze@gabi-soft.fr (J. Kanze)
Date: 1996/06/12
Raw View
In article <31BDD5F7.2A6B1419@cantrip.org> Nathan Myers
<ncm@cantrip.org> writes:

|> Eric Gindrup wrote:
|> >
|> > James Kanze US/ESC 60/3/141 #40763 wrote:
|> > > In article <ww7mtmbznh.fsf@nellie.bby.com.au> Gregory Bond
|> > > <gnb@bby.com.au> writes:
|> > [... cast pointers to integrals and compare? ...]
|> > > > The above discussions imply no.  Why not?

|> > > What is the appropriate integral type.  Consider that there are, for
|> > > example, implementations in which a pointer is larger than any
|> > > integral type.  (I've worked on a system where pointers were 48 bits,
|> > > but long's only 32.  Obviously, on such a system, there is no way to
|> > > cast a pointer to an integer without some loss of information.)

|> > Unless I have failed to remember correctly, such a system would be
|> > incapable of supporting the type ptrdiff_t.  This type is (still)
|> > standard C, and I recall it being transplanted into standard C++
|> > (still).  ptrdiff_t would also seem to address the original question.

|> ptrdiff_t need only be big enough to represent differences within a single
|> array; but an implementation might have a 48-bit pointer, but only permit
|> arrays of size 2^32 -- or in the extreme case (:-) a 20-bit pointer, and
|> allow arrays of only 2^16.

Is this actually required by the standard (that ptrdiff_t be big enough
to represent differences within a single array).  I believe that most
MS-DOS implementations, for example, declare ptrdiff_t as (16 bit) int,
but allowed arrays of up to 64K.  Although I've not tried it, I think
that a Sparc implementation will allow arrays of char larger than
2147483648.  (I don't have enough virtual memory to actually test this
case.)  This would mean that long is not big enough.
--
James Kanze           (+33) 88 14 49 00          email: kanze@gabi-soft.fr
GABI Software, Sarl., 8 rue des Francs Bourgeois, 67000 Strasbourg, France
Conseils en informatique industrielle --
                            -- Beratung in industrieller Datenverarbeitung
---
[ comp.std.c++ is moderated.  To submit articles: try just posting with      ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu         ]
[ FAQ:      http://reality.sgi.com/employees/austern_mti/std-c++/faq.html    ]
[ Policy:   http://reality.sgi.com/employees/austern_mti/std-c++/policy.html ]
[ Comments? mailto:std-c++-request@ncar.ucar.edu                             ]