Hi Bart (or anyone else interested)

(and hopefully this doesn't start a 3 month
long thread about ... what?)

You posted a flavor of cc64.c called cc32n.c,
which is available from http://pdos.org/cc32n.c

My understanding is that this can be compiled
with 32-bit gcc and produce a 32-bit executable
that produces 64-bit code.

The instructions say to compile with gcc or tcc.
I tried with gcc 3.2 from cygwin. I also tried
using visual studio 2005.

Note that I'm running on Windows 2000 (under
Virtualbox under KylinOS).

cygwin of that vintage (or at least the components
I installed) doesn't have stdint.h, but I have my own.

D:\devel\pdos\cc64>gcc --version
gcc (GCC) 3.2 20020927 (prerelease)
Copyright (C) 2002 Free Software Foundation, Inc.
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

D:\devel\pdos\cc64>gcc -I. -D__NOCWINTTYPES cc32n.c
cc32n.c: In function `mlib_checkfreelists':
cc32n.c:10243: warning: decimal constant is so large that it is unsigned
cc32n.c: In function `cc_lex_readhex':
cc32n.c:13173: warning: decimal constant is so large that it is unsigned
cc32n.c: In function `cc_lex_readdecimal':
cc32n.c:13423: warning: decimal constant is so large that it is unsigned
cc32n.c: In function `cc_lex_setnumberoffset':
cc32n.c:15385: warning: decimal constant is so large that it is unsigned
cc32n.c: In function `cc_parse_createnegop':
cc32n.c:19900: warning: decimal constant is so large that it is unsigned
cc32n.c: In function `cc_parse_eval_convert':
cc32n.c:20420: warning: decimal constant is so large that it is unsigned
cc32n.c: In function `cc_genasm_do_and':
cc32n.c:26616: warning: decimal constant is so large that it is unsigned
cc32n.c: In function `cc_genasm_do_or':
cc32n.c:26628: warning: decimal constant is so large that it is unsigned
cc32n.c: In function `cc_genasm_do_xor':
cc32n.c:26640: warning: decimal constant is so large that it is unsigned
cc32n.c: In function `cc_genasm_convertimm':
cc32n.c:27135: warning: decimal constant is so large that it is unsigned
cc32n.c:27145: warning: decimal constant is so large that it is unsigned
cc32n.c: In function `ax_genss_isdwordsized':
cc32n.c:31450: warning: decimal constant is so large that it is unsigned
cc32n.c: In function `ax_genss_do_arith':
cc32n.c:31772: warning: decimal constant is so large that it is unsigned
cc32n.c:31772: warning: decimal constant is so large that it is unsigned
cc32n.c: In function `ax_genss_do_mov':
cc32n.c:31863: warning: decimal constant is so large that it is unsigned
cc32n.c:31886: warning: decimal constant is so large that it is unsigned
cc32n.c:31940: warning: decimal constant is so large that it is unsigned
cc32n.c: In function `ax_writeexe_writesectionheader':
cc32n.c:33685: warning: decimal constant is so large that it is unsigned
cc32n.c:33688: warning: decimal constant is so large that it is unsigned
cc32n.c:33694: warning: decimal constant is so large that it is unsigned
cc32n.c: In function `ax_writeobj_writecoff':
cc32n.c:35811: warning: decimal constant is so large that it is unsigned
cc32n.c:35818: warning: decimal constant is so large that it is unsigned

D:\devel\pdos\cc64>

D:\devel\pdos\cc64>type world.c
int printf(char *x, ...);
int main(void)
{ printf("hello, world\n");
return 0;
}

D:\devel\pdos\cc64>a -c world.c
Compiling world.c to world.obj
0 00000000
SS code gen error: 1:exceeding word32 value
On line: 11

D:\devel\pdos\cc64>

Am I doing something wrong?

Note that although Kylin OS is 64-bit and
has 64-bit gcc, Windows 2000 is not. So I
am hoping to produce a 64-bit PE executable
that takes the MSABI registers and then
(using custom assembler) puts them into
appropriate registers to do a Linux syscall
(no libraries, including glibc, are ever
used). And use objcopy to convert from PE to ELF.

This will give me a pseudo-bios (suitable for
putting into an APK (see PdAndro at pdos.org)
or running directly from Linux x64), which can
then handle either pdos-generic executables, or
64-bit msvcrt.dll-based executables (similar
to UCX64).

Note that the 32-bit x86 executable in UC386L
is already capable of running those limited
win32 executables.

Thanks. Paul.

On 26.01.2024 11:16, Paul Edwards wrote:
> Hi Bart (or anyone else interested)
>
> (and hopefully this doesn't start a 3 month
> long thread about ... what?)

Looks like a support question for a piece of proprietary code.

Why don't you contact the author or issue a bug report?

On 26/01/24 18:53, Janis Papanagnou wrote:
> On 26.01.2024 11:16, Paul Edwards wrote:
>> Hi Bart (or anyone else interested)
>>
>> (and hopefully this doesn't start a 3 month
>> long thread about ... what?)
>
> Looks like a support question for a piece of proprietary code.

It's as far from proprietary as possible - it's
public domain. Without the hassle of having to
wait for the author to die and then waiting
another 70 years for him to properly decompose.

> Why don't you contact the author or issue a bug report?

It's public domain. You're the owner as much as
anyone else. And if you think it's a bug, then
I've just given you a bug report.

BFN. Paul.

On 26/01/2024 10:16, Paul Edwards wrote:
> Hi Bart (or anyone else interested)
>
> (and hopefully this doesn't start a 3 month
> long thread about ... what?)
>
>
> You posted a flavor of cc64.c called cc32n.c,
> which is available from http://pdos.org/cc32n.c
>
> My understanding is that this can be compiled
> with 32-bit gcc and produce a 32-bit executable
> that produces 64-bit code.
>
> The instructions say to compile with gcc or tcc.
> I tried with gcc 3.2 from cygwin. I also tried
> using visual studio 2005.

This must be a pretty old program, as I haven't supported a 32-bit C
target for years.

I can't remember how much testing I did on it. At the moment, my gcc
(13.2.0) can compile it but can't link a 32-bit program.

Only TCC can produce an executable. Both gcc and tcc need the -m32
option as the versions I have default to 64 bits. Neither show those
warnings.

But when I produce c32.exe, that crashes compiling hello.c using -E, -S,
-c or -exe (-exe is not viable anyway, as this 32-bit c32.exe needs to
load a 64-bit msvcrt.dll).

It does however build your minimal program:

c:\cx>c32 -c world
Compiling world.c to world.obj

c:\cx>gcc world.obj

c:\cx>a
hello, world

I don't get the error about '0' exceeding some bounds.

Note that world.obj contains 64-bit code and gcc turns it into a 64-bit
program.

I wouldn't really trust this version at all. Those 32-bit pointer fields
in those structs, with or without 'pack(1)', look a little dubious.

If you like, I can spend an hour or two working with this C code trying
to find the cause of the crashing, but when it's built with my 'tcc -m32'.

Your gcc 3.2 appears to produce different behaviour. I can't test with
that unless you can make that available somehow. But I expect that gcc
3.2 is not a single EXE like the stuff I do, so that is not so easy.

On 26/01/2024 10:57, Paul Edwards wrote:
> On 26/01/24 18:53, Janis Papanagnou wrote:
>> On 26.01.2024 11:16, Paul Edwards wrote:
>>> Hi Bart (or anyone else interested)
>>>
>>> (and hopefully this doesn't start a 3 month
>>> long thread about ... what?)
>>
>> Looks like a support question for a piece of proprietary code.
>
> It's as far from proprietary as possible - it's
> public domain. Without the hassle of having to
> wait for the author to die and then waiting
> another 70 years for him to properly decompose.
>
>> Why don't you contact the author or issue a bug report?
>
> It's public domain. You're the owner as much as
> anyone else. And if you think it's a bug, then
> I've just given you a bug report.

JP and I had an argument so he (I assume) has it in for me.

On 26/01/24 19:04, bart wrote:
> On 26/01/2024 10:16, Paul Edwards wrote:

Hi Bart.

I'm expecting to do 3 separate replies to
this message, as I gather/digest the required
information.

Here's the first bit:

> Your gcc 3.2 appears to produce different behaviour. I can't test with
> that unless you can make that available somehow. But I expect that gcc
> 3.2 is not a single EXE like the stuff I do, so that is not so easy.

I have gcc 3.2.3 as a single executable, so
I'll get back to you later on that.

In the meantime, I can make gcc 3.2 available:

This is what I did (uncompress in order)

# with manual install from 4 individual packages
# (cygwin, binutils, gcc, w32api - in that order,
# with overwrite).

# The (old) cygwin packages used to build this were obtained from:
# #
https://web.archive.org/web/20030216221913/http://mirrors.rcn.com/pub/sourceware/cygwin/release/cygwin/cygwin-1.3.20-1.tar.bz2
#
https://web.archive.org/web/20030405055233/http://mirrors.rcn.com/pub/sourceware/cygwin/release/cygwin/cygwin-1.3.20-1-src.tar.bz2

#
#
https://web.archive.org/web/20030216230006/http://mirrors.rcn.com/pub/sourceware/cygwin/release/binutils/binutils-20021117-1.tar.bz2
#
https://web.archive.org/web/20030216230006/http://mirrors.rcn.com/pub/sourceware/cygwin/release/binutils/binutils-20021117-1-src.tar.bz2
# #
https://web.archive.org/web/20030330170119/http://mirrors.rcn.com/pub/sourceware/cygwin/release/gcc/gcc-3.2-3.tar.bz2
#
https://web.archive.org/web/20030405070436/http://mirrors.rcn.com/pub/sourceware/cygwin/release/gcc/gcc-3.2-3-src.tar.bz2
# #
https://web.archive.org/web/20040223120154/http://cygwin.get-software.com/release/w32api/w32api-2.2-1.tar.bz2
#
https://web.archive.org/web/20040204103925/http://cygwin.get-software.com/release/w32api/w32api-2.2-1-src.tar.bz2

On 26/01/24 19:04, bart wrote:
> On 26/01/2024 10:16, Paul Edwards wrote:

> Your gcc 3.2 appears to produce different behaviour. I can't test with
> that unless you can make that available somehow. But I expect that gcc
> 3.2 is not a single EXE like the stuff I do, so that is not so easy.

I have uploaded a http://pdos.org/bart.zip

It's about 5 MB in size and has a snapshot of
my development environment.

If you go to pdos\cc64 you will find a makefile.hybrid

Also there is a single gccwin.exe for the compiler.

Maybe when you talked about "single executable"
you mean "embedded assembler and linker". I thought
you meant "no DLLs", so I thought I could provide
that (there is no DLL unless you count the reference
to msvcrt.dll).

This cc32n.c is slightly changed as I needed to
comment out the non-C90 includes present in the original.

Regardless, this is a switch from cygwin gcc 3.2
to my own build of a slightly modified gcc 3.2.3,
with gcc 3.2.3 being a single executable.

makefile.hybrid also calls cygwin gcc to do the
link, as it is more convenient.

D:\devel\pdos\cc64>pdmake -f makefile.hybrid
gccwin -S -fno-common -DBLDGENERIC -D__WIN32__ -D__CC64__ -I . -I
.../pdpclib -o cc32n.s cc32n.c
cc32n.c: In function `mlib_checkfreelists':
cc32n.c:10243: warning: decimal constant is so large that it is unsigned
cc32n.c: In function `cc_lex_readhex':
cc32n.c:13173: warning: decimal constant is so large that it is unsigned
cc32n.c: In function `cc_lex_readdecimal':
cc32n.c:13423: warning: decimal constant is so large that it is unsigned
cc32n.c: In function `cc_lex_setnumberoffset':
cc32n.c:15385: warning: decimal constant is so large that it is unsigned
cc32n.c: In function `cc_parse_createnegop':
cc32n.c:19900: warning: decimal constant is so large that it is unsigned
cc32n.c: In function `cc_parse_eval_convert':
cc32n.c:20420: warning: decimal constant is so large that it is unsigned
cc32n.c: In function `cc_genasm_do_and':
cc32n.c:26616: warning: decimal constant is so large that it is unsigned
cc32n.c: In function `cc_genasm_do_or':
cc32n.c:26628: warning: decimal constant is so large that it is unsigned
cc32n.c: In function `cc_genasm_do_xor':
cc32n.c:26640: warning: decimal constant is so large that it is unsigned
cc32n.c: In function `cc_genasm_convertimm':
cc32n.c:27135: warning: decimal constant is so large that it is unsigned
cc32n.c:27145: warning: decimal constant is so large that it is unsigned
cc32n.c: In function `ax_genss_isdwordsized':
cc32n.c:31450: warning: decimal constant is so large that it is unsigned
cc32n.c: In function `ax_genss_do_arith':
cc32n.c:31772: warning: decimal constant is so large that it is unsigned
cc32n.c:31772: warning: decimal constant is so large that it is unsigned
cc32n.c: In function `ax_genss_do_mov':
cc32n.c:31863: warning: decimal constant is so large that it is unsigned
cc32n.c:31886: warning: decimal constant is so large that it is unsigned
cc32n.c:31940: warning: decimal constant is so large that it is unsigned
cc32n.c: In function `ax_writeexe_writesectionheader':
cc32n.c:33685: warning: decimal constant is so large that it is unsigned
cc32n.c:33688: warning: decimal constant is so large that it is unsigned
cc32n.c:33694: warning: decimal constant is so large that it is unsigned
cc32n.c: In function `ax_writeobj_writecoff':
cc32n.c:35811: warning: decimal constant is so large that it is unsigned
cc32n.c:35818: warning: decimal constant is so large that it is unsigned
as -o cc32n.obj cc32n.s
rm -f cc32n.s
gcc -o cc64.exe cc32n.obj

