On 29/01/2024 06:38, Janis Papanagnou wrote:
> On 28.01.2024 20:10, David Brown wrote:

>>
>> Toys can be big, can't they? (Again, I can't answer for JP.)
>
> I'm not sure I'd have found a better reply of appropriate terseness.
>

Just to be clear - I did not say or intend to imply that I think the
program here is a "toy". I haven't commented on the program itself. I
/have/, in the past, referred to some programs or projects as "toys",
but I do that in context, and I might mean something different by the
word. All I was saying here is that having a large line count does not
in itself imply that a piece of code is not a "toy" - for whatever
meaning that term has.

(I really should have put a smiley on that comment, or even better,
stayed out of the disagreement entirely.)

On 29/01/2024 01:59, Paul Edwards wrote:
> On 29/01/24 00:01, David Brown wrote:
>
>> But if the original source is not available, or the means to compile (or
>> transpile) it is not available, then it's more "binary only" or
>> "abandonware" than C source.
>
> Yes, you can consider it to be "binary only",
> although that would be a too-harsh categorization,
> as I have indeed been able to make changes to
> the code to fix other issues.
>

That will depend on how close the transpiled C is to the original
source, and I have little idea about that.

>> I'm not saying this groups topicality is ideal for any particular
>> purpose.  I am not saying that others do not post off-topic.  I am not
>> saying the topicality of the group should not be changed.  I am just
>> saying that I thought the original post was off-topic, and that the OP
>> was more likely (not guaranteed, but more likely) to get help in a
>> different way.
>
> "more likely" based on what statistics or analysis?
>

None - it was based on my expectations and assumptions.

> I'm not aware of anywhere that can beat 24 hours.

That is a non sequitur. If I say "you are unlikely to roll 12 on two
dice - you are more likely to get 7", and you roll two dice getting a
double six on your first attempt, it does not mean that event was more
likely than getting a 7.

Note that you got help as a result of replies from Bart - replies that
you might well have got just the same if you had emailed him or
communicated through the project hosting site (if there had been one for
the tool). It is, of course, conceivable that he would not have
bothered replying to you by email - perhaps people saying your post was
off-topic is what prompted him to look at the issue and take it further.
That would be ironic!

>
>> It's not patronising.  It's giving what I hope is helpful advice.  Have
>> you never asked someone - online or in real life - for help, and been
>> told that they can't do much there, but you might get an answer over
>> there?
>
> You haven't provided an "over there" that has a
> snowball's chance in hell of producing a solution
> in 24 hours.
>

Then you have a challenge to build up more of a community "over there".
(Though as I noted above, the "over there" I suggested included emailing
Bart, who was the one that found the issue, or at least turned it into
something others could help with.)

I see there has been some other discussions about possibly expanding the
scope of what is on-topic in c.l.c. I personally am not adverse to
that. I would not mind at all if discussions of particular C compilers
was considered topical. I think there's plenty that could be said about
commonly used tools that could be of benefit to many people here, and
occasional discussions about niche tools could be interesting even if
they are of no practical use to most people.

I still think even then that something that is communication between two
people is usually best by email unless there is good reason to suspect
that others will want to listen in. And I still think your public
domain project would do better by having as much discussion as possible
within that group, making it a livelier environment that can grow.
Niche groups need care and nurture - even if you are confident that
you'll get faster answers elsewhere, it can still be better for the
growth of that group if you discuss the issue there first.

