bart <bc@freeuk.com> writes:

On 10/04/2025 12:28, Keith Thompson wrote:

bart <bc@freeuk.com> writes:
[...]

Someone, not anyone but the all-knowing Tim, said: "and those types
are not compatible, because the two struct tags are different."

Do you agree with that? Or is there something more to making two types
be incompatible?

I don't recall the exact discussion

It stems from this, a reply from DB dated: "Tue, 8 Apr 2025 16:50:56
+0200". (About half way down there is some quoted code of mine.)

It concerned two struct types in different translations units, which
needed to be compatible for the test program to work corectly.

I said they were compatible enough. David said they were entirely
compatible. Tim said "No they are not". Three different opinions.

If you pretend not to understand the C standard, you can argue
about it forever.

It's been explained to you more than once, but really, just read
the flippin standard and stop arguing.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 10/04/2025 15:33, Scott Lurndal wrote:

bart <bc@freeuk.com> writes:

On 10/04/2025 12:28, Keith Thompson wrote:

bart <bc@freeuk.com> writes:
[...]

Someone, not anyone but the all-knowing Tim, said: "and those types
are not compatible, because the two struct tags are different."

Do you agree with that? Or is there something more to making two types >>>> be incompatible?

I don't recall the exact discussion

It stems from this, a reply from DB dated: "Tue, 8 Apr 2025 16:50:56
+0200". (About half way down there is some quoted code of mine.)

It concerned two struct types in different translations units, which
needed to be compatible for the test program to work corectly.

I said they were compatible enough. David said they were entirely
compatible. Tim said "No they are not". Three different opinions.

If you pretend not to understand the C standard, you can argue
about it forever.

It's been explained to you more than once, but really, just read
the flippin standard and stop arguing.

Fucking hell.

Three people have said three different things. They can't all be right.

But according to you, only one of them is wrong: me, even though the
other two have made exactly opposite claims!

So to you it's not about who's right and who's wrong; you are just
CONSTANTLY having a go at me personally for reasons that are nothing to
do with the subject. That is persecution.

In fact you don't really care about the topic (if you're even aware of
it). So, FUCK YOU.

As for reading the standard, since that is this group's favourite
subject, then why does the group even exist? Since every possible
question can be answered there.

Apart of course from the interminable 'halting problem' (apparently half
of you just can't resist joining in) and discussions about religion and
ancient history.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 10.04.2025 17:12, bart wrote:

On 10/04/2025 15:33, Scott Lurndal wrote:

bart <bc@freeuk.com> writes:

On 10/04/2025 12:28, Keith Thompson wrote:

bart <bc@freeuk.com> writes:
[...]

Someone, not anyone but the all-knowing Tim, said: "and those types
are not compatible, because the two struct tags are different."

Do you agree with that? Or is there something more to making two types >>>>> be incompatible?

I don't recall the exact discussion

It stems from this, a reply from DB dated: "Tue, 8 Apr 2025 16:50:56
+0200". (About half way down there is some quoted code of mine.)

It concerned two struct types in different translations units, which
needed to be compatible for the test program to work corectly.

I said they were compatible enough. David said they were entirely
compatible. Tim said "No they are not". Three different opinions.

If you pretend not to understand the C standard, you can argue
about it forever.

It's been explained to you more than once, but really, just read
the flippin standard and stop arguing.

Fucking hell.

Three people have said three different things. They can't all be right.

But according to you, only one of them is wrong: me, even though the
other two have made exactly opposite claims!

So to you it's not about who's right and who's wrong; you are just
CONSTANTLY having a go at me personally for reasons that are nothing to
do with the subject. That is persecution.

In fact you don't really care about the topic (if you're even aware of
it). So, FUCK YOU.

As for reading the standard, since that is this group's favourite
subject, then why does the group even exist? Since every possible
question can be answered there.

"I don't recall the exact discussion", and less the context of any
formulation in any of the many posts. I also don't understand what
your goal is. As I see it some posters tried to explain aspects of
the topic to you, and they feel that you didn't understand it but
are instead arguing just for the argument. Your post seems to show
a desire that you want one (or two) of these posters to be wrong.
It was suggested to you to refer to the standard document to clear
the topic since there's obviously an unsolvable communication issue
between the participants.

