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 ]