D:\devel\pdos\cc64>

Same result:

D:\devel\pdos\cc64>cc64 -c world.c
Compiling world.c to world.obj
0 00000000
SS code gen error: 1:exceeding word32 value
On line: 11

D:\devel\pdos\cc64>

I need to do some more work before I can
use gccwin without using anything in cygwin,
because cc32n.c uses 64-bit values and my
support routines exist, but don't work
properly, so need to be debugged first.
That's why I switched to Visual Studio 2005
Professional first, and later to cygwin,
and got the same unexpected result for both.

Thanks. Paul.

On 26/01/24 19:38, Paul Edwards wrote:

> I need to do some more work before I can
> use gccwin without using anything in cygwin,
> because cc32n.c uses 64-bit values and my
> support routines exist, but don't work
> properly, so need to be debugged first.

If anyone can spot the error in this assembler
(starting with udivmodsi3 on line 100):

https://sourceforge.net/p/pdos/gitcode/ci/master/tree/pdpclib/winsupa.asm#l100

I will be able to eliminate cygwin.

Note that I didn't write this code as I
didn't know how to do it, but debugging
was left to me.

BFN. Paul.

On 26/01/24 19:46, Paul Edwards wrote:

> If anyone can spot the error in this assembler
> (starting with udivmodsi3 on line 100):
>
> https://sourceforge.net/p/pdos/gitcode/ci/master/tree/pdpclib/winsupa.asm#l100

