«

On 03/23/2011 07:33 PM, Spiros Bousbouras wrote:
> On Tue, 22 Mar 2011 17:45:05 -0700
> Keith Thompson<kst-> wrote:
>> Spiros Bousbouras<> writes:
>>> On Tue, 22 Mar 2011 15:19:27 -0700
>>> Keith Thompson<kst-> wrote:
....
>>>> I think your option A is the general consensus; the footnote
>>>> claims to state something that's implied by the normative text,
>>>> but a careful reading of the normative text indicates that it isn't.
>>>
>>> When you say "general" how general do you mean ? Even outside the
>>> present discussion ? And on what basis has this consensus been formed ?

Oh yes, that footnote has been the subject of many previous discussions,
both here and on comp.std.c. Search for the exact phrase "is meant to
imply", if you want to review them.

>> I've never seen any suggestion, other than yours, that "same"
>> is used in some intransitive sense here.
>
> Have you had or seen the same discussion elsewhere ? If not then using
> the expression "general consensus" seems like an exaggeration to me.

The consensus of the numerous previous discussions has, indeed, been as
Keith describes, though I'm not entirely sure "consensus" is the right
word for it. That word implies fewer and less strongly felt
disagreements than I've seen about this issue.

However, the idea that an extremely unusual meaning for "same" was
intended when the committee wrote "same representation and alignment"
is, to the best of my knowledge, your own completely unique contribution
to this discussion. The consensus has not been previously tested against
that hypothesis. Unless and until you explain the concept more clearly,
I think it's extremely unlikely to change that consensus.

....
>> The usual meaning of "same" is transitive. In common English usage, it
>> just doesn't make any sense to say that A is the same as B, and B is the
>> same as C, but A is not the same as C. Similarity can certainly be
>> non-transitive; sameness cannot.
>>
>> If you were to suggest a mathematical relation that's like equality
>> "minus the implication of transitivity", I would be equally at a
>> loss to understand what you have in mind.
>
> What I have in mind is that SRAR() may not be transitive.

Yes, but can you describe what it would mean, with transitivity removed?
Could you give an example of a possible non-transitive meaning for SRAR?
The meaning of the phrase seems pretty clear, until you remove
transitivity - then I have no idea what it could possibly mean, nor why
any sane person would use the word "same" to describe a relationship
that wasn't transitive.

....
>> The footnote has problems. They're not caused by the use of the word
>> "same".
>
> Of course not. A word on its own won't cause problems , it's the
> combination of words which might do. I note also that it wasn't me who
> focused on the meaning of "same" , it was others who put it at a
> central place in their argumentation.

You made transitivity central to your discussion; since transitivity is
a trivial consequence of using the word "same" in anything that even
remotely resembles it's ordinary meaning, your questioning of
transitivity inherently focuses attention on the word "same".
--
James Kuyper

Spiros Bousbouras <> writes:
> On Tue, 22 Mar 2011 16:27:12 -0700
> Keith Thompson <kst-> wrote:
>> Oh, and speaking of footnotes, it would have been useful for N1256
>> to retain the same numbering of foonotes seen in the original C99
>> standard.
>
> Do you mean the one before technical corrigendum 1 ?

Yes, I bought it from ansi.org.

> The printed copy I
> have includes technical corrigendum 1 and I've seen no difference in
> the numbering of footnotes between that and
> http://www.open-std.org/jtc1/sc22/wg...docs/n1256.pdf

The footnote on section 7.25.2.1.6 is numbered 297 in the original ISO
C99 standard, and 306 in n1256.pdf.

--
Keith Thompson (The_Other_Keith) kst- <http://www.ghoti.net/~kst>
Nokia
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"

Keith Thompson <kst-> wrote:
> writes:
> > Keith Thompson <kst-> wrote:
> >> Oh, and speaking of footnotes, it would have been useful for N1256
> >> to retain the same numbering of foonotes seen in the original C99
> >> standard. Newly added foonotes might be labeled "42a", "42b", and
> >> so forth. I think some Ada standard drafts have taken this approach.
> >> (Section and paragraph numbers have *mostly* remained the same,
> >> but those have also changed in a few cases.)
> >
> > Yes, it would, but it's excruciatingly hard to do without making the
> > document unmaintainable.
>
> Is the pdf created with a tool that numbers the footnotes automatically?

Yes, it's created with groff using the mm macros.