I basically do agree with your perception of this newsgroup and its
purpose. But...

*If* you're really interested in the topic, and since all the other
posters obviously gave up to continue explaining their sight to you,
why don't you accept that suggestion and read the standard document
to have clarity about the topic? [FYI; this was a rhetoric question.]

Janis

[...]

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 10/04/2025 23:18, Janis Papanagnou wrote:

On 10.04.2025 17:12, bart wrote:

On 10/04/2025 15:33, Scott Lurndal wrote:

bart <bc@freeuk.com> writes:

On 10/04/2025 12:28, Keith Thompson wrote:

bart <bc@freeuk.com> writes:
[...]

Someone, not anyone but the all-knowing Tim, said: "and those types >>>>>> are not compatible, because the two struct tags are different."

Do you agree with that? Or is there something more to making two types >>>>>> be incompatible?

I don't recall the exact discussion

It stems from this, a reply from DB dated: "Tue, 8 Apr 2025 16:50:56
+0200". (About half way down there is some quoted code of mine.)

It concerned two struct types in different translations units, which
needed to be compatible for the test program to work corectly.

I said they were compatible enough. David said they were entirely
compatible. Tim said "No they are not". Three different opinions.

If you pretend not to understand the C standard, you can argue
about it forever.

It's been explained to you more than once, but really, just read
the flippin standard and stop arguing.

Fucking hell.

Three people have said three different things. They can't all be right.

But according to you, only one of them is wrong: me, even though the
other two have made exactly opposite claims!

So to you it's not about who's right and who's wrong; you are just
CONSTANTLY having a go at me personally for reasons that are nothing to
do with the subject. That is persecution.

In fact you don't really care about the topic (if you're even aware of
it). So, FUCK YOU.

As for reading the standard, since that is this group's favourite
subject, then why does the group even exist? Since every possible
question can be answered there.

"I don't recall the exact discussion", and less the context of any formulation in any of the many posts. I also don't understand what
your goal is. As I see it some posters tried to explain aspects of
the topic to you, and they feel that you didn't understand it but
are instead arguing just for the argument. Your post seems to show
a desire that you want one (or two) of these posters to be wrong.
It was suggested to you to refer to the standard document to clear
the topic since there's obviously an unsolvable communication issue
between the participants.

I basically do agree with your perception of this newsgroup and its
purpose. But...

*If* you're really interested in the topic, and since all the other
posters obviously gave up to continue explaining their sight to you,
why don't you accept that suggestion and read the standard document
to have clarity about the topic? [FYI; this was a rhetoric question.]

I've read the document, or the relevant section. According to that, DB
was wrong, and TR was half-right.

Neither of them is willing to back down, while no one else is willing to
back me up: KT will not say anything against his mates, and SL hasn't
really got a clue about the topic, but he never misses a change to put
the boot in when I'm already on the ground.

Janis

[...]

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 2025-04-10, bart <bc@freeuk.com> wrote:

On 10/04/2025 23:18, Janis Papanagnou wrote:

On 10.04.2025 17:12, bart wrote:

On 10/04/2025 15:33, Scott Lurndal wrote:

bart <bc@freeuk.com> writes:

On 10/04/2025 12:28, Keith Thompson wrote:

bart <bc@freeuk.com> writes:
[...]

Someone, not anyone but the all-knowing Tim, said: "and those types >>>>>>> are not compatible, because the two struct tags are different."

Do you agree with that? Or is there something more to making two types >>>>>>> be incompatible?

I don't recall the exact discussion

It stems from this, a reply from DB dated: "Tue, 8 Apr 2025 16:50:56 >>>>> +0200". (About half way down there is some quoted code of mine.)

It concerned two struct types in different translations units, which >>>>> needed to be compatible for the test program to work corectly.

I said they were compatible enough. David said they were entirely
compatible. Tim said "No they are not". Three different opinions.

If you pretend not to understand the C standard, you can argue
about it forever.

It's been explained to you more than once, but really, just read
the flippin standard and stop arguing.

