On Tuesday, March 22, 2022 at 12:00:06 PM UTC+11, muta...@gmail.com wrote:

> > This is for a project that is 20 .h/.c files, some 6000 lines in total;
> > not a big project, and the self-hosting comment gives the impression
> > that it will build with pretty much any compiler as most support a
> > bigger subset.

> Yes, if you do:
>
> pdmake -f makefile.w32
> in \devel\subc\src
> it will build with gccwin (included in the full PDOS/386 distribution) instead.

A caveat.

I found that I needed to compile with "char" being
unsigned for SubC to work properly after being compiled with
gccwin.

BFN. Paul.

On 22/03/2022 00:59, muta...@gmail.com wrote:
> On Tuesday, March 22, 2022 at 10:50:09 AM UTC+11, Bart wrote:
>

> I have different instructions for Windows, but I haven''t
> written them down.
>
> Add \dos (which contains only Windows executables,
> almost all dependent on just msvcrt.dll but some depend
> on kernel32.dll instead) to your path and then go:
>
> cd \devel\world
> pdmake -f worldw2.mak
>
>> "The Windows version of SubC requires the MinGW infrastructure,
>> but does not use the GNU libc. To build the compiler, the MSYS
>> environment of MinGW is needed."
>
> I have replacement instructions, also not written down:
>
> Go:
>
> cd \devel\subc\src
> pdmake -f makefile.p32
>
>> "* DO NOT use "make". It will probably not work. Use the
>> WINBUILD.BAT script instead."
>
> This is not required.
>
>> Too right! And WINBUILD still needs that MSYS stuff.
>
> This is not required.
>
>> All the docs including for DOS have long lists of things imported from
>> Unix, and in fact you have to cross-compile from Unix.
>
> To compile for DOS run sccdos.exe instead.
>
>> These aren't the dependency problems you need in your post-apocalyptic
>> scenario!
>
> If you just boot the UC disk and go through the readme
> files, none of those dependencies arise.
>
>> This is for a project that is 20 .h/.c files, some 6000 lines in total;
>> not a big project, and the self-hosting comment gives the impression
>> that it will build with pretty much any compiler as most support a
>> bigger subset.
>
> Yes, if you do:
>
> pdmake -f makefile.w32
> in \devel\subc\src
> it will build with gccwin (included in the full PDOS/386 distribution) instead.

I don't believe in unnecessary tools. This is a C program, and all it
should need is a C compiler (actually I was trying mine).

The first obstacle is that some header files are not present: cg.c/cg.h,
but these can to copied from elsewhere via manual configuration.

The next is that these macros are not defined anywhere (maybe they're
D-macros?); I've just given them dummy values:

#define ASCMD "AAA"
#define LDCMD "LLL"
#define SYSLIBC "SSS"
#define OS "OOO"

With that, it was able to compile hello.c to hello.s, but failed on
trying to invoke an assembler AAA, unsurprisingly.

But it shows that even if `make` is dispensed with, it still needs a
separate assembler and linker are needed.

(Tiny C is a self-contained C99 compiler, much better suited for your
purpose, and it's only twice as large as subc.exe, but then subc.exe
needs those extra components.

However it probably won't support your desired targets.)

On Tuesday, March 22, 2022 at 12:51:02 PM UTC+11, Bart wrote:

> I don't believe in unnecessary tools. This is a C program, and all it
> should need is a C compiler (actually I was trying mine).
>
> The first obstacle is that some header files are not present: cg.c/cg.h,
> but these can to copied from elsewhere via manual configuration.
>
> The next is that these macros are not defined anywhere (maybe they're
> D-macros?); I've just given them dummy values:
>
> #define ASCMD "AAA"
> #define LDCMD "LLL"
> #define SYSLIBC "SSS"
> #define OS "OOO"
>
> With that, it was able to compile hello.c to hello.s, but failed on
> trying to invoke an assembler AAA, unsurprisingly.

The source I provide in \devel\subc\src has all the defines
ready for Windows.

> But it shows that even if `make` is dispensed with, it still needs a
> separate assembler and linker are needed.

Yes.

> (Tiny C is a self-contained C99 compiler, much better suited for your
> purpose, and it's only twice as large as subc.exe, but then subc.exe
> needs those extra components.
>
> However it probably won't support your desired targets.)

Tiny C is not public domain, so I have no interest in that.
I can just use gccwin.exe if I want a copyrighted compiler.

BFN. Paul.

On Tuesday, March 22, 2022 at 12:51:02 PM UTC+11, Bart wrote:

> With that, it was able to compile hello.c to hello.s, but failed on
> trying to invoke an assembler AAA, unsurprisingly.

And I always compile with "-S" to avoid the assembler
getting invoked.

And one other thing - some of the executables I provide
are dependent on both msvcrt.dll and kernel32.dll.

BFN. Paul.

2022-03-21 at 15:00 -0700, muta...@gmail.com wrote:
> You suggested using OCR software to read the paper, but
> if we're in a post-apocalyptic world, aren't punched cards
> easier to be machine-read than attempting to OCR characters?

OCR is just software. Hardware-wise, it requires only "something" that
is able to put the A4 sheet into a file. A punched card would require a
specific machinery to be read. Also, OCR can be performed by a human
without (too much) errors. Reading punched cards is harder and slower.

> PDOS is going to be first-to-market after the apocalypse.

My bets are on SvarDOS (http://svardos.org). But it's definitely a good
thing for new-age cavemen to have choice when it comes to DOS computing.

Mateusz

On 21/03/2022 21:50, muta...@gmail.com wrote:
> On Monday, March 21, 2022 at 11:51:47 PM UTC+11, David Brown wrote:
>
>> Let's now get back to the C. When you say you have implemented a subset
>> of C90, what is missing, and why?
>
> It isn't me who wrote SubC. I don't have the required skills
> to write a compiler. I'm not good with complex algorithms.
>
> The things missing are listed here:
>
> https://www.t3x.org/subc/README-current.html
>
> search for "full c89".
>
> Almost all of those things don't actually affect me. The
> preprocessor shortcomings are overcome by using pdcc,
> a public domain prepreprocessor. I'm only interested in
> the 80386 at the moment so I just get the preprocessor
> to define long=int and short=int. I have my own C library.
>
> Although my coding style normally puts all the variables
> at the top of a function, occasionally I am "lazy" and just
> declare a variable inside a block. I do have some such
> code. So if I can't change SubC I would need to change
> that coding style.
>
> Another thing I do is initialize local variables, even though
> it is something that happens at run-time, and that doesn't
> work. Maybe because it is difficult to parse or something.
>
> If things are difficult to parse, I'm willing to change my coding
> style to SubC, rather than wait for someone to release a public
> domain fully-C90-compliant compiler - something no-one has
> been willing to do for 50 years.
>
> Note that a public domain 80386 assembler capable of
> handling the output from SubC was only recently written
> (by someone from Slovakia). And an a.out linker by someone
> from Italy. These were the final things that allowed the
> "University Challenge" disk to be produced.
>
> BFN. Paul.
>

I looked at the link. To me, the restrictions there are /massive/, even
for a 20+ years outdated version of C. I've had occasion to work with
"C" compilers with serious limitations, missing features or bugs in
connection with some microcontrollers, and it's not something I
personally would be willing to accept again. It looks like this
software is part of a book about how to write a C compiler - it is no
more than a basic starting point of some important features, with the
rest left as homework for the reader.

Do you have plans to work on the compiler and improve it? You
personally might be happy (or at least willing!) to write code to its
limitations, but I doubt if you'll find many other programmers who will
join you or use your software when the key tool is at that level. Maybe
the original SubC author is working more on it, or interested in
collaboration?

On Tuesday, March 22, 2022 at 7:05:00 PM UTC+11, Mateusz Viste wrote:

> > You suggested using OCR software to read the paper, but
> > if we're in a post-apocalyptic world, aren't punched cards
> > easier to be machine-read than attempting to OCR characters?

> OCR is just software.

Complex software.

> Hardware-wise, it requires only "something" that
> is able to put the A4 sheet into a file.

I wouldn't say "only". That's a tough task too.

> A punched card would require a
> specific machinery to be read.

Machinery that has existed for centuries, with "looms", right?

> Also, OCR can be performed by a human
> without (too much) errors. Reading punched cards is harder and slower.

When reading the machine code you can't have any errors.
It is good that humans can read it by hand if necessary, and
if it comes down to that, the fact that it is harder and slower
is unlikely to be the biggest issue.

> > PDOS is going to be first-to-market after the apocalypse.

> My bets are on SvarDOS (http://svardos.org). But it's definitely a good
> thing for new-age cavemen to have choice when it comes to DOS computing.

Why are you betting on a 16:16 processor? Historically
32-bit processors predated that, right?

And 16-bit processors require a different software suite,
won't they? I don't think you can fit an OS written in C
and a C compiler written in C into 64k. SubC itself weighs
in at 64k, not including the C library (msvcrt.dll is used
instead).

BFN. Paul.

On Tuesday, March 22, 2022 at 7:59:27 PM UTC+11, David Brown wrote:

> I looked at the link. To me, the restrictions there are /massive/, even

Care to be specific?

> for a 20+ years outdated version of C. I've had occasion to work with
> "C" compilers with serious limitations, missing features or bugs in
> connection with some microcontrollers, and it's not something I
> personally would be willing to accept again. It looks like this
> software is part of a book about how to write a C compiler - it is no
> more than a basic starting point of some important features, with the
> rest left as homework for the reader.

Sure.

> Do you have plans to work on the compiler and improve it? You

Right at the moment I don't have specific plans for my life.
I've reached this milestone a few days ago and now need to
consolidate.

I'm lacking a lot of the theoretical background to all
components, plus I'm not very good with complex
algorithms. I have skills in other areas (but don't know
how to describe it). I just bludgeoned my way to get
here.

> personally might be happy (or at least willing!) to write code to its
> limitations,

It's actually more that I threw my existing code at it and
most of it worked. I did make some small changes to
SubC to get it to handle my existing code. But what was
left was not a lot.

> but I doubt if you'll find many other programmers who will
> join you or use your software when the key tool is at that level.

This is more for people who have no choice. For whatever
reason they are being restricted to public domain code, and
if you want to use a more advanced flavor of C, or indeed
a different language altogether, you need to start by writing
a compiler. Fortunately for that person they can code in
SubC instead of writing machine code. Those are the only
two options if you are restricted to PD code.

> Maybe
> the original SubC author is working more on it, or interested in
> collaboration?

He added "typedef" for me because that was part of my style
that I wasn't willing to give up, plus some other changes, but
beyond that he has been very clear that I'm on my own as he
no longer has time for this project.

BFN. Paul.

On 22/03/2022 09:14, muta...@gmail.com wrote:
> On Tuesday, March 22, 2022 at 7:59:27 PM UTC+11, David Brown wrote:
>
>> I looked at the link. To me, the restrictions there are /massive/, even
>
> Care to be specific?
>
>> for a 20+ years outdated version of C. I've had occasion to work with
>> "C" compilers with serious limitations, missing features or bugs in
>> connection with some microcontrollers, and it's not something I
>> personally would be willing to accept again. It looks like this
>> software is part of a book about how to write a C compiler - it is no
>> more than a basic starting point of some important features, with the
>> rest left as homework for the reader.
>
> Sure.
>
>> Do you have plans to work on the compiler and improve it? You
>
> Right at the moment I don't have specific plans for my life.
> I've reached this milestone a few days ago and now need to
> consolidate.
>
> I'm lacking a lot of the theoretical background to all
> components, plus I'm not very good with complex
> algorithms. I have skills in other areas (but don't know
> how to describe it). I just bludgeoned my way to get
> here.
>
>> personally might be happy (or at least willing!) to write code to its
>> limitations,
>
> It's actually more that I threw my existing code at it and
> most of it worked. I did make some small changes to
> SubC to get it to handle my existing code. But what was
> left was not a lot.
>
>> but I doubt if you'll find many other programmers who will
>> join you or use your software when the key tool is at that level.
>
> This is more for people who have no choice. For whatever
> reason they are being restricted to public domain code,

This doesn't make sense.

You're talking rebooting all computer systems and software in an
apocalyptic world; who's going to care about the fine details of
software licenses!

Especially as all the sources will have disappeared from the planet,
apart from the ones stored on your fire-proof and damp-proof punched cards.

But if you are worried about such aspects, then licences probably apply
to processor designs too.

and
> if you want to use a more advanced flavor of C, or indeed
> a different language altogether, you need to start by writing
> a compiler. Fortunately for that person they can code in
> SubC instead of writing machine code. Those are the only
> two options if you are restricted to PD code.

Actually there are a few more options. Someone can write can assembler
in machine code, then they can write in symbolic assembly. They can use
that to create a simple HLL or even a HLA that doesn't need to be C (you
do know other HLLs exist?).

The problem however will be this: assuming pockets of source code
survive somewhere, and assuming those are in C, those most likely will
not be in a the SubC subset. You will need a more full-featured C compiler.

On Tuesday, March 22, 2022 at 9:16:43 PM UTC+11, Bart wrote:

> > This is more for people who have no choice. For whatever
> > reason they are being restricted to public domain code,

> This doesn't make sense.
>
> You're talking rebooting all computer systems and software in an
> apocalyptic world;

It's not necessarily an apocalyptic world.

Most people are totally opposed to releasing their code to
the public domain because they fear xyz will happen.

I want to see xyz happen.

Or I want to prove that the fears are unfounded because
xyz didn't happen.

> who's going to care about the fine details of
> software licenses!

Some sort of magnetic strike that wipes computers clean
doesn't necessarily mean governments will no longer exist
and enforce copyright laws.

> Especially as all the sources will have disappeared from the planet,
> apart from the ones stored on your fire-proof and damp-proof punched cards.
>
> But if you are worried about such aspects, then licences probably apply
> to processor designs too.

Those are subject to patents, not copyright, and patents only
last 20 years, so the 80386 is free, assuming Intel found
something to patent in the first place.

> > and
> > if you want to use a more advanced flavor of C, or indeed
> > a different language altogether, you need to start by writing
> > a compiler. Fortunately for that person they can code in
> > SubC instead of writing machine code. Those are the only
> > two options if you are restricted to PD code.

> Actually there are a few more options. Someone can write can assembler
> in machine code,

Sure. They have to start by writing in machine code. As of a
few days ago they now also have the option of writing their
assembler in SubC.

> then they can write in symbolic assembly. They can use
> that to create a simple HLL or even a HLA that doesn't need to be C (you
> do know other HLLs exist?).

Sure.

> The problem however will be this: assuming pockets of source code
> survive somewhere, and assuming those are in C, those most likely will
> not be in a the SubC subset. You will need a more full-featured C compiler.

That source code includes PDOS/386, and tools like the linker.
So the first order of the day will be to write the full-featured
C compiler you speak of. And they can write that in SubC
instead of machine code (if they think, as I do, that SubC is
a shit-ton easier). And they can even use the SubC source code
as a base if they think it is useful.

BFN. Paul.

On 22/03/2022 10:14, muta...@gmail.com wrote:
> On Tuesday, March 22, 2022 at 7:59:27 PM UTC+11, David Brown wrote:
>
>> I looked at the link. To me, the restrictions there are /massive/, even
>
> Care to be specific?

Poor support for structs and unions.

Poor support for typedef.

No long, short, or other integer sizes. No unsigned types. No floating
point at all.

Extremely limited pointer support.

No more than two levels of indirection.

Broken initialisation.

Hopeless pre-processor support.

(And of course there are many C99 features that I would find painful to
do without, but that's beyond the scope of the compiler.)

Other people no doubt see other issues as more important.

>
>> for a 20+ years outdated version of C. I've had occasion to work with
>> "C" compilers with serious limitations, missing features or bugs in
>> connection with some microcontrollers, and it's not something I
>> personally would be willing to accept again. It looks like this
>> software is part of a book about how to write a C compiler - it is no
>> more than a basic starting point of some important features, with the
>> rest left as homework for the reader.
>
> Sure.
>
>> Do you have plans to work on the compiler and improve it? You
>
> Right at the moment I don't have specific plans for my life.
> I've reached this milestone a few days ago and now need to
> consolidate.
>

Fair enough.

> I'm lacking a lot of the theoretical background to all
> components, plus I'm not very good with complex
> algorithms. I have skills in other areas (but don't know
> how to describe it). I just bludgeoned my way to get
> here.
>
>> personally might be happy (or at least willing!) to write code to its
>> limitations,
>
> It's actually more that I threw my existing code at it and
> most of it worked. I did make some small changes to
> SubC to get it to handle my existing code. But what was
> left was not a lot.
>

I suppose you were already writing mainly in a subset of C90. This will
be harder for people who have moved on. Opinions and preferences vary,
of course, but I believe most people who are used to C99 would see a
return to C90 as a major step backwards, never mind a limited subset of it.

>> but I doubt if you'll find many other programmers who will
>> join you or use your software when the key tool is at that level.
>
> This is more for people who have no choice.

OK. I don't know who these people might be, but as I said before I'd
rather not get into a discussion about license philosophy.

> For whatever
> reason they are being restricted to public domain code, and
> if you want to use a more advanced flavor of C, or indeed
> a different language altogether, you need to start by writing
> a compiler. Fortunately for that person they can code in
> SubC instead of writing machine code. Those are the only
> two options if you are restricted to PD code.
>
>> Maybe
>> the original SubC author is working more on it, or interested in
>> collaboration?
>
> He added "typedef" for me because that was part of my style
> that I wasn't willing to give up, plus some other changes, but
> beyond that he has been very clear that I'm on my own as he
> no longer has time for this project.
>
> BFN. Paul.
>

On Tuesday, March 22, 2022 at 9:37:30 PM UTC+11, David Brown wrote:

> No long, short, or other integer sizes.

I'm targeting the 80386, so I just use the preprocessor to
define all of these to a 32-bit int.

> No unsigned types.

I define this to nothing, making all my integers signed,
and I'm not sure what the impact of that is.

> No floating point at all.

For the tools I am interested in (OS, C compiler, linker
etc) no floating point is used.

> Hopeless pre-processor support.

You can use pdcc -E, which is also public domain, so that
becomes irrelevant.

> > This is more for people who have no choice.

> OK. I don't know who these people might be

Well, I wouldn't say I have "no choice", but I do fall into
the category of people who want this.

I don't like having my computer crash and not being able
to debug what the problem is. I don't want to pay contract
rates to fix bugs in other people's copyrighted software.

Fixing bugs in software that I own (jointly with the public,
or myself, or a company I have shares in), I may be willing
to pay for if the price is right. Or I may be willing to do it
myself. But with the expectation that if I become familiar
with the code base in the process, I am free to make my
derived version a commercial product without restriction.
Or even take any code I find useful and use that
commercially. I don't want to waste my time understanding
someone else's copyrighted code.

This is applicable:

https://dilbert.com/strip/2000-03-19

And is probably the basis of the entire crappy state of the
software industry. I don't want my personal PC to be in
that state, and with "University Challenge" I can get my PC
out of that state without needing to learn any other language
than C90 which I already know sufficiently well.

BFN. Paul.

On Tuesday, 22 March 2022 at 10:37:30 UTC, David Brown wrote:
>
> I suppose you were already writing mainly in a subset of C90. This will
> be harder for people who have moved on. Opinions and preferences vary,
> of course, but I believe most people who are used to C99 would see a
> return to C90 as a major step backwards, never mind a limited subset of it.
>
There's a tendency to add features over time. That's because removing a feature
breaks old code, and also because the marginal cost of a new feature in
terms of the complexity it adds is small. However the cumulative effect of
adding many new features is that the software becomes difficult to learn,
and difficult to maintain or re-implement.

On 22/03/2022 11:29, muta...@gmail.com wrote:
> On Tuesday, March 22, 2022 at 9:37:30 PM UTC+11, David Brown wrote:
>
>> No long, short, or other integer sizes.
>
> I'm targeting the 80386, so I just use the preprocessor to
> define all of these to a 32-bit int.
>
>> No unsigned types.
>
> I define this to nothing, making all my integers signed,
> and I'm not sure what the impact of that is.
>
>> No floating point at all.
>
> For the tools I am interested in (OS, C compiler, linker
> etc) no floating point is used.
>
>> Hopeless pre-processor support.
>
> You can use pdcc -E, which is also public domain, so that
> becomes irrelevant.

That's another odd priority. You're OK without things such as floats
(which I decided were useful enough to add to my very first language 40
years ago).

But function-like macros are a must-have! (Something I've easily managed
to do without over that same period.)

Doing preprocessing properly is difficult. You can read about it here:

https://marc.info/?l=boost&m=118835769257658&w=2

(Try and make it through to the end...)

On Tuesday, 22 March 2022 at 15:09:46 UTC, Bart wrote:
> On 22/03/2022 11:29, muta...@gmail.com wrote:
> > On Tuesday, March 22, 2022 at 9:37:30 PM UTC+11, David Brown wrote:
> >
> >> No long, short, or other integer sizes.
> >
> > I'm targeting the 80386, so I just use the preprocessor to
> > define all of these to a 32-bit int.
> >
> >> No unsigned types.
> >
> > I define this to nothing, making all my integers signed,
> > and I'm not sure what the impact of that is.
> >
> >> No floating point at all.
> >
> > For the tools I am interested in (OS, C compiler, linker
> > etc) no floating point is used.
> >
> >> Hopeless pre-processor support.
> >
> > You can use pdcc -E, which is also public domain, so that
> > becomes irrelevant.
> That's another odd priority. You're OK without things such as floats
> (which I decided were useful enough to add to my very first language 40
> years ago).
>
> But function-like macros are a must-have! (Something I've easily managed
> to do without over that same period.)
>
You nick a preprocessor from somewhere else, and you have function-like
macros.
However to deal with floats you've got to program the compiler to recognise
floating point expressions, then emit floating point machine code. Essentially
you need another arithmetical expression parser, then some logic to allow
the two to mix. It's quite a task, as you probably know better than i do.

On 22/03/2022 15:37, Malcolm McLean wrote:
> On Tuesday, 22 March 2022 at 15:09:46 UTC, Bart wrote:
>> On 22/03/2022 11:29, muta...@gmail.com wrote:
>>> On Tuesday, March 22, 2022 at 9:37:30 PM UTC+11, David Brown wrote:
>>>
>>>> No long, short, or other integer sizes.
>>>
>>> I'm targeting the 80386, so I just use the preprocessor to
>>> define all of these to a 32-bit int.
>>>
>>>> No unsigned types.
>>>
>>> I define this to nothing, making all my integers signed,
>>> and I'm not sure what the impact of that is.
>>>
>>>> No floating point at all.
>>>
>>> For the tools I am interested in (OS, C compiler, linker
>>> etc) no floating point is used.
>>>
>>>> Hopeless pre-processor support.
>>>
>>> You can use pdcc -E, which is also public domain, so that
>>> becomes irrelevant.
>> That's another odd priority. You're OK without things such as floats
>> (which I decided were useful enough to add to my very first language 40
>> years ago).
>>
>> But function-like macros are a must-have! (Something I've easily managed
>> to do without over that same period.)
>>
> You nick a preprocessor from somewhere else, and you have function-like
> macros.

That's just acquiring yet another dependency, and one so complex you are
forced to use some third party implementation. (Good thing the OP isn't
that bothered about trust.)

> However to deal with floats you've got to program the compiler to recognise
> floating point expressions, then emit floating point machine code. Essentially
> you need another arithmetical expression parser, then some logic to allow
> the two to mix. It's quite a task, as you probably know better than i do.

This other stuff however, you can cut as many corners as you like, but
it is also a million times easier.

These days you don't even need to write your own floating point
emulation. If my current language didn't already have float support, I
could add float-add for example in a couple of minutes:

function addf64(u64 x,y)u64 z =
assem
movq xmm0, [x]
addsd xmm0, [y]
movq [z], xmm0
end
z
end

Now look again at the link I posted.

My own C preprocessor (not standalone) is 3500 lines of code, took a
month to do, and will probably still fail with most of the weird things
people like to do with the CPP.

Yet I'm not about to incorporate someone else's work (apart from it
being in a different language). Other people than the OP have their owm
preferences, one of mine is to be responsible for 100% of may languages'
toolchains.

On Wednesday, March 23, 2022 at 3:49:36 AM UTC+11, Bart wrote:

> > You nick a preprocessor from somewhere else, and you have function-like
> > macros.

> That's just acquiring yet another dependency, and one so complex you are
> forced to use some third party implementation. (Good thing the OP isn't
> that bothered about trust.)

Trust in what?

> being in a different language). Other people than the OP have their owm
> preferences, one of mine is to be responsible for 100% of may languages'
> toolchains.

You can pick up someone else's public domain implementation,
read it to ensure you understand it, and then take responsibility
for maintaining it (you don't need to give away the source code
to your modifications). Surely that is easier than writing it from
scratch?

BFN. Paul.

On 2022-03-22, muta...@gmail.com <mutazilah@gmail.com> wrote:
> On Wednesday, March 23, 2022 at 3:49:36 AM UTC+11, Bart wrote:
>
>> > You nick a preprocessor from somewhere else, and you have function-like
>> > macros.
>
>> That's just acquiring yet another dependency, and one so complex you are
>> forced to use some third party implementation. (Good thing the OP isn't
>> that bothered about trust.)
>
> Trust in what?
>
>> being in a different language). Other people than the OP have their owm
>> preferences, one of mine is to be responsible for 100% of may languages'
>> toolchains.
>
> You can pick up someone else's public domain implementation,

Your obsession with the public domain needlessly limits your options.

First of all, an assignment to the public domain may not be recognized
everywhere in the world. If the only notice on a work is something like
that "Author Bob Smith assigned this to the public domain on July 19,
2013" then it may not be considered to be properly licensed in all. If
assignment to the public domain doesn't hold, then the work remains
copyrighted by Bob, with all rights being reserved.

If you redistribute such a thing, you should add a warranty disclaimer,
otherwise you could be held liable for damages (even in a jurisdiction
where a disclaimer could have protected you).

Code with MIT or BSD licenses, and similar ones, is just as /functionally/
free as "public domain". All that you would reasonably want to do as a
developer with public domain code, you can do with BSD or MIT code.
These licenses ask you to preserve those licenses. Therefore you may not
perpetrate certain plagiarism that you might get away with in the case
of a public domain work, like falsely asserting authorship over
something.

Unless your goal is to be a plagiarist, you don't have a problem with
these licenses whatsoever. Moreover, they are proper licenses.

The Free Software Foundation recommends(1), to people who wish to assign
to the public domain, to use the CC0 (Creative Commons 0) license in
order to to do so(2). This license contains a warranty disclaimer,
wording which assigns to the public domain, as well as a fallback to
licensing provisions for jurisdiction where such an assignment isn't
supported.

(I find CC0 verbose; whereas BSD is small enough that you can have
it as a header in every source file, so things are crystal clear even if
people pick pieces out of your program.)

--
1. https://directory.fsf.org/wiki/License:PublicDomain
2. http://directory.fsf.org/wiki/License:CC0

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

On Wednesday, March 23, 2022 at 6:24:06 AM UTC+11, Kaz Kylheku wrote:

> > You can pick up someone else's public domain implementation,

> Your obsession with the public domain needlessly limits your options.

I have a different opinion, and provided it earlier in this thread.

> First of all, an assignment to the public domain may not be recognized
> everywhere in the world.

Even if that is true, it is harmless to add that wording.

And it is harmless to NOT write the word "copyright".

While ever people are going to the effort to write that word,
I'm going to the effort to find one without that word.

> If the only notice on a work is something like
> that "Author Bob Smith assigned this to the public domain on July 19,
> 2013" then it may not be considered to be properly licensed in all.

I'm happy to use it. I'm not happy to use something with
the word "copyright" in it, or rather, I'll only do that
temporarily.

> If
> assignment to the public domain doesn't hold, then the work remains
> copyrighted by Bob, with all rights being reserved.

Theoretically in some jurisdictions, which is why PDOS has
a CC0 fallback.

> If you redistribute such a thing, you should add a warranty disclaimer,
> otherwise you could be held liable for damages (even in a jurisdiction
> where a disclaimer could have protected you).

People write disclaimers on their software as if programmers
are being sued every 5 seconds for every bug in their program.
Have you heard of a single person without a disclaimer being
sued for their freeware? I put this into one of mine:

https://sourceforge.net/p/pdos/gitcode/ci/master/tree/src/world.c

No-one has taken me up on the offer so far. Maybe you
could be the first.

> Code with MIT or BSD licenses, and similar ones, is just as /functionally/
> free as "public domain".

I disagree.

> All that you would reasonably want to do as a
> developer with public domain code, you can do with BSD or MIT code.

Wrong. I don't want to be sued by the copyright holder
because he thinks I have violated some implied right
in what is unambiguously his code, because he never
ever relinquished copyright. He explicitly held onto it.
> These licenses ask you to preserve those licenses.

Hence the term "virus".

> Therefore you may not
> perpetrate certain plagiarism that you might get away with in the case
> of a public domain work, like falsely asserting authorship over
> something.

The modified version IS your version, it's not false ownership.

> Unless your goal is to be a plagiarist, you don't have a problem with
> these licenses whatsoever. Moreover, they are proper licenses.

My goal is to not have anyone claim ownership of a single
byte of my source or executables.

> The Free Software Foundation recommends(1), to people who wish to assign
> to the public domain, to use the CC0 (Creative Commons 0) license in
> order to to do so(2). This license contains a warranty disclaimer,
> wording which assigns to the public domain, as well as a fallback to
> licensing provisions for jurisdiction where such an assignment isn't
> supported.

Yes, I release my code to the public domain and say that you can
follow CC0 if you prefer.

> (I find CC0 verbose; whereas BSD is small enough that you can have
> it as a header in every source file, so things are crystal clear even if
> people pick pieces out of your program.)

The word "copyright" is crystal clear.

BFN. Paul.

On 2022-03-22, muta...@gmail.com <mutazilah@gmail.com> wrote:
> On Wednesday, March 23, 2022 at 6:24:06 AM UTC+11, Kaz Kylheku wrote:
>
>> > You can pick up someone else's public domain implementation,
>
>> Your obsession with the public domain needlessly limits your options.
>
> I have a different opinion, and provided it earlier in this thread.
>
>> First of all, an assignment to the public domain may not be recognized
>> everywhere in the world.
>
> Even if that is true, it is harmless to add that wording.
>
> And it is harmless to NOT write the word "copyright".
>
> While ever people are going to the effort to write that word,
> I'm going to the effort to find one without that word.
>
>> If the only notice on a work is something like
>> that "Author Bob Smith assigned this to the public domain on July 19,
>> 2013" then it may not be considered to be properly licensed in all.
>
> I'm happy to use it. I'm not happy to use something with
> the word "copyright" in it, or rather, I'll only do that
> temporarily.

But this situation is that the copyright protection is implicit;
so you're just having a pointless allergic reaction to it being
spelled out in a word.

>
>> If
>> assignment to the public domain doesn't hold, then the work remains
>> copyrighted by Bob, with all rights being reserved.
>
> Theoretically in some jurisdictions, which is why PDOS has
> a CC0 fallback.
>
>> If you redistribute such a thing, you should add a warranty disclaimer,
>> otherwise you could be held liable for damages (even in a jurisdiction
>> where a disclaimer could have protected you).
>
> People write disclaimers on their software as if programmers
> are being sued every 5 seconds for every bug in their program.
> Have you heard of a single person without a disclaimer being
> sued for their freeware? I put this into one of mine:

I can't think of any software that I use that lacks such a disclaimer.

It's conceivable that some crooks (similar to copyright trolls) could
latch onto this idea and find software authors to harass with trumped
up liability claims.
>
> https://sourceforge.net/p/pdos/gitcode/ci/master/tree/src/world.c

Your program fails to flush the output stream to force the error message
to be passed from the stream's buffer to the host environment, and
check whether that forwarding succeeded. It relies on the output being
implicitly flushed, and returns success unconditionally.

You've not explicitly documented that these are *not* requirements for
your program, so they could be inferred as being general reliability
issues, particularly in light of your strong claim that the program
is error-free. If you don't say what constitutes errors, it has the
broadest possible interpretation: every conceivable fault is absent.

> No-one has taken me up on the offer so far. Maybe you
> could be the first.
>
>> Code with MIT or BSD licenses, and similar ones, is just as /functionally/
>> free as "public domain".
>
> I disagree.
>
>> All that you would reasonably want to do as a
>> developer with public domain code, you can do with BSD or MIT code.
>
> Wrong. I don't want to be sued by the copyright holder
> because he thinks I have violated some implied right
> in what is unambiguously his code,

That could happen anyway even if the word "copyright" isn't there.

Someone who makes their code public using any copying/licensing blurb
whatsoever (including none at all or "assigned to the public domain")
could change their mind and try to sue people.

People will try this and that.

Your best bet is to have a clear license from them which confirms what
rights they passed on to you at the time.

Shit will happen. Sometimes people put a license on something which
isn't theirs. If you take some piece of leaked MS WIndows code,
remove any copyright notices and add a public domain assignment,
that doesn't mean it's valid. Any improper claim can be voided,
hanging its believers out to dry.

> because he never relinquished copyright. He explicitly held onto it.

That is false; the BSD and MIT licenses relinquish specific rights,
just not the attribution right, entirely.

>> These licenses ask you to preserve those licenses.
>
> Hence the term "virus".

I'm not aware of the term "virus" being applied to BSD, MIT and their
ilk; they are not commonly described as viral licenses.

They are not viral because they make no conditions about what license
may be or must be applied to *other* pieces that the work is combined
with.

The GNU licenses are called "viral" because works which are a
combination of GPL and non-GPL licensed code must have the non-GNU parts
be adjusted to be licensed in a GPL-compatible way, and the whole
combination be under the GPL.
>
>> Therefore you may not
>> perpetrate certain plagiarism that you might get away with in the case
>> of a public domain work, like falsely asserting authorship over
>> something.
>
> The modified version IS your version, it's not false ownership.

It is not so much about ownership as academic conduct.

If you're taking an exam, and the person next to you put a CC0 license
above their answer sheet, that doesn't mean it's OK for you to crib the
answer, and present it as your original work, for reasons not directly
related to copyright.

But copyright can be used as an assertion against plagiarism.
Basicall that's all BSD does. "Don't plagiarize this, and don't
remove the liability disclaimer".

> My goal is to not have anyone claim ownership of a single
> byte of my source or executables.

Then public domain is not aligned with your goal, Someone can easily
engage in behavior in which other people believe that they are the
author of that code.

Excerpts of public domain code may be placed into any code without any
attribution, and if that surrounding code has an obvious owner, that
will be assumed over the borrowed excerpt too.

> Yes, I release my code to the public domain and say that you can
> follow CC0 if you prefer.

But that's redundant, since CC0 already has the public domain assignment
as the primary feature, with fallback on as-free-as-possible licensing.
>
>> (I find CC0 verbose; whereas BSD is small enough that you can have
>> it as a header in every source file, so things are crystal clear even if
>> people pick pieces out of your program.)
>
> The word "copyright" is crystal clear.

No, it isn't; you cannot infer all the facts about copyright from
the word alone, or its brief definition in a general dictionary.

You don't know everything from "copy" and "right", such as that there
are multiple different rights under the umbrella of copyright law, such
as the right not to have something you *didn't* produce attributed to
you (attribution right).

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

2022-03-22 at 12:45 -0700, muta...@gmail.com wrote:
> https://sourceforge.net/p/pdos/gitcode/ci/master/tree/src/world.c

Why printf() ? Calling puts() would likely produce a smaller executable.

Also, on some platforms/compilers/output devices using \n might leave
the cursor at column 11.

Mateusz

On Wednesday, March 23, 2022 at 7:30:49 AM UTC+11, Kaz Kylheku wrote:

> >> If the only notice on a work is something like
> >> that "Author Bob Smith assigned this to the public domain on July 19,
> >> 2013" then it may not be considered to be properly licensed in all.
> >
> > I'm happy to use it. I'm not happy to use something with
> > the word "copyright" in it, or rather, I'll only do that
> > temporarily.

> But this situation is that the copyright protection is implicit;
> so you're just having a pointless allergic reaction to it being
> spelled out in a word.

It's not pointless. No attempt to assert copyright when
copyright could have easily been asserted weakens any
case the author may have against me.

The public domain dedication weakens his case even more.

> It's conceivable that some crooks (similar to copyright trolls) could
> latch onto this idea and find software authors to harass with trumped
> up liability claims.

We've had decades of laborious disclaimers against a
fear of something that might happen one day in some
galaxy?

> > https://sourceforge.net/p/pdos/gitcode/ci/master/tree/src/world.c
>
> Your program fails to flush the output stream to force the error message
> to be passed from the stream's buffer to the host environment, and
> check whether that forwarding succeeded. It relies on the output being
> implicitly flushed, and returns success unconditionally.
>
> You've not explicitly documented that these are *not* requirements for
> your program, so they could be inferred as being general reliability
> issues, particularly in light of your strong claim that the program
> is error-free. If you don't say what constitutes errors, it has the
> broadest possible interpretation: every conceivable fault is absent.

So sue me and see how far you get. It would be good
to have a test case after decades of nothing.

> >> All that you would reasonably want to do as a
> >> developer with public domain code, you can do with BSD or MIT code.
> >
> > Wrong. I don't want to be sued by the copyright holder
> > because he thinks I have violated some implied right
> > in what is unambiguously his code,

> That could happen anyway even if the word "copyright" isn't there.

Sure, but he'll have a much tougher time in court. And in
America, my main target (I'm not American), he has no
chance at all.

> Someone who makes their code public using any copying/licensing blurb
> whatsoever (including none at all or "assigned to the public domain")
> could change their mind and try to sue people.
>
> People will try this and that.

So far I don't think anyone has tried that.

And regardless, that's as good as it gets. Your only other
choice is to write everything yourself, and even then, someone
can STILL sue you claiming you copied their code.

> Your best bet is to have a clear license from them which confirms what
> rights they passed on to you at the time.

Your best bet is public domain, with CC0 fallback, making it
clear that zero attempt has been made to add any restriction
or hold on to any ownership such that the author may one day
see you in court. He doesn't own it.

> Shit will happen. Sometimes people put a license on something which
> isn't theirs. If you take some piece of leaked MS WIndows code,
> remove any copyright notices and add a public domain assignment,
> that doesn't mean it's valid. Any improper claim can be voided,
> hanging its believers out to dry.

That's true of any license, and is a completely different issue
of authorship. Regardless, the person using such code is not
guilty of WILFULL copyright violation.

> > because he never relinquished copyright. He explicitly held onto it.
>
> That is false; the BSD and MIT licenses relinquish specific rights,
> just not the attribution right, entirely.

It's not false. I said he explicitly held on to copyright.

And yes, if your legal team thinks that the copyright holder
has allowed you to use his code without a popup every 5
seconds saying "ha ha this code is copyrighted by me" without
taking you to court if you fail to do so, that's your risk to take.

Me, I'll hang on until someone makes zero attempt to retain
ownership of the code, and every attempt to disown it.

> >> These licenses ask you to preserve those licenses.
> >
> > Hence the term "virus".

> I'm not aware of the term "virus" being applied to BSD, MIT and their
> ilk; they are not commonly described as viral licenses.
>
> They are not viral because they make no conditions about what license
> may be or must be applied to *other* pieces that the work is combined
> with.

Derived work need to contain what they tell you to contain.
They're the boss. They tell you to jump, you say "how high".

With public domain, there is no longer a boss. Nothing for
your legal team to ponder.

> >> Therefore you may not
> >> perpetrate certain plagiarism that you might get away with in the case
> >> of a public domain work, like falsely asserting authorship over
> >> something.
> >
> > The modified version IS your version, it's not false ownership.

> It is not so much about ownership as academic conduct.
>
> If you're taking an exam, and the person next to you put a CC0 license
> above their answer sheet, that doesn't mean it's OK for you to crib the
> answer, and present it as your original work, for reasons not directly
> related to copyright.

Copying code in an exam is a completely different topic,
and applies regardless of the license. Assuming exam
answers are actually copyrightable.

> But copyright can be used as an assertion against plagiarism.
> Basicall that's all BSD does. "Don't plagiarize this, and don't
> remove the liability disclaimer".

Plus any implied rights the author may verbalize when he
takes you to court.

Regardless, if you trust your interpretation of the BSD license
and are comfortable with it, that's fine. No skin off my nose.

But me, or anyone like me, will hang out until someone is
willing to totally distance themselves from ownership of a
bit of code.

And those are the people I am catering for. Not you.

> > My goal is to not have anyone claim ownership of a single
> > byte of my source or executables.

> Then public domain is not aligned with your goal,

Not true.

> Someone can easily
> engage in behavior in which other people believe that they are the
> author of that code.

Proof of authorship is an entirely different topic and applies
to any license. And some people believe in the Loch Ness
Monster too. That is beyond scope for me.

> Excerpts of public domain code may be placed into any code without any
> attribution, and if that surrounding code has an obvious owner, that
> will be assumed over the borrowed excerpt too.

Which is fine by me. That's actually what I want. I want
commercial vendors to copy and paste my code into
theirs, and for people to pay for that new work, rewarding
them for their apparent hard work, even though, for this
bit of code, the value that they added is just to make
people aware this code exists and can be used (on their
terms).

Most people aren't going to spend the effort to try to find
the original public domain code from me which they could
have had for free. I'm not the one risking my money on
advertising.

> > Yes, I release my code to the public domain and say that you can
> > follow CC0 if you prefer.

> But that's redundant, since CC0 already has the public domain assignment
> as the primary feature, with fallback on as-free-as-possible licensing.

Redundancy is harmless. I want to see someone prepared
to write those words.

BTW, the full text doesn't actually include that phrase:

https://creativecommons.org/publicdomain/zero/1.0/legalcode

> >> (I find CC0 verbose; whereas BSD is small enough that you can have
> >> it as a header in every source file, so things are crystal clear even if
> >> people pick pieces out of your program.)
> >
> > The word "copyright" is crystal clear.

> No, it isn't; you cannot infer all the facts about copyright from
> the word alone, or its brief definition in a general dictionary.
>
> You don't know everything from "copy" and "right", such as that there
> are multiple different rights under the umbrella of copyright law, such
> as the right not to have something you *didn't* produce attributed to
> you (attribution right).

It is crystal clear that all the legal implications of copyright
protection are being invoked. It is crystal clear that the
right of ownership is not being rescinded.

"muta...@gmail.com" <mutazilah@gmail.com> writes:
> On Wednesday, March 23, 2022 at 7:30:49 AM UTC+11, Kaz Kylheku wrote:
[228 lines deleted]

A gentle reminder: This newsgroup is about C, not about copyright law.

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

Le 22/03/2022 à 21:41, Mateusz Viste a écrit :
> 2022-03-22 at 12:45 -0700, muta...@gmail.com wrote:
>> https://sourceforge.net/p/pdos/gitcode/ci/master/tree/src/world.c
>
> Why printf() ? Calling puts() would likely produce a smaller executable.

Decent and recent C compilers already generate a call to puts() for this
(and rightfully removes the final '\n' from the string.) GCC certainly does.

2022-03-24 at 04:40 +0100, Guillaume wrote:
> Decent and recent C compilers already generate a call to puts() for
> this (and rightfully removes the final '\n' from the string.) GCC
> certainly does.

Maybe they do, but they will no longer when for example the program
evolves and starts storing its string in a resource file. There are
optimizations that are better being left to the compiler, but obvious
ones still might benefit from being handled by a human brain.

Also worth noting that the context of this thread is not exactly about
most "decent and recent" things. :)

Mateusz