From -8987064428146085848
X-Google-Language: ENGLISH,ASCII-7-bit
X-Google-Thread: f78e5,e94695845965b249
X-Google-Attributes: gidf78e5,public
X-Google-ArrivalTime: 1992-12-10 13:35:47 PST
Newsgroups: comp.std.c++
Path: sparky!uunet!stanford.edu!lucid.com!lucid.com!jss
From: jss@lucid.com (Jerry Schwarz)
Subject: Re: Zero-length structures and pointer comparisons
Message-ID: <1992Dec10.212116.7923@lucid.com>
Sender: usenet@lucid.com
Reply-To: jss@lucid.com (Jerry Schwarz)
Organization: Lucid, Inc.
References: <1992Dec07.222242.18703@microsoft.com> <1992Dec8.103218.27689@lth.se> <9234423.15066@mulga.cs.mu.OZ.AU> <1992Dec10.121200.18889@ucc.su.OZ.AU>
Date: Thu, 10 Dec 92 21:21:16 GMT
Lines: 24

In article <1992Dec10.121200.18889@ucc.su.OZ.AU>, maxtal@extro.ucc.su.OZ.AU (John MAX Skaller) writes:
|> >
|> >int compare_pointers(const void *, const void *);
|> >    /* Returns negative, zero, or positive in the same manner as strcmp().
|> >       Perhaps in the interests of tradition and unreadability it should
|> >       be called ptrcmp() instead of compare_pointers() :-) */
|> >
|> 
|> 	This seems like an excellent suggestion. It suffers only
|> in those cases where we must ask whether it makes sense to 
|> compare two pointers at all. For example a char* and a function
|> pointer. Might not these accidentally have the same address?
|> 
|> 	Similarly suppose we allowed nested functions, then
|> pointers to them would need a pointer to a stack frame as well
|> as the function address (or instead of?). They would be totally
|> different types of objects really.

Function pointers and data pointers are differnt.  The conversions
between them are always undefined.  This would argue for a variant

  int compare_pointers(void(*)(), void(*)()) 

   // Jerry Schwarz