Fucking hell.

Three people have said three different things. They can't all be right.

But according to you, only one of them is wrong: me, even though the
other two have made exactly opposite claims!

So to you it's not about who's right and who's wrong; you are just
CONSTANTLY having a go at me personally for reasons that are nothing to
do with the subject. That is persecution.

In fact you don't really care about the topic (if you're even aware of
it). So, FUCK YOU.

As for reading the standard, since that is this group's favourite
subject, then why does the group even exist? Since every possible
question can be answered there.

"I don't recall the exact discussion", and less the context of any
formulation in any of the many posts. I also don't understand what
your goal is. As I see it some posters tried to explain aspects of
the topic to you, and they feel that you didn't understand it but
are instead arguing just for the argument. Your post seems to show
a desire that you want one (or two) of these posters to be wrong.
It was suggested to you to refer to the standard document to clear
the topic since there's obviously an unsolvable communication issue
between the participants.

I basically do agree with your perception of this newsgroup and its
purpose. But...

*If* you're really interested in the topic, and since all the other
posters obviously gave up to continue explaining their sight to you,
why don't you accept that suggestion and read the standard document
to have clarity about the topic? [FYI; this was a rhetoric question.]

I've read the document, or the relevant section. According to that, DB
was wrong, and TR was half-right.

Neither of them is willing to back down, while no one else is willing to
back me up: KT will not say anything against his mates, and SL hasn't
really got a clue about the topic, but he never misses a change to put
the boot in when I'm already on the ground.

These persecution complexes are pointless. What backs you up is chapter-and-verse citations with solid analysis, if required. That's it.

If you don't want to read standards, go to notebooklm.google.com
create a workspace there, and upload the documents into it.

Then you can ask the friendly AI questions about it.

Let me try it. Okay, I gave it C90, draft C99 and the current
workign draft N3301. I have those three documents in the workspace.

Let's try a question to the AI:

What changed in the concept of two struct types being compatible in
C90, C99 and the current draft version of C?

The answer is long, but looks pretty good. You don't see it in the
copy and paste, but in the workspace chat window, it has links to
citations from the documents I uploaded to check the facts.

Here is the answer:

The concept of compatibility between two struct types has evolved across
C90, C99, and the current draft version of C. Here's a breakdown of
the key changes:

C90 Standard:

In C90, as described in, two structure types declared in separate translation
units are considered to have **compatible types** if they meet the following
criteria:

* They have the **same number of members**.
* The members have the **same names**.
* The corresponding members have **compatible types**.
* For structures, the members must be declared in the **same order**.
* For structures or unions, any **bit-fields** must have the **same widths**.

It's important to note that C90 primarily focused on the structural
similarity of the types in terms of their members when declared
separately. All declarations referring to the same object or function
were also required to have compatible types. A structure declaration
introduced a new type within a translation unit, and this type was
incomplete until the closing brace of the definition.

C99 Standard:

C99 introduced the crucial concept of **tags** for determining
compatibility between structure, union, or enumeration types declared
in separate translation units. The rules for compatibility became:

* If one type is declared with a **tag**, the other must be declared
with the **same tag**.
* If both are **complete types**, they must have:
* A **one-to-one correspondence** between their members.
* Each pair of corresponding members declared with **compatible
types**.
* If a member has a name, the corresponding member must have the
**same name**.
* For structures, corresponding members must be declared in the
**same order**.
* For structures or unions, corresponding **bit-fields** must
have the **same widths**.
* For enumerations, corresponding members must have the **same
values**.

C99 emphasized that for structure, union, or enumerated types declared
in different scopes or using different tags, they declare **distinct
types**. Even declarations without a tag declared distinct types. This
shift towards tag-based compatibility provided a stronger mechanism
for ensuring type safety across different compilation units.

Current C Draft (n3301.pdf):

The current draft of the C standard further refines the rules for
structure type compatibility:

* For two **complete structure, union, or enumerated types declared
with the same tag** to be compatible:
* There must be a **one-to-one correspondence** between their
members with **compatible types**.
* If one member has an **alignment specifier**, the other must
have an **equivalent alignment specifier**.
* Corresponding members must have the **same name**.
* For structures, corresponding members must be in the **same
order**.
* For unions declared in the same translation unit,
corresponding members must be in the **same order**.
* Corresponding **bit-fields** must have the **same widths**.
* For enumerations, corresponding members must have the **same
values**, and if one has a **fixed underlying type**, the other must
have a **compatible fixed underlying type**.
* The draft introduces the concept that **anonymous structures
and unions** are considered regular members, and their types are
compatible if their members fulfill the preceding requirements.

* For structure, union, or enumerated types declared in **separate
translation units**, they are compatible in the following cases:
* Both are declared **without tags** and fulfill the
member-based requirements.
* Both have the **same tag** and are **completed** somewhere in
their respective translation units, fulfilling the member-based
requirements.
* Both have the **same tag**, and **at least one** of the two
types is **not completed** in its translation unit.

The current draft continues to emphasize tag-based compatibility
but adds nuances like the consideration of alignment specifiers and
explicitly addresses anonymous structures and unions. The summary of
changes from C99 mentions "**improved tag compatibility rules, enabling
more types to be compatible with other types**", indicating a trend
towards a more flexible yet still type-safe system. Similar to C99,
declarations in different scopes or with different tags still declare
distinct types.

--
TXR Programming Language: http://nongnu.org/txr
Cygnal: Cygwin Native Application Library: http://kylheku.com/cygnal
Mastodon: @Kazinator@mstdn.ca

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 11/04/2025 01:10, bart wrote:

On 10/04/2025 23:18, Janis Papanagnou wrote:

*If* you're really interested in the topic, and since all the other
posters obviously gave up to continue explaining their sight to you,
why don't you accept that suggestion and read the standard document
to have clarity about the topic? [FYI; this was a rhetoric question.]

I had certainly given up and moved on.

I've read the document, or the relevant section.

Finally! Now you too can move on.

According to that, DB
was wrong, and TR was half-right.

Yes, it seems I was inaccurate about the compatibility - the names of
the struct and fields need to match across translation units, not just
the types of the fields. That's why it is important that /you/ read the standard.

Tim was, as usual in these matters, entirely correct as far as I can
see. I don't see how he could be considered "half-right" here. Tim has
a communication style that some people find grating (to put it mildly),
but there is no question that his knowledge of the C standards is
outstanding.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 11/04/2025 09:14, David Brown wrote:

On 11/04/2025 01:10, bart wrote:

On 10/04/2025 23:18, Janis Papanagnou wrote:

*If* you're really interested in the topic, and since all the other
posters obviously gave up to continue explaining their sight to you,
why don't you accept that suggestion and read the standard document
to have clarity about the topic? [FYI; this was a rhetoric question.]

I had certainly given up and moved on.

I've read the document, or the relevant section.

Finally!  Now you too can move on.

According to that, DB was wrong, and TR was half-right.

Yes, it seems I was inaccurate about the compatibility - the names of
the struct and fields need to match across translation units, not just
the types of the fields.  That's why it is important that /you/ read the standard.

But no one, absolutely no one, said outright that you were wrong. Only
Keith eventually agreed that one of you (and Tim) was right, but didn't
care who, and the next day admitted that one of you might be wrong, but
still didn't want to commit himself as to who it might be.

On the other hand, I was the only one not to make a bold claim one way
or another (I said types were compatible enough for my test to work),
but Keith had no hesitation in telling me I was 100% wrong!

That is what is very worrying to me, and makes this a toxic environment
(see my last post here where I remark on the contrast with how KT treats
me and how he treats TR.)

Tim was, as usual in these matters, entirely correct as far as I can
see.  I don't see how he could be considered "half-right" here.  Tim has
a communication style that some people find grating (to put it mildly),
but there is no question that his knowledge of the C standards is outstanding.

I said half-right because as he put it, it sounded as though
compatibility depended entirely on struct tags.

(Which I then proceeded to put to the test with examples where there
were no tags, and those where the tags were the same (but defined in
different scopes). But these were examples where both structs were
visible to the compiler.

In my original example, the compiler could only see one at a time, as
they were in different translation units.)

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Fri, 11 Apr 2025 12:32:43 +0100
bart <bc@freeuk.com> wrote:

That is what is very worrying to me, and makes this a toxic
environment (see my last post here where I remark on the contrast
with how KT treats me and how he treats TR.)

I am reading this group for enough time to question sincerity of above statement. IMHO, you are not worried, more like an opposite. You enjoy
a toxicity of the environment.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 11/04/2025 12:50, Michael S wrote:

On Fri, 11 Apr 2025 12:32:43 +0100
bart <bc@freeuk.com> wrote:

That is what is very worrying to me, and makes this a toxic
environment (see my last post here where I remark on the contrast
with how KT treats me and how he treats TR.)

I am reading this group for enough time to question sincerity of above statement. IMHO, you are not worried, more like an opposite. You enjoy
a toxicity of the environment.

That's a shame. From your post half an hour ago, you seemed like one of
the good guys: the only person here to back up my position.

But at least you seem to acknowledge the toxicity.

You enjoy a toxicity of the environment.

You would be wrong. It makes me very sad and depressed.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Fri, 11 Apr 2025 12:56:18 +0100
bart <bc@freeuk.com> wrote:

You would be wrong. It makes me very sad and depressed.

It sounded to me like a quote from Monty Python, but quick googling
didn't discovery anything from them that uses this exact phrase.

Communication at that level oveer Internet is generally not easy.
Especially so in the absence of common cultural background.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 11/04/2025 13:32, bart wrote:

On 11/04/2025 09:14, David Brown wrote:

On 11/04/2025 01:10, bart wrote:

On 10/04/2025 23:18, Janis Papanagnou wrote:

*If* you're really interested in the topic, and since all the other
posters obviously gave up to continue explaining their sight to you,
why don't you accept that suggestion and read the standard document
to have clarity about the topic? [FYI; this was a rhetoric question.]

I had certainly given up and moved on.

I've read the document, or the relevant section.

Finally!  Now you too can move on.

According to that, DB was wrong, and TR was half-right.

Yes, it seems I was inaccurate about the compatibility - the names of
the struct and fields need to match across translation units, not just
the types of the fields.  That's why it is important that /you/ read
the standard.

But no one, absolutely no one, said outright that you were wrong. Only
Keith eventually agreed that one of you (and Tim) was right, but didn't
care who, and the next day admitted that one of you might be wrong, but
still didn't want to commit himself as to who it might be.

Some people (certainly Kaz) gave accurate explanations without bothering
to say explicitly who was right or wrong. Others posted with fewer
details - presumably because they didn't want to go to the effort of establishing exactly what the rules are. After all, none of this is of
any concern to most serious C programmers - we all know that "struct"
(and "union") create types, "typedef" creates type aliases, if you want
to use the same type in several places in one translation unit you
re-use the same type, and if you want to do so across translation units
you declare the type in a shared header. The precise compatibility
rules are typically only relevant if you are dealing with jumbled and
poorly structured code.

On the other hand, I was the only one not to make a bold claim one way
or another (I said types were compatible enough for my test to work),
but Keith had no hesitation in telling me I was 100% wrong!

"Type compatibility" is a specific term in C with a specific meaning.
It is a binary relationship - two types are compatible, or they are not compatible. You can't have "compatible enough".