> (I see that both the C99 standard and n1256.pdf were created by "Acrobat
> Distiller Command 3.0 for HP-UX A.09.01 and later (HPPA)"; I've never
> used it myself.)

That's because they are, in a sense, the same PDF file. Once, long ago,
I used that tool to convert the PostScript output from groff to PDF and
then created all the bookmarks by hand. Since then, I've simply
replaced all the pages to create newer versions in order to avoid having
to recreate the bookmarks again. Replacing pages doesn't change the
"created by" comment.

> Speaking of the pdf, how difficult would it be to have index entries
> link to the referenced text?

The current version of groff has infrastructure to enable it, but it
hasn't been integrated with the mm macro set. There have also been
issues with newer versions of both groff itself and the mm macro set
which cause them to misformat the document. To date, I've been too busy
just trying to get all the content correct to spend time debugging and
enhancing the formatting tools.
--
Larry Jones

These findings suggest a logical course of action. -- Calvin

Spiros Bousbouras <> wrote:
> On Tue, 22 Mar 2011 16:45:57 -0400
> wrote:
> > James Kuyper <> wrote:
> > >
> > > There are seven cases where the standard currently requires "same
> > > representation and alignment" (and incorrectly suggests in non-normative
> > > footnotes that this implies interchangeability as arguments to
> > > functions, return values from functions, and members of unions):
> >
> > The footnotes don't imply that interchangeability is required, they say
> > that it is intended to work.
>
> Could you show some code which is intended to work ?

As one example:

file1.c:

int f(usigned u)
{
return u;
}

file2.c:

#include <stdio.h>
extern unsigned f(int);

int main(void)
{
printf("%d\n", f(10));
return 0;
}

This code exhibits undefined behavior because the declaration of f in
file2 is not compatible with the definition in file1 (both the parameter
types and return types are incompatible) , so an implementation is not
required to behave in any particular way, but the code "should" work and
print "10". If not, the implementation may still conform, but it's
"unfriendly" at best.
--
Larry Jones

I wonder what's on TV now. -- Calvin

On Thu, 24 Mar 2011 09:02:42 -0400
James Kuyper <> wrote:
> On 03/23/2011 08:05 PM, Spiros Bousbouras wrote:
> > On Tue, 22 Mar 2011 21:45:42 -0400
> > James Kuyper<> wrote:
> ...
> >> What I consider to be the usual meaning of "same" is rendered almost
> >> completely non-existent by removing transitivity. Whatever it is that
> >> you think is left of the idea after removing that feature needs to be
> >> explained in considerably more detail than the above paragraph.
> >
> > The key issue is that SRAR() may not be transitive. That's the only
> > explanation I can offer.
>
> Then you've failed to explain it. There's infinitely many possible
> intransitive relationships between two C types; but there's not a single
> one them for which I would consider "same representation and alignment"
> a sane description.

Which would make it a "damn poor choice of terminology" as I said earlier.
But you seem convinced that whatever other errors the committee members
might have made , they would not make this particular one , they would
never use the word "same" to describe a relation which is not
transitive. My view is that people have made worse errors so why not
this one ?

> You don't have to describe to us the actual
> relationship that you thought the committee meant to describe; if you're
> not sure what that relationship was. It just has to be an precisely
> described example of a relationship that would fit the context.

A relation between 2 types which is symmetric and therefore would
guarantee that

int foo2(void) {
char c = 0 , *p = &c ;
void *v = (void *) p ;

return p == (char *)v ;
}

always returns 1. Since you have convinced me that the foo() which I
posted earlier ([1]) always returns 1 regardless of the transitivity of
SRAR() , I don't see any point in having SRAR() be transitive which
makes it even more uncertain how "same" should be understood. But
symmetry of SRAR() is still important for the code above and that's an
argument in favour of "same" having its usual meaning.

> I need that description so I can ask you my next question: "How in the
> world could you possibly imagine that the committee might describe that
> relationships by saying 'same representation and alignment'?".

People make mistakes.

> Alternatively, your example might make the answer to that question so
> clear to me that I won't have to ask it - but that seems unlikely at
> this point.
>
> >> More to the point, the key flaw in the footnote is neither the symmetry
> >> nor the transitivity of SRAR();
> >
> > The properties of SRAR() is the key issue.
>
> It's an important issue for you. Those properties are irrelevant to the
> problem with that footnote, since that problem can be demonstrated
> without any reference to the transitivity or symmetry of SRAR.

So you say but I don't see it.