>> I certainly didn't tell him to go away.  I told him that we can try and
>> help with C issues, but it's unlikely that this is the best place to
>> help with build issues for some large lump of C code.
>
> Unlikely based on what analysis or statistics?
>
> And your prediction was totally incorrect regardless.
> This is a proven good place.
>
> Partly because Bart hangs out here of course.
>
> Because you're hitting something different now.
>
> A public post saying "can anyone help" is very
> different from harassing a specific individual
> (who you haven't paid either) who has told you
> "I'm not interested in this software - don't
> come to me for support" (or words to that effect).

True.

>
> I haven't violated that wish. I posted in public,
> not email. Unless you want to quibble that I
> shouldn't have mentioned his name at all in the
> public post.

Well, the post /was/ addressed to him - in thread title and greeting.

But you have a fair point here, and it is absolutely a reasonable
consideration.

>
> I consider I did the right thing. And I got the
> result I wanted.
>
> And now maybe you have a result that is useful
> to you (or someone you know, or at a future
> workplace) - you can write a Win64 utility and
> if you do it a certain way, you can run it on
> Linux with ridiculously small overhead.
>

That may be of use to some people, yes.

On 29/01/2024 01:35, Paul Edwards wrote:
> On 28/01/24 21:05, David Brown wrote:
>
>> The BCC compiler is not written in C - it is, AFAIUI, written in Bart's
>> own language.  (gcc was, at that time, written in C.)
>>
>> This is a C /discussion/ group, not a support group.  It is primarily
>> for discussing the C language, standards, and standard library, and for
>> discussing bits of C code.  We don't support compilers or C software. We
>> might try to help if it is tools we are familiar with, but we are not a
>> support group.  The primary support forum for gcc is the "gcc-help"
>> mailing list.  I don't know where the primary support forum is for BCC,
>> but it is not here.
>
> I'm not sure this is considered to be "bcc".
>
> BCC was actually on github or something. The
> code that I am using was only temporarily
> placed somewhere so that I could download it.
>
> Again - if anyone supports this code, it's me.
>
> I can report a problem - to myself.
>
> I already did that. And it was beyond my ability
> to solve in a reasonable timeframe so I tried my
> luck here, and got exactly what I needed within
> 24 hours flat.
>
> This is quite literally the best support forum
> for this (unnamed software) that I am aware of.

That may be true. But it is still not a support forum for software like
that. It is entirely possible that this group contains some of the best
COBOL programmers around - but it would be inappropriate to post COBOL
questions here. It could be that this group would be able to provide
better support for thousands of old C projects than any other forum -
but it is still not a support forum for that software. If everyone with
a program written in C, or an issue trying to compile and build a
program written in C, were to post here - what do you think would
happen? Perhaps to start with there would be helpful answers on
difficulties with make, autotools, MSVC, and whatever else. But then
the regulars would start getting fed up - the group would lose its
appeal to them, and they'd move elsewhere. No one would get any better
answers than they'd find from other web-based forums, and the group
would be ruined for the people that are here, now.

As I have said, I am not adverse to viewing posts like yours as
on-topic, or more actively changing what is seen as topical. But
changes to topicality in a group must be done carefully. That this is
the best place to get answers to a particular type of question is /not/
a reason to consider the post on-topic, or to say that posting it here
was the right thing for the group. It might have been the right thing
for /you/, at least in the short term - but maybe if you make lots of
off-topic posts, people will stop answering you. Your post was
successful from your viewpoint, but perhaps not from the group's viewpoint.

(Perhaps the ensuing discussion of topicality /will/ be good for the
group. That remains to be seen.)

>
>> None of this means you can't make off-topic posts - there is nothing to
>> stop you doing so.  But you should be aware about what is on-topic and
>> what is not, and how you can make your posts closer to topical, and
>> better suited to getting help.  For example, instead of posting a pile
>> of compiler error messages, you could have looked at the code and tried
>> to see what C code in "cc32n.c" was the cause of the problem.
>
> I had already looked at it. But I wasn't even sure
> I was expecting a result I shouldn't be expecting.
> I knew what cc64.c did, but this was the first
> at least recent attempt at running cc32n.c.
>
>> Isolate
>> an example, add the minimum required typedefs and surrounding code to
>> get something that is comprehensible to any C programmer.  Try it with
>> different compilers - <https://godbolt.org> is perfect for this.  Then
>> you'd have something that is on-topic, and which people can answer.
>
> I already did try with different compilers which
> is why I started wondering whether I had incorrect
> expectations from the software.

A small example section would have been much more helpful to people here
than the build messages.

>
>>> You're about as unlikely to change my mind
>>> about that as vice-versa.
>>
>> I'm hoping to help you help yourself.
>
> I am already doing that.
>
>>> There are a handful of people who are interested
>>> in public domain software. I can give some names
>>> if that is of any relevance (if you tell me what
>>> the relevance is first - like - what action will
>>> you take when I give you the first name).
>>
>> No need for names, of course.  I am just trying to get an idea if there
>> are actually other people involved in this.  And if so, then details of
>> your tools and work on outdated compilers, outdated computers, and
>> outdated languages would be best handled in a group who are interested
>> in that.  You'd be helping them, and they would be helping you.  Surely
>> that would be a good thing?
>
> It's a question of technical expertise. In
> that circle, I'm the one most likely to be
> able to solve the problem.
>

Even then, talking about it in the group makes people feel included and
keeps them informed that you are working on such issues. (Perhaps I am
concerning myself too much here, and you already have enough lively
discussions in that group.)

>>> So the announcement is that you can have a
>>> reasonable C90-compliant public domain
>>> compiler that runs on a 32-bit system (I am
>>> using Windows 2000 but you can also use
>>> PDOS/386). It produces 64-bit code though.
>>> Using the Microsoft calling convention.
>>
>> I don't see anything against making such an announcement in this group,
>> but you can expect that no one will care (and that people will tell you
>> they don't care).
>
> That's all fine by me.
>
>> There will not be many people for whom this is
>> remotely relevant or interesting - that's why you should work with your
>> community of people who /have/ expressed an interest.
>
> The bottleneck is technical expertise, not interest.
>

OK.

>>> However, also an hour ago (here's the next
>>> announcement), you can run (certain) 64-bit PE
>>> Win64 executables (that are dependent on
>>> msvcrt.dll) on Linux - even though Linux uses
>>> a different function call convention.
>>
>> Hasn't wine supported this for a decade or two?
>
> Theoretically yes. I tried installing it on a
> few different Linux machines and after doing
> massive downloads, it didn't work. And any
> issue in it would probably take months of
> effort trying to understand (or even build
> the code from source).
>

I've always installed wine with "apt-get install wine", or with Steam.
I can't say I have had to run many Windows programs on Linux (I also
have an old Windows machine at the office), but it has not been an issue
for me. But I guess experiences vary.

> As of an hour or so ago, you can now get a
> 103k executable that does that (limited, but
> what I need) task. It's UCX64L from the UCARM
> section (as opposed to UCX64 from the UCX64
> section) at http://pdos.org .
>
>>> So - in the case of Macbeth - if EVERYONE owned
>>> it (as opposed to NOONE owning it - as you say
>>> the definition of public domain is), then what
>>> exactly would that mean?
>>
>> Everyone would be entitled to a share of any royalties when the play was
>> performed.
>
> Everyone effectively can do that. The
> government in your country can effectively
> get royalties from the play and distribute
> them according to the democratic wishes of
> the people who own it.
>
> But regardless, yes, I see why you prefer
> the term unowned.

OK. And I also see what you are trying to do with your public domain
software. (That doesn't mean I agree that it's a useful endeavour, but
there's nothing wrong with having different philosophies.) So now
that's all cleared up, we can leave that off-topic discussion!

>
>> with international law experience.  An alternative, that is not absurdly
>> expensive, would be to look at things like the Creative Commons CCO
>> license as a way of getting the effect you want.)
>
> I already do mention you can follow CC0 if
> you wish and provide a link.
>
> BFN. Paul.
>

Paul Edwards <mutazilah@gmail.com> writes:

[..is the code in cc32n.c topical?..]

> I have a different opinion about whether a
> C compiler written in C is on-topic in a C
> support forum.

Any program written in C, whether or not it's a compiler, is
topical in comp.lang.c.

Unfortunately neither cc32n.c nor cc64.c is written in C. Rather
they are written in a language that resembles C, and may even be
compilable by some "C" compilers in a non-conforming mode, but
they are not written in standard C.

If you want help with one of these programs, and want to get it
in this newsgroup, get the code to compile under, for example,
gcc -std=c99 -pedantic-errors or gcc -std=c11 -pedantic-errors.
Until that is done people are quite right to tell you to look
for help elsewhere.

Moreover, the code in these programs is a disaster. No sensible
person would spend any time on it if they have a choice. If you
want to waste your time on it, that's up to you. I don't see any
incentive for anyone else to spend any time on it at all, except
perhaps as a learning exercise to see how truly awful bad code
can be. It's easy to believe no one wants to take credit for
this mess.

On 2024-01-28, Paul Edwards <mutazilah@gmail.com> wrote:
> I have a different opinion about whether a
> C compiler written in C is on-topic in a C
> support forum.

Say, would you be okay if all the traffic from the GCC mailing lists and
the Clang discourse forum were copies to comp.lang.c?

https://discourse.llvm.org/c/clang/6

https://gcc.gnu.org/lists.html

Why or why not? Which gcc mailing lists would you gateway here?
gcc-help? gcc-bugs? gcc? gcc-patches? All of them?

None of us here have open source projects; you're special!

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

In article <20240129171130.110@kylheku.com>,
Kaz Kylheku <433-929-6894@kylheku.com> wrote:
>On 2024-01-28, Paul Edwards <mutazilah@gmail.com> wrote:
>> I have a different opinion about whether a
>> C compiler written in C is on-topic in a C
>> support forum.
>
>Say, would you be okay if all the traffic from the GCC mailing lists and
>the Clang discourse forum were copies to comp.lang.c?

Davy (and others, both presently, and going back through the years) have
made it abundantly clear that "stuff I like" is on-topic, and stuff I don't
isn't.

Very subjective, that.

--
https://en.wiktionary.org/wiki/res_ipsa_loquitur

On 30/01/2024 00:41, Tim Rentsch wrote:
> Paul Edwards <mutazilah@gmail.com> writes:
>
> [..is the code in cc32n.c topical?..]
>
>> I have a different opinion about whether a
>> C compiler written in C is on-topic in a C
>> support forum.
>
> Any program written in C, whether or not it's a compiler, is
> topical in comp.lang.c.
>
> Unfortunately neither cc32n.c nor cc64.c is written in C. Rather
> they are written in a language that resembles C, and may even be
> compilable by some "C" compilers in a non-conforming mode, but
> they are not written in standard C.
>
> If you want help with one of these programs, and want to get it
> in this newsgroup, get the code to compile under, for example,
> gcc -std=c99 -pedantic-errors or gcc -std=c11 -pedantic-errors.
> Until that is done people are quite right to tell you to look
> for help elsewhere.

I tried those options on these programs, which all failed:

- Tiny C source code (0.9.27)

- Some modules of Lua 5.4 interpreter

- Pico C (C interpreter)

- piet.c (interpreter)

However, who are YOU to tell ME what options to use when compiling my C
code?

One thing I've learned here is that /I/ get to stipulate how my programs
are compiled. Do you routinely get inside the makefiles that you come
across and add your own options?

On 30/01/2024 01:42, bart wrote:
> On 30/01/2024 00:41, Tim Rentsch wrote:
>> Paul Edwards <mutazilah@gmail.com> writes:
>>
>> [..is the code in cc32n.c topical?..]
>>
>>> I have a different opinion about whether a
>>> C compiler written in C is on-topic in a C
>>> support forum.
>>
>> Any program written in C, whether or not it's a compiler, is
>> topical in comp.lang.c.
>>
>> Unfortunately neither cc32n.c nor cc64.c is written in C.  Rather
>> they are written in a language that resembles C, and may even be
>> compilable by some "C" compilers in a non-conforming mode, but
>> they are not written in standard C.
>>
>> If you want help with one of these programs, and want to get it
>> in this newsgroup, get the code to compile under, for example,
>> gcc -std=c99 -pedantic-errors or gcc -std=c11 -pedantic-errors.
>> Until that is done people are quite right to tell you to look
>> for help elsewhere.
>
>
> I tried those options on these programs, which all failed:
>
> - Tiny C source code (0.9.27)
>
> - Some modules of Lua 5.4 interpreter
>
> - Pico C (C interpreter)
>
> - piet.c (interpreter)
>
> However, who are YOU to tell ME what options to use when compiling my C
> code?
>
> One thing I've learned here is that /I/ get to stipulate how my programs
> are compiled. Do you routinely get inside the makefiles that you come
> across and add your own options?
>
You see I don't get to stipulate that.

We have a deployment system so that a programmer can quickly make a
change to a program, get the changes signed off, then push it through
the pipeline to create a release for the customer.
Now I suppose I could say "My programs are special. They need all sorts
of extra flags and settings." And if I insisted hard enough maybe they
would have to agree. But it would make everything that bit more
difficult. And it's far easier to write all the programs so that they
compile with standard settings.

--
Check out Basic Algorithms and my other books:
https://www.lulu.com/spotlight/bgy1mm

bart <bc@freeuk.com> writes:

> On 30/01/2024 00:41, Tim Rentsch wrote:
>
>> Paul Edwards <mutazilah@gmail.com> writes:
>>
>> [..is the code in cc32n.c topical?..]
>>
>>> I have a different opinion about whether a
>>> C compiler written in C is on-topic in a C
>>> support forum.
>>
>> Any program written in C, whether or not it's a compiler, is
>> topical in comp.lang.c.
>>
>> Unfortunately neither cc32n.c nor cc64.c is written in C. Rather
>> they are written in a language that resembles C, and may even be
>> compilable by some "C" compilers in a non-conforming mode, but
>> they are not written in standard C.
>>
>> If you want help with one of these programs, and want to get it
>> in this newsgroup, get the code to compile under, for example,
>> gcc -std=c99 -pedantic-errors or gcc -std=c11 -pedantic-errors.
>> Until that is done people are quite right to tell you to look
>> for help elsewhere.
>
> I tried those options on these programs, which all failed:
> [...]
>
> However, who are YOU to tell ME what options to use when compiling
> my C code?

I'm not telling anyone how to compile their programs. All I'm
doing is giving a way of checking whether a program is C code or
is written in a language that may look like C but isn't. Knowing
how to do that is something I could have benefited from - many
years ago I wrote some code that I thought was being written in
C, but later I discovered that it wasn't. I started programming
in C long before there was a C standard, and didn't realize the
degree to which different compilers had different ideas of what
"C" was. As of this year we are celebrating the 35th anniversary
of the original C standard, and the 25th anniversary of C99, so I
think it's reasonable to expect that people participating in the
newsgroup here at least know how to tell if some code they are
working on is written in C or it isn't.

On 30/01/2024 02:28, Kenny McCormack wrote:
> In article <20240129171130.110@kylheku.com>,
> Kaz Kylheku <433-929-6894@kylheku.com> wrote:
>> On 2024-01-28, Paul Edwards <mutazilah@gmail.com> wrote:
>>> I have a different opinion about whether a
>>> C compiler written in C is on-topic in a C
>>> support forum.
>>
>> Say, would you be okay if all the traffic from the GCC mailing lists and
>> the Clang discourse forum were copies to comp.lang.c?
>
> Davy (and others, both presently, and going back through the years) have
> made it abundantly clear that "stuff I like" is on-topic, and stuff I don't
> isn't.
>
> Very subjective, that.
>

I am assuming, perhaps incorrectly, that you are referring to me. My
name is "David". Not "Davy", "Dave", or any other abbreviation. You
are free to disagree with any of my opinions, or the way I express them,
but please at least get my name right - it's hardly a difficult task.

If you want to share your thoughts about topicality, that's great.
Rational arguments and justification would be preferable, but purely
personal preferences are fine too. But if you just want to stir up
annoyance, please don't.

On 30/01/2024 06:31, Tim Rentsch wrote:
> bart <bc@freeuk.com> writes:
>
>> On 30/01/2024 00:41, Tim Rentsch wrote:
>>
>>> Paul Edwards <mutazilah@gmail.com> writes:
>>>
>>> [..is the code in cc32n.c topical?..]
>>>
>>>> I have a different opinion about whether a
>>>> C compiler written in C is on-topic in a C
>>>> support forum.
>>>
>>> Any program written in C, whether or not it's a compiler, is
>>> topical in comp.lang.c.
>>>
>>> Unfortunately neither cc32n.c nor cc64.c is written in C. Rather
>>> they are written in a language that resembles C, and may even be
>>> compilable by some "C" compilers in a non-conforming mode, but
>>> they are not written in standard C.
>>>
>>> If you want help with one of these programs, and want to get it
>>> in this newsgroup, get the code to compile under, for example,
>>> gcc -std=c99 -pedantic-errors or gcc -std=c11 -pedantic-errors.
>>> Until that is done people are quite right to tell you to look
>>> for help elsewhere.
>>
>> I tried those options on these programs, which all failed:
>> [...]
>>
>> However, who are YOU to tell ME what options to use when compiling
>> my C code?
>
> I'm not telling anyone how to compile their programs. All I'm
> doing is giving a way of checking whether a program is C code or
> is written in a language that may look like C but isn't. Knowing
> how to do that is something I could have benefited from - many
> years ago I wrote some code that I thought was being written in
> C, but later I discovered that it wasn't. I started programming
> in C long before there was a C standard, and didn't realize the
> degree to which different compilers had different ideas of what
> "C" was. As of this year we are celebrating the 35th anniversary
> of the original C standard, and the 25th anniversary of C99, so I
> think it's reasonable to expect that people participating in the
> newsgroup here at least know how to tell if some code they are
> working on is written in C or it isn't.

This program was machine generated. The way that is done now is a little
different (for example it doesn't use standard C headers).

If I apply -std=c11 -pedantic-errors, it fails on only 3 kinds of error:

* String literals longer than 4095 characters

* Initialising a void* value with the address of function

* Casting an object pointer to a function pointer

I consider the first genuinely pedantic (I've only seen one compiler
with an actual limit for string literals, that was a 16K limit on MSVC,
a decade ago).

Those others are complaining about converting one kind of 64-bit pointer
to another kind of 64-bit pointer. A conversion which, weirdly, would be
considered fine if it want through an intermediate 64-bit integer type.

The options I stipulate for compiling with gcc on Windows are:

-m64 when not already the default (a 64-bit pointer size
is hard-coded)

-Wbuiltin-declaration-mismatch

This is requested within the source via a #pragma

On Linux (where a slightly different C file is needed as some
OS-dependent routines are differently), they are:

-m64

-fno-builtin

-lm -ldl

Where the C compiler is invoked by the transpiler, the necessary options
(plus -O3 if requested to be optimised) are applied automatically. The
process of using intermediate C can be transparent.

On 2024-01-30, bart <bc@freeuk.com> wrote:
> Those others are complaining about converting one kind of 64-bit pointer
> to another kind of 64-bit pointer. A conversion which, weirdly, would be
> considered fine if it want through an intermediate 64-bit integer type.

All these conversions are fine in that implementation.

Someone using the pedantic warning wants to be informed about some
exotic portability issues; would the code be other than fine on certain
implementations.

In an implementation in which you cannot convert between object and
function pointers (or not in both ways), the detour through integers
also won't be fine!

See?

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

bart <bc@freeuk.com> writes:

> On 30/01/2024 06:31, Tim Rentsch wrote:

[...]

>> I'm not telling anyone how to compile their programs. All I'm
>> doing is giving a way of checking whether a program is C code or
>> is written in a language that may look like C but isn't. Knowing
>> how to do that is something I could have benefited from - many
>> years ago I wrote some code that I thought was being written in
>> C, but later I discovered that it wasn't. I started programming
>> in C long before there was a C standard, and didn't realize the
>> degree to which different compilers had different ideas of what
>> "C" was. As of this year we are celebrating the 35th anniversary
>> of the original C standard, and the 25th anniversary of C99, so I
>> think it's reasonable to expect that people participating in the
>> newsgroup here at least know how to tell if some code they are
>> working on is written in C or it isn't.
>
> This program was machine generated. The way that is done now is a
> little different (for example it doesn't use standard C headers).
>
> If I apply -std=c11 -pedantic-errors, it fails on only 3 kinds of
> error:
>
> * String literals longer than 4095 characters
>
> * Initialising a void* value with the address of function
>
> * Casting an object pointer to a function pointer

If the .c file is program generated, it should be easy to fix.
So fix it.

(1) Presumably the generator knows which pointers are function
pointers and which are not. Use a generic function type for
storing function pointers rather than trying to force everything
through void*.

(2) Rather than use long string literals, store and initialize
the variables involved (it looks like there are only two) as
character arrays. It looks ugly but hey it's program generated
code anyway. I tried writing a simple convertor using awk and it
took maybe 10 or 15 minutes.

Speaking of program generated source, C code that is program
generated is definitely a second class citizen as far as the
newsgroup is concerned. It's like saying a .o file is written in
assembly. It isn't. Generated C source may clear the hurdle of
being compilable but they can't usefully be worked on in that
form and are generally incomprehensible to humans. It's fair
game to ask about how to make generated source be legal C, but
describing programs like this as "written in C" is hokum. Such
programs are useless as C code in any practical sense of the term
and thus are not suitable for discussion in comp.lang.c.

In article <86a5omat4q.fsf@linuxsc.com>,
Tim Rentsch <tr.17687@z991.linuxsc.com> wrote:
....
>Speaking of program generated source, C code that is program
>generated is definitely a second class citizen as far as the
>newsgroup is concerned. It's like saying a .o file is written in
>assembly. It isn't. Generated C source may clear the hurdle of
>being compilable but they can't usefully be worked on in that
>form and are generally incomprehensible to humans. It's fair
>game to ask about how to make generated source be legal C, but
>describing programs like this as "written in C" is hokum. Such
>programs are useless as C code in any practical sense of the term
>and thus are not suitable for discussion in comp.lang.c.

Keep in mind that, as I've shown many times over the years, nothing is
actually on topic in CLC.

--
Genesis 2:7 And the LORD God formed man of the dust of the ground, and
breathed into his nostrils the breath of life; and man became a living soul.

gazelle@shell.xmission.com (Kenny McCormack) writes:

> In article <86a5omat4q.fsf@linuxsc.com>,
> Tim Rentsch <tr.17687@z991.linuxsc.com> wrote:
> ...
>
>> Speaking of program generated source, C code that is program
>> generated is definitely a second class citizen as far as the
>> newsgroup is concerned. It's like saying a .o file is written in
>> assembly. It isn't. Generated C source may clear the hurdle of
>> being compilable but they can't usefully be worked on in that
>> form and are generally incomprehensible to humans. It's fair
>> game to ask about how to make generated source be legal C, but
>> describing programs like this as "written in C" is hokum. Such
>> programs are useless as C code in any practical sense of the term
>> and thus are not suitable for discussion in comp.lang.c.
>
> Keep in mind that, as I've shown many times over the years, nothing is
> actually on topic in CLC.

What you have most often shown is that the group would benefit from
you departing the group and never returning, and lose nothing in
return. Also that you take delight in being an asshole.