From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 14197 invoked by alias); 26 Jul 2005 04:43:08 -0000 Mailing-List: contact gcc-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Archive: List-Post: List-Help: Sender: gcc-owner@gcc.gnu.org Received: (qmail 14187 invoked by uid 22791); 26 Jul 2005 04:43:05 -0000 Received: from rwcrmhc11.comcast.net (HELO rwcrmhc11.comcast.net) (204.127.198.35) by sourceware.org (qpsmtpd/0.30-dev) with ESMTP; Tue, 26 Jul 2005 04:43:05 +0000 Received: from [10.69.69.128] (c-24-6-220-207.hsd1.ca.comcast.net[24.6.220.207]) by comcast.net (rwcrmhc11) with SMTP id <2005072604430201300h8bsqe>; Tue, 26 Jul 2005 04:43:03 +0000 In-Reply-To: References: Mime-Version: 1.0 (Apple Message framework v733) Content-Type: multipart/signed; micalg=sha1; boundary=Apple-Mail-1-164377056; protocol="application/pkcs7-signature" Message-Id: Cc: , From: Geoff Keating Subject: Re: Pointers in comparison expressions Date: Tue, 26 Jul 2005 04:43:00 -0000 To: Paul Schlie X-SW-Source: 2005-07/txt/msg01086.txt.bz2 --Apple-Mail-1-164377056 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Content-length: 1654 On 23/07/2005, at 6:12 PM, Paul Schlie wrote: >> Geoffrey Keating wrote: >> >>> Mirco Lorenzon wrote: >>> >>> .., are comparisons in the following program legal code? >>> >> >> No. >> >> >>> ... >>> void *a, *b; >>> ... >>> if (a < b) >>> >> >> Because 'a' and 'b' are not part of the same array, >> the behaviour is undefined. >> > > Although I don't mean to contest the conclusion, I do find it > curious that > as all pointer values referencing unique objects must be > correspondingly > unique, it would follow that they will be correspondingly ordered with > respect to each other. Therefore although technically undefined, > it seems > quite reasonable to expect an implementation to support ordered > inequality > comparisons between arbitrary pointers to equivalent effective types? Consider an implementation which does garbage collection and compaction. In such an implementation, it might be quite inconvenient to have to maintain a consistent ordering for all pointers. > As it would seem otherwise impossible for an implementation to > support the > ability to write code which enables the relative comparison of > generalized > memory pointers unless one were to explicitly declare a union of an > array > of all potentially allocateable memory, and all explicitly and > implicitly > declared objects; which doesn't seem reasonable? Although the C language doesn't guarantee the availability of such support, there is nothing that prevents an implementation from saying that it supports it, and in fact GCC does say that it supports it, through the use of a construct like ((intptr_t) a) < ((intptr_t) b) --Apple-Mail-1-164377056 Content-Transfer-Encoding: base64 Content-Type: application/pkcs7-signature; name=smime.p7s Content-Disposition: attachment; filename=smime.p7s Content-length: 3270 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEH AQAAoIIGRTCCAv4wggJnoAMCAQICAw7dozANBgkqhkiG9w0BAQQFADBiMQsw CQYDVQQGEwJaQTElMCMGA1UEChMcVGhhd3RlIENvbnN1bHRpbmcgKFB0eSkg THRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIElzc3Vp bmcgQ0EwHhcNMDUwNjA2MDUzNzU1WhcNMDYwNjA2MDUzNzU1WjByMRAwDgYD VQQEEwdLZWF0aW5nMRkwFwYDVQQqExBHZW9mZnJleSBGcmFuY2lzMSEwHwYD VQQDExhHZW9mZnJleSBGcmFuY2lzIEtlYXRpbmcxIDAeBgkqhkiG9w0BCQEW EWdlb2Zma0BnZW9mZmsub3JnMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIB CgKCAQEAvVUVLIqA8o0p5LSCLGEOKfXVu5Mh4+aYBV6MUeFVDCcQPj3LndH+ OHXbK7sx2dG+HdMTow+wBzvF/qkUlu+p1hwVUNRTo+80Y6Er+5PnajA/ZCVE QIhat/NfiN7DOwbShhbblSSKyKBCzvtMjHC4S5HCnnIyvS7sMDi/BQc+2ogb WsoCiPYut3hnuyXNbxTcLxhj2sA3Y8AOkwexQ+N/leyg9pMxcPiHdDJHUaQC 5Wiy2dKyFLlF0uCbtqf3aQGdfrKsahCv0HC/Nbob/0PNcN1ShlEvV23AR2VE +4iq/H6dI7CfSmdvrVLkfZL4tkeKJptliZVADuTD9Ct4IIOLjwIDAQABoy4w LDAcBgNVHREEFTATgRFnZW9mZmtAZ2VvZmZrLm9yZzAMBgNVHRMBAf8EAjAA MA0GCSqGSIb3DQEBBAUAA4GBAKpzHInnRIk3lJbLNLoNWoV/f8j3WW79TAZu frKWiNRoZUdXvxu3qC+mgtzbv4xqKSGAMlmrYYtFDSDT+WhX+OseSOxoFm7N 5H93qpXLjn3SHVDklSnRGoCRe8sDGxuQmkYa45D0k7ENVva7PG5Ymtwf26Ff DdQCNYGJIgVbUUscMIIDPzCCAqigAwIBAgIBDTANBgkqhkiG9w0BAQUFADCB 0TELMAkGA1UEBhMCWkExFTATBgNVBAgTDFdlc3Rlcm4gQ2FwZTESMBAGA1UE BxMJQ2FwZSBUb3duMRowGAYDVQQKExFUaGF3dGUgQ29uc3VsdGluZzEoMCYG A1UECxMfQ2VydGlmaWNhdGlvbiBTZXJ2aWNlcyBEaXZpc2lvbjEkMCIGA1UE AxMbVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIENBMSswKQYJKoZIhvcNAQkB FhxwZXJzb25hbC1mcmVlbWFpbEB0aGF3dGUuY29tMB4XDTAzMDcxNzAwMDAw MFoXDTEzMDcxNjIzNTk1OVowYjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRo YXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQ ZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMIGfMA0GCSqGSIb3DQEBAQUA A4GNADCBiQKBgQDEpjxVc1X7TrnKmVoeaMB1BHCd3+n/ox7svc31W/Iadr1/ DDph8r9RzgHU5VAKMNcCY1osiRVwjt3J8CuFWqo/cVbLrzwLB+fxH5E2JCoT zyvV84J3PQO+K/67GD4Hv0CAAmTXp6a7n2XRxSpUhQ9IBH+nttE8YQRAHmQZ cmC3+wIDAQABo4GUMIGRMBIGA1UdEwEB/wQIMAYBAf8CAQAwQwYDVR0fBDww OjA4oDagNIYyaHR0cDovL2NybC50aGF3dGUuY29tL1RoYXd0ZVBlcnNvbmFs RnJlZW1haWxDQS5jcmwwCwYDVR0PBAQDAgEGMCkGA1UdEQQiMCCkHjAcMRow GAYDVQQDExFQcml2YXRlTGFiZWwyLTEzODANBgkqhkiG9w0BAQUFAAOBgQBI jNFQg+oLLswNo2asZw9/r6y+whehQ5aUnX9MIbj4Nh+qLZ82L8D0HFAgk3A8 /a3hYWLD2ToZfoSxmRsAxRoLgnSeJVCUYsfbJ3FXJY3dqZw5jowgT2Vfldr3 94fWxghOrvbqNOUQGls1TXfjViF4gtwhGTXeJLHTHUb/XV9lTzGCAucwggLj AgEBMGkwYjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0 aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVl bWFpbCBJc3N1aW5nIENBAgMO3aMwCQYFKw4DAhoFAKCCAVMwGAYJKoZIhvcN AQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMDUwNzI2MDQ0MzAx WjAjBgkqhkiG9w0BCQQxFgQUjJOS5s3bzRTqdjinI24jw1X2rfIweAYJKwYB BAGCNxAEMWswaTBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhhd3RlIENv bnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFs IEZyZWVtYWlsIElzc3VpbmcgQ0ECAw7dozB6BgsqhkiG9w0BCRACCzFroGkw YjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQ dHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJ c3N1aW5nIENBAgMO3aMwDQYJKoZIhvcNAQEBBQAEggEAfM4RSwP7roZ3phFO 2Mi5SgiFzk5AYtj1/7vFPiZCNY+Fp6cNPtYCVMXyKvEc+FAOpvEeAMiDNS2f B6XdSu/DL9SfAL330YbwlWJAq0IvWSsaUOxfqBXD+H8FeVJALE6E5O83F/eW PMMr+S/YmvycktuNj4KW3JV5Lzh0R/mIaclM5gZbFg4WHKGaCJhjYA6x8IXm yF6qBbea4GWc8nvpb/tJxUaARL/LucG6fXbdg+5KkxePhsJwIT1gxtL1afsM vDgzu6uXZDmRlp50m7kiLVwCq90g/uz/P2yXGhV+2JZ0h+dmfPQLAnhugaot mT7Ju3U6r5RIeL2fVujC8e0+oAAAAAAAAA== --Apple-Mail-1-164377056--