boltar@cylonHQ.com: Aug 31 08:31AM
On Thu, 30 Aug 2018 22:14:02 +0200
>You could equally well say that if it is valid C++11, then a C11
>compiler should handle it in C since the compiler can already handle it
>in C++. That would be nonsense just the same.
The superset should handle the subset, not vice verca.
>C is not a subset of C++. It is /close/ to a subset, but not an exact one.
Its close enough as makes no difference and that is how its used. Actual use
cases should trump academic opinion.
>> any more.
>If people had really wanted this particular form of VLAs in their C++
>code, I am sure the gcc team would have allowed it as an extension. If
Having used gcc for MANY years I think its fair to say the gcc team include
and exclude what they feel like, not necessarily what their users want. Which
given the compiler is free and a lot of them do it for no money is entirely
reasonable. But one shouldn't assume the users are at the head of their list
when it comes to wish fulfillment.
>modes of gcc, then the way forward is to file a bug in gcc asking for
>the missing feature. If other people agree with you, and it is as
>simple to support as you think, then maybe it will get added. It is
Its already supported. I very much doubt the C++ and C sections of the compiler
use different parsers and lexical analysers, its almost certainly the same ones
with various feature flags switched on and off depending on the language.
|
Ian Collins <ian-news@hotmail.com>: Aug 31 09:50PM +1200
>> compiler should handle it in C since the compiler can already handle it
>> in C++. That would be nonsense just the same.
> The superset should handle the subset, not vice verca.
Which doesn't include VLAs.
--
Ian
|
boltar@cylonHQ.com: Aug 31 09:56AM
On Fri, 31 Aug 2018 21:50:31 +1200
>>> in C++. That would be nonsense just the same.
>> The superset should handle the subset, not vice verca.
>Which doesn't include VLAs.
It seems to me idiotic to switch off a feature which is already built into the
compiler simply because its not part of an official standard.
|
Ian Collins <ian-news@hotmail.com>: Aug 31 10:03PM +1200
>> Which doesn't include VLAs.
> It seems to me idiotic to switch off a feature which is already built into the
> compiler simply because its not part of an official standard.
One problem with VLAs and C++ is constructs that are regular arrays in
C++ have to be VLAs in C. For example
const size_t s = 42;
int n[s];
--
Ian.
|
David Brown <david.brown@hesbynett.no>: Aug 31 12:38PM +0200
>> compiler should handle it in C since the compiler can already handle it
>> in C++. That would be nonsense just the same.
> The superset should handle the subset, not vice verca.
Obviously - /if/ C++ were a superset of C. It isn't - it is only
approximately, and so C++ can only handle most of C code instead of all
of it.
I think what you are trying to say is that you would prefer C++ to be a
full superset of C. That would not work (though it could, reasonably,
be slightly closer than it is today).
>> C is not a subset of C++. It is /close/ to a subset, but not an exact one.
> Its close enough as makes no difference and that is how its used. Actual use
> cases should trump academic opinion.
No, that's wrong - on both accounts.
It is not hard to write code that is compatible with both languages -
and that is the practical solution that people use if they have to mix
the languages. There are a few fiddly bits, but mostly it's fine.
There are, I think, three main cases for such mixes. One is header
files that should be usable by both C and C++. There you see a fine
example of incompatibility - a declaration of an external function is
incompatible between C and C++. It has an easy solution for headers,
but it is still needed.
A second case is for people programming C on Windows with MSVC, because
the compiler is crap for C. So they write code that is C (or at least
is intended to be C), but compiled as C++.
A final case is for mixed development groups where code is originally in
C but is migrated to C++.
However, C written to be compatible with C++ has some restrictions. You
are likely to get some non-idiomatic coding, like casting the result of
malloc (some C programmers have very strong opinions against that).
There are lots of other things where C++ is stricter than C, leading to
code that is fine in C being a failure in C++ (some types of casts,
mixing enums and ints, having multiple tentative declarations of the
same variable in a file). Some of these - such as K&R function
declarations and definitions - most C programmers are happy to see gone.
Then there are features that can be very useful in C that don't exist in
C++. Designated initialisers are, I think, the biggest in this class.
(C++ plans to adopt them in C++20.) VLAs and complex numbers are others
that are somewhat less used. _Generic is a new one in C11.
There are things that exist in both languages, but have different
details - such as the type of 'a' or file-scope "const" data.
And clearly keywords in C++ that don't exist in C can be identifiers in
normal C code.
So no, C++ is not a proper superset of C, and never can be. It could be
closer, of course. VLA's were not supported in C++ because there was a
hope of introducing a better alternative, but that initiative failed
because no one could figure out how to implement it with the desired
syntax and semantics. So some compilers (like gcc) have partial support
for VLAs in C++.
And no, "actual use cases" should not trump the standards. Compilers
and standards committees should work together (as they do) - sometimes
one will be ahead of the other, but we don't want compiler implementers
having a free-for-all, even for copying features from C. That leads to
incompatibilities and restrictions in later versions of the language.
> given the compiler is free and a lot of them do it for no money is entirely
> reasonable. But one shouldn't assume the users are at the head of their list
> when it comes to wish fulfillment.
You are mixing up "users in general" with individual users. gcc
developers are interested in hearing the ideas and opinions of
individuals, but will usually not implement something unless it seems
useful to a wide range of users (or the individual writes the
implementation themselves).
So if someone says they want VLAs with sizes from file-scope variables
passed to functions, it is not likely to come high up on their to-do
lists. It would be a lot of work for little gain. If several people
ask, and show how that coding style is used in a lot of C programs and
is better than alternative constructs, and if the gcc C++ experts can
see that it will not conflict with other things in C++ present or
expected future, /then/ they would give it some priority.
> Its already supported. I very much doubt the C++ and C sections of the compiler
> use different parsers and lexical analysers, its almost certainly the same ones
> with various feature flags switched on and off depending on the language.
They use different parsers and different lexical analysis, AFAIUI. The
C++ front-end was split off from the C front-end long ago as it became
too complex to maintain as a "C with extras" parser. It would be
possible, I suppose, to use the C++ parser to handle C as a sort of "C++
with lots of limits and a few extra bits". But I don't expect that to
happen - the result would be a good deal less efficient for C, and
probably lose many of the useful gcc C extensions.
clang has a different development history, and different models for
their front-end handling. Where gcc started with C and gradually added
C++ as the language developed, clang started when C++ was a
well-established language. AFAIK, it /does/ handle C and C++ in the
same parser, and so is much more likely to support C constructs in C++.
|
boltar@cylonHQ.com: Aug 31 11:02AM
On Fri, 31 Aug 2018 22:03:43 +1200
>C++ have to be VLAs in C. For example
>const size_t s = 42;
>int n[s];
And the problem is...?
|
Sam <sam@email-scan.com>: Aug 31 07:02AM -0400
> It seems to me idiotic to switch off a feature which is already built into
> the
> compiler simply because its not part of an official standard.
Feel free to write your own C++ compiler, to show everyone how it should
be done.
|
boltar@cylonHQ.com: Aug 31 11:14AM
On Fri, 31 Aug 2018 12:38:40 +0200
>Then there are features that can be very useful in C that don't exist in
>C++. Designated initialisers are, I think, the biggest in this class.
I don't remember seeing them ever used in code whereas I've seen VLAs a number
of times.
>And clearly keywords in C++ that don't exist in C can be identifiers in
>normal C code.
That is pretty much the only real issue preventing C++ being a proper superset
of C.
>And no, "actual use cases" should not trump the standards. Compilers
I disagree. A programming language and its compiler is a tool to get a job
done, its not a purely academic exercise. You can see this with objective C++
compilers - a hideous mash up of languages which unfortunately is required
because of Apple sticking with Objective-C for its APIs long after it should
have been taken out back and shot.
>is better than alternative constructs, and if the gcc C++ experts can
>see that it will not conflict with other things in C++ present or
>expected future, /then/ they would give it some priority.
I imagine most programmers have neither the time nor inclination to get into
in depth argumenst over compiler features with compiler writers, they're too
busy doing their job. The only people who will are those involved in compilers
or students who have lots of free time. Neither of which will probably be
using the compilers in a "get it done by yesterday" business enviroment.
>They use different parsers and different lexical analysis, AFAIUI. The
>C++ front-end was split off from the C front-end long ago as it became
>too complex to maintain as a "C with extras" parser. It would be
Well thats odd because very often with gcc you get a "use flag -xyz to use
this language feature" type of error. Though perhaps its only within a
particular language, not between them.
|
boltar@cylonHQ.com: Aug 31 11:23AM
On Fri, 31 Aug 2018 07:02:47 -0400
>This is a MIME GnuPG-signed message. If you see this text, it means that
>your E-mail or Usenet software does not support MIME signed messages.
Indeed it doesn't, I don't need any attachment shite with usenet.
>> compiler simply because its not part of an official standard.
>Feel free to write your own C++ compiler, to show everyone how it should
>be done.
I should have known the utterly moronic "If you don't like something do it
yourself" argument would pop up from some muppet eventually. Sorry sonny, I
have a job to do. When you get one you might realise that free time can be
scarce (he says writing a usenet post, but hey ;). But FWIW I wrote a (subset
of) C interpreter about 10 years ago so I do have some skin in the game.
|
David Brown <david.brown@hesbynett.no>: Aug 31 01:42PM +0200
>> C++. Designated initialisers are, I think, the biggest in this class.
> I don't remember seeing them ever used in code whereas I've seen VLAs a number
> of times.
People write code in different ways. I have seen and used designated
initialisers more often than VLAs - but equally I have no reason to
doubt your experience.
In discussions of "what does C have that C++ does not", I find
designated initialisers coming up more often than VLAs. Perhaps it is
because there is no equivalent in C++, while C++ programmers have
various alternatives to use in situations where a VLA might be of
interest in C.
VLA's in C have (unfairly, IMHO) an image of being "dangerous" -
designated initialisers are considered either harmless convenient
syntax, or directly useful for safer more legible coding.
>> normal C code.
> That is pretty much the only real issue preventing C++ being a proper superset
> of C.
No, it is not - that's why I gave other issues. But the keyword one
here is certainly a big and insurmountable issue.
> compilers - a hideous mash up of languages which unfortunately is required
> because of Apple sticking with Objective-C for its APIs long after it should
> have been taken out back and shot.
I agree about Objective-C++. But that goes against your case - it is an
example of a language created in compilers for actual use, rather than
one that was planned or defined by academics or committees.
> busy doing their job. The only people who will are those involved in compilers
> or students who have lots of free time. Neither of which will probably be
> using the compilers in a "get it done by yesterday" business enviroment.
I'm lost here. You are blaming the language for being run by
"academics" rather than real compilers (forgetting that the standards
committee consists mainly of major language users and compiler
developers, with only a few academics). You blame the compiler writers
for making things up for their own interest instead of listening to
users. You blame the users for being too busy working to tell compiler
developers what they want.
Everyone, it seems, is to blame for not solving your impossible request
for making C++ a full superset of C.
> Well thats odd because very often with gcc you get a "use flag -xyz to use
> this language feature" type of error. Though perhaps its only within a
> particular language, not between them.
There are few features that are controlled by flags in gcc (other than
the obvious ones that are controlled by the choice of language
standards). But there are certainly a large number of extensions to C
that are not available in C++ in gcc - usually because doing so would
mean duplicating effort, or at least adding significant effort, for a
feature deemed of little worth.
|
Bo Persson <bop@gmb.dk>: Aug 31 03:46PM +0200
>> const size_t s = 42;
>> int n[s];
> And the problem is...?
The problem is with C where this is a VLA, which are optional in C11. So
C99 only?
In C++ this is a fixed size array (s is a constant), so just works.
Bo Persson
|
boltar@cylonHQ.com: Aug 31 01:47PM
On Fri, 31 Aug 2018 13:42:11 +0200
>because there is no equivalent in C++, while C++ programmers have
>various alternatives to use in situations where a VLA might be of
>interest in C.
To me designated initialisers is one of those features that looks like it
would be very useful but rarely is. But as you say, each to their own.
>I agree about Objective-C++. But that goes against your case - it is an
>example of a language created in compilers for actual use, rather than
>one that was planned or defined by academics or committees.
Well not really, what it shows is that when there's a will there's a way
and if the gcc and clang teams can merge the hideous syntax of Obj-C with C++
then C99 should be a doddle.
>I'm lost here. You are blaming the language for being run by
>"academics" rather than real compilers (forgetting that the standards
>committee consists mainly of major language users and compiler
I'm not sure what you mean by "major language users". Corporations will
inveitably try and skew things there own way to suit their own compiler
implementations and needs which don't necessarily intersect with coders
at large.
>for making things up for their own interest instead of listening to
>users. You blame the users for being too busy working to tell compiler
>developers what they want.
You said it yourself - when solitary users do make a point it generally gets
lost in the noise.
>Everyone, it seems, is to blame for not solving your impossible request
>for making C++ a full superset of C.
I never said a full superset, I simply said it should support the syntax of
NINETEEN year old C99.
|
Paavo Helde <myfirstname@osa.pri.ee>: Aug 31 06:46PM +0300
> I never said a full superset, I simply said it should support the syntax of
> NINETEEN year old C99.
I'm curious - how do the C programmers protect themselves against stack
overflow with VLA-s? A VLA takes an unknown amount of space in the
stack, and the stack size is typically very limited (in order of some
MB-s). Also, running out of stack is UB, there is no error recovery.
In my little test I could only call 5 nested functions each having a VLA
of meager 50,000 doubles, until getting a segfault. Max stack depth 5
seems too small even for C, not to speak about C++ where I routinely see
stack backtraces of depth 100 or more.
|
David Brown <david.brown@hesbynett.no>: Aug 31 05:57PM +0200
On 31/08/18 17:46, Paavo Helde wrote:
> overflow with VLA-s? A VLA takes an unknown amount of space in the
> stack, and the stack size is typically very limited (in order of some
> MB-s). Also, running out of stack is UB, there is no error recovery.
C programmers (good ones, anyway!) make sure they don't allocate too big
VLAs - they check the sizes or get the size from a known source. They
don't ask web site users to give them a number and use that as the size
of the array!
It is exactly the same as for any other allocation. You don't
pre-allocate a std::vector with a size that is unreasonable.
Yes, overrunning your stack space is UB. For most real programs, so is
overrunning your heap. On some OS's (like Linux, with typical
configurations) the OS will happily accept memory requests for much more
space than it can give you, and crash your application (or a different
program) when the space gets used. Even when OS's are more
conservative, you can happily allocate so much space that other programs
get moved out to swap and everything slows to a fraction of its normal
speed. The C or C++ code may have defined behaviour in such cases, but
the user certainly doesn't! And if you have an OS is clever enough to
refuse the allocation, programs are rarely smart enough to deal with the
situation well. Exiting due to an unhandled exception, or simply
failing to do the job expected of the program, is not much better than
crashing from a stack overflow.
> of meager 50,000 doubles, until getting a segfault. Max stack depth 5
> seems too small even for C, not to speak about C++ where I routinely see
> stack backtraces of depth 100 or more.
Use VLAs - or any other stack data - in a way that makes sense for the
target. There is nothing special about VLAs here - the same would
happen if you made a std::array of 50,000 doubles local to the function.
|
Paavo Helde <myfirstname@osa.pri.ee>: Aug 31 07:32PM +0300
On 31.08.2018 18:57, David Brown wrote:
> situation well. Exiting due to an unhandled exception, or simply
> failing to do the job expected of the program, is not much better than
> crashing from a stack overflow.
That's right. Relying on the bad_alloc exception is not wise because at
that point the computer has already become unusably slow anyway and
there is also a good chance the OS will kill your program before it gets
bad_alloc.
Also, the memory reported as free is often actually not unused. The OS
is using it for disk file caching, for example. If the programs will
grab it to themselves, the system performance will go down.
Decent memory-demanding software should actually monitor the available
free memory and reduce the number of parallel threads or refuse to start
new tasks if there is too little of it. OTOH, being nice will often just
mean that other programs can grab more. When I get a notice from my
program "avoiding parallelization because of low memory", I already know
this is because Firefox has eaten up 12 GB again.
|
David Brown <david.brown@hesbynett.no>: Aug 31 06:44PM +0200
On 31/08/18 18:32, Paavo Helde wrote:
> that point the computer has already become unusably slow anyway and
> there is also a good chance the OS will kill your program before it gets
> bad_alloc.
Use the same attitude - thinking sensibly and realistically - when using
VLAs, and you will be equally successful at using them as with any other
kind of resource.
Take a cavalier attitude of allocating resources without a care, and
you'll get trouble regardless of whether it is stack space, heap space,
threads, processor time, or any other resource.
VLAs are not different or more dangerous than anything else in programming.
|
Chris Vine <chris@cvine--nospam--.freeserve.co.uk>: Aug 31 08:29PM +0100
On Fri, 31 Aug 2018 18:44:05 +0200
David Brown <david.brown@hesbynett.no> wrote:
[snip]
> you'll get trouble regardless of whether it is stack space, heap space,
> threads, processor time, or any other resource.
> VLAs are not different or more dangerous than anything else in programming.
I know that you know this, and moving back to the original proposition,
it is worth mentioning that VLAs are also by no means the main part of
the things in C99 that do not form part of valid C++. The proposition
of your respondent that "[VLAs] is pretty much the only real issue
preventing C++ being a proper superset of C" is weird.
C++ has numerous incompatibilities with C99, and even more with C11.
For example there are a number of C99 types, macros and operators
beginning with an underscore and followed by a capital letter which are
and always will be represented differently in C++ (_Bool, _Complex,
_Imaginery, _Pragma), and more in C11 (_Alignas, _Alignof, _Atomic,
_Noreturn, _Static_assert, _Thread_local). Aside from that, off the top
of my head, C99 has compound literals, designated initializers and the
restrict qualifier which are not in C++, C's unions behave differently
and its character literals are of different size. I am sure there are
lots of other incompatibilities as well.
I don't know anyone who writes code other than headers which is
deliberately designed to be both valid C and valid C++. Headers are
different. Many C libraries aim to be usable in C++ and their headers
are in the common subset between C89/90 and C++.
|
"Rick C. Hodgin" <rick.c.hodgin@gmail.com>: Aug 30 06:45PM -0700
On Thursday, August 30, 2018 at 6:38:41 PM UTC-4, Chris M. Thomasson wrote:
> What happens in the rapture? Will you just drop dead, or disappear?
The Bible describes it:
Jesus describes how it will be a worldwide event:
https://www.biblegateway.com/passage/?search=Matthew+24%3A34-42&version=KJV
34 Verily I say unto you, This generation shall not pass,
till all these things be fulfilled.
35 Heaven and earth shall pass away, but my words shall
not pass away.
36 But of that day and hour knoweth no man, no, not the
angels of heaven, but my Father only.
37 But as the days of Noah were, so shall also the coming
of the Son of man be.
38 For as in the days that were before the flood they were
eating and drinking, marrying and giving in marriage,
until the day that Noe entered into the ark,
39 And knew not until the flood came, and took them all
away; so shall also the coming of the Son of man be.
==> 40 Then shall two be in the field; the one shall be taken,
and the other left.
==> 41 Two women shall be grinding at the mill; the one shall
be taken, and the other left.
42 Watch therefore: for ye know not what hour your Lord
doth come.
https://www.biblegateway.com/passage/?search=Luke+17%3A34-36&version=KJV
==> 34 I tell you, in that night there shall be two men in
one bed; the one shall be taken, and the other shall
be left.
35 Two women shall be grinding together; the one shall
be taken, and the other left.
36 Two men shall be in the field; the one shall be taken,
and the other left.
Luke 17:34 suggests it will be in the evening in Jerusalem. But,
no one knows for sure.
Paul goes further, describes how quickly it will occur. People
will just wink out of existe in immediacy, probably with no visible
flash or audio sound.
https://www.biblegateway.com/passage/?search=1+Corinthians+15%3A51-52%2C1+Thessalonians+4%3A13-18&version=KJV
1 Corinthians 15:51-52
51 Behold, I shew you a mystery; We shall not all sleep,
but we shall all be changed,
52 In a moment, in the twinkling of an eye, at the last
trump: for the trumpet shall sound, and the dead shall
be raised incorruptible, and we shall be changed.
1 Thessalonians 4:13-18
13 But I would not have you to be ignorant, brethren,
concerning them which are asleep, that ye sorrow not,
even as others which have no hope.
14 For if we believe that Jesus died and rose again, even
so them also which sleep in Jesus will God bring with
him.
15 For this we say unto you by the word of the Lord, that
we which are alive and remain unto the coming of the
Lord shall not prevent them which are asleep.
16 For the Lord himself shall descend from heaven with a
shout, with the voice of the archangel, and with the
trump of God: and the dead in Christ shall rise first:
17 Then we which are alive and remain shall be caught up
together with them in the clouds, to meet the Lord in
the air: and so shall we ever be with the Lord.
18 Wherefore comfort one another with these words.
Study these things. Faith comes by hearing, and hearing by the
word of God (the Bible).
Some verse by verse, concept by concept, explanation:
https://www.youtube.com/watch?v=5te0v0zCOjc
--
Rick C. Hodgin
|
"Rick C. Hodgin" <rick.c.hodgin@gmail.com>: Aug 30 06:46PM -0700
On Thursday, August 30, 2018 at 6:40:51 PM UTC-4, Chris M. Thomasson wrote:
> >> group.
> > I didn't write the posts on this thread. Look at the headers.
> Rick C. Hodgin Enterprises?
Giganews. I post from Google Groups or Eternal September.
--
Rick C. Hodgin
|
"Chris M. Thomasson" <invalid_chris_thomasson@invalid.invalid>: Aug 30 09:12PM -0700
On 8/30/2018 6:46 PM, Rick C. Hodgin wrote:
>>> I didn't write the posts on this thread. Look at the headers.
>> Rick C. Hodgin Enterprises?
> Giganews. I post from Google Groups or Eternal September.
I see Giganews here:
___________________
eternal-september.org!reader02.eternal-september.org!feeder.eternal-september.org!feeder4.usenet.farm!feed.usenet.farm!weretis.net!feeder6.news.weretis.net!feeder.usenetexpress.com!feeder-in1.iad1.usenetexpress.com!border1.nntp.dca1.giganews.com!nntp.giganews.com!z10-v6no1138729qtb.0!news-out.google.com!i36-v6ni658qti.0!nntp.google.com!z10-v6no1138728qtb.0!postnews.google.com!glegroupsg2000goo.googlegroups.com!not-for-mail
___________________
|
"Rick C. Hodgin" <rick.c.hodgin@gmail.com>: Aug 30 09:18PM -0700
On Friday, August 31, 2018 at 12:12:15 AM UTC-4, Chris M. Thomasson wrote:
> ___________________
> eternal-september.org!reader02.eternal-september.org!feeder.eternal-september.org!feeder4.usenet.farm!feed.usenet.farm!weretis.net!feeder6.news.weretis.net!feeder.usenetexpress.com!feeder-in1.iad1.usenetexpress.com!border1.nntp.dca1.giganews.com!nntp.giganews.com!z10-v6no1138729qtb.0!news-out.google.com!i36-v6ni658qti.0!nntp.google.com!z10-v6no1138728qtb.0!postnews.google.com!glegroupsg2000goo.googlegroups.com!not-for-mail
> ___________________
https://groups.google.com/forum/?nomobile=true#!original/comp.lang.c++/eF0aM6K1Ki0/dCwkEobAEAAJ
NNTP-Posting-Date: Thu, 23 Aug 2018 11:31:23 -0500
Newsgroups: comp.lang.c++
===> X-Mozilla-News-Host: news://news.giganews.com:119
From: "Rick C. Hodgin" <rick.c...@gmail.com>
Subject: The Rapture (Reprise ad infinitum)
===> Organization: Rick C. Hodgin Enterprises
Date: Thu, 23 Aug 2018 17:31:24 +0100
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101
Thunderbird/52.9.1
MIME-Version: 1.0
Message-ID: <jOydnXk6ubDGfOPGnZ2dnUU7-RGdnZ2d@giganews.com>
Lines: 6
===> X-Usenet-Provider: http://www.giganews.com
X-Trace: sv3-W1ehWKd9taIIJtfziaTYlIsjiukIWaJgEnE8h5OpJ0MlkkUOD4gNKNsZdw81Zcv/1KnE4jf/F9PmLq1!Rsx1aOHhNWNei/XVXhMLXbwjM68xbfVm/429hLqpj1KYYfJfXjhTaSppItAYVssGDikotoruAFRr
===> X-Complaints-To: ab...@giganews.com
X-DMCA-Notifications: http://www.giganews.com/info/dmca.html
X-Abuse-and-DMCA-Info: Please be sure to forward a copy of ALL headers
X-Abuse-and-DMCA-Info: Otherwise we will be unable to process your complaint properly
X-Postfilter: 1.3.40
X-Original-Bytes: 1289
Content-Type: text/plain; charset=utf-8; format=flowed
===> Content-Language: en-GB
Content-Transfer-Encoding: 7bit
The ===> highlighted lines show his signature. Compare these
to my headers.
--
Rick C. Hodgin
|
David Brown <david.brown@hesbynett.no>: Aug 31 08:22AM +0200
On 31/08/18 06:12, Chris M. Thomasson wrote:
> ___________________
> eternal-september.org!reader02.eternal-september.org!feeder.eternal-september.org!feeder4.usenet.farm!feed.usenet.farm!weretis.net!feeder6.news.weretis.net!feeder.usenetexpress.com!feeder-in1.iad1.usenetexpress.com!border1.nntp.dca1.giganews.com!nntp.giganews.com!z10-v6no1138729qtb.0!news-out.google.com!i36-v6ni658qti.0!nntp.google.com!z10-v6no1138728qtb.0!postnews.google.com!glegroupsg2000goo.googlegroups.com!not-for-mail
> ___________________
News posts pass through various servers, and the headers you see will
include the originating server, the server you use, and any servers
along the way. Giganews is one of the biggies in the business - a great
deal of Usenet posts pass through one of their systems along the way.
Usually it is quite obvious when a post is one of the real Rick's
annoying sermons, or one of the fake Rick's equally annoying so-called
"satires". And if Poe's law applies, then it really doesn't matter who
made the post.
|