> >> it's the failure to keep in mind that
> >> there are features of a type other than it's representation and
> >> alignment which can affect the interchangeability with another type.
> >
> > Also the failure to bring that fact to the reader's attention.
>
> That's not a separate issue. Failure to bring a fact to the reader's
> attention is a pretty much inevitable consequence of failing to think
> about the fact in the first place.

Ok , I shouldn't have said "Also". So perhaps they did think about it
and they still decided to leave the footnote as it is for whatever
reason. Perhaps their only omission was not realising that the footnote
is misleading as it is written.

> >> No, it is the phrase "is meant to imply" that leads to the problems;
> >> "same" is just an innocent bystander.
> >
> > Since you think that it unambiguously determines the properties of
> > SRAR() then you certainly can't consider it an innocent bystander.
>
> But the problem is not the properties of SRAR, but rather the additional
> issues that were not even mentioned while describing SRAR. Granted, I
> believe that the issues that weren't mentioned, are issues not covered
> by SRAR. However, my belief that those issues are not covered by SRAR
> has nothing to do with the word "same", it has to do with the words
> "representation" and "alignment". Neither of those words can be
> stretched to cover such issues as which registers are used to pass
> values to and from a function during a function call. Suggesting a
> bizarre alternative meaning of "same" is not sufficient to stretch the
> concept to cover those issues.

Why the standard would have anything whatsoever to say about which
registers are used to pass values to functions ? C is supposed to
abstract away from such stuff.

> >> Larry Jones has posted a message
> >> in another branch of this thread that describes the intended meaning.
> >> Keith has suggested that more appropriate wording to cover the intended
> >> meaning would have used the phrase "recommended practice"; I agree.
> >> There's no need to assume that "same" was intended to convey a meaning
> >> almost completely divorced from it's normal one.
> >
> > After Larry Jones's latest intervention perhaps not. But I'd rather he
> > post some code to make it clearer what the intention is.
>
> Me too. It seems to me that "interchangeability" inherently implies
> constraining the range of behavior under some situations which currently
> have undefined behavior. I'd appreciate knowing whether or not that
> understanding matches the committee's intent.

So your theory is that if footnote 39 of 6.2.5 p26 did not have the
flaw you say it has then certain behaviors which now are undefined ,
would become defined in those implementations which would follow the
recommendation in the footnote. Do you have some specific code in mind
which would become defined ?

> >> I can't even imagine what "same" would mean if it were neither symmetric
> >> nor transitive. Without those two features, I would strongly recommend
> >> using some entirely different English word for whatever concept it is
> >> that you're trying to describe - perhaps "similar"?
> >
> > I have already used different words. I have said
> > *** SRAR() may not be transitive ***.
> > You don't see any mention of "same" in that phrase , do you ?
>
> Yes, I do. The capital S in "SRAR" is an abbreviation for "same".

You know what ? I had completely forgotten about that. But I think this
is actually a good thing. Because all I see now is an abstract relation
and the question is what are the properties of the relation and what is
the correspondence between the relation and the semantics of the language.

> The
> only definition provided by the standard is exactly four words long, one
> of which is "same".

Actually it was me who defined SRAR.

> Any interpretation of that phrase which drops the
> transitivity implied by the word "same" has a meaning that I can't wrap
> my head around.

So I suggest that you stop thinking about "same" and think in terms of
"SRAR" without paying attention to which words inspired the name
"SRAR". In fact , since you say that the flaw you think footnote 39 has
is independent from whether SRAR() is symmetric or transitive , you
actually don't lose anything by forgetting about "same" and what
properties it may imply.

> If you care whether or not anyone has any idea what it
> is you're talking about, you have to explain the idea better than simply
> saying it's not transitive.

I do and that's why I posted some code. So far I'm the only one who
has.

> > Not really and in any case I'm kind of fed up discussing the meaning of
> > "same" in the footnote. As I've just said in [1] I don't consider it
> > the right approach to interpreting the footnote. For me much more
> > relevant is the question I ask above :
> >
> > Would it be guaranteed to be true without assuming that
> > SRAR() is symmetric and transitive ?
>
> No. The faults that prevent it from being true would still remain,
> whether or not SRAR were symmetric and transitive.

The context appears in [1]. According to "The code you've posted is
guaranteed to return 1" below, the answer should be yes.

