From mboxrd@z Thu Jan 1 00:00:00 1970 MIME-Version: 1.0 In-Reply-To: References: <8edba5d726ee6a032d8521c7de33f499@felloff.net> Date: Tue, 5 Jan 2016 13:53:29 -0800 Message-ID: From: "Devon H. O'Dell" To: Fans of the OS Plan 9 from Bell Labs <9fans@9fans.net> Content-Type: text/plain; charset=UTF-8 Subject: Re: [9fans] subtracting pointers on amd64 6c Topicbox-Message-UUID: 7e7e308c-ead9-11e9-9d60-3106f5b1d025 2016-01-05 12:40 GMT-08:00 erik quanstrom : > On Tue Jan 5 11:49:06 PST 2016, charles.forsyth@gmail.com wrote: > >> On 5 January 2016 at 19:01, Devon H. O'Dell wrote: >> >> > so given any of the examples in this thread, if you typedef'ed >> > ptrdiff_t to long, then the compiler technically isn't actually doing >> > anything wrong. whether it is doing something useful is a different >> > question. >> > >> >> Well, although I knew that was true, I didn't want to push the point because >> in practice, people have a right to expect certain reasonable behaviour, >> and it's quite reasonable to expect that p+(q-p) yields q if they both point >> into the same array that the system agreed to allocate somehow. >> It make sense to use 64 bits for the difference, and indeed the code >> block that adds the current cast has an if(1 && ...) suggesting an if(0 && > > yes! this. one thing i love about the plan 9 compilers is that my reasonable > expectations are not violated by some happy optimizer, or decision. for reference, i said, "technically [the plan 9 compiler] isn't actually doing anything wrong. whether it is doing something useful is a different question." so far, we're all in agreement. > this gets us back to the op's pov how? it really doesn't, because you've misunderstood me apparently based on understanding me through charles' reply... >> i get that probably nobody cares about c standards here, but it might >> be useful to mention what c99 and c11 say about this issue, since the ...and are now bringing up the one sentence of my post that has the least meaning or relevance for this discussion... > which i think is wrong. there is some current silliness with compilers that > conflates allowed with required and undefined with can be deleted. i > see plan 9's decisions as rejecting this way of thinking. however, this is > in no way anti-standard. ...and arguing with it, based on assuming charles is disagreeing with me about reasonable behavior. he isn't. apparently, you didn't take the time to read what i had written in the first place. or at least not past the first sentence. this is really annoying to me because it tends to be a frequent thing you do when replying to me on this list: disagreeing with me based on something that seems like either assuming i don't have any basis for understanding what i'm talking about, or not reading what i've written and assuming others are disagreeing with me. the reason this is annoying is because i have to re-read what i've written, carefully, to make sure i don't have to retract anything i've said. in this case i don't. you seem to agree with everything i've said, except for further misinterpreting a point about the compilers being "anti-standard" and somehow correlating this statement to other compilers (which I didn't talk about at all) and undefined behavior. to be clear, in C, undefined behavior means the compiler can do anything it likes at all, whether that is some compiler removing an entire conditional body because it relies on signed integer overflow, optimizing a loop to a memcpy because of strict aliasing, or plan 9 doing something in some case that you like. i haven't mentioned any compilers or what they do with any undefined behavior in my original post, only the spec, so it seems odd that you're going to disagree with me based on stuff i didn't actually say. furthermore, the only undefined behavior i mentioned was what happens when the difference between two pointers exceeds the width of the ptrdiff type. this undefined behavior is still possible with a 64-bit ptrdiff type. which would have been obvious if you actually read what i said, instead of assuming charles was disagreeing with me (he wasn't). so nothing about anything i said had anything to do with undefined behavior other than to note that if plan 9's ptrdiff type is long (which is allowed because impl. defined), then the behavior is correct. and immediately after that, i said that's not useful behavior. all charles was saying was that he didn't mention any of this because whether or not the behavior is correct per spec, it is not useful. and the part that can be changed to be useful actually falls within implementation-defined behavior. (which further makes your complaints about compiler "silliness" with UB irrelevant, since nobody is talking about UB at all). finally, when i say "i get that probably nobody cares about c standards here", it's because there are plenty of differences between plan 9 c and any current c standard (or even ansi c). presenting the standard as an argument to change the compiler is therefore unlikely to hold any weight. there's a reason that plenty of c99 and c11 is neither supported, nor intended to be supported by anybody on this list, and it's not just because nobody cares enough to implement it. but since i've written more than 2 sentences, i'm sure you'll find plenty more to disagree with me on, especially in the infinite sentences i didn't write.