Note that that code is in http://pdos.org/bart.zip

Assuming the executables in http://pdos.org/pdos.zip
(\dos directory in pdos.vhd) are available, then
the following sequence:

cd pdos\src
pdmake -f makek32.std
cd ..\pdpclib
pdmake -f makefile.std
cd ..\cc64
pdmake -f makefile.std

gives:

D:\devel\pdos\cc64>cc64 -c world.c
1 0
Alloc mem failure
ABORTING: Press key...
D:\devel\pdos\cc64>

I would have said "almost certainly due to those
assembler support routines", except that with
the unexpected failure of Visual Studio 2005
and cygwin, all bets are off.

BFN. Paul.

On 26/01/2024 11:04, bart wrote:
> On 26/01/2024 10:16, Paul Edwards wrote:

> If you like, I can spend an hour or two working with this C code trying
> to find the cause of the crashing, but when it's built with my 'tcc -m32'.
>

It turned out there wasn't much of a problem: my hello.c used __DATE__
and __TIME__, which it didn't like, so I just took those out. (If your
stuff uses them, I will need to look again.)

Otherwise most programs work using -S -E -c options.

So, I take it the main problem is the 'exceeding word32 value' error?

That is due to this code around line 31865 in cc32n.c:

if (!((((i64)-2147483648 <= value) && (value <=
(i64)((u64)4294967295u))))) {
...
ax_lib_gerror((byte*)"1:exceeding word32 value");
};

You can simply comment out this block. But I suspect that if there's a
problem with that 4294967295 value, it will manifest itself in other places.

This is also the value that your gcc complained of, but those I think
didn't have that 'u' suffix. (Maybe adding that will shut it up.)

The intention of this bit of code is to allow values in the range
i32.min to u32.max (not i32.max), to detect definitely rogue values. In
this machine-generated assembly, it should not be needed.

(I downloaded your PDOS stuff, but that had various issues, eg. gccwin
compiled, but produced no output. The a.exe that was already there,
expected a CYGWIN environment.

So there's a lot of rabbit holes there that I would rather not go down.)

bart <bc@freeuk.com> writes:
>On 26/01/2024 10:57, Paul Edwards wrote:
>> On 26/01/24 18:53, Janis Papanagnou wrote:
>>> On 26.01.2024 11:16, Paul Edwards wrote:
>>>> Hi Bart (or anyone else interested)
>>>>
>>>> (and hopefully this doesn't start a 3 month
>>>> long thread about ... what?)
>>>
>>> Looks like a support question for a piece of proprietary code.
>>
>> It's as far from proprietary as possible - it's
>> public domain. Without the hassle of having to
>> wait for the author to die and then waiting
>> another 70 years for him to properly decompose.
>>
>>> Why don't you contact the author or issue a bug report?
>>
>> It's public domain. You're the owner as much as
>> anyone else. And if you think it's a bug, then
>> I've just given you a bug report.
>
>JP and I had an argument so he (I assume) has it in for me.
>

Perhaps, yet it is still off-topic for comp.lang.c.

On 26/01/2024 15:36, Scott Lurndal wrote:
> bart <bc@freeuk.com> writes:
>> On 26/01/2024 10:57, Paul Edwards wrote:
>>> On 26/01/24 18:53, Janis Papanagnou wrote:
>>>> On 26.01.2024 11:16, Paul Edwards wrote:
>>>>> Hi Bart (or anyone else interested)
>>>>>
>>>>> (and hopefully this doesn't start a 3 month
>>>>> long thread about ... what?)
>>>>
>>>> Looks like a support question for a piece of proprietary code.
>>>
>>> It's as far from proprietary as possible - it's
>>> public domain. Without the hassle of having to
>>> wait for the author to die and then waiting
>>> another 70 years for him to properly decompose.
>>>
>>>> Why don't you contact the author or issue a bug report?
>>>
>>> It's public domain. You're the owner as much as
>>> anyone else. And if you think it's a bug, then
>>> I've just given you a bug report.
>>
>> JP and I had an argument so he (I assume) has it in for me.
>>
>
> Perhaps, yet it is still off-topic for comp.lang.c.

It is about C and compiling C.

I understand that is not quite as on-topic as posting chunks of COBOL
and Algol68, for that I'm sorry.

On 26/01/2024 11:57, Paul Edwards wrote:
> On 26/01/24 18:53, Janis Papanagnou wrote:
>> On 26.01.2024 11:16, Paul Edwards wrote:
>>> Hi Bart (or anyone else interested)
>>>
>>> (and hopefully this doesn't start a 3 month
>>> long thread about ... what?)
>>
>> Looks like a support question for a piece of proprietary code.
>
> It's as far from proprietary as possible - it's
> public domain. Without the hassle of having to
> wait for the author to die and then waiting
> another 70 years for him to properly decompose.
>
>> Why don't you contact the author or issue a bug report?
>
> It's public domain. You're the owner as much as
> anyone else. And if you think it's a bug, then
> I've just given you a bug report.
>

It is public domain, but it is software written solely by Bart, and used
(AFAIK) only by you and Bart, and it's mainly of interest to you two.
It seems perfectly fair to use bcc as an example of a C compiler in
posts in c.l.c., but details of bugs or development of it do not belong
here. We do not normally discuss bugs in gcc or clang, two open source
C compilers of vastly more interest to vastly more people than bcc.
Discussions of the details of bcc are similarly off-topic.

I don't know if Bart has the project on some hosting site (github,
sourceforge, etc.), but if so, then that would be the appropriate place
for discussing issues. If not, and there is no dedicated group or
mailing list, then direct email would seem the right way to go.