> > The question refers to code which has been snipped when it shouldn't
> > have but I'm also fed up posting the code again and again.
>
> The code you've posted is guaranteed to return 1 because of the rules
> for conversions between the different pointer types. Section 6.3.2.3p7,
> and particularly the last sentence of that paragraph, is the key
> reference for that conclusion. SRAR and interchangeability have nothing
> to do with it. It's guaranteed to return 1 even on implementations where
> they are NOT interchangeable. It would still be guaranteed to return 1
> even if the standard were changed to allow those pointer types to have
> completely unrelated representations, so long as it continued to say
> what it currently says in 6.3.2.3p7. What it says in that clause does
> imply that all three character types must have an alignment of 1, and
> therefore the same alignment, but that's only one half of SRAR.

Good point. It didn't occur to me that the last sentence of 6.3.2.3 p7
implies that all char types have alignment of 1.


[1] <nJaip.82224$2>
http://groups.google.com/group/comp....6?dmode=source


--
Did you ever wonder how much deeper the ocean would be if it weren't
full of sponges?
Steven Wright

On Fri, 25 Mar 2011 16:19:55 -0400
wrote:
> Spiros Bousbouras <> wrote:
> > On Tue, 22 Mar 2011 16:45:57 -0400
> > wrote:
> > > James Kuyper <> wrote:
> > > >
> > > > There are seven cases where the standard currently requires "same
> > > > representation and alignment" (and incorrectly suggests in non-normative
> > > > footnotes that this implies interchangeability as arguments to
> > > > functions, return values from functions, and members of unions):
> > >
> > > The footnotes don't imply that interchangeability is required, they say
> > > that it is intended to work.
> >
> > Could you show some code which is intended to work ?
>
> As one example:
>
> file1.c:
>
> int f(usigned u)
unsigned

> {
> return u;
> }
>
> file2.c:
>
> #include <stdio.h>
> extern unsigned f(int);
>
> int main(void)
> {
> printf("%d\n", f(10));
> return 0;
> }
>
> This code exhibits undefined behavior because the declaration of f in
> file2 is not compatible with the definition in file1 (both the parameter
> types and return types are incompatible) , so an implementation is not
> required to behave in any particular way, but the code "should" work and
> print "10".

I don't see why it should work. "Morally" the code simply doesn't make
sense , why should one expect any particular behavior regardless of
what the standard specifies ? And it's not just the undefined behavior.
Even if file2.c had correct declaration the code still is suspect
because the "return u" does assignment from unsigned to signed int.
Obviously with the value 10 it doesn't matter but even if I saw file1.c
on its own , I would still consider the code suspicious.

So I don't think it should print "10" , it should print a warning. If
footnote 31 of 6.2.5 p9 and footnote 39 of 6.2.5 p26 exist to encourage
implementations to accept such nonsense then the 2 footnotes should be
removed IMO.

> If not, the implementation may still conform, but it's
> "unfriendly" at best.

On the contrary , I would consider dodgy an implementation which
doesn't warn me about the code. I actually tried a modified version
with file2.c being

#include <stdio.h>
extern unsigned f(int);

int main(void) {
f(10) ;
//printf("%d\n", f(10));
return 0;
}

gcc , tcc and Sun Studio 12 c99 will all warnings turned on do not
complain. Shocking. But Sun Studio 12 lint and splint both point out
both type mismatches.

And since the discussion has been mainly centred around footnote 39 of
6.2.5 p26 here's a version of the code for that footnote:

file1.c:
unsigned char * f(char *p) {
return (unsigned char *)p ;
}

file2.c
extern char * f(unsigned char*) ;

int main(void) {
char c = 0 ;
f((unsigned char*)&c) ;
return 0 ;
}

Would you also consider unfriendly an implementation which rejects this
code ? I wouldn't.

The 3 compilers I mentioned above again accept the code silently but
the 2 lints produce the appropriate warnings.

--
Abstractions = page-faults
Richard Gabriel in "Money Through Innovation Reconsidered"

On Thu, 24 Mar 2011 09:03:51 -0400
James Kuyper <> wrote:
> On 03/23/2011 07:33 PM, Spiros Bousbouras wrote:
> > On Tue, 22 Mar 2011 17:45:05 -0700
> > Keith Thompson<kst-> wrote:
> >> Spiros Bousbouras<> writes:
> >>> On Tue, 22 Mar 2011 15:19:27 -0700
> >>> Keith Thompson<kst-> wrote:
> ...
> >>>> I think your option A is the general consensus; the footnote
> >>>> claims to state something that's implied by the normative text,
> >>>> but a careful reading of the normative text indicates that it isn't.
> >>>
> >>> When you say "general" how general do you mean ? Even outside the
> >>> present discussion ? And on what basis has this consensus been formed ?
>
> Oh yes, that footnote has been the subject of many previous discussions,
> both here and on comp.std.c. Search for the exact phrase "is meant to
> imply", if you want to review them.