It is true that some compilers are laxer than others in regards to type compatibility. It is possible that some compilers do not issue the
required diagnostics when you mix incompatible types in ways that
violate constraint requirements. It is certainly the case that some
compilers do not do any kind of analysis for optimisation based type compatibility (known as "type-based alias analysis" or "strict
aliasing") - in which case, as long as you use casts or other
conversions you can pretend that types with identical representations
are compatible in non-portable code for those specific tools.

However, it is also certainly true that some compilers /do/ make use of
the type compatibility rules to generate more optimal code, or for
better static analysis. It is also certainly true that some programmers
make use of incompatible types to ensure that some kinds of mistakes in
their code result in compile-time errors, thus reducing the risk of errors.

And it is always the case that some things may "just work" even though
the behaviour is undefined in C or the code breaks constraints or other requirements. That is never a good thing to rely on, unless you
understand exactly why the code is problematic, and exactly why it works
in the given situation despite the issues, and if you are happy with the non-portable code.

That is what is very worrying to me, and makes this a toxic environment
(see my last post here where I remark on the contrast with how KT treats
me and how he treats TR.)

My impression of KT is that he always tries to argue the case, not the
person - thus he has had agreements and disagreements with Tim, and has sometimes answered your questions as well as he could while at other
times he expresses his frustration at your determined misunderstanding
of C and refusal to learn about it or read relevant parts of the standards.

Tim was, as usual in these matters, entirely correct as far as I can
see.  I don't see how he could be considered "half-right" here.  Tim
has a communication style that some people find grating (to put it
mildly), but there is no question that his knowledge of the C
standards is outstanding.

I said half-right because as he put it, it sounded as though
compatibility depended entirely on struct tags.

He did not say that, and I as I read his post, I don't interpret it as
implying that. There are a number of criteria needed for two structs to
be compatible across translation units. Your example there failed the
first criterium, and I suppose Tim didn't feel the need to go any
further. Perhaps it would have been more helpful if he had, or if he
had at least indicated that other things were important, but the post
was not wrong or even half-wrong.

(Which I then proceeded to put to the test with examples where there
were no tags, and those where the tags were the same (but defined in different scopes). But these were examples where both structs were
visible to the compiler.

In my original example, the compiler could only see one at a time, as
they were in different translation units.)

Testing can only prove the existence of bugs, not their absence.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 11.04.2025 14:12, Michael S wrote:

On Fri, 11 Apr 2025 12:56:18 +0100
bart <bc@freeuk.com> wrote:

It makes me very sad and depressed.

It sounded to me like a quote from Monty Python, but quick googling
didn't discovery anything from them that uses this exact phrase.

It sounds more like Marvin in Douglas Adams' HGTTG...


“I think you ought to know I’m feeling very depressed.”

“Wearily, I sit here, pain and misery my only companions. And vast intelligence, of course. And infinite sorrow.”

“Don’t pretend you want to talk to me, I know you hate me.”

“No one consulted me or considered my feelings in the matter.”

“I’d give you advice, but you wouldn’t listen. No one ever does.”


(Quotes taken from [*].)

Janis

[*] https://liammartinwriter.medium.com/what-marvin-the-paranoid-android-can-teach-us-about-a-i-fa6901af1d35

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 11/04/2025 13:12, Michael S wrote:

On Fri, 11 Apr 2025 12:56:18 +0100
bart <bc@freeuk.com> wrote:

You would be wrong. It makes me very sad and depressed.

It sounded to me like a quote from Monty Python, but quick googling
didn't discovery anything from them that uses this exact phrase.

So you think I was making a joke? It's not funny.

Communication at that level oveer Internet is generally not easy.
Especially so in the absence of common cultural background.

I think the gaslighting, bullying and utter disrepect that's going on
here is pretty clear, don't you think?

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

bart <bc@freeuk.com> writes:

On 11/04/2025 09:14, David Brown wrote:

On 11/04/2025 01:10, bart wrote:

According to [the C standard?], DB was wrong, and TR was half-right.

Yes, it seems I was inaccurate about the compatibility - the names
of the struct and fields need to match across translation units,
not just the types of the fields. That's why it is important that
/you/ read the standard.

But no one, absolutely no one, said outright that you were wrong.
Only Keith eventually agreed that one of you (and Tim) was right,
but didn't care who, and the next day admitted that one of you
might be wrong, but still didn't want to commit himself as to who
it might be.

On the other hand, I was the only one not to make a bold claim one
way or another (I said types were compatible enough for my test to
work), but Keith had no hesitation in telling me I was 100% wrong!

That is what is very worrying to me, and makes this a toxic
environment (see my last post here where I remark on the contrast
with how KT treats me and how he treats TR.)

If your comments and style were more like mine, you might find that
how Keith Thompson treats you would be different.

Incidentally, Keith doesn't always respond to my postings with kid
gloves. If something I say offends his sensibilities he isn't shy
about calling me out on it.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)