Posting here would be appropriate if it is something strictly C related
- perhaps a question about the implementation of somewhat unusual code
constructs where you can't figure out the correct rules according to the
standards.

So think - if this were about gcc rather than bcc, would you post it
here? If not, then don't post it here.

And no, none of us are "owners" of the software in any sense of that
word. We did not buy it or receive it in other ways, we did not create
it, we are not responsible for it or its uses, we cannot sell it or
otherwise transfer ownership of it. Bart is the original owner - there
are no other owners.

On 2024-01-26, David Brown <david.brown@hesbynett.no> wrote:
> I don't know if Bart has the project on some hosting site (github,

Bart ... git ... think about it. :)

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

On 26/01/2024 16:33, David Brown wrote:
> On 26/01/2024 11:57, Paul Edwards wrote:

> Posting here would be appropriate if it is something strictly C related
> - perhaps a question about the implementation of somewhat unusual code
> constructs where you can't figure out the correct rules according to the
> standards.

This is extraordinary.

For the past month the discussion here has been about everything under
the sun, except actual C.

For me it was refresing in this thread to deal with some actual,
concrete, real-life C code, and some real bugs (here, possibly within
gcc 3.2).

But there have so far been 4 people posting in this thread who have
nothing to say on the topic on hand, other than complain about
topicality (I'm not sure what KK's post was about, it looked like an
insult).

Meanwhile, just JP has been talking about or posting examples of Ada,
Eiffel, COBOL, C++, Algol and Shell. I've struggled to see any posts
from JP with even one line of C code. Others have talked about Python or
posted makefile scripts or discussed Scandinavian heritage.

> So think - if this were about gcc rather than bcc, would you post it
> here?  If not, then don't post it here.

As noted above, it might well turn out to be a gcc bug in an old version
of it.

> And no, none of us are "owners" of the software in any sense of that
> word.  We did not buy it or receive it in other ways, we did not create
> it, we are not responsible for it or its uses, we cannot sell it or
> otherwise transfer ownership of it.  Bart is the original owner - there
> are no other owners.

This was a program of transpiled C which I put into the public domain. I
don't have copies, and Github was only used as a one-off distribution
method. The product is not supported.

On 26/01/2024 13:51, bart wrote:
> On 26/01/2024 11:04, bart wrote:
>> On 26/01/2024 10:16, Paul Edwards wrote:
>
>> If you like, I can spend an hour or two working with this C code
>> trying to find the cause of the crashing, but when it's built with my
>> 'tcc -m32'.
>>
>
> It turned out there wasn't much of a problem: my hello.c used __DATE__
> and __TIME__, which it didn't like, so I just took those out. (If your
> stuff uses them, I will need to look again.)
>
> Otherwise most programs work using -S -E -c options.
>
> So, I take it the main problem is the 'exceeding word32 value' error?
>
> That is due to this code around line 31865 in cc32n.c:
>
>
>  if (!((((i64)-2147483648 <= value) && (value <=
> (i64)((u64)4294967295u))))) {
>      ...
>      ax_lib_gerror((byte*)"1:exceeding word32 value");
>  };
>

If this is an issue with gcc 3.2, it should fail this program too:

--------------------
#include <stdio.h>

typedef long long int i64;
typedef unsigned long long int u64;

int main(void) {
i64 value=0;

if (!(((i64)-2147483648 <= value) && (value <=
(i64)(u64)4294967295u))) {
printf("%lld is out of range\n", value);
}
--------------------
}

With a modern compiler this program passes with no output, which is the
intended behaviour.

However if I compile with gcc 13.2.0 using:

gcc -std=c89 c.c

then it says:

c.c:9:5: warning: this decimal constant is unsigned only in ISO C90
9 | if (!(((i64)-2147483648 <= value) && (value <=
(i64)(u64)4294967295u))) {
| ^~

Running it shows:

0 is out of range.

The compiler message is like the ones in your OP, in this case the
culprit is that first number -2147483648.

I'm not quite how to fix this, perhaps the C experts here, if they can
deign to deal with an actual C issue for a change, will have suggestions.

As I said, you can just try commenting it out, but I don't think ATM
that it's a bug in my cc32n.c program.

On 26/01/2024 19:00, bart wrote:
> On 26/01/2024 16:33, David Brown wrote:
>> On 26/01/2024 11:57, Paul Edwards wrote:
>
>> Posting here would be appropriate if it is something strictly C
>> related - perhaps a question about the implementation of somewhat
>> unusual code constructs where you can't figure out the correct rules
>> according to the standards.
>
> This is extraordinary.
>
> For the past month the discussion here has been about everything under
> the sun, except actual C.
>

A lot of it was off-topic, yes. But a lot of it was at least of
interest to a number of people here.

You are free to complain that people have been talking too much about
COBOL, C++, or whatever - and that would be a valid complaint, and
something that people in the group should respect.

Two wrongs, however, do not make a right.

> For me it was refresing in this thread to deal with some actual,
> concrete, real-life C code, and some real bugs (here, possibly within
> gcc 3.2).

But this thread is not talking about real-life C code. It is talking
about a real-life C /compiler/. That is different.

If the OP was posting some C code and asking "what's wrong with this?",
so that we could look at the C code and help find problems with the C,
it would be on-topic. But he is posting error messages from a
compilation - he is having trouble with /tools/, not /C/.

Can you see that this is different?

>
> But there have so far been 4 people posting in this thread who have
> nothing to say on the topic on hand, other than complain about
> topicality (I'm not sure what KK's post was about, it looked like an
> insult).

I /did/ have something to say. I gave the OP suggestions about better
ways to get help with his problem that is not really c.l.c material. If
your project is on github, sourceforge, or any similar platform, then
discussing the issue there may help more people, and may also help grow
a community around it since potential users will see it as active. It
helps everyone.

It is not that I don't want the OP to get things working - it is simply
that this is not the best place for such help.

>
>> So think - if this were about gcc rather than bcc, would you post it
>> here?  If not, then don't post it here.
>
> As noted above, it might well turn out to be a gcc bug in an old version
> of it.
>

And posting about that would be off-topic too. If it was a particularly
interesting bug, or particularly dangerous, or a bug that had lasted
from gcc 3.2 to current versions (which could make it interesting /and/
dangerous), then it might be of interest to many people here and
therefore worth posting even if it is technically off-topic.

But there are nearly a hundred thousand bugs or issues registered for
gcc (including duplicates, non-bugs, etc. - everything in the gcc
bugzilla database). Posting about all these here would be absurd.

>> And no, none of us are "owners" of the software in any sense of that
>> word.  We did not buy it or receive it in other ways, we did not
>> create it, we are not responsible for it or its uses, we cannot sell
>> it or otherwise transfer ownership of it.  Bart is the original owner
>> - there are no other owners.
>
> This was a program of transpiled C which I put into the public domain. I
> don't have copies, and Github was only used as a one-off distribution
> method. The product is not supported.
>

None of that makes it likely that c.l.c. is a good place to talk about
the compilation issues the OP is having.

On 26.01.2024 11:57, Paul Edwards wrote:
> On 26/01/24 18:53, Janis Papanagnou wrote:
>> On 26.01.2024 11:16, Paul Edwards wrote:
>>> Hi Bart (or anyone else interested)
>>>
>>> (and hopefully this doesn't start a 3 month
>>> long thread about ... what?)
>>
>> Looks like a support question for a piece of proprietary code.
>
> It's as far from proprietary as possible - it's
> public domain. [...]

You are right, the choice of that word was not appropriate.

>
>> Why don't you contact the author or issue a bug report?
>
> It's public domain. You're the owner as much as
> anyone else. And if you think it's a bug, then
> I've just given you a bug report.

No, you are wrong, I'm not the owner of this piece of... code.

If someone makes a big heap of fecal in a public park, would
you think I'm the owner? I'd rather sue the one who did that;
because the park (or Usenet) is common property, and the heap
of fecal (or that code) is not.

It's interesting that there's again so many posts in this thread.
A thread about some ominous "cc32n" tool, that is running in some
mythical D:\ universe. - Or is that >>> D:\ <<< just a smiley?

Mind, I had just observed:
"Looks like a support question for a piece of proprietary code."
and suggested:
"Why don't you contact the author or issue a bug report?"

The thread is even under subject "bart" and that person is also
personally addressed in the salutation. - Clear indications that
a personal email would be much better. - Paul, why aren't you
contacting the tool author if you have issues with his tool?

Googlies may not know that; Usenet is not a "public mailbox".

Especially since you also express your hope:
"and hopefully this doesn't start a 3 month long thread"
It was on you to not initiate this spam, and it's still on you
to redirect it to a more appropriate place.

Good luck.

Janis

bart <bc@freeuk.com> writes:
[...]
> If this is an issue with gcc 3.2, it should fail this program too:
>
> --------------------
> #include <stdio.h>
>
> typedef long long int i64;
> typedef unsigned long long int u64;
>
> int main(void) {
> i64 value=0;
>
> if (!(((i64)-2147483648 <= value) && (value <=
> (i64)(u64)4294967295u))) {
> printf("%lld is out of range\n", value);
> }
> --------------------
> }
>
> With a modern compiler this program passes with no output, which is
> the intended behaviour.
>
> However if I compile with gcc 13.2.0 using:
>
> gcc -std=c89 c.c
>
> then it says:
>
> c.c:9:5: warning: this decimal constant is unsigned only in ISO C90
> 9 | if (!(((i64)-2147483648 <= value) && (value <=
> (i64)(u64)4294967295u))) {
> | ^~

I get that same warning, but only if I specify "-m32". long int is 64
bits by default on my system; "-m32" makes it 32 bits, which triggers
the warning.

And if I compile with "gcc -m32 -std=c89 -pedantic", I get warnings
about "long long" and the "ll" length modifier. gcc in C89 mode
supports both as an extension, but is required to warn about "long long"
in conforming mode. ("gcc -std=c89" does not issue all C89-required
diagnostics.)

The rules for integer constants changed between C89/C90 and C99, when
"long long" was added.

In C89/C90, the type of an unsuffixed decimal integer constant is the
first of int, long int, or unsigned long int, in which its value fits.
In C99 and later, the list is int, long int, long long int; unsuffixed
decimal constants are never of any unsigned type.

So in C89/C90 on a system where long int is 32 bits, 2147483648 is of
type unsigned long int. Negating that value yields 2147483648.
In C99 and later, 2147483648 is of type long long int, and negating it
yields -2147483648.

Remember that -2147483648 is not an integer constant. It's an
expression consisting of a unary "-" operator applied to the constant
2147483648. The negation operator is the one for the type of the
constant, regardless of the context in which the expression appears.

In C90 with 32-bit long int, there is no signed type that can hold the
value 2147483648 .

[...]

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

bart <bc@freeuk.com> wrote:
<snip>

> For the past month the discussion here has been about everything under
> the sun, except actual C.
>
> For me it was refresing in this thread to deal with some actual,
> concrete, real-life C code, and some real bugs (here, possibly within
> gcc 3.2).

I for one is fine with this thread since seems to have to do
with a c program used in an obscure OS or emulation package.

It is easy enough to kill it if you do not like it. We all
have had plenty of practice with filtering in the past few
months :)

--
[t]csh(1) - "An elegant shell, for a more... civilized age."
- Paraphrasing Star Wars

On 27/01/24 04:47, Keith Thompson wrote:
> bart <bc@freeuk.com> writes:
> [...]
>> If this is an issue with gcc 3.2, it should fail this program too:
>>
>> --------------------
>> #include <stdio.h>
>>
>> typedef long long int i64;
>> typedef unsigned long long int u64;
>>
>> int main(void) {
>> i64 value=0;
>>
>> if (!(((i64)-2147483648 <= value) && (value <=
>> (i64)(u64)4294967295u))) {
>> printf("%lld is out of range\n", value);
>> }
>> --------------------
>> }
>>
>> With a modern compiler this program passes with no output, which is
>> the intended behaviour.
>>
>> However if I compile with gcc 13.2.0 using:
>>
>> gcc -std=c89 c.c
>>
>> then it says:
>>
>> c.c:9:5: warning: this decimal constant is unsigned only in ISO C90
>> 9 | if (!(((i64)-2147483648 <= value) && (value <=
>> (i64)(u64)4294967295u))) {
>> | ^~
>
> I get that same warning, but only if I specify "-m32". long int is 64
> bits by default on my system; "-m32" makes it 32 bits, which triggers
> the warning.
>
> And if I compile with "gcc -m32 -std=c89 -pedantic", I get warnings
> about "long long" and the "ll" length modifier. gcc in C89 mode
> supports both as an extension, but is required to warn about "long long"
> in conforming mode. ("gcc -std=c89" does not issue all C89-required
> diagnostics.)
>
> The rules for integer constants changed between C89/C90 and C99, when
> "long long" was added.
>
> In C89/C90, the type of an unsuffixed decimal integer constant is the
> first of int, long int, or unsigned long int, in which its value fits.
> In C99 and later, the list is int, long int, long long int; unsuffixed
> decimal constants are never of any unsigned type.
>
> So in C89/C90 on a system where long int is 32 bits, 2147483648 is of
> type unsigned long int. Negating that value yields 2147483648.
> In C99 and later, 2147483648 is of type long long int, and negating it
> yields -2147483648.
>
> Remember that -2147483648 is not an integer constant. It's an
> expression consisting of a unary "-" operator applied to the constant
> 2147483648. The negation operator is the one for the type of the
> constant, regardless of the context in which the expression appears.
>
> In C90 with 32-bit long int, there is no signed type that can hold the
> value 2147483648 .

Thankyou. That was difficult to comprehend,
but the "never unsigned type" was the phrase
that triggered me to make this change:

https://sourceforge.net/p/pdos/gitcode/ci/bb6e46a06241965f1d755563c998be196e217eca/

to eliminate the warnings, and then it worked great!

During the debugging process I also confirmed
that this code:

# Note that the push and pop of ecx appears to
# be unnecessary but harmless. It was originally
# missing, but adding it didn't help

udivmodsi3:

push ebp
mov ebp, esp

push edi
push esi
push ebx
push ecx

sub esp, 36

mov ecx, dword ptr [ebp + 8]
mov dword ptr [ebp - 40], ecx

mov ecx, dword ptr [ebp + 12]
mov dword ptr [ebp - 36], ecx

mov ecx, dword ptr [ebp + 16]
mov dword ptr [ebp - 48], ecx

mov ecx, dword ptr [ebp + 20]
mov dword ptr [ebp - 44], ecx

mov dword ptr [ebp - 24], 1
mov dword ptr [ebp - 20], 0

jmp L2

L4:

mov ecx, dword ptr [ebp - 48]
mov ebx, dword ptr [ebp - 44]

shld ebx, ecx, 1
add ecx, ecx

mov dword ptr [ebp - 48], ecx
mov dword ptr [ebp - 44], ebx

sal dword ptr [ebp - 24], 1

L2:

mov ecx, dword ptr [ebp - 48]
mov ebx, dword ptr [ebp - 44]

cmp ecx, dword ptr [ebp - 40]
sbb ebx, dword ptr [ebp - 36]
jnc L5

cmp dword ptr [ebp - 24], 0
jnb L5

mov ecx, dword ptr [ebp - 48]
and ecx, -2147483648

mov eax, ecx
mov ecx, dword ptr [ebp - 44]
and ch, -1

mov edi, ecx
mov ebx, eax
xor bh, 0

mov edi, ebx
mov ebx, edx
xor bh, 0

mov edi, ebx
mov ecx, edi
or ecx, esi

test ecx, ecx
jna L4

jmp L5

L7:

mov eax, dword ptr [ebp - 40]
mov edx, dword ptr [ebp - 36]

cmp eax, dword ptr [ebp - 48]
mov eax, edx
sbb eax, dword ptr [ebp - 44]
jc L6

mov eax, dword ptr [ebp - 48]
mov edx, dword ptr [ebp - 44]

sub dword ptr [ebp - 40], eax
sbb dword ptr [ebp - 36], edx

mov eax, dword ptr [ebp - 24]
or dword ptr [ebp - 20], eax

L6:

shr dword ptr [ebp - 24], 1

mov eax, dword ptr [ebp - 48]
mov edx, dword ptr [ebp - 44]

shrd eax, edx, 1
shr edx, 1

mov dword ptr [ebp - 48], eax
mov dword ptr [ebp - 44], edx

L5:

cmp dword ptr [ebp - 24], 0
jne L7

; did they ask for the divided amount (0)
; or the remainder (1)?

cmp dword ptr [ebp + 24], 0
je L8

; return remainder
mov eax, dword ptr [ebp - 40]
mov edx, dword ptr [ebp - 36]

jmp L9

; return divided amount
L8:

mov eax, dword ptr [ebp - 20]
xor edx, edx

L9:

add esp, 36
pop ecx
pop ebx
pop esi
pop edi
pop ebp
ret

__umoddi3:

push ebp
mov ebp, esp

push 1
push dword ptr [ebp + 20]
push dword ptr [ebp + 16]
push dword ptr [ebp + 12]
push dword ptr [ebp + 8]

call udivmodsi3
add esp, 20

pop ebp
ret

__udivdi3:

push ebp
mov ebp, esp

push 0
push dword ptr [ebp + 20]
push dword ptr [ebp + 16]
push dword ptr [ebp + 12]
push dword ptr [ebp + 8]

call udivmodsi3
add esp, 20

pop ebp
ret

__moddi3:

push ebp
mov ebp, esp

push 1
push dword ptr [ebp + 20]
push dword ptr [ebp + 16]
push dword ptr [ebp + 12]
push dword ptr [ebp + 8]

call udivmodsi3
add esp, 20

pop ebp
ret

; bottom of stack has original number as 32:32, e.g. 50
; top of stack has number to divide by as 32:32, e.g. 10
; result, e.g. 5, should be in edx:eax
__divdi3:

push ebp
mov ebp, esp

push 0
push dword ptr [ebp + 20]
push dword ptr [ebp + 16]
push dword ptr [ebp + 12]
push dword ptr [ebp + 8]

call udivmodsi3
add esp, 20

pop ebp
ret

is return 1 for a divdi3 (seems always 1)
instead of a proper value. So that issue
is still preventing me from moving from
cygwin gcc 3.2 to my own gcc 3.2.3.

BFN. Paul.

On 27/01/24 00:33, David Brown wrote:
> On 26/01/2024 11:57, Paul Edwards wrote:

>> It's public domain. You're the owner as much as
>> anyone else. And if you think it's a bug, then
>> I've just given you a bug report.
>>
>
> It is public domain, but it is software written solely by Bart, and used

Doesn't make any difference who wrote it.

> (AFAIK) only by you and Bart,

It's not used by Bart at all that I am aware of.

> and it's mainly of interest to you two.

No. It's of interest to me and some other people,
not Bart.

> It
> seems perfectly fair to use bcc as an example of a C compiler in posts

This isn't bcc.

> in c.l.c., but details of bugs or development of it do not belong here.
> We do not normally discuss bugs in gcc or clang, two open source C
> compilers of vastly more interest to vastly more people than bcc.
> Discussions of the details of bcc are similarly off-topic.
>
> I don't know if Bart has the project on some hosting site (github,
> sourceforge, etc.),

It is me who has the compiler on sourceforge.

> but if so, then that would be the appropriate place
> for discussing issues. If not, and there is no dedicated group or
> mailing list, then direct email would seem the right way to go.

Bart does not own it, and has explicitly said he
has no interest in it, and doesn't support it.

So I'm on my own, and I don't have the skills to
know what to do. It was in fact Keith who had the
skills, but I didn't know that in advance. And
Bart was kind enough to get it to the point where
Keith was able to identify the issue.

> Posting here would be appropriate if it is something strictly C related
> - perhaps a question about the implementation of somewhat unusual code
> constructs where you can't figure out the correct rules according to the
> standards.
>
> So think - if this were about gcc rather than bcc, would you post it
> here? If not, then don't post it here.

I exactly posted a gcc issue a week ago, so, yes.

There's nowhere else for me to go.

The GNU people have no interest in supporting
gcc 3.2.3, in fact, they were "keen to delete"
the precious (to me) i370 target, displaying
the massive contempt for one of the most
important machines in the world.

> And no, none of us are "owners" of the software in any sense of that
> word.

Yes you are. As much as anyone else in the world is.
That's the exact definition of public domain.

If you were an alien from Alpha Centauri you could
perhaps argue that you're not a member of the public.

> We did not buy it or receive it in other ways,

Nobody bought it. We're all in the same boat.
And it was exactly received by a post to this
exact newsgroup. If you didn't bother to
download it when it was posted, so be it.

> we did not create it,

It's unclear if even Bart created it. It is
generated code.

> we are not responsible for it or its uses,

Nobody is responsible, or everyone is equally
responsible, whichever way you look at it.

> we cannot sell it

Yes you can.

> or otherwise transfer ownership of it.

Nobody can. It's in the public domain. Again,
we're all in the same boat.

> Bart is the original owner

He was indeed the original owner. But not any
more. You are the equal of Bart.

In fact, if there is anyone who is top dog,
it's me. I maintain the source code and
build it and distribute it, and take an
interest in bugs. Bart doesn't do any of
those things, but he does graciously assist.

> - there are no other owners.

There are no owners full stop. Unless the
public is considered an owner, which it is.

Public domain code is not "unowned" waiting
for the first person do notice it to declare
ownership of. It is owned by the public.

BFN. Paul.

On 27/01/24 04:42, Janis Papanagnou wrote:
> On 26.01.2024 11:57, Paul Edwards wrote:

>>> Why don't you contact the author or issue a bug report?
>>
>> It's public domain. You're the owner as much as
>> anyone else. And if you think it's a bug, then
>> I've just given you a bug report.
>
> No, you are wrong, I'm not the owner of this piece of... code.

Yes you are. The reason above stands.

> If someone makes a big heap of fecal in a public park, would
> you think I'm the owner? I'd rather sue the one who did that;

If Bart had deliberately inserted a virus into
cc32n.c, yes, he could be sued. This is not the
case. A better analogy is Shakespeare's "Hamlet".
Even if Hamlet had put a computer virus into the
text somehow - he can't be sued. He's been dead
for more than 70 years.

> because the park (or Usenet) is common property, and the heap
> of fecal (or that code) is not.

That code is exactly common property, just as
"Hamlet" is.

> It's interesting that there's again so many posts in this thread.
> A thread about some ominous "cc32n" tool, that is running in some
> mythical D:\ universe. - Or is that >>> D:\ <<< just a smiley?
>
> Mind, I had just observed:
> "Looks like a support question for a piece of proprietary code."
> and suggested:
> "Why don't you contact the author or issue a bug report?"
>
> The thread is even under subject "bart" and that person is also
> personally addressed in the salutation.

That's true. Although Bart transferred ownership
(to the public) and said he wanted nothing to do
with it anymore (but I have a use for it - so I
attempt to support it myself), I was hoping that
"for old times' sake" he would venture an opinion
anyway. And that's exactly what happened.

And it wasn't just to bart. The salutation clearly
says "anyone else".

> - Clear indications that
> a personal email would be much better.

That would be a last resort.

That would be targeting someone who clearly
stated they didn't want to be targeted.

> - Paul, why aren't you
> contacting the tool author if you have issues with his tool?

Because the tool author is no longer the owner
and does not support it.

> Googlies may not know that; Usenet is not a "public mailbox".

It's a place that you can get support.

And that's exactly what I got. Not for the
first time.

> Especially since you also express your hope:
> "and hopefully this doesn't start a 3 month long thread"
> It was on you to not initiate this spam, and it's still on you
> to redirect it to a more appropriate place.

That was a joke.

I don't care if you carry this thread off on a
tangent for the next 50 years.

I'm unlikely to read the tangent myself - well,
actually - I did read some with incredulity.

BFN. Paul.

On 27/01/2024 14:24, Paul Edwards wrote:
> On 27/01/24 00:33, David Brown wrote:
>> On 26/01/2024 11:57, Paul Edwards wrote:
>
>>> It's public domain. You're the owner as much as
>>> anyone else. And if you think it's a bug, then
>>> I've just given you a bug report.
>>>
>>
>> It is public domain, but it is software written solely by Bart, and used
>
> Doesn't make any difference who wrote it.
>

It makes a very big difference in regard to who can help you with it,
and who might be interested in its details.

>> (AFAIK) only by you and Bart,
>
> It's not used by Bart at all that I am aware of.
>

That just makes it even less appropriate to post it here.

>> and it's mainly of interest to you two.
>
> No. It's of interest to me and some other people,
> not Bart.
>

Who else? And is this the appropriate place to talk to them about your
issues?

If you were announcing the availability of a new C compiler, that could
be of interest to the group even if no one wanted to use it. But you
are talking about some details of problems you are having compiling it -
that's a different matter. Just because it is a C compiler, does not
make it on-topic for the group. Someone having trouble compiling
"sqllite" (to pick a random example) would not post here even though the
program was written in C and released in the public domain. They would
post in a place where they would find users people that might be able to
help them, and where it is on topic - such as a a mailing list or
project issue handler for sqllite.

>
> There's nowhere else for me to go.

If you can get this down to a C question, this would be a perfectly good
place to come. If you are having trouble building software, posting a
heap of meaningless build errors is not helpful.

People can help here with C questions. We can't, generally, help with
build issues with random bits of software. Keith didn't answer your
question - he helped with /Bart/'s question. Bart posted some C code,
which Keith was able to comment on.

>
> The GNU people have no interest in supporting
> gcc 3.2.3, in fact, they were "keen to delete"
> the precious (to me) i370 target, displaying
> the massive contempt for one of the most
> important machines in the world.

Of course the GNU folks have no interest in supporting gcc 3.2.3 - it's
ancient history. The i370 may have been an important machine in its
time, now it is a museum article. There's nothing wrong with history or
museums - I'm a great history fan myself. But there is something very
wrong with obsessing with it or trying to keep it "alive" like this.
It's great to learn about Roman soldiers, to see their weapons and
armour in museums, and to have re-enactments of old battles. But it is
pointless to try to use new materials or methods to make better Roman
armour - that would be showing contempt for the history.

So I understand that you are interested in the history of old computers.
I don't understand that you think other people should have any kind of
duty or obligation to do so too. And if anyone involved in gcc
development were really keen on the i370, they'd want to make it work
for /modern/ gcc, not such an old version.

People can't support things forever - if they try to do so, no one would
ever have time to work in the modern world. Let the past be the past -
be interested in it, learn from it, teach it, but do not forget that it
is the past.

(There are no doubt still some i370 machines running. And no one using
them will ever be interested in using your personal port of an ancient
version of gcc. They will run the software they have always run on
them, because that's why they are still running those machines.)

>
>> And no, none of us are "owners" of the software in any sense of that
>> word.
>
> Yes you are. As much as anyone else in the world is.
> That's the exact definition of public domain.

No, it is not. For someone who is so obsessed with "public domain", you
are remarkably ignorant about it. /No one/ owns the software released
into the public domain, at least in countries that recognise such the
concept of relinquishing ownership. (Not all countries accept that as a
legal concept.)

>
>> we are not responsible for it or its uses,
>
> Nobody is responsible, or everyone is equally
> responsible, whichever way you look at it.
>

These are hugely different ways of looking at it. If I were to say "I
think some people in your family are murderers", would you respond with
"No one in my family is a murderer", or "Everyone in my family is
equally murderous" ?

No one owns the software - it is not the case that we all own it. No
one is responsible for it (except perhaps in some countries, or in
certain aspects). It is not that case that everyone is responsible for it.

>> we cannot sell it
>
> Yes you can.

No you can't. You can sell copies of it, but you can't sell the
software itself in any real sense. Selling the software itself would
imply transferring ownership or rights.

>
>> or otherwise transfer ownership of it.
>
> Nobody can. It's in the public domain. Again,
> we're all in the same boat.

The point is, no one is in any boat.

>
>> Bart is the original owner
>
> He was indeed the original owner. But not any
> more.

Correct.

> You are the equal of Bart.

That is true only in the same meaningless sense that Bart and I have
equal numbers of wings sprouting from our shoulders.

>
> In fact, if there is anyone who is top dog,
> it's me. I maintain the source code and
> build it and distribute it, and take an
> interest in bugs. Bart doesn't do any of
> those things, but he does graciously assist.
>

You are free to do that, and to take responsibility of the software -
that's a choice you can make.

>> - there are no other owners.
>
> There are no owners full stop.

So stop there.

> Unless the
> public is considered an owner, which it is.

It is not. That's the point. "The public" does not exist as a legal
entity, and cannot own anything.

>
> Public domain code is not "unowned" waiting
> for the first person do notice it to declare
> ownership of. It is owned by the public.
>

It is not owned by the public, because that concept has no meaning. But
you are correct that no one can declare ownership of it. Note that
"public domain" refers only to things for which copyright law may apply,
and that necessarily means things that can be copied. Public domain
means no one owns the copyrights or other exclusive intellectual rights
to the software.

On 27/01/2024 17:36, David Brown wrote:
> On 27/01/2024 14:24, Paul Edwards wrote:

> If you can get this down to a C question, this would be a perfectly good
> place to come.  If you are having trouble building software, posting a
> heap of meaningless build errors is not helpful.

But in the end it did come down to a C question.

I'm curious however as to what you think this newsgroup is for.

The C group on Reddit, which is moderated, is far more diverse in what
is allowed. Nobody seems that bothered about it.

It might be about tools to build and work with the language. Building
problems encountered in some project. Requests for code reviews. Even
careers advice; all sorts of stuff.

I would have found this thread interesting even if I'd had nothing to do
with it, because I like problem-solving and bug-hunting.

> People can help here with C questions.  We can't, generally, help with
> build issues with random bits of software.

Why not? I'm sure there are lurkers with the practical experience to
help out, but are put off thinking only theoretical and hypothetical
matters discussed.