Then why the hell didn't someone say so much earlier ? It might have
saved us all a lot of time.

[...]

> >> The footnote has problems. They're not caused by the use of the word
> >> "same".
> >
> > Of course not. A word on its own won't cause problems , it's the
> > combination of words which might do. I note also that it wasn't me who
> > focused on the meaning of "same" , it was others who put it at a
> > central place in their argumentation.
>
> You made transitivity central to your discussion; since transitivity is
> a trivial consequence of using the word "same" in anything that even
> remotely resembles it's ordinary meaning, your questioning of
> transitivity inherently focuses attention on the word "same".

No , it focuses attention on what purpose relevant to implementors or
programmers the footnote is meant to serve and whether that purpose
requires SRAR to be transitive.

--
Home is where the books are
Susan Stepney

On Fri, 25 Mar 2011 23:23:03 GMT
Spiros Bousbouras <> wrote:
>
> I do and that's why I posted some code. So far I'm the only one who
> has.

I posted the above before seeing
http://groups.google.com/group/comp....8?dmode=source
<b0av58->

It's good to have something concrete to discuss.

On 03/25/2011 09:43 PM, Spiros Bousbouras wrote:
> On Thu, 24 Mar 2011 09:03:51 -0400
> James Kuyper<> wrote:
....
>> Oh yes, that footnote has been the subject of many previous discussions,
>> both here and on comp.std.c. Search for the exact phrase "is meant to
>> imply", if you want to review them.
>
> Then why the hell didn't someone say so much earlier ? It might have
> saved us all a lot of time.

I don't normally cite the existence of a consensus of opinion as an
argument in favor of a given point of view. Citations from the standard
are what's really important, not people's opinions about what they mean.

....
>> You made transitivity central to your discussion; since transitivity is
>> a trivial consequence of using the word "same" in anything that even
>> remotely resembles it's ordinary meaning, your questioning of
>> transitivity inherently focuses attention on the word "same".
>
> No , it focuses attention on what purpose relevant to implementors or
> programmers the footnote is meant to serve and whether that purpose
> requires SRAR to be transitive.

I believe that the intended purpose depends upon "sameness": that is,
the use of EXACTLY the same relationship between bit patterns and
values, and possession of EXACTLY the same alignment. These things allow
type punning; anything less than perfect "sameness" would not serve any
useful purpose. A relationship similar to "sameness", but sufficiently
different to remove transitivity, would necessarily be only a similarity
relationship, and as such, would not allow type punning.
--
James Kuyper

On 03/25/2011 07:23 PM, Spiros Bousbouras wrote:
> On Thu, 24 Mar 2011 09:02:42 -0400
> James Kuyper<> wrote:
....
>> Then you've failed to explain it. There's infinitely many possible
>> intransitive relationships between two C types; but there's not a single
>> one them for which I would consider "same representation and alignment"
>> a sane description.
>
> Which would make it a "damn poor choice of terminology" as I said earlier.
> But you seem convinced that whatever other errors the committee members
> might have made , they would not make this particular one , they would
> never use the word "same" to describe a relation which is not
> transitive. My view is that people have made worse errors so why not
> this one ?

Because I can't imagine what they might possibly have meant by "same
representation and alignment" that was NOT accurately described by that
phrase. If you'd provided a possible alternative meaning, I might be
able to evaluate the plausibility of the idea that they actually
intended that alternative. But all you've been able to say is "not
transitive", without giving any details about what this intransitive
alternative meaning might be.

>> You don't have to describe to us the actual
>> relationship that you thought the committee meant to describe; if you're
>> not sure what that relationship was. It just has to be an precisely
>> described example of a relationship that would fit the context.
>
> A relation between 2 types which is symmetric and therefore would
> guarantee that
>
> int foo2(void) {
> char c = 0 , *p =&c ;
> void *v = (void *) p ;
>
> return p == (char *)v ;
> }
>
> always returns 1. Since you have convinced me that the foo() which I
> posted earlier ([1]) always returns 1 regardless of the transitivity of
> SRAR() , I don't see any point in having SRAR() be transitive which
> makes it even more uncertain how "same" should be understood. But
> symmetry of SRAR() is still important for the code above and that's an
> argument in favour of "same" having its usual meaning.

Your code doesn't involve the representations in any way that depends
upon their sameness; it only involves conversions, which can preserve
all of the relevant properties, even if different representations are
used by the different types.

>> I need that description so I can ask you my next question: "How in the
>> world could you possibly imagine that the committee might describe that
>> relationships by saying 'same representation and alignment'?".
>
> People make mistakes.

Yes, but they're generally not random mistakes; there are reasons the
mistakes are made, which can be inferred in many cases from the nature
of the mistake. To me, it's entirely plausible that someone might have
made the mistake of thinking that "same representation and alignment"
was sufficient to ensure interchangeability - you don't understand yet
my explanation of how this is a mistaken conclusion, and I (sort-of)
understand why; they might have made a similar mistake.
However, I can't figure out plausible way for someone writing "same"
when they meant "similar", nor any plausible reason why they might have
meant "similar" when sameness is the characteristic that gives this
guarantee what little value it might have.

....
>> It's an important issue for you. Those properties are irrelevant to the
>> problem with that footnote, since that problem can be demonstrated
>> without any reference to the transitivity or symmetry of SRAR.
>
> So you say but I don't see it.

I've been trying and failing to find spare time to write up a response
to your earlier question on this matter for several days now. It's a
complicated task and I've had a lot of distractions. I'll try to get it
out sometime this weekend.

....
>> But the problem is not the properties of SRAR, but rather the additional
>> issues that were not even mentioned while describing SRAR. Granted, I
>> believe that the issues that weren't mentioned, are issues not covered
>> by SRAR. However, my belief that those issues are not covered by SRAR
>> has nothing to do with the word "same", it has to do with the words
>> "representation" and "alignment". Neither of those words can be
>> stretched to cover such issues as which registers are used to pass
>> values to and from a function during a function call. Suggesting a
>> bizarre alternative meaning of "same" is not sufficient to stretch the
>> concept to cover those issues.
>
> Why the standard would have anything whatsoever to say about which
> registers are used to pass values to functions ? C is supposed to
> abstract away from such stuff.

It shouldn't. My real preference would be for the standard to merely
require interchangeability (and provide a precise definition of what
that means), and leave the details of how interchangeability can be
ensured up to the implementation. SRAR would merely be a derivable
feature of the implementation, not a requirement in itself.

....
>>> Me too. It seems to me that "interchangeability" inherently implies
>> constraining the range of behavior under some situations which currently
>> have undefined behavior. I'd appreciate knowing whether or not that
>> understanding matches the committee's intent.
>
> So your theory is that if footnote 39 of 6.2.5 p26 did not have the
> flaw you say it has then certain behaviors which now are undefined ,
> would become defined in those implementations which would follow the
> recommendation in the footnote. Do you have some specific code in mind
> which would become defined ?

Yes, and I'll provide it soon, when I don't have a wife yelling at me
that it's time to get to bed.

>> Any interpretation of that phrase which drops the
>> transitivity implied by the word "same" has a meaning that I can't wrap
>> my head around.
>
> So I suggest that you stop thinking about "same" and think in terms of
> "SRAR" without paying attention to which words inspired the name
> "SRAR". In fact , since you say that the flaw you think footnote 39 has
> is independent from whether SRAR() is symmetric or transitive , you
> actually don't lose anything by forgetting about "same" and what
> properties it may imply.

If I don't pay attention to the four words "same representation and
alignment", I have absolutely no idea what it means; you've provided
only the vaguest clues to a possible alternative meaning. If I do pay
attention to them, I can't figure out what alternative you could
possibly be implying. Maybe it's just a failure of my imagination; but
if you can imagine such an alternative, could you please describe it?

>> If you care whether or not anyone has any idea what it
>> is you're talking about, you have to explain the idea better than simply
>> saying it's not transitive.
>
> I do and that's why I posted some code. So far I'm the only one who
> has.

You have not yet explained the alternative interpretation of SRAR that
allows the behavior of that code to be in question.

....
>> No. The faults that prevent it from being true would still remain,
>> whether or not SRAR were symmetric and transitive.
>
> The context appears in [1]. According to "The code you've posted is
> guaranteed to return 1" below, the answer should be yes.

The code can be guaranteed to be true despite interchangeability not
being a valid conclusion to reach from SRAR, because the code doesn't
involve interchangeability; not as I understand that term.

--
James Kuyper