On Wednesday, August 30, 2023 at 10:54:10 PM UTC+8, Bart wrote:

> It's not clear which C library is being linked in here. BCC is designed
> to use MSVCRT.DLL (that is reflected in headers like stdio.h).

I have my own msvcrt.dll, built using makefile.s64 or makefile.n64

> Because '__imp__iob' is not exported by msvcrt.dll; '_iob' is as a

I believe it is - that's why I can use mingw64 and it works.

> I managed to get your example working by using a function instead of a
> variable. See that version below. Note that in my stdio.h, 'stdout' is
> defined as:
>
> #define stdout ((FILE*)(__iob_func()+sizeof(FILE)))
>
> sizeof(FILE) is 48.

Thankyou! I wasn't aware that the function __iob_func()
existed. That is good enough for my purposes and is
now working in my environment too.

Thanks a lot!

BFN. Paul.

On 30/08/2023 20:46, Paul Edwards wrote:
> On Wednesday, August 30, 2023 at 10:54:10 PM UTC+8, Bart wrote:
>
>> It's not clear which C library is being linked in here. BCC is designed
>> to use MSVCRT.DLL (that is reflected in headers like stdio.h).
>
> I have my own msvcrt.dll, built using makefile.s64 or makefile.n64
>
>> Because '__imp__iob' is not exported by msvcrt.dll; '_iob' is as a
>
> I believe it is - that's why I can use mingw64 and it works.

__imp_ appears to be an artefact of the linking system on Windows, and
may be to do with .lib and .a files.

If I look inside mingw64's libmsvcrt.a, I can see names starting with
__imp_. But inside msvcrt.dll itself, there are no __imp_ prefixes.

I was surprised you can use __imp_ in a source file, but it's possible
that some compilers, if you annotate a DLL imported name with
__declspec(dllimport), will add that prefix when it writes .obj files.

So that explains why you can just add it manually.

My compiler normally links directly to .DLL files (but cannot statically
link); there no .obj, .a, or .lib files involved, so that stuff isn't
needed.

Hi Bart.

Next error I have is:

cc64 -c -out:cclib/cclib.obj cclib/cclib.i
Compiling cclib/cclib.i to cclib/cclib.obj
In function ccpartype On line 1315 in file cclib/cclib.i

**** Code Gen Error: Block call after return ****

You can see the code here:

https://sourceforge.net/p/pdos/gitcode/ci/master/tree/pdcc/cclib/cclib.c

Change the first CC64 to XCC64 to activate the error.

It was built with makefile.n64 one level up.

BFN. Paul.

On 30/08/2023 23:54, Paul Edwards wrote:
> Hi Bart.
>
> Next error I have is:
>
> cc64 -c -out:cclib/cclib.obj cclib/cclib.i
> Compiling cclib/cclib.i to cclib/cclib.obj
> In function ccpartype On line 1315 in file cclib/cclib.i
>
> **** Code Gen Error: Block call after return ****
>
> You can see the code here:
>
> https://sourceforge.net/p/pdos/gitcode/ci/master/tree/pdcc/cclib/cclib.c
>
> Change the first CC64 to XCC64 to activate the error.
>
> It was built with makefile.n64 one level up.

This is a tricky one. It can be invoked like this:

typedef struct {int a,b,c;} S;

S F(void) {
S x;
return x;
}

void G(void) {
F();
return;
F();
return;
}

'S' is a struct type that is other than 1/2/4/8 bytes in size. If you
make a call to a function that returns such a type, like my F() call
above, even if you don't use the return value, it must be just before
the final return.

Once one 'return' has been seen, you can't make another such call. This
is just due to primitive handling of such data types.

Such functions need to be adjusted to use a common return point, for
example:

void G(void) {
F();
goto retpoint;
F();
retpoint:
return;

If a return value is involved, copy it to a common variable before jumping.

(I couldn't find function ccpartype in your link.)

On Thursday, August 31, 2023 at 7:17:30 AM UTC+8, Bart wrote:

> Once one 'return' has been seen, you can't make another such call. This
> is just due to primitive handling of such data types.
>
> Such functions need to be adjusted to use a common return point, for
> example:
>
> void G(void) {
> F();
> goto retpoint;
> F();
> retpoint:
> return;
>
> If a return value is involved, copy it to a common variable before jumping.

Thanks for the workaround!

> (I couldn't find function ccpartype in your link.)

Names were shortened because I build on the mainframe (MVS) too:

C:\devel\pdos\pdcc>dir *.jcl
Volume in drive C has no label.
Volume Serial Number is 4E58-AF11

Directory of C:\devel\pdos\pdcc

2023-07-23 21:55 6,124 makemvs.jcl

Here is the original name:

C:\devel\pdos\pdcc\cclib>grep cc_parse_type cclib.c
cclib.c: member.type = cc_parse_type(reader);
cclib.c: cc_type cc_parse_type(cc_reader *reader)
cclib.c: param.type = cc_parse_type(reader);
cclib.c: expr.data.cast.type = cc_parse_type(reader);
cclib.c: var.type = cc_parse_type(reader); /* Now parse the type */

C:\devel\pdos\pdcc\cclib>cd include

C:\devel\pdos\pdcc\cclib\include>grep ccpartype '*'
cclib.h: #define cc_parse_type ccpartype

C:\devel\pdos\pdcc\cclib\include>

BFN. Paul.

On 30/08/2023 23:54, Paul Edwards wrote:
> Hi Bart.
>
> Next error I have is:
>
> cc64 -c -out:cclib/cclib.obj cclib/cclib.i
> Compiling cclib/cclib.i to cclib/cclib.obj

BTW the -out option is not needed here. The output file uses the same
filename and the same path, just the extension is changed.

So the generated .obj file is in the same folder as the .c or .i source
file. The same applies when generating executables; you can compile code
remotely.

Other C compilers may be different; gcc for example applies the right
extension, but the object file (or executable) is written to the current
directory. And others tend to copy gcc.

(Sorry, this is part of a feud I have between my compiler, and the
quirky way that gcc works.

Apparently whatever gcc does is right, even when it's wrong. If gcc
drives over a cliff, other compilers have to do the same!)

On Thursday, August 31, 2023 at 6:59:08 PM UTC+8, Bart wrote:

> BTW the -out option is not needed here. The output file uses the same
> filename and the same path, just the extension is changed.

Ok, thanks for the info.

Next problem I have encountered is this:

With this code:

https://sourceforge.net/p/pdos/gitcode/ci/master/tree/pdcc/cpplib/directs.c

Plus this modification:

C:\devel\pdos\pdcc>git diff .
diff --git a/pdcc/cpplib/directs.c b/pdcc/cpplib/directs.c
index 8674a696..bd515203 100644
--- a/pdcc/cpplib/directs.c
+++ b/pdcc/cpplib/directs.c
@@ -792,6 +792,13 @@ void _cpp_init_directives(cpp_reader *reader)
{
unsigned int i;

+printf("in init_directives\n");
+printf("element 0 is %p\n", directives[0].name);
+printf("element 0 alternate is %p\n", &directives[0]);
+printf("element 1 is %p\n", directives[1].name);
+printf("element 1 alternate is %p\n", &directives[1]);
+exit(0);
+ for (i = 0; i < DIRECTIVE_COUNT; i++)
{
cpp_unknown *unknown = cpp_find(reader, directives[i].name,

C:\devel\pdos\pdcc>

I see:

C:\devel\pdos\pdcc>pdcc -E abc.c
in init_directives
element 0 is 0000000000403368
element 0 alternate is 00000000004031F8
element 1 is 0200000000004033
element 1 alternate is 00000000004031F9

C:\devel\pdos\pdcc>type abc.c
int x;

C:\devel\pdos\pdcc>

I shouldn't be getting those high addresses.

The situation has been analyzed by the author of pdld, who says:

The problem seems to be cc64 wrongly accessing an address field.

If you look at .text section relocations in directs.obj, you can find relocation with "printf" with RVA 0x17A (that is the call part of the faulty "printf("element 1 is %p\n", directives[1].name);" line).

In .text section at that address the code is this:
....
48 83 ec 20 sub rsp,0x20
ff 34 25 29 00 00 00 push QWORD PTR ds:0x29 (the cc64 wrongly accessing an address field)
48 b9 19 02 00 00 00 movabs rcx,0x219
00 00 00
5a pop rdx
e8 00 00 00 00 call 0x1f (the call to printf at 0x17A)
....

The 0x29 is wrong and correctly it should be 0x28 what can be seen by looking at .data section at that address.

Are you able to comment on this?

Thanks. Paul.

On 31/08/2023 12:58, Bart wrote:
> On 30/08/2023 23:54, Paul Edwards wrote:
>> Hi Bart.
>>
>> Next error I have is:
>>
>> cc64 -c -out:cclib/cclib.obj cclib/cclib.i
>> Compiling cclib/cclib.i to cclib/cclib.obj
>
>
> BTW the -out option is not needed here. The output file uses the same
> filename and the same path, just the extension is changed.
>
> So the generated .obj file is in the same folder as the .c or .i source
> file. The same applies when generating executables; you can compile code
> remotely.
>
> Other C compilers may be different; gcc for example applies the right
> extension, but the object file (or executable) is written to the current
> directory. And others tend to copy gcc.
>

Putting object files (or other generated files) in the same directory as
the source files is okay for small projects. If you've only got a
half-dozen source files, it can be tidy to keep them all in the same
directory.

If you are doing something bigger you almost invariably want to keep the
source tree and the generated files in separate directories. It makes
it much easier to see what's changed, to clean out object files, to
track source in a revision control system of some kind, to find the
source files amongst all the generated files, etc. Details, of course,
vary by person and project - too many directories and subdirectories
makes it hard to keep an overview of the files, as does too few
directories. This is known as "out of tree builds", and is the norm for
most projects above a certain size.

So whatever your default here - whether it is generating the object file
in the same directory as the source file, or generating it in the
current directory - it will be convenient in some cases, and completely
wrong in other cases.

So IMHO it's a good habit to have an "-out" (or equivalent) option in
your build files - then you know exactly where things are going.

People who use "make" have simple and common shortcuts for this. Since
you prefer not to use "make" or any alternative build system, you might
want to at least add an option to specify an output directory. Then,
for example, "cc64 -c -outdir:build src/file.c" would put the output
object file as "build/src/file.obj". You want to copy the directory
structure in the build directory, since a project written by several
people might coincidentally have matching filenames in different
directories.

On 31/08/2023 13:32, Paul Edwards wrote:
> On Thursday, August 31, 2023 at 6:59:08 PM UTC+8, Bart wrote:
>
>> BTW the -out option is not needed here. The output file uses the same
>> filename and the same path, just the extension is changed.
>
> Ok, thanks for the info.
>
> Next problem I have encountered is this:
>
> With this code:
>
> https://sourceforge.net/p/pdos/gitcode/ci/master/tree/pdcc/cpplib/directs.c
>
> Plus this modification:
>
> C:\devel\pdos\pdcc>git diff .
> diff --git a/pdcc/cpplib/directs.c b/pdcc/cpplib/directs.c
> index 8674a696..bd515203 100644
> --- a/pdcc/cpplib/directs.c
> +++ b/pdcc/cpplib/directs.c
> @@ -792,6 +792,13 @@ void _cpp_init_directives(cpp_reader *reader)
> {
> unsigned int i;
>
> +printf("in init_directives\n");
> +printf("element 0 is %p\n", directives[0].name);
> +printf("element 0 alternate is %p\n", &directives[0]);
> +printf("element 1 is %p\n", directives[1].name);
> +printf("element 1 alternate is %p\n", &directives[1]);
> +exit(0);
> +
> for (i = 0; i < DIRECTIVE_COUNT; i++)
> {
> cpp_unknown *unknown = cpp_find(reader, directives[i].name,
>
> C:\devel\pdos\pdcc>
>
>
> I see:
>
> C:\devel\pdos\pdcc>pdcc -E abc.c
> in init_directives
> element 0 is 0000000000403368
> element 0 alternate is 00000000004031F8
> element 1 is 0200000000004033
> element 1 alternate is 00000000004031F9
>
>
> C:\devel\pdos\pdcc>type abc.c
> int x;
>
> C:\devel\pdos\pdcc>
>
>
>
> I shouldn't be getting those high addresses.
>
>
> The situation has been analyzed by the author of pdld, who says:
>
> The problem seems to be cc64 wrongly accessing an address field.
>
> If you look at .text section relocations in directs.obj, you can find relocation with "printf" with RVA 0x17A (that is the call part of the faulty "printf("element 1 is %p\n", directives[1].name);" line).
>
> In .text section at that address the code is this:
> ...
> 48 83 ec 20 sub rsp,0x20
> ff 34 25 29 00 00 00 push QWORD PTR ds:0x29 (the cc64 wrongly accessing an address field)
> 48 b9 19 02 00 00 00 movabs rcx,0x219
> 00 00 00
> 5a pop rdx
> e8 00 00 00 00 call 0x1f (the call to printf at 0x17A)
> ...
>
> The 0x29 is wrong and correctly it should be 0x28 what can be seen by looking at .data section at that address.
>
>
> Are you able to comment on this?

No, sorry. I gave up on this stuff because I was being drawn into it so
much. 90% of it was having to grapple with complex C source code for
which I don't have the right tools for browsing and searching.

I realise the code generator on BCC is poor, and is buggy, which is why
I kept it as a private tool. (/My/ C code is very conservative; there it
works fine!)

What I will do however is this:

* I will take the BCC project and look at the possibility of replacing
the backend code generator with a new one.

* I can't directly use the one from my own compilers, as C is different:
I normally work with 64-bit intermediates throughout, C is mixed
32/64-bit, but mostly 32 bits

So I will do an evaluation first of how viable it will be, but if I
decide to attempt it, it will take some time so is not an immediate
solution.

That would be a better use of my time than trying to do ad hoc fixes and
patches for bugs I can't easily reproduce anyway.

Note a new backend won't fix any conformance issues. The problem with
(*F)()/F() is borderline; maybe that will fixed. The Block problem
should be. I don't want to touch the front end.

On 31/08/2023 13:36, David Brown wrote:
> On 31/08/2023 12:58, Bart wrote:
>> On 30/08/2023 23:54, Paul Edwards wrote:
>>> Hi Bart.
>>>
>>> Next error I have is:
>>>
>>> cc64 -c -out:cclib/cclib.obj cclib/cclib.i
>>> Compiling cclib/cclib.i to cclib/cclib.obj
>>
>>
>> BTW the -out option is not needed here. The output file uses the same
>> filename and the same path, just the extension is changed.
>>
>> So the generated .obj file is in the same folder as the .c or .i
>> source file. The same applies when generating executables; you can
>> compile code remotely.
>>
>> Other C compilers may be different; gcc for example applies the right
>> extension, but the object file (or executable) is written to the
>> current directory. And others tend to copy gcc.
>>
>
> Putting object files (or other generated files) in the same directory as
> the source files is okay for small projects.  If you've only got a
> half-dozen source files, it can be tidy to keep them all in the same
> directory.
>
> If you are doing something bigger you almost invariably want to keep the
> source tree and the generated files in separate directories.  It makes
> it much easier to see what's changed, to clean out object files, to
> track source in a revision control system of some kind, to find the
> source files amongst all the generated files, etc.  Details, of course,
> vary by person and project - too many directories and subdirectories
> makes it hard to keep an overview of the files, as does too few
> directories.  This is known as "out of tree builds", and is the norm for
> most projects above a certain size.
>
> So whatever your default here - whether it is generating the object file
> in the same directory as the source file, or generating it in the
> current directory - it will be convenient in some cases, and completely
> wrong in other cases.

But putting it in the current directory is sloppy. The current location
can be arbitrary (or it might not be writeable):

c:\random>gcc \proj1\foo.c
c:\random>gcc \proj2\bar.c

Here, both compilations generate a.exe. But to cap that, both end up in
c:\random; the second overwrites the first, something you might be
unaware of.

If I do:

c:\random>gcc \proj1\foo.c
c:\random>gcc \proj2\bar.c

then there are three differences from gcc:

(1) The executables are called foo.exe and bar.exe respectively
(2) They are written to their respective folders
(3) The compiler will report exactly what it is doing so there
are fewer surprises:

Compiling \proj1\foo.c to \proj2\foo.exe

You can use -v with gcc, but it is not helpful!

> So IMHO it's a good habit to have an "-out" (or equivalent) option in
> your build files - then you know exactly where things are going.
>
> People who use "make" have simple and common shortcuts for this.  Since
> you prefer not to use "make" or any alternative build system, you might
> want to at least add an option to specify an output directory.  Then,
> for example, "cc64 -c -outdir:build src/file.c"

Actually I have exactly that option, called '-outpath', but in my main
compilers; I haven't put it into bcc because bcc is an older project.

Paul Edwards <mutazilah@gmail.com> writes:
>On Thursday, August 31, 2023 at 6:59:08=E2=80=AFPM UTC+8, Bart wrote:
>
>> BTW the -out option is not needed here. The output file uses the same=20
>> filename and the same path, just the extension is changed.
>
>Ok, thanks for the info.
>
>Next problem I have encountered is this:

Please take it to email. This is not relevent to comp.lang.c.

On Thursday, August 31, 2023 at 9:45:14 PM UTC+8, Bart wrote:

> I realise the code generator on BCC is poor, and is buggy, which is why
> I kept it as a private tool. (/My/ C code is very conservative; there it
> works fine!)

Ok, thanks. I'll see if I can rework the C code to be conservative.

> So I will do an evaluation first of how viable it will be, but if I
> decide to attempt it, it will take some time so is not an immediate
> solution.

Sure. No problem. And no expectations.

This is already a decades-long endeavor anyway. It's more just
trying to understand where we stand after this latest breakthrough.

> That would be a better use of my time than trying to do ad hoc fixes and
> patches for bugs I can't easily reproduce anyway.

You should be able to reproduce my results.

I have uploaded http://pdos.org/uc386.zip which has all the
executables that get executed when running makefile.n64.
Plus it has the source code itself, so that you don't need to
go to sourceforge.

Also note that since producing the above, I have committed
a bit more development to sourceforge, but nothing related
to or that affects this issue.

> Note a new backend won't fix any conformance issues. The problem with
> (*F)()/F() is borderline; maybe that will fixed. The Block problem
> should be. I don't want to touch the front end.

Sure. The new cc64 (if it arrives) will still be public domain
though, right?

Thanks. Paul.

On 31/08/2023 15:43, Paul Edwards wrote:
> On Thursday, August 31, 2023 at 9:45:14 PM UTC+8, Bart wrote:
>
>> I realise the code generator on BCC is poor, and is buggy, which is why
>> I kept it as a private tool. (/My/ C code is very conservative; there it
>> works fine!)
>
> Ok, thanks. I'll see if I can rework the C code to be conservative.
>
>> So I will do an evaluation first of how viable it will be, but if I
>> decide to attempt it, it will take some time so is not an immediate
>> solution.
>
> Sure. No problem. And no expectations.
>
> This is already a decades-long endeavor anyway. It's more just
> trying to understand where we stand after this latest breakthrough.
>
>> That would be a better use of my time than trying to do ad hoc fixes and
>> patches for bugs I can't easily reproduce anyway.
>
> You should be able to reproduce my results.
>
> I have uploaded http://pdos.org/uc386.zip which has all the
> executables that get executed when running makefile.n64.
> Plus it has the source code itself, so that you don't need to
> go to sourceforge.
>
> Also note that since producing the above, I have committed
> a bit more development to sourceforge, but nothing related
> to or that affects this issue.
>
>> Note a new backend won't fix any conformance issues. The problem with
>> (*F)()/F() is borderline; maybe that will fixed. The Block problem
>> should be. I don't want to touch the front end.
>
> Sure. The new cc64 (if it arrives) will still be public domain
> though, right?

It can be. (Personally I don't care about that aspect at all.)

I can confirm that I've started an overhaul of the project, which will
have a working title of 'DD' to distinguish it from 'CC'. The first
stage is to get it to generate a new intermediate (IL) code (perhaps
within a week).

If that looks promising, then I need to turn that into ASM code. That is
likely to smaller, faster, fully ABI-conforming, and with hopefully
fewer bugs.

On 31/08/2023 15:30, Bart wrote:
> On 31/08/2023 13:36, David Brown wrote:
>> On 31/08/2023 12:58, Bart wrote:
>>> On 30/08/2023 23:54, Paul Edwards wrote:
>>>> Hi Bart.
>>>>
>>>> Next error I have is:
>>>>
>>>> cc64 -c -out:cclib/cclib.obj cclib/cclib.i
>>>> Compiling cclib/cclib.i to cclib/cclib.obj
>>>
>>>
>>> BTW the -out option is not needed here. The output file uses the same
>>> filename and the same path, just the extension is changed.
>>>
>>> So the generated .obj file is in the same folder as the .c or .i
>>> source file. The same applies when generating executables; you can
>>> compile code remotely.
>>>
>>> Other C compilers may be different; gcc for example applies the right
>>> extension, but the object file (or executable) is written to the
>>> current directory. And others tend to copy gcc.
>>>
>>
>> Putting object files (or other generated files) in the same directory
>> as the source files is okay for small projects.  If you've only got a
>> half-dozen source files, it can be tidy to keep them all in the same
>> directory.
>>
>> If you are doing something bigger you almost invariably want to keep
>> the source tree and the generated files in separate directories.  It
>> makes it much easier to see what's changed, to clean out object files,
>> to track source in a revision control system of some kind, to find the
>> source files amongst all the generated files, etc.  Details, of
>> course, vary by person and project - too many directories and
>> subdirectories makes it hard to keep an overview of the files, as does
>> too few directories.  This is known as "out of tree builds", and is
>> the norm for most projects above a certain size.
>>
>> So whatever your default here - whether it is generating the object
>> file in the same directory as the source file, or generating it in the
>> current directory - it will be convenient in some cases, and
>> completely wrong in other cases.
>
> But putting it in the current directory is sloppy. The current location
> can be arbitrary (or it might not be writeable):
>
>  c:\random>gcc \proj1\foo.c
>  c:\random>gcc \proj2\bar.c
>
> Here, both compilations generate a.exe. But to cap that, both end up in
> c:\random; the second overwrites the first, something you might be
> unaware of.
>
> If I do:
>
>  c:\random>gcc \proj1\foo.c
>  c:\random>gcc \proj2\bar.c
>
> then there are three differences from gcc:

This is not necessarily a typo due to forgetting to change 'gcc' to
'bcc'. I could have decided to rename 'bcc.exe' to 'gcc.exe' for this test.

On Thursday, August 31, 2023 at 10:57:05 PM UTC+8, Bart wrote:

> > Sure. The new cc64 (if it arrives) will still be public domain
> > though, right?

> It can be. (Personally I don't care about that aspect at all.)

If you don't care, then please keep it public domain, because
that is the whole point - I care, and I am working with people
who care. And all the people I work with have attempted or
are still attempting to write a public domain C90-compliant
compiler, but nobody has reached cc64 level yet.

> I can confirm that I've started an overhaul of the project, which will
> have a working title of 'DD' to distinguish it from 'CC'. The first
> stage is to get it to generate a new intermediate (IL) code (perhaps
> within a week).
>
> If that looks promising, then I need to turn that into ASM code. That is
> likely to smaller, faster, fully ABI-conforming, and with hopefully
> fewer bugs.

Ok, cool.

Note that it was suggested to take this to email, but I
personally don't think it is off-topic. If you do, my email
address is mutazilah AT gmail DOT com.

I have a new problem regardless.

C:\devel\pdos\pdmake>pdmake -f makefile.n64
rm -f main.obj read.obj rule.obj variable.obj xmalloc.obj hashtab.obj ../pdpclib/x64supb.obj pdmake.exe
pdcc -E -I. -I./hashtab -I../pdpclib -D__WIN32__ -D__NOBIVA__ -D__64BIT__ -D__CC64__ -o main.i main.c
cc64 -c -out:main.obj main.i
Compiling main.i to main.obj
rm -f main.i
pdcc -E -I. -I./hashtab -I../pdpclib -D__WIN32__ -D__NOBIVA__ -D__64BIT__ -D__CC64__ -o read.i read.c
cc64 -c -out:read.obj read.i
Compiling read.i to read.obj
rm -f read.i
pdcc -E -I. -I./hashtab -I../pdpclib -D__WIN32__ -D__NOBIVA__ -D__64BIT__ -D__CC64__ -o rule.i rule.c
cc64 -c -out:rule.obj rule.i
Compiling rule.i to rule.obj
rm -f rule.i
pdcc -E -I. -I./hashtab -I../pdpclib -D__WIN32__ -D__NOBIVA__ -D__64BIT__ -D__CC64__ -o variable.i variable.c
cc64 -c -out:variable.obj variable.i
Compiling variable.i to variable.obj
rm -f variable.i
pdcc -E -I. -I./hashtab -I../pdpclib -D__WIN32__ -D__NOBIVA__ -D__64BIT__ -D__CC64__ -o xmalloc.i xmalloc.c
cc64 -c -out:xmalloc.obj xmalloc.i
Compiling xmalloc.i to xmalloc.obj
rm -f xmalloc.i
pdcc -E -I. -I./hashtab -I../pdpclib -D__WIN32__ -D__NOBIVA__ -D__64BIT__ -D__CC64__ -o ./hashtab/hashtab.i ./hashtab/hashtab.c
cc64 -c -out:hashtab.obj ./hashtab/hashtab.i
Compiling ./hashtab/hashtab.i to hashtab.obj
rm -f ./hashtab/hashtab.i
pdld -s -nostdlib --no-insert-timestamp --image-base 0x400000 -o pdmake.exe ../pdpclib/w32start.obj main.obj read.obj rule.obj variable.obj xmalloc.obj hashtab.obj ../pdpclib/x64supb.obj ../pdpclib/msvcrt.lib

C:\devel\pdos\pdmake>pdmake --help
before

C:\devel\pdos\pdmake>

C:\devel\pdos\pdmake>git diff .
diff --git a/pdmake/hashtab/hashtab.c b/pdmake/hashtab/hashtab.c
index 57184ed4..00e43d9b 100644
--- a/pdmake/hashtab/hashtab.c
+++ b/pdmake/hashtab/hashtab.c
@@ -18,6 +18,7 @@

#include <math.h>
#include <stddef.h>
+#include <stdio.h>

#include "hashtab.h"

@@ -85,6 +86,7 @@ static int rehash (struct hashtab *hashtab, size_t target_size)
{
struct hashtab old_hashtab = *hashtab;
struct hashtab_entry *entry;
+ double ggg;

size_t i;

@@ -96,6 +98,11 @@ static int rehash (struct hashtab *hashtab, size_t target_size)
}

hashtab->probe_limit = max (internal_log2 (hashtab->size), MINIMAL_PROBE_LIMIT);
+ + printf("before\n");
+ ggg = hashtab->max_load_factor * hashtab->size;
+ printf("after\n");
+ hashtab->max_number_of_elements = ceil (hashtab->max_load_factor * hashtab->size);

/* Allocates size + probe_limit + 1 so no bounds checking needs to be done. */

C:\devel\pdos\pdmake>

A double multiplied by a long long is crashing.

If I cast the long long to int, it doesn't crash.

Code is all in sourceforge.

Note that it could be related to the assembler support
routines. We have converted some of your bcclib.asm
into intel syntax, which can be found here:

https://sourceforge.net/p/pdos/gitcode/ci/master/tree/pdpclib/x64supb.asm

And relevant stuff copied here, in case you can see
something we have done wrong in the conversion:

# These routines were copied (and then modified) from bcclib.asm generated
# by the public domain cc64, and are used for cc64
# (Converted to PDAS .intel_syntax noprefix by guessing.)

..globl m$ufloat_r64u32
m$ufloat_r64u32:
mov ecx, ecx # clear top half (already done if value just moved there)
cvtsi2sd xmm15, rcx
ret

..globl m$ufloat_r32u32
m$ufloat_r32u32:
mov ecx, ecx
cvtsi2ss xmm15, rcx
ret

..globl m$ufloat_r64u64
m$ufloat_r64u64:
cmp ecx, 0
jl fl1
#number is positive, so can treat like i64
cvtsi2sd xmm15, rcx
ret
fl1: #negative value
and rcx, QWORD PTR mask63[rip] #clear top bit (subtract 2**63)
cvtsi2sd xmm15, rcx
addsd xmm15, QWORD PTR offset64[rip] #(add 2**63 back to result)
ret

..globl m$ufloat_r32u64
m$ufloat_r32u64:
cmp ecx, 0
jl fl2
#number is positive, so can treat like i64
cvtsi2ss xmm15, rcx
ret
fl2: #negative value
and rcx, QWORD PTR mask63[rip] #clear top bit (subtract 2**63)
cvtsi2ss xmm15, rcx
addss xmm15, DWORD PTR offset32[rip] #(add 2**63 back to result)
ret

..section rdata
mask63:
.quad 0x7fffffffffffffff
offset64:
.quad 9223372036854775808 # 2**63 as r64
offset32:
.quad 9223372036854775808 # 2**63 as r32

Thanks. Paul.

On 31/08/2023 16:30, Bart wrote:
> On 31/08/2023 13:36, David Brown wrote:
>> On 31/08/2023 12:58, Bart wrote:
>>> On 30/08/2023 23:54, Paul Edwards wrote:
>>>> Hi Bart.
>>>>
>>>> Next error I have is:
>>>>
>>>> cc64 -c -out:cclib/cclib.obj cclib/cclib.i
>>>> Compiling cclib/cclib.i to cclib/cclib.obj
>>>
>>>
>>> BTW the -out option is not needed here. The output file uses the same
>>> filename and the same path, just the extension is changed.
>>>
>>> So the generated .obj file is in the same folder as the .c or .i
>>> source file. The same applies when generating executables; you can
>>> compile code remotely.
>>>
>>> Other C compilers may be different; gcc for example applies the right
>>> extension, but the object file (or executable) is written to the
>>> current directory. And others tend to copy gcc.
>>>
>>
>> Putting object files (or other generated files) in the same directory
>> as the source files is okay for small projects.  If you've only got a
>> half-dozen source files, it can be tidy to keep them all in the same
>> directory.
>>
>> If you are doing something bigger you almost invariably want to keep
>> the source tree and the generated files in separate directories.  It
>> makes it much easier to see what's changed, to clean out object files,
>> to track source in a revision control system of some kind, to find the
>> source files amongst all the generated files, etc.  Details, of
>> course, vary by person and project - too many directories and
>> subdirectories makes it hard to keep an overview of the files, as does
>> too few directories.  This is known as "out of tree builds", and is
>> the norm for most projects above a certain size.
>>
>> So whatever your default here - whether it is generating the object
>> file in the same directory as the source file, or generating it in the
>> current directory - it will be convenient in some cases, and
>> completely wrong in other cases.
>
> But putting it in the current directory is sloppy. The current location
> can be arbitrary (or it might not be writeable):
>
>  c:\random>gcc \proj1\foo.c
>  c:\random>gcc \proj2\bar.c
>

So don't do that.

Make sure you are in the appropriate directory, then compile - or give
the output file name directly. As I said, whatever default you use, it
will be wrong sometimes.

> Here, both compilations generate a.exe. But to cap that, both end up in
> c:\random; the second overwrites the first, something you might be
> unaware of.

If you are not aware of that, you'll learn pretty quickly!

>
> If I do:
>
>  c:\random>gcc \proj1\foo.c
>  c:\random>gcc \proj2\bar.c
>
> then there are three differences from gcc:
>
>  (1) The executables are called foo.exe and bar.exe respectively
>  (2) They are written to their respective folders
>  (3) The compiler will report exactly what it is doing so there
>      are fewer surprises:
>
>      Compiling \proj1\foo.c to \proj2\foo.exe
>
> You can use -v with gcc, but it is not helpful!

Nor is it helpful for the compiler to tell me what it is doing -
generally I know what it is doing - it is doing what I told it to do.
It is only if it can't do that (due to some error) that I want to be told.

Again, different defaults suit different uses and different people.
Plenty of gcc's defaults are inappropriate for me, and I think should be
different - but your compiler's defaults are no better. You only
/think/ that your compiler's defaults are good, because they suit you
personally - don't expect them to be ideal for anyone else. For any big
program, excluding ones they write themselves to use themselves, some of
the default settings will be sub-optimal or unusable.

So your compiler's defaults are not worse than any others, nor are they
better - except for your own personal tastes.

>
>> So IMHO it's a good habit to have an "-out" (or equivalent) option in
>> your build files - then you know exactly where things are going.
>>
>> People who use "make" have simple and common shortcuts for this.
>> Since you prefer not to use "make" or any alternative build system,
>> you might want to at least add an option to specify an output
>> directory.  Then, for example, "cc64 -c -outdir:build src/file.c"
>
> Actually I have exactly that option, called '-outpath', but in my main
> compilers; I haven't put it into bcc because bcc is an older project.
>

Fair enough.

Do you also have a "-quiet" option to hide non-essential messages?
That's also something I like in compilers and other tools, if it is not
the default - though again, preferences vary.

On 2023-08-31, Bart <bc@freeuk.com> wrote:
> On 31/08/2023 13:36, David Brown wrote:
>> So whatever your default here - whether it is generating the object file
>> in the same directory as the source file, or generating it in the
>> current directory - it will be convenient in some cases, and completely
>> wrong in other cases.
>
> But putting it in the current directory is sloppy. The current location
> can be arbitrary (or it might not be writeable):
>
> c:\random>gcc \proj1\foo.c
> c:\random>gcc \proj2\bar.c
>
> Here, both compilations generate a.exe. But to cap that, both end up in
> c:\random; the second overwrites the first, something you might be
> unaware of.

Nobody cares about this in the world of building components from C.

The build systems by and large operate from the assumption that
the current working directory is the top-level build directory.

If you do

$ make -f /path/to/project/build/Makefile

it will not work. The correct ways, if you're not in that
directory are any of these:

$ cd /path/to/project/build; make

or

$ make -C /path/to/project/build

or, if the name of the makefile is nonstandard:

$ make -C /path/to/project/build -f Makefile.foo

The argument to -f is considered from the directory that
was changed into with -C.

While you could probably make a Makefile that can be dispatched from
anywhere without changing the current working directory, I suspect there
is zero demand.

If you end up feeding resolvd, absolute paths to your tools, that's
actually a negative. The __FILE__ macro resolves to something that
makes no ssense on the target system where the program is running
like "/home/bob/open-source-projects/foo/src/parsere.c"instead of just
"src/parser.c".

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

On 31/08/2023 18:36, David Brown wrote:
> On 31/08/2023 16:30, Bart wrote:
>> On 31/08/2023 13:36, David Brow

>> But putting it in the current directory is sloppy. The current
>> location can be arbitrary (or it might not be writeable):
>>
>>   c:\random>gcc \proj1\foo.c
>>   c:\random>gcc \proj2\bar.c
>>
>
> So don't do that.
>
> Make sure you are in the appropriate directory, then compile - or give
> the output file name directly.  As I said, whatever default you use, it
> will be wrong sometimes.

But it's an extra thing that could be easily have been done right.
Compilers work for us, not us for them.

Suppose gcc decided to put the output files in a root directory, or some
place where it would be a very bad idea to write or overwrite a file.

You can't just fob people off with 'So don't do that'; it needs to be
fixed. But then neither can you further fob them off with: 'It's always
done that, and further, one person in 1000, or some makefile from 1974,
depends on it, so we can't change it, ever'.

>> Here, both compilations generate a.exe. But to cap that, both end up
>> in c:\random; the second overwrites the first, something you might be
>> unaware of.
>
> If you are not aware of that, you'll learn pretty quickly!

It may not have crossed your mind, or if it had, your might assume that
two distinct a.exe files were produced.

>>
>> If I do:
>>
>>   c:\random[gcc \proj1\foo.c
>>   c:\random>gcc \proj2\bar.c
>>
>> then there are three differences from gcc:
>>
>>   (1) The executables are called foo.exe and bar.exe respectively
>>   (2) They are written to their respective folders
>>   (3) The compiler will report exactly what it is doing so there
>>       are fewer surprises:
>>
>>       Compiling \proj1\foo.c to \proj2\foo.exe
>>
>> You can use -v with gcc, but it is not helpful!
>
> Nor is it helpful for the compiler to tell me what it is doing -

If the compiler is doing multiple files, especially a slow compiler,
then it is highly useful to know where it's up to, or what it's stuck on.

But this seems to be a Linux thing: if I do 'cp *.c dest', then nothing
is output, until you get the prompt back. So, did work, did it copy
anything, was it one big file, or lots of small ones?

If I do 'copy *.c test' on Windows, it shows each file copied, and it
tells how many files were copied in all. The 'cp' command needs '-v' to
force to show what it's doing.

The defaults are backwards.

> generally I know what it is doing - it is doing what I told it to do. It
> is only if it can't do that (due to some error) that I want to be told.
>
> Again, different defaults suit different uses and different people.
> Plenty of gcc's defaults are inappropriate for me, and I think should be
> different - but your compiler's defaults are no better.  You only
> /think/ that your compiler's defaults are good, because they suit you
> personally

No, they make more sense for casual use from a command line for anybody.

> Do you also have a "-quiet" option to hide non-essential messages?
> That's also something I like in compilers and other tools, if it is not
> the default - though again, preferences vary.

Yes, I think it's -q. If a lot of files are being processed, then you
might want to turn it off (or if timing, it can make a small difference).

However gcc's -v option generates 40 times as much output as my compiler
without -q. So it's either far too verbose, or not enough.

On 2023-08-31, Kaz Kylheku <864-117-4973@kylheku.com> wrote:
> On 2023-08-31, Bart <bc@freeuk.com> wrote:
>> On 31/08/2023 13:36, David Brown wrote:
>>> So whatever your default here - whether it is generating the object file
>>> in the same directory as the source file, or generating it in the
>>> current directory - it will be convenient in some cases, and completely
>>> wrong in other cases.
>>
>> But putting it in the current directory is sloppy. The current location
>> can be arbitrary (or it might not be writeable):
>>
>> c:\random>gcc \proj1\foo.c
>> c:\random>gcc \proj2\bar.c
>>
>> Here, both compilations generate a.exe. But to cap that, both end up in
>> c:\random; the second overwrites the first, something you might be
>> unaware of.
>
> Nobody cares about this in the world of building components from C.
>
> The build systems by and large operate from the assumption that
> the current working directory is the top-level build directory.

In fact, I should add, there is a practice of separating source
and build directories.

Any properly constructed AutoConf project supports this:

$ mkdir build-dir
$ cd build-dir
build-dir $ /path/to/some/project/configure

You create a build directory and call a configure script located
elsewhere. It prepares that build directory for building the program.

build-dir $ make

The build references source files in /path/to/some/project.

It drops object files here, inthis directory. Or some child like obj/
depending on the exact build system.

You don't want to be dropping binaries in the sae place where the
sources are located.

*THAT* location may be read-only!

Building sources that sit on a read-only mounted filesystem is a thing.

The MIT XWindow system devised a scheme for dealing with this: the lndir
utility.

With lndir, you create a parallel tree to the target source tree,
populated with symlinks:

$ mkdir build-dir
$ cd build-dir
build-dir$ lndir /path/to/some/project .

A directory structure skeleton is created mirroring that of the
target projet, and populated with symlinks to each of its files.

lndir's man page says:

"This is usually useful for maintaining source code for different
machine architectures. You create a shadow directory containing links
to the real source, which you will have usually mounted from a
remote machine."

I was once employed producing a from-scratch embedded Linux distro,
and doing kernel work, toolchain support and such.

I religiously used separate build directories for everything I built.
A few programs refused to cooperate. For those that couldn't be patched,
I reached for lndir.

The Linux kernel cannot (or couldn't at the time?) support separate
build directories; I used lndir and it worked like a charm. That allowed
me to build the same tree for x86 and MIPS without its cooperation.

(The one thing that defeated lndir was that goddamed ASDF build system
for Common Lisp. Internally, it called (truepath ...) which resolves
all symlinks, and then it calculated object paths from the resolved
source paths.)

But anyway, if you're sitting in a different tree from where your
source files are, you rarely want object files to be pooped into
that tree, instead of this one here.

If you do, you're an oddball, and nobody will listen to you;
they will say, just change to that directory and work there.

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

On 31/08/2023 20:17, Kaz Kylheku wrote:
> On 2023-08-31, Bart <bc@freeuk.com> wrote:
>> On 31/08/2023 13:36, David Brown wrote:
>>> So whatever your default here - whether it is generating the object file
>>> in the same directory as the source file, or generating it in the
>>> current directory - it will be convenient in some cases, and completely
>>> wrong in other cases.
>>
>> But putting it in the current directory is sloppy. The current location
>> can be arbitrary (or it might not be writeable):
>>
>> c:\random>gcc \proj1\foo.c
>> c:\random>gcc \proj2\bar.c
>>
>> Here, both compilations generate a.exe. But to cap that, both end up in
>> c:\random; the second overwrites the first, something you might be
>> unaware of.
>
> Nobody cares about this in the world of building components from C.

I guess that's because people using off-the-shelf tools are forced to do
things the way the tools dictate. They don't have a choice!

After a while they become inured enough to think that's the only way it
can be.

>
> The build systems by and large operate from the assumption that
> the current working directory is the top-level build directory.

So, you have to build things in-situ. To build multiple projects, you
have to navigate from folder to folder.

Whereas I can build all my language projects from one location, for example:

c:\demo>mm \ax\aa
Compiling \ax\aa.m------ to \ax\aa.exe

c:\demo>mm \cx\cc
Compiling \cx\cc.m------ to \cx\cc.exe

c:\demo>mm \qx\qq
Compiling \qx\qq.m------ to \qx\qq.exe

c:\demo>mm \mx\mm
Compiling \mx\mm.m------ to \mx\mm.exe

> If you do
>
> $ make -f /path/to/project/build/Makefile
>
> it will not work.

Why doesn't the tool just navigate to that path? And maybe, navigate
back to the start point when it's done?

Oh, I get it, 'zero demand'!

(You can see I don't use makefiles; most of them would consist of one line.)

The correct ways, if you're not in that
> directory are any of these:
>
> $ cd /path/to/project/build; make
>
> or
>
> $ make -C /path/to/project/build
>
> or, if the name of the makefile is nonstandard:
>
> $ make -C /path/to/project/build -f Makefile.foo
>
> The argument to -f is considered from the directory that
> was changed into with -C.
>
> While you could probably make a Makefile that can be dispatched from
> anywhere without changing the current working directory, I suspect there
> is zero demand.

I was right...

> If you end up feeding resolvd, absolute paths to your tools, that's
> actually a negative. The __FILE__ macro resolves to something that
> makes no ssense on the target system where the program is running
> like "/home/bob/open-source-projects/foo/src/parsere.c"instead of just
> "src/parser.c".

__FILE__ is a compile-time thing. But people do feed absolute or
sometimes relative paths to their compilers; the OP did so for example.

Also, that Baby X RC project was built with a command line like this:

gcc *.c abc\*.c def\*.c

Whatever path is provided for a source file, is what ends up as a a
prefix to __FILE__. You don't want a dozen files, all called foo.c but
in different folders, to all show "foo.c" in their __FILE__ macros; that
is not helpful!

Bart <bc@freeuk.com> writes:
[...]
> I can confirm that I've started an overhaul of the project, which will
> have a working title of 'DD' to distinguish it from 'CC'. The first
> stage is to get it to generate a new intermediate (IL) code (perhaps
> within a week).

There's a common Unix file conversion tool called "dd". Do whatever you
like with that information.

https://pubs.opengroup.org/onlinepubs/9699919799/utilities/dd.html

--
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
Will write code for food.
void Void(void) { Void(); } /* The recursive call of the void */

scott@slp53.sl.home (Scott Lurndal) writes:

> Paul Edwards <mutazilah@gmail.com> writes:

>>Ok, thanks for the info.
>>
>>Next problem I have encountered is this:
>
> Please take it to email. This is not relevent to comp.lang.c.

It is certainly niche, but it's all about C. I'd say these posts are
among the most topical there have been in a while. As it happens, they
don't interest me much, but that not the same thing at all.

--
Ben.

On 31/08/2023 20:28, Kaz Kylheku wrote:
> On 2023-08-31, Kaz Kylheku <864-117-4973@kylheku.com> wrote:
>> On 2023-08-31, Bart <bc@freeuk.com> wrote:
>>> On 31/08/2023 13:36, David Brown wrote:
>>>> So whatever your default here - whether it is generating the object file
>>>> in the same directory as the source file, or generating it in the
>>>> current directory - it will be convenient in some cases, and completely
>>>> wrong in other cases.
>>>
>>> But putting it in the current directory is sloppy. The current location
>>> can be arbitrary (or it might not be writeable):
>>>
>>> c:\random>gcc \proj1\foo.c
>>> c:\random>gcc \proj2\bar.c
>>>
>>> Here, both compilations generate a.exe. But to cap that, both end up in
>>> c:\random; the second overwrites the first, something you might be
>>> unaware of.
>>
>> Nobody cares about this in the world of building components from C.
>>
>> The build systems by and large operate from the assumption that
>> the current working directory is the top-level build directory.
>
> In fact, I should add, there is a practice of separating source
> and build directories.
>
> Any properly constructed AutoConf project supports this:
>
> $ mkdir build-dir
> $ cd build-dir
> build-dir $ /path/to/some/project/configure
>
> You create a build directory and call a configure script located
> elsewhere. It prepares that build directory for building the program.
>
>
> build-dir $ make
>
> The build references source files in /path/to/some/project.
>
> It drops object files here, inthis directory. Or some child like obj/
> depending on the exact build system.
>
> You don't want to be dropping binaries in the sae place where the
> sources are located.
>
> *THAT* location may be read-only!

The location that you invoke the compiler from may be read-only!

For example, DVD-ROM drive, if you still have one.

> Building sources that sit on a read-only mounted filesystem is a thing.

I can build and run applications in my language on a read-only device
like this:

ms prog

This runs the app from source without creating an executable file.

>
> The MIT XWindow system devised a scheme for dealing with this: the lndir
> utility.
>
> With lndir, you create a parallel tree to the target source tree,
> populated with symlinks:
>
>
> $ mkdir build-dir
> $ cd build-dir
> build-dir$ lndir /path/to/some/project .
>
> A directory structure skeleton is created mirroring that of the
> target projet, and populated with symlinks to each of its files.
>
> lndir's man page says:
>
> "This is usually useful for maintaining source code for different
> machine architectures. You create a shadow directory containing links
> to the real source, which you will have usually mounted from a
> remote machine."
>
> I was once employed producing a from-scratch embedded Linux distro,
> and doing kernel work, toolchain support and such.
>
> I religiously used separate build directories for everything I built.
> A few programs refused to cooperate. For those that couldn't be patched,
> I reached for lndir.
>
> The Linux kernel cannot (or couldn't at the time?) support separate
> build directories; I used lndir and it worked like a charm. That allowed
> me to build the same tree for x86 and MIPS without its cooperation.
>
> (The one thing that defeated lndir was that goddamed ASDF build system
> for Common Lisp. Internally, it called (truepath ...) which resolves
> all symlinks, and then it calculated object paths from the resolved
> source paths.)
>
> But anyway, if you're sitting in a different tree from where your
> source files are, you rarely want object files to be pooped into
> that tree, instead of this one here.

And yet, when you do:

gcc hello.c

it will write a.out or a.exe in the same folder.

> If you do, you're an oddball, and nobody will listen to you;
> they will say, just change to that directory and work there.

I guess I'm an oddball. I routinely modify source files and write new
EXEs in the same folder. What's the point of mucking about with a
special folder just for the one EXE file?

For a user installation, then sure, but a user installation is something
removed from a developer's directory tree.

The impression I get is that in Linux, the entire file system is
considered to be one giant developer's tree, and installed software is
part of it.

Bart <bc@freeuk.com> writes:
[...]
> If the compiler is doing multiple files, especially a slow compiler,
> then it is highly useful to know where it's up to, or what it's stuck
> on.
>
> But this seems to be a Linux thing: if I do 'cp *.c dest', then
> nothing is output, until you get the prompt back. So, did work, did it
> copy anything, was it one big file, or lots of small ones?
>
> If I do 'copy *.c test' on Windows, it shows each file copied, and it
> tells how many files were copied in all. The 'cp' command needs '-v'
> to force to show what it's doing.
>
> The defaults are backwards.
[...]

I acknowledge that you prefer tools to be verbose, and that you have
perfectly valid reasons to want a compiler to show what it's doing and
for a file copying program to print the name of each file as it's
copying it.

Please acknowledge that others have valid preferences that differ from
yours. I'm not even asking you to understand why, or to like it, just
that different valid preferences exist.

Or don't. Up to you.

--
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
Will write code for food.
void Void(void) { Void(); } /* The recursive call of the void */

In article <87o7in7yqm.fsf@nosuchdomain.example.com>,
Keith Thompson <Keith.S.Thompson+u@gmail.com> wrote:
....
>I acknowledge that you prefer tools to be verbose, and that you have
>perfectly valid reasons to want a compiler to show what it's doing and
>for a file copying program to print the name of each file as it's
>copying it.
>
>Please acknowledge that others have valid preferences that differ from
>yours. I'm not even asking you to understand why, or to like it, just
>that different valid preferences exist.

Yes, but...

The problem with this form of argumentation is that it fails to acknowledge
the difference between actual constructive belief and mere defense of the
status quo.

I.e., one often (and by "often", I mean almost universally) gets the
impression that people who criticize posters like "Bart" aren't doing so
out of a genuine belief that they are right and Bart is wrong, but rather
out of general fear of change (i;e., the fear of the cognitive dissonance
that acceptance of Bart's ideas would cause them).

I get this a lot in the responses I get to my own posts.

--
The randomly chosen signature file that would have appeared here is more than 4
lines long. As such, it violates one or more Usenet RFCs. In order to remain
in compliance with said RFCs, the actual sig can be found at the following URL:
http://user.xmission.com/~gazelle/Sigs/Noam