Keith Thompson <Keith.S.Thompson+u@gmail.com> writes:
> "james...@alumni.caltech.edu" <jameskuyper@alumni.caltech.edu> writes:
>> On Friday, September 10, 2021 at 9:35:09 AM UTC-4, Fabian Russell wrote:
>>> Decimal floating point was standardized as IEEE758-2008 and new C types
>>> were defined: _Decimal128, _Decimal64, and _Decimal32.
>>
>> Can you cite a reference for that? The latest draft of the C standard that I
>> currently have access to is n2176.pdf, a draft version of the standard that
>> eventually got approved as C2017. I found no mention of those types in that
>> document.
>
> See n2596.pdf, a more recent draft of the C 202x standard. Yes, decimal
> floating-point is being proposed as an optional standard C feature.
>
> http://www.open-std.org/JTC1/SC22/WG14/www/docs/n2176.pdf
>
> [...]

Sorry, that was a typo (or rather a copy-and-pasto). The correct URL is

http://www.open-std.org/JTC1/SC22/WG14/www/docs/n2596.pdf

and that one isn't (currently) password-protected.

--
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
Working, but not speaking, for Philips
void Void(void) { Void(); } /* The recursive call of the void */

Fabian Russell <fr314159@gmail.com> wrote:
> On Friday, September 10, 2021 at 12:52:28 PM UTC-4, james...@alumni.caltech.edu wrote:
> > Decimal-FP is being discussed precisely because there are platforms currently
> > planned which will have hardware support for it (they may already be in
> > production
> >
>
> IBM mainframes, like the z-series, have had hardware decFP for quite some time.
>
> In fact, the GCC extensions that I referred to earlier are based on libdecnumber
> which was developed by IBM.
>
> Also, IBM has donated to the FSF another decFP library of theirs called libdfp:
>
> https://github.com/libdfp/libdfp
>
> Libdfp essentially extends most glibc functions to the decFP types.
>
> So GNU/Linux has very complete decFP capability.
>
> Unfortunately, and maybe also surprisingly, considering how long the decFP
> type has been around there is little information about decFP applications to be found.
>
> Whether Intel or AMD will include decFP hardware support in the future is unknown.

No wonder there is almost no use of decimal FP outside IBM: AFAIK
most experts think that this is bad idea (solves no real problem
and introduces unnecessary cost and complexity). Group in IBM
got management backing and they are pushing decimal FP. Intel
joined standarization effort, but it seems Intel mostly
wanted to avoid standarizing IBM hardware, so Intel proposed
alternative encoding ("nice thing about standards is that there
are many to choose from"). It seems that most folks now hope
that decimal FP will join huge pile of "trash standards" that
can be safely ignored. But given push from IBM and existing
IBM hardware there will be optional support in C standard.

--
Waldek Hebisch

On 9/10/21 2:11 PM, Eli the Bearded wrote:
> In comp.lang.c, James Kuyper <jameskuyper@alumni.caltech.edu> wrote:
>> On 9/10/21 11:44 AM, Scott Lurndal wrote:
>>> I believe Fabian was referring to the IEEE standard, not the C standard.
>> Yes, but because they are not in the C standard, they're not C standard
>> types, which means that the best place to ask questions about them is
>> not this newsgroup.
>
> I'm reading this in comp.lang.c and I look at the Newsgroups header and
> don't see a crosspost to comp.std.c so I'm wondering why you believe
> "not C Standard ... not this newsgroup".

comp.std.c is for discussions of the standard for the C language.
comp.lang.c is for discussion of the language defined by that standard.
Comp.lang.c is unmoderated, and has no official charter, having been
created before charters were required. Therefore, it's perfectly
feasible to post questions about association football here, if you want.
You won't be violating any official rules by doing so. However, as a
simple practical matter, if your question is relevant to a specific
compiler, a specific operating system, or a particular library, you'll
get better answers by posting questions in a forum more tightly focused
on that compiler, operating system, or library than this newsgroup is.

On 9/10/21 3:04 PM, Scott Lurndal wrote:
> James Kuyper <jameskuyper@alumni.caltech.edu> writes:
....
>> Yes, but because they are not in the C standard, they're not C standard
>> types, which means that the best place to ask questions about them is
>> not this newsgroup.
>
> I disagree. This is comp.lang.c, not comp.lang.std.c.

That doesn't change anything - you'll get better responses to a question
about GnuC in a forum specific to GnuC, and you'll get better answers to
a question about Visual C in a forum devoted to Visual C, you'll get
better answers to questions about tcc are in a forum devoted to tcc,
etc. The only questions where this is the best place to get an answer
are questions that are not specific to any particular compiler - which
is pretty much the same as standard C.

Am 10.09.2021 um 21:07 schrieb Scott Lurndal:

>> Decimal-FP is too highlevel for such a lowlevel language.

> Incorrect, as usual.
> Decimal FP, when implemented in the hardware[*], is suitable for any
> language (especially COBOL).

Such datatypes and operations will never be part of a lowlevel-language
like C.

In article <shhbeb$d3n$1@dont-email.me>,
Bonita Montero <Bonita.Montero@gmail.com> wrote:

> Am 10.09.2021 um 21:07 schrieb Scott Lurndal:
>
> >> Decimal-FP is too highlevel for such a lowlevel language.
>
> > Incorrect, as usual.
> > Decimal FP, when implemented in the hardware[*], is suitable for any
> > language (especially COBOL).
>
> Such datatypes and operations will never be part of a lowlevel-language
> like C.

They are being added to C extension called C.SHEKEL.

--
:-<> Siri Seal of Disavowal #000-001. Disavowed. Denied. Deleted. @
'I desire mercy, not sacrifice.' /|\
Discordia: not just a religion but also a parody. This post / \
I am an Andrea Doria sockpuppet. insults Islam. Mohammed

Keith Thompson <Keith.S.Thompson+u@gmail.com> writes:

> Eli the Bearded <*@eli.users.panix.com> writes:
>
>> In comp.lang.c, James Kuyper <jameskuyper@alumni.caltech.edu> wrote:
>>
>>> On 9/10/21 11:44 AM, Scott Lurndal wrote:
>>>
>>>> I believe Fabian was referring to the IEEE standard, not the C
>>>> standard.
>>>
>>> Yes, but because they are not in the C standard, they're not C
>>> standard types, which means that the best place to ask questions
>>> about them is not this newsgroup.
>>
>> I'm reading this in comp.lang.c and I look at the Newsgroups header
>> and don't see a crosspost to comp.std.c so I'm wondering why you
>> believe "not C Standard ... not this newsgroup".
>
> Because the general (though not universal) consensus is that
> comp.lang.c is for discussion of the C language as defined by
> the standard,

I believe that is a minority view. First off the newsgroup
(albeit with a different name) predates the existence of any ISO
or ANSI standard. Second, and probably more important, most of
the discussion that actually takes place is about using the C
language rather than about the language per se. Even if a
program is written in "standard C", it can reasonably lead to
questions outside the ISO standard proper, because C allows
extensions, and because tools (compilers, linkers, etc) come into
play when trying to write C code, and I think also some other
causes. Furthermore I think there is at least tacit agreement
among most participants here that these kinds of questions are
appropriate to be brought up in the newsgroup, even if better
answers might (and I emphasize might) be available in another
venue.

What comp.lang.c is definitely NOT for is subjects that are
primarily concerned with languages other than C. Almost everyone
(other than trolls) adheres to this principle, with a small
number of repeat offender exceptions.

Am 11.09.2021 um 08:29 schrieb Siri Cruise:
> In article <shhbeb$d3n$1@dont-email.me>,
> Bonita Montero <Bonita.Montero@gmail.com> wrote:
>
>> Am 10.09.2021 um 21:07 schrieb Scott Lurndal:
>>
>>>> Decimal-FP is too highlevel for such a lowlevel language.
>>
>>> Incorrect, as usual.
>>> Decimal FP, when implemented in the hardware[*], is suitable for any
>>> language (especially COBOL).
>>
>> Such datatypes and operations will never be part of a lowlevel-language
>> like C.
>
> They are being added to C extension called C.SHEKEL.

But never in ISO C.

On 2021-09-10, Stefan Ram <ram@zedat.fu-berlin.de> wrote:
> Fabian Russell <fr314159@gmail.com> writes:
>>Why bother to include the new types yet now allow them to be used
>>arithmetically like all other standard numeric types?
>
> One would have to define many new rules for cases like
> "double + decimal" and so on. And these would have to be

This cn be handled via, say, a general decimal contagion rule.
The double operand is converted to the best approximation in decimal
floating point, or undefined behavior if it is out of range. Then the
calculation proceeds as decimal <op> decimal.

This does not require a large expenditure of words, or their
proliferation.

> worded conditionally to support systems that do not support
> such decimal types.

That just requires an indication in one place in the document that
the type is optional, and thus implementations can omit all requirements
pertaining to that type.

It's just like making uint64_t or VLA's optional.

An implementation which has no decimal type simply cannot process
decimal * double. The requirements for how that multiplication is done
do not have to be polluted with conditional text. Just any requirements
involving decimal do not apply according to that type being optional.

--
TXR Programming Language: http://nongnu.org/txr
Cygnal: Cygwin Native Application Library: http://kylheku.com/cygnal

On Sat, 11 Sep 2021 16:31:33 +0200, Bonita Montero
<Bonita.Montero@gmail.com> wrote:

>Am 11.09.2021 um 08:29 schrieb Siri Cruise:
>> In article <shhbeb$d3n$1@dont-email.me>,
>> Bonita Montero <Bonita.Montero@gmail.com> wrote:
>>
>>> Am 10.09.2021 um 21:07 schrieb Scott Lurndal:
>>>
>>>>> Decimal-FP is too highlevel for such a lowlevel language.
>>>
>>>> Incorrect, as usual.
>>>> Decimal FP, when implemented in the hardware[*], is suitable for any
>>>> language (especially COBOL).
>>>
>>> Such datatypes and operations will never be part of a lowlevel-language
>>> like C.
>>
>> They are being added to C extension called C.SHEKEL.
>
>But never in ISO C.

Since decimal floating point is already in the December 2020 version
of the N2596 draft, why do you say that?

--
Remove del for email

On 11/09/2021 00:50, Bart wrote:
>
>
>> http://www.open-std.org/JTC1/SC22/WG14/www/docs/n2176.pdf
>>
>
> (This link is password protected. None of the handful of rude words I
> typed in seemed to work.)

Yes. That's annoying, and seems very strange to me given that they made
it available freely and unprotected earlier, and give out other drafts
freely.

You can get it from here: <https://en.cppreference.com/w/c/links>

(That page also links to other standards from C89 up to the latest C23
proposal.)

On Sat, 11 Sep 2021 16:31:33 +0200, Bonita Montero
<Bonita.Montero@gmail.com> wrote:

>Am 11.09.2021 um 08:29 schrieb Siri Cruise:
>> In article <shhbeb$d3n$1@dont-email.me>,
>> Bonita Montero <Bonita.Montero@gmail.com> wrote:
>>
>>> Am 10.09.2021 um 21:07 schrieb Scott Lurndal:
>>>
>>>>> Decimal-FP is too highlevel for such a lowlevel language.
>>>
>>>> Incorrect, as usual.
>>>> Decimal FP, when implemented in the hardware[*], is suitable for any
>>>> language (especially COBOL).
>>>
>>> Such datatypes and operations will never be part of a lowlevel-language
>>> like C.
>>
>> They are being added to C extension called C.SHEKEL.
>
>But never in ISO C.

n2596.pdf contains the latest (2021-12-11) draft of C202X, and has been
extensively updated to include specifications for Decimal FP. Do you
have any particular reason to believe that those specifications will be
dropped before the final standard is approved?

As I'd speculated earlier in this thread, in n2596.pdf Decimal FP is
optional, and will presumably only ever be supported on platforms with
hardware support for Decimal FP, meaning that it is not at all
high-level, on those platforms. Why shouldn't C implementations
targeting such platforms provide this feature?

David Brown <david.brown@hesbynett.no> writes:
> On 11/09/2021 00:50, Bart wrote:
>>> http://www.open-std.org/JTC1/SC22/WG14/www/docs/n2176.pdf
>>
>> (This link is password protected. None of the handful of rude words I
>> typed in seemed to work.)
>
> Yes. That's annoying, and seems very strange to me given that they made
> it available freely and unprotected earlier, and give out other drafts
> freely.
>
> You can get it from here: <https://en.cppreference.com/w/c/links>
>
> (That page also links to other standards from C89 up to the latest C23
> proposal.)

Links to drafts of standards, not to the standards themselves. Most of
the links are to the WG14 site.

N2176 says "This version of the document is intended to be the version
that is to go into ballot for C17"; it's the closest publicly available
draft of the C17 standard. (It's odd that the password-protected
version is substantially smaller than the unprotected version.)

(And as I said, it's not the document I meant to link to. That was
N2596, the latest C23 working draft, also linked from cppreference.com,
which adds decimal floating-point.)

--
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
Working, but not speaking, for Philips
void Void(void) { Void(); } /* The recursive call of the void */

James Kuyper <jameskuyper@alumni.caltech.edu> writes:
[...]
> As I'd speculated earlier in this thread, in n2596.pdf Decimal FP is
> optional, and will presumably only ever be supported on platforms with
> hardware support for Decimal FP, meaning that it is not at all
> high-level, on those platforms.

I wouldn't assume that. It could make sense to emulate decimal
FP in software. The only question is whether some implementer
considers it to be worth the effort.

> Why shouldn't C implementations
> targeting such platforms provide this feature?

Agreed.

--
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
Working, but not speaking, for Philips
void Void(void) { Void(); } /* The recursive call of the void */

Kaz Kylheku <563-365-8930@kylheku.com> writes:
> On 2021-09-10, Stefan Ram <ram@zedat.fu-berlin.de> wrote:
>> Fabian Russell <fr314159@gmail.com> writes:
>>>Why bother to include the new types yet now allow them to be used
>>>arithmetically like all other standard numeric types?
>>
>> One would have to define many new rules for cases like
>> "double + decimal" and so on. And these would have to be
>
> This cn be handled via, say, a general decimal contagion rule.
> The double operand is converted to the best approximation in decimal
> floating point, or undefined behavior if it is out of range. Then the
> calculation proceeds as decimal <op> decimal.

As I mentioned yesterday, the latest C23 draft includes (optional)
decimal FP. It simply disallows mixing decimal and standard
floating-point types as operands. N2596 6.3.1.8.

It strikes me as a reasonable decision to require the programmer
to decide (by using a cast) whether to perform the operation in
standard or decimal floating-point.

--
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
Working, but not speaking, for Philips
void Void(void) { Void(); } /* The recursive call of the void */

On 9/11/21 6:39 PM, Keith Thompson wrote:
> James Kuyper <jameskuyper@alumni.caltech.edu> writes:
> [...]
>> As I'd speculated earlier in this thread, in n2596.pdf Decimal FP is
>> optional, and will presumably only ever be supported on platforms with
>> hardware support for Decimal FP, meaning that it is not at all
>> high-level, on those platforms.
>
> I wouldn't assume that. It could make sense to emulate decimal
> FP in software. The only question is whether some implementer
> considers it to be worth the effort.
>
>> Why shouldn't C implementations
>> targeting such platforms provide this feature?
>
> Agreed.
>

I agree too. There are enough problem domains where having a close match
to the way the arithmetic works in the program matches the way the
arithmatic works when doing the math 'by hand' (which would naturally be
done in 'Decimals') that it makes sense to support it.

There is basically no cost to programs that don't use decimal floating
point for its presence if one corner can be handled, it just adds a bit
of complexity to the compiler and library.

The one issue is that routines like *printf/*scanf need to be able to be
selected to support or not support that ability, to avoid pulling in the
library to support the option.

This is a solved problem, either using a compile flag that enables the
feature (and change the library linked in) or I have seen an equivalent
ability in the embedded world which detects the use of floating point
libraries being used, and the presence of that causes the version with
floating support to get included, otherwise a non-floating point version
is used to avoid loading all the floating point libraries.

On 12/09/2021 00:37, Keith Thompson wrote:
> David Brown <david.brown@hesbynett.no> writes:
>> On 11/09/2021 00:50, Bart wrote:
>>>> http://www.open-std.org/JTC1/SC22/WG14/www/docs/n2176.pdf
>>>
>>> (This link is password protected. None of the handful of rude words I
>>> typed in seemed to work.)
>>
>> Yes. That's annoying, and seems very strange to me given that they made
>> it available freely and unprotected earlier, and give out other drafts
>> freely.
>>
>> You can get it from here: <https://en.cppreference.com/w/c/links>
>>
>> (That page also links to other standards from C89 up to the latest C23
>> proposal.)
>
> Links to drafts of standards, not to the standards themselves. Most of
> the links are to the WG14 site.
>

Yes.

> N2176 says "This version of the document is intended to be the version
> that is to go into ballot for C17"; it's the closest publicly available
> draft of the C17 standard. (It's odd that the password-protected
> version is substantially smaller than the unprotected version.)
>
> (And as I said, it's not the document I meant to link to. That was
> N2596, the latest C23 working draft, also linked from cppreference.com,
> which adds decimal floating-point.)
>

I didn't notice that when I replied, but I think the page on
cppreference.com will be useful anyway to people looking for standards
(or, as you correctly point out, drafts that are extremely close to the
official standards).

On 9/10/2021 6:35 AM, Fabian Russell wrote:
> Decimal floating point was standardized as IEEE758-2008 and new C types
> were defined: _Decimal128, _Decimal64, and _Decimal32.
>
> Gcc has many built-in functions (via libgcc) to handle decimal FP:
>
> https://gcc.gnu.org/onlinedocs/gccint/Decimal-float-library-routines.html
>
> However, what puzzles me is that C has not yet incorporated the decimal
> FP types so that the ordinary binary operators, such as "+ - * /" can operate
> directly on them. Rather, to add two _Decimal_64 values, x, y, for example,
> one must use the function __bid_adddd3(x, y) instead of x + y.
>
> Why bother to include the new types yet now allow them to be used
> arithmetically like all other standard numeric types?
>

Fwiw, here is a project I am working on from time to time that could
"benefit" from a standardized arbitrary precision decimal lib in C/C++.
It involves storing information in the n-ary roots of complex numbers,
in the form of Julia sets. The generating technique involves mapping
symbols to the roots of a Julia set during iteration. Here is a crude
example using decimal.js:

http://fractallife247.com/test/rifc_cipher/

For instance, my name is contained within the following complex number
using the default secret key:

real:
(-0.70928383564905214400492596591643890200098992164665980782966227733203960188288097070737389345985516069300117982413622497654113697)

imag:
(0.75006448767684071252250616852543657203512420946592887596427538863664520584158627985390890157772176873489867565028334553930789721)

I am doing this just for fun; to prove that data can be stored in an
escape time fractal. Fwiw, here is an impl in C++:

https://github.com/ChrisMThomasson/fractal_cipher/blob/master/RIFC/cpp/ct_rifc_sample.cpp

Fabian Russell wrote:

>Decimal floating point was standardized as IEEE758-2008 and new C types
>were defined: _Decimal128, _Decimal64, and _Decimal32.
>
>Gcc has many built-in functions (via libgcc) to handle decimal FP:
>
>https://gcc.gnu.org/onlinedocs/gccint/Decimal-float-library-routines.html
>
>However, what puzzles me is that C has not yet incorporated the decimal
>FP types so that the ordinary binary operators, such as "+ - * /" can operate
>directly on them. Rather, to add two _Decimal_64 values, x, y, for example,
>one must use the function __bid_adddd3(x, y) instead of x + y.
>
>Why bother to include the new types yet now allow them to be used
>arithmetically like all other standard numeric types?
>
>
>
Just F.Y.I. - the BID format is suggested by Intel for their processors,
the DPD format is used by IBM in their processors (z/Arch and Power.)
The various standards allow for either... if you dig down in that library
you can also find a function named __dpd_adddd3(x,y) for using the DPD
decimal floating-point format.

We implement those types/operations in the Dignus mainframe C compilers
and take advantage of the native hardware operations (for the DPD format.)

And, you can add two _Decimal64 values with just '+' (and the other
arithmetic operations as well as some I/O operations); it's part of the
suggested
(not yet adopted) standard.

- Dave Rivers -

--
rivers@dignus.com Work: (919) 676-0847
Get your mainframe programming tools at http://www.dignus.com

On 2021-09-11, Keith Thompson <Keith.S.Thompson+u@gmail.com> wrote:
> Kaz Kylheku <563-365-8930@kylheku.com> writes:
>> On 2021-09-10, Stefan Ram <ram@zedat.fu-berlin.de> wrote:
>>> Fabian Russell <fr314159@gmail.com> writes:
>>>>Why bother to include the new types yet now allow them to be used
>>>>arithmetically like all other standard numeric types?
>>>
>>> One would have to define many new rules for cases like
>>> "double + decimal" and so on. And these would have to be
>>
>> This cn be handled via, say, a general decimal contagion rule.
>> The double operand is converted to the best approximation in decimal
>> floating point, or undefined behavior if it is out of range. Then the
>> calculation proceeds as decimal <op> decimal.
>
> As I mentioned yesterday, the latest C23 draft includes (optional)
> decimal FP. It simply disallows mixing decimal and standard
> floating-point types as operands. N2596 6.3.1.8.
>
> It strikes me as a reasonable decision to require the programmer
> to decide (by using a cast) whether to perform the operation in
> standard or decimal floating-point.

It strikes me as prudent: it's the best way to delay making a decision
which can later be amended in a backward-compatible way.

If it turns out that promoting from decimal to double is preferred, then
that can just be blessed as not requiring a diagnostic. Compilers which
previously diagnosed it turn that into a warning and move on. Existing
code is unaffected.

It's reasonable from a safety POV also, but it's not in the "C spirit".
C is not Ada.

The C programmer expects implicit conversions. Denying them between two
flavors of floating-point won't save the language due to all the
existing ones. It's not a "good start" to anything that leads anywhere.

--
TXR Programming Language: http://nongnu.org/txr
Cygnal: Cygwin Native Application Library: http://kylheku.com/cygnal

On 9/11/2021 5:23 AM, James Kuyper wrote:
> On 9/10/21 3:04 PM, Scott Lurndal wrote:
>> James Kuyper <jameskuyper@alumni.caltech.edu> writes:
> ...
>>> Yes, but because they are not in the C standard, they're not C standard
>>> types, which means that the best place to ask questions about them is
>>> not this newsgroup.
>>
>> I disagree. This is comp.lang.c, not comp.lang.std.c.
>
> That doesn't change anything - you'll get better responses to a question
> about GnuC in a forum specific to GnuC, and you'll get better answers to
> a question about Visual C in a forum devoted to Visual C, you'll get
> better answers to questions about tcc are in a forum devoted to tcc,
> etc. The only questions where this is the best place to get an answer
> are questions that are not specific to any particular compiler - which
> is pretty much the same as standard C.
>

I am not going to make a lot of fuzz about this, however one
consideration seems relevant:

You keep saying "you'll get better answers...", now while this obviously
depends on topicality (although I don't agree entirely with your
definition of this newsgroup), it also depends on the activity of the
posters involved.
Considering that most of the Usenet is dead thanks to spammers, trolls,
and, last in order, migration to other platforms, while this newsgroup
is still somewhat active, this gives a better chance to get a good
answer here, where there is a fair number of competent people, rather
than from a group that might be more specific, but just inactive.

Obviously this doesn't mean that any question about programming should
land here, but a question about feasibility or use of numeric C types
(considerably more general than e.g. Gtk types) in the language doesn't
seem odd to me - better than kicking off anything that is not (yet) in
the standard; that doesn't seem helpful for the activity of the group,
to my opinion.
You might have seen that recently there was a thread on comp.lang.c++
about rational numbers, also not part of the C++ standard, but which
still led to some interesting follow-ups - again, better than kicking
the thing off as "not standard"

On 9/18/21 1:20 PM, Manfred wrote:
> On 9/11/2021 5:23 AM, James Kuyper wrote:
....
>> That doesn't change anything - you'll get better responses to a question
>> about GnuC in a forum specific to GnuC, and you'll get better answers to
>> a question about Visual C in a forum devoted to Visual C, you'll get
>> better answers to questions about tcc are in a forum devoted to tcc,
>> etc. The only questions where this is the best place to get an answer
>> are questions that are not specific to any particular compiler - which
>> is pretty much the same as standard C.
....
> You keep saying "you'll get better answers...", now while this obviously
> depends on topicality (although I don't agree entirely with your
> definition of this newsgroup), it also depends on the activity of the
> posters involved.
> Considering that most of the Usenet is dead thanks to spammers, trolls,
> and, last in order, migration to other platforms, while this newsgroup
> is still somewhat active, this gives a better chance to get a good
> answer here, where there is a fair number of competent people, rather
> than from a group that might be more specific, but just inactive.

I was very careful to say "forum", not "usenet newsgroup". If there is
any particular compiler or operating system for which comp.lang.c is the
best available forum for discussing it, then it is almost completely
dead - if it were still alive, there would be a currently active forum
somewhere that would be a better place than here to get answers about it.
Now, that allows for the possibility that there might be some zombie
systems for which that is actually true - but neither Visual C++, GnuC,
Windows, nor POSIX are zombies. I'm not so sure about tcc.