From 4306495680463473146
X-Google-Language: ENGLISH,ASCII-7-bit
X-Google-Thread: f78e5,e94695845965b249
X-Google-Attributes: gidf78e5,public
X-Google-ArrivalTime: 1992-12-22 17:08:25 PST
Path: sparky!uunet!tdat!tools3!swf
From: swf@tools3teradata.com (Stan Friesen)
Newsgroups: comp.std.c++
Subject: Re: Zero-length structures and pointer comparisons
Message-ID: <1660@tdat.teradata.COM>
Date: 22 Dec 92 21:48:33 GMT
References: <1992Dec9.075125.22405@lth.se> <1992Dec12.154918.2220@ucc.su.OZ.AU> <1992Dec14.225659.24225@microsoft.com> <1992Dec16.150144.6004@ucc.su.OZ.AU>
Sender: news@tdat.teradata.COM
Distribution: world
Organization: NCR Teradata Database Business Unit
Lines: 35

In article <1992Dec16.150144.6004@ucc.su.OZ.AU>, maxtal@extro.ucc.su.OZ.AU (John MAX Skaller) writes:
|> 	In that case it is implementable on all systems
|> 	where (opinion follows, please correct errors)
|> 
|> 	a) void* is big enough to hold all pointer types

This assumption, as written, is violated by compact and medium model on Intel
chips.  I suggest rewording this to:
	a) void* is big enough to hold all object pointer types
					   ^^^^^^
[function pointers are *not* guarenteed to be convertable to void *, and,
in C++, neither are member 'pointers'].

|> 	b) conversions always pad systematically
|> 	c) bitwise comparison is done 
|> 	d) the bits of a pointer cannot be magically changed by the system
|> 	e) a pointer is implemented as an object in contiguous storage
|> ...
|> 
|> 	Certainly, (e) might cause problems on the 80x86 where part of the
|> pointer is implicit and not physically stored. Does it *actually*
|> cause this problem?

In 'small data' models, YES!  There is simply no reason for void* to contain
the segment when all data is in the same segment.

Of course, in paractice, the limitations on the 'small data' models make this lack
of little *practical* concern for ptrcmp() - that is since all data are in the
same segment a segmentless comparison will always work (as long as you use the
*stronger* form of (a) I mention above).

-- 
sarima@teradata.com			(formerly tdatirv!sarima)
  or
Stanley.Friesen@ElSegundoCA.ncr.com