Re: [9fans] subtracting pointers on amd64 6c

["Devon H. O'Dell" <devon.odell@gmail.com>]

2016-01-05 12:40 GMT-08:00 erik quanstrom <quanstro@quanstro.net>:
> 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 <devon.odell@gmail.com> 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.