On 2024-01-18, bart <[email protected]> wrote:

On 18/01/2024 04:30, Kaz Kylheku wrote:

On 2024-01-18, bart <[email protected]> wrote:

You mean via layers like WSL or MSYS2 or CYGWIN? I don't really consider >>> that running on Windows.

What is it? To the left of Windows? Behind Windows? Under Windows?

It doesn't matter which one of these prepositions it is, because in this
situation being discussed all those programs are doing is providing an
environment for building something.

Let's consider an OS like Android, to avoid a made-up one. (Put aside
the likelihood that deep inside Android might be a Linux core. Think of
the glossy-looking consumer OS that everyone knows.)

Android is a Linux-based OS. It has a C library called Bionic.

There is an environment you can install on Android called Termux.

In Termux you get a shell with utilities and numerous common packages.
git, ssh, you name it. You can compile programs like on other Unix-likes.

I ported TXR to Android with Termux in literally minutes, originally.

When Android rolled out pointer tagging, I had to do a few things to
make it work, because it clashes with the NaN-boxing technique used
for representing values. We turn on a build option
CONFIG_NAN_BOXING_STRIP_TAG invented for that, which will strip
the pointer tags from the heaps allocated from malloc, and put
them back when calling free. In between that, we refer to the objects
via tag-free pointers.

In the test suite, a few things have to be done differently on Android.
It is detected like this;

(if (ignerr (dlsym (dlopen "libandroid.so") "AAsset_close"))
:android
( ... else detect other platforms ...))

I.e. if we are able to successfully open a library called
"libandroid.so" and resolve the symbol "AAsset_close", then
we conclude we are running on Android. I probably could have
relied on some clues from the kernel.

In other ways, it's just another Linux.

Now, somebody brings out some piece of software that only builds under Android.

To build it under Linux, requires installing a vast virtual Android OS
to do that.

There is application software for Android that cannot run on any
other platform. People run this via emulators.

Would you consider that being able to build 'under Linux'?

Tentatively, yes, if:

- you can prepare the files that need to be built just by
storing them in the host Linux filesystem.

- you can dispatch the build process from Linux, from a script.
(No manual fiddling with the GUI of some emulator, and no
remote logins to an emulator to run anything).

- you can collect the deliverables in the host filesystem.

such that this whole thing can be automated on a Linux build server,
that runs without any manual steps, and which doesn't have to use
networking to connect to any emulated machine to copy anything
in or out.


--
TXR Programming Language: http://nongnu.org/txr
Cygnal: Cygwin Native Application Library: http://kylheku.com/cygnal
Mastodon: @[email protected]
NOTE: If you use Google Groups, I don't see you, unless you're whitelisted.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 18/01/2024 20:47, David Brown wrote:

On 18/01/2024 16:16, bart wrote:

Could you, in good faith, provide sources to that project and say it
builds 'under Linux, no problem'. Never mind the considerable
dependencies they would need and the significant likelihood of failure.

Dependencies are part of life with computers.  A Windows installation without additional software gives you Minesweeper and Wordpad.  How can
you possibly justify thinking that installing msys2 and mingw-64 for a compilation means you are "not building under Windows" while installing
MSVC means you /are/ "building under Windows"?  The MSVC installation is
10 times the size of mingw-64.

Actually I don't consider an MSVC dependency much better that MSYS2 and
WSL. At least WSL works; I haven't had a working MSVC for years.

MSVC/VS/etc is a vast, corporate monstrosity, as is most of Windows
these days.

But you can still do things on a small scale and informally as I do
within a small corner of Windows.

My last analogy didn't work very well, I'll try another one. Suppose you
wanted a product but it only comes in kit form that you have to build
yourself.

It promises it only needs a hammer and a screwdriver. But it turns out
there is one extra thing you need: a massive great factory next door
that contains all the specialist equipment, processes and manpower
needed to complete that job.

Apart from that, then sure: you can assemble this 'at home'.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 18/01/2024 20:15, bart wrote:

On 06/01/2024 07:39, David Brown wrote:

On 05/01/2024 19:42, Kaz Kylheku wrote:

On 2024-01-05, Keith Thompson <[email protected]> wrote:

When you wrote "in Linux", I wondered if you were being imprecise, but >>>> in fact that code is in the Linux kernel.

That means the macros aren't directly available to normal C code, but
you can always copy their definitions (*if* you're using a compiler
that supports the __builtin_types_compatible_p extension).

You can always copy their definitions, if you're using a compiler
that doesn't arbitrarily define __GNUC__ without providing the
associated behaviors:

#ifdef __GNU__

// define array_size in the Linux kernel way

#else

#define arrray_size(x) (sizeof (x)/sizeof *(x))

#endif

If you regularly build the code with a compiler that provides GNU
extensions (like as part of your CI), you're covered, even if you're
going to production with something else.

I use C++ this way in C projects; I have some macro features that
provide extra checks under C++. I get the benefit even if I just
compile the code as C++ only once before every release.

That is a good tactic if your code needs to be used with compilers
that don't have such features for static checking (perhaps you are
releasing your source code, and can't influence the tools or settings
users use). In a way, you are using gcc (or C++) as a linter.

I've done this myself when the actual target compiler had little in
the way of static checking - I ran gcc in parallel, for a different
target (the generated output was ignored), but with lots of warning
flags that the real compiler did not support.

This is pretty much how in the past I have suggested people use Tiny C:
use it for very fast compilation turnaround. Use gcc from time to time
for better error checking, and for production builds for faster code.

My use was not like that. I used the other compiler because I had no
choice - I would not intentionally use a weaker compiler when a better
one was available, certainly not for something as irrelevant as compile
speed. But gcc does not support all the devices I have used over the years.

And I certainly don't run the weak tool regularly and gcc occasionally -
that defeats the purpose of static error checking, when you want the
results as soon as possible. As I said, I would run them in parallel,
and if I were only going to run one, it would be gcc - the sooner a bug
or potential problem is found, the better. (Thus it makes sense to use
an IDE or advanced editor that checks many things on the fly, as you type.)

If you are running more advanced static analysis tools, such as
clang-analyzer, that can take a long time doing simulated execution and inter-module analysis, then you might not want to run it for every build.

As a rule of thumb, if the static analysis takes less time than a sip of coffee, do it on every build. If it takes as long as making coffee, do
it when you are making coffee.

Another is for situations where obtaining the small-footprint Tiny C
compiler is simpler, or where it can be bundled with your source code.

That's very rarely a realistic scenario for anyone, and never has been
for me.

Yet another is when you have a compiler for another language that
targets C code. Since the program has already been verified, the C code should be correct. Then extensive static checking is not needed; you
just want a fast backend that doesn't take up 95% of the overall
compilation time.

I think it is better to say that when someone who has no connection to
the development process, but simply receives the source code ready-made
and fully debugged and tested, they have no need of extensive static
checking. And that's true - any appropriate static checks should have
been made already, so the code should compile warning-free (and
obviously error-free). But usually the build times here are irrelevant
- this person will build once, as part of the installation procedure -
and may run the program many times. So that build should be done with a
good compiler, not a "tiny" compiler, with optimisations enabled. And
it might as well have static error checking enabled as the extra cost in
time is negligible, and it might catch something the developer had not expected.

If there is a good reason not to use a top quality compiler - such as
lack of support for a particular target, or source code that uses
extensions from a different tool - your hand is forced. If not, then I
simply can't see any realistic circumstance where you would not want to
use the best tools you have available. (And if you have a compiler
better than gcc, use that instead - for at least some uses, icc or clang
can be better than gcc.)

Again, use gcc for a production version for some extra speed, but it is
not essential to have it.

This is a compiler you've dismissed as a toy.

Yes, TCC is a toy. That does not mean it is not impressive in many
ways, but it has almost no real-world use-cases where gcc would not be
better. There may be circumstances where it is more convenient and good enough, making it the right choice.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 18/01/2024 21:21, bart wrote:

AFAIK, if I wanted to supply a program to any Linux user, I can't just
supply a binary, since every Linux is a bit different and they run on
more different kinds of processor.

As so often, "AFAIK" for you is not very far.

For almost all Linux users, for almost all their programs, they download
and install binaries - they don't compile from source. Compiling from
source as a common method of distributing programs fell out of fashion
some 20 or 30 years ago.

Of course it is an absolutely essential aspect of free and open source
that the source code is available, and you /can/ compile it yourself.
But for the great majority, they don't do that. Intermediaries -
typically Linux distributions - get the source and compile the binaries,
and users download the binaries.


For developers or companies who don't want to distribute source, or who
want to provide the users the convenience of binaries but it's not
appropriate to include the programs in distros, it is normal to provide
only one or two binaries - an x86-64 binary, and sometimes also an
AArch64 binary if that is a likely target.

It can be more complicated if the software has to integrate tightly with different aspects of the system, but that's usually not an issue for
most software.

This is where MS Windows reigned supreme.

You mean it is so much more limited?

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 19/01/2024 12:17, bart wrote:

On 19/01/2024 10:07, David Brown wrote:

On 18/01/2024 21:21, bart wrote:

AFAIK, if I wanted to supply a program to any Linux user, I can't
just supply a binary, since every Linux is a bit different and they
run on more different kinds of processor.

As so often, "AFAIK" for you is not very far.

For almost all Linux users, for almost all their programs, they
download and install binaries - they don't compile from source.
Compiling from source as a common method of distributing programs fell
out of fashion some 20 or 30 years ago.

That's good news. So I can build an ELF binary on my WSL today, I can
email it to you and you can run it on the nearest Linux machine?

I know little about WSL - I have never used it, and don't have a current Windows system. But if it is a Linux virtual system, and your elf file
doesn't rely on uncommon shared libraries and doesn't have low-level interaction with the system (i.e., you'd call it an "application" rather
than a "system utility"), the probably yes, it would work. Copy it to a
USB stick, boot Linux, and try it yourself.

I assume it will only work if that machine happens to be x64 (as that's
what mine is)?

Obviously.

Or will it not work even then?

What are the rules? Do I have to make a version for every variant of
Linux and make it available in the 'apt-get' repository?

If you want rules, find a suitable place to look for them or discuss
them. I have no interest in talking more about this here, and I think
I've already said more than most in this group are willing to do. It
doesn't matter what anyone says, you will always twist things to fit
your preconceived ideas that everything Linux-related is terrible in
every way, and that somehow you think it all proves that your own tools
are brilliant and the rest of the world is wrong.

So try google.

For developers or companies who don't want to distribute source, or
who want to provide the users the convenience of binaries but it's not
appropriate to include the programs in distros, it is normal to
provide only one or two binaries - an x86-64 binary, and sometimes
also an AArch64 binary if that is a likely target.

It can be more complicated if the software has to integrate tightly
with different aspects of the system, but that's usually not an issue
for most software.

This is where MS Windows reigned supreme.

You mean it is so much more limited?

In being able to run EXEs created by anyone on any machine, and being
able to run them on any Windows computer, even years later.

I run Linux programs on all sorts of machines without recompiling, years
later. Of course the processor family must be compatible if you don't
want to use emulation.

(I think you can still run 32-bit EXEs compiled in the 1990s today.
16-bit EXEs can still run today on a 32-bit Windows.)

You can't get new 32-bit Windows systems now - there is no 32-bit
Windows 11, and manufacturers have not been able to sell new machines
with 32-bit Windows 10 for years. If you have to use 16-bit Windows
programs on a modern computer, you can of course use Wine to run it on
Linux.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 19/01/2024 10:07, David Brown wrote:

On 18/01/2024 21:21, bart wrote:

AFAIK, if I wanted to supply a program to any Linux user, I can't just
supply a binary, since every Linux is a bit different and they run on
more different kinds of processor.

As so often, "AFAIK" for you is not very far.

For almost all Linux users, for almost all their programs, they download
and install binaries - they don't compile from source.  Compiling from source as a common method of distributing programs fell out of fashion
some 20 or 30 years ago.

That's good news. So I can build an ELF binary on my WSL today, I can
email it to you and you can run it on the nearest Linux machine?

I assume it will only work if that machine happens to be x64 (as that's
what mine is)?

Or will it not work even then?

What are the rules? Do I have to make a version for every variant of
Linux and make it available in the 'apt-get' repository?

For developers or companies who don't want to distribute source, or who
want to provide the users the convenience of binaries but it's not appropriate to include the programs in distros, it is normal to provide
only one or two binaries - an x86-64 binary, and sometimes also an
AArch64 binary if that is a likely target.

It can be more complicated if the software has to integrate tightly with different aspects of the system, but that's usually not an issue for
most software.

This is where MS Windows reigned supreme.

You mean it is so much more limited?

In being able to run EXEs created by anyone on any machine, and being
able to run them on any Windows computer, even years later.

(I think you can still run 32-bit EXEs compiled in the 1990s today.
16-bit EXEs can still run today on a 32-bit Windows.)

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 19/01/2024 11:41, David Brown wrote:

On 19/01/2024 12:17, bart wrote:

It
doesn't matter what anyone says, you will always twist things to fit
your preconceived ideas that everything Linux-related is terrible in
every way,

That's funny. I find that Linux people always have terrible things to
say about software development using Windows, usually totally unjustified.

The main reason is that on Linux they are reliant on a huge mountain of dependencies that don't exist on Windows, even when creating supposedly cross-platform products.

(That there have been many thousands of programs developed on Windows
without that mountain totally passes them by.)

My issues with it are when *I'm* expected to recreate that same mountain
even when building an application supposedly written in C.

and that somehow you think it all proves that your own tools
are brilliant and the rest of the world is wrong.

Um no. It's just that I can do without that mountain. If I can do that
on Windows (remember, Windows doesn't equal Visual Studio; that's just
one over-the-top application), I can do it on Linux. And I have done.

So if I can do it, so can anyone. /That/ is what is superior.

What /I/ do is to remove complexity and simplify. What everyone else
does is to add complexity, extra dependencies and extra layers of
software. Apparently it doesn't matter how big that mountain gets.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 19/01/2024 14:42, David Brown wrote:

On 19/01/2024 14:18, bart wrote:

It is also incomprehensible how someone can rant endlessly about "simplification" and "easy of use" when their claimed solution is to
make non-standard limited duplications of the functionality already
found on other machines.

The programs I write ARE easy to build, using ONLY a compiler.

You don't want to accept that, you'd rather it involved those mountains
of stuff.

Maybe you don't like it because you're rather just type 'make', no
matter much pointless garbage is invoked. Fine, a makefile for most of
my projects would be two lines long.

Happy?

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 19/01/2024 14:18, bart wrote:

On 19/01/2024 11:41, David Brown wrote:

On 19/01/2024 12:17, bart wrote:

It doesn't matter what anyone says, you will always twist things to
fit your preconceived ideas that everything Linux-related is terrible
in every way,

That's funny. I find that Linux people always have terrible things to
say about software development using Windows, usually totally unjustified.

And feel free to ignore these if you have good reason to believe they
are not fact based. Don't feel free to exaggerate what people say (I
say Linux is better for most development and programming work, other
than when targeting Windows itself - but you /can/ use Windows for many
tasks, and I do use Windows as well as Linux). And don't imagine that
just because you feel someone has said something unjustifiably bad about
X, it means it is appropriate to say something similarly unjustifiably
bad about Y. That's just petty.

The main reason is that on Linux they are reliant on a huge mountain of dependencies that don't exist on Windows, even when creating supposedly cross-platform products.

You are making stuff up.

People do cross-platform (and I assume by this you just mean "for x86-64
Linux and x86-64 Windows") all the time. /You/ have difficulty with
this kind of thing, but many other developer groups manage. (I'm sure
there are others who have problems too.)

There are no mountains.

What there is, that seems to be a stumbling block for you, is a set of
common utility programs that has been standardised and used on most
serious OS's for decades (since most serious OS's, except for Windows,
aim for POSIX compatibility). These are easily available on Windows
too, and once you install them, they are there and usable. I've had
them on every Windows PC I have used since I had internet access.

I can fully understand how someone who is only familiar with Windows
(and DOS before it) doesn't know about these utilities or where to get
them, and finds them strange at first. It is incomprehensible, however,
to be having the same questions, difficulties and complaints after a
decade or so.

It is also incomprehensible how someone can rant endlessly about "simplification" and "easy of use" when their claimed solution is to
make non-standard limited duplications of the functionality already
found on other machines.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

bart <[email protected]> writes:

On 19/01/2024 10:07, David Brown wrote:

On 18/01/2024 21:21, bart wrote:

AFAIK, if I wanted to supply a program to any Linux user, I can't just
supply a binary, since every Linux is a bit different and they run on
more different kinds of processor.

As so often, "AFAIK" for you is not very far.

For almost all Linux users, for almost all their programs, they download
and install binaries - they don't compile from source.  Compiling from
source as a common method of distributing programs fell out of fashion
some 20 or 30 years ago.

That's good news. So I can build an ELF binary on my WSL today, I can
email it to you and you can run it on the nearest Linux machine?

That's not what David said. The major distributions offer
repositories containing all supported packages (far more than will
be installed by default), built for that specific distribution.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 19.01.2024 15:42, David Brown wrote:

On 19/01/2024 14:18, bart wrote:

On 19/01/2024 11:41, David Brown wrote:

On 19/01/2024 12:17, bart wrote:

It doesn't matter what anyone says, you will always twist things to
fit your preconceived ideas that everything Linux-related is terrible
in every way,

That's funny. I find that Linux people always have terrible things to
say about software development using Windows, usually totally
unjustified.

And feel free to ignore these if you have good reason to believe they
are not fact based. Don't feel free to exaggerate what people say (I
say Linux is better for most development and programming work, other
than when targeting Windows itself - but you /can/ use Windows for many tasks, and I do use Windows as well as Linux). [...]

There was a time when I dual booted (pre-installed) WinDOS and
Linux. At some point I got aware that it makes no sense, Windows
was - besides its inherent issues - also completely unnecessary
(as could be seen soon); further installs were Linux-only.

It's a phenomenon that the marketing division of MS did so great
a job to mentally bind such a huge community. (There were other
reasons as well (driver support of companies, pre-installed OS
on hardware, gaming focus, or self-enforcing dissemination
feedback processes), but discussion would lead too far here.)

I've often observed uninformed WinDozers just spread uninformed
nonsense. But never in such extreme stubbornness as in this thread.

[...]

[...]

I can fully understand how someone who is only familiar with Windows
(and DOS before it) doesn't know about these utilities or where to get
them, and finds them strange at first. [...]

This is part of the phenomenon.

And as we see nothing helps if folks grew up and didn't leave
that bubble, didn't even dare to have a look outside and try
to grasp what's going on. Yet continuing uninformed rants about
something they never experienced nor understood to a minimum
extent.

We have to accept though that the condition where someone is
making specialized niche-software for a specific platform is
also not fostering susceptive open-mindedness when confronted
with the huge professional IT world.

But I have hope; after issues with Windows I installed Linux
even for my (very old) father, and he has no problems with it
(using browser, email, and a text processor). And my children
installed Linux by themselves, anyway, and they're programming
their academic research tasks on that platform. - No lengthy
stupid discussions as in this thread.

Janis

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 19/01/2024 16:03, bart wrote:

On 19/01/2024 14:42, David Brown wrote:

On 19/01/2024 14:18, bart wrote:

It is also incomprehensible how someone can rant endlessly about
"simplification" and "easy of use" when their claimed solution is to
make non-standard limited duplications of the functionality already
found on other machines.

The programs I write ARE easy to build, using ONLY a compiler.

You don't want to accept that, you'd rather it involved those mountains
of stuff.

/Please/ stop making stupid, exaggerated and incorrect claims about what
other people want or think.

I don't give a *beep* how easy or hard your programs are to compile -
they are utterly irrelevant to me. I don't have reason to believe they
are very relevant to anyone else either. But even if they were useful
to me, or at least of interest to me, it does not matter to me if they
need a whole range of standard utilities to build - because every system
I have, or ever have had, has the standard utilities.

Why is it so difficult for you to understand the concept of not caring?
It is absurd to suggest I /want/ your programs to need "make" or other utilities to compile - I *do* *not* *care* if it needs them or not.
There is no advantage or disadvantage to me if it uses make, sed, awk,
bash, date. There is no advantage or disadvantage to me if it does not
need them either. It is irrelevant.

It /would/ be an inconvenience to me if it required some obscure and
rarely used compiler like your own tools. TCC is also pretty obscure,
but Debian has it in it's repositories. Needing an invasive tool that
screws up your system, like MSVC, would also be a pain, as would
anything that required very specific versions of tools. But that would
only matter if your programs were of interest.

And of course I accept that /you/ think it is important that you don't
use tools that everyone else finds convenient and useful. I don't
understand your reasons for that - it seems to be based on a determined
battle to ensure that you fail to get anything you deem to be "Linux
related" to work, combined with a fanaticism about "simple" that
completely misses the point. But I don't think anyone here doubts that
/you/ think this is all desperately important, even though pretty much
no one else cares.


And /please/ stop making an arse of yourself here by calling a dozen
standard utilities "mountains of stuff".

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 19/01/2024 16:32, Janis Papanagnou wrote:

On 19.01.2024 15:42, David Brown wrote:

On 19/01/2024 14:18, bart wrote:

On 19/01/2024 11:41, David Brown wrote:

On 19/01/2024 12:17, bart wrote:

It doesn't matter what anyone says, you will always twist things to
fit your preconceived ideas that everything Linux-related is terrible
in every way,

That's funny. I find that Linux people always have terrible things to
say about software development using Windows, usually totally
unjustified.

And feel free to ignore these if you have good reason to believe they
are not fact based. Don't feel free to exaggerate what people say (I
say Linux is better for most development and programming work, other
than when targeting Windows itself - but you /can/ use Windows for many
tasks, and I do use Windows as well as Linux). [...]

There was a time when I dual booted (pre-installed) WinDOS and
Linux. At some point I got aware that it makes no sense, Windows
was - besides its inherent issues - also completely unnecessary
(as could be seen soon); further installs were Linux-only.

It's a phenomenon that the marketing division of MS did so great
a job to mentally bind such a huge community. (There were other
reasons as well (driver support of companies, pre-installed OS
on hardware, gaming focus, or self-enforcing dissemination
feedback processes), but discussion would lead too far here.)

I've often observed uninformed WinDozers just spread uninformed
nonsense. But never in such extreme stubbornness as in this thread.

[...]

[...]

I can fully understand how someone who is only familiar with Windows
(and DOS before it) doesn't know about these utilities or where to get
them, and finds them strange at first. [...]

This is part of the phenomenon.

And as we see nothing helps if folks grew up and didn't leave
that bubble, didn't even dare to have a look outside and try
to grasp what's going on. Yet continuing uninformed rants about
something they never experienced nor understood to a minimum
extent.

It's not me who's in the bubble. How about that giant bubble called 'Linux'?

People who complain about Windows will moan about something that is
missing because Linux has it and Windows doesn't.

My complaints about Linux are not about something missing from Linux
that is in Windows. See the difference?

We have to accept though that the condition where someone is
making specialized niche-software for a specific platform is
also not fostering susceptive open-mindedness when confronted
with the huge professional IT world.

But I have hope; after issues with Windows

What kinds of issues? Many millions of ordinary people have used
Windows. Not many ordinary people use raw Linux.

I installed Linux
even for my (very old) father, and he has no problems with it
(using browser, email, and a text processor). And my children
installed Linux by themselves, anyway, and they're programming
their academic research tasks on that platform. - No lengthy
stupid discussions as in this thread.

Well, be oblivious to all the issues then. Clearly that giant mountain
of stuff works for you and it works for your kids.

I however can see when someone is using a sledgehammer to crack a nut.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 19/01/2024 17:12, David Brown wrote:

On 19/01/2024 16:03, bart wrote:

On 19/01/2024 14:42, David Brown wrote:

On 19/01/2024 14:18, bart wrote:

It is also incomprehensible how someone can rant endlessly about
"simplification" and "easy of use" when their claimed solution is to
make non-standard limited duplications of the functionality already
found on other machines.

The programs I write ARE easy to build, using ONLY a compiler.

You don't want to accept that, you'd rather it involved those
mountains of stuff.

/Please/ stop making stupid, exaggerated and incorrect claims about what other people want or think.

I don't give a *beep* how easy or hard your programs are to compile -
they are utterly irrelevant to me.  I don't have reason to believe they
are very relevant to anyone else either.  But even if they were useful
to me, or at least of interest to me, it does not matter to me if they
need a whole range of standard utilities to build - because every system
I have, or ever have had, has the standard utilities.

Why is it so difficult for you to understand the concept of not caring?
It is absurd to suggest I /want/ your programs to need "make" or other utilities to compile - I *do* *not* *care* if it needs them or not.
There is no advantage or disadvantage to me if it uses make, sed, awk,
bash, date.  There is no advantage or disadvantage to me if it does not
need them either.  It is irrelevant.

It /would/ be an inconvenience to me if it required some obscure and
rarely used compiler like your own tools.  TCC is also pretty obscure,
but Debian has it in it's repositories.  Needing an invasive tool that screws up your system, like MSVC, would also be a pain, as would
anything that required very specific versions of tools.  But that would
only matter if your programs were of interest.

And of course I accept that /you/ think it is important that you don't
use tools that everyone else finds convenient and useful.  I don't understand your reasons for that

Because they don't work. Things like makefiles, even designed to work on Windows, had a 50% failure rate.

Higher if they originated on Linux.

100% if they originated on Linux and expected to run in that
environment. Your solution here is to replicated that environment even
on Windows.

Then the failure rate is much lower, if I use WSL (but it can still
fail). However that doesn't produce the native binaries I need.

You will say use MSYS2, and here I need to put my foot down - how many
rabbit holes do I have to go down to just to build a C program?

You obviously have a high tolerance of such rabbit holes.

Apparently it is inconceivable to you to have an application written in
C say, that can be compiled either on Linux or Windows using only a C
compiler.

- it seems to be based on a determined
battle to ensure that you fail to get anything you deem to be "Linux
related" to work, combined with a fanaticism about "simple" that
completely misses the point.  But I don't think anyone here doubts that /you/ think this is all desperately important, even though pretty much
no one else cares.

And /please/ stop making an arse of yourself here by calling a dozen
standard utilities "mountains of stuff".

Half of a Linux system, many thousands of lines of scripting code and makefiles, to build a project of a few dozen source files, is not a
mountain?

I've been looking at someone's C++ project which is a compiler for what
they call a 'toy' language. There are 33 .cpp files.

One of the dependencies however is something called LLVM. I've
downloaded what appears to be the bundle needed to build this project.

It is 140,000 files. Just unzipping it took 15 minutes.

You guys just don't get it. What /I/ do is the exact opposite of this.

You think it doesn't matter? A number of major language implementations
that are currently using an LLVM backend are thinking of moving away
from LLVM, or offering an alternative, BECAUSE it is so slow and cumbersome.

But I will leave this alone now.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

bart <[email protected]> writes:

On 19/01/2024 17:12, David Brown wrote:

On 19/01/2024 16:03, bart wrote:

On 19/01/2024 14:42, David Brown wrote:

On 19/01/2024 14:18, bart wrote:

It is also incomprehensible how someone can rant endlessly about
"simplification" and "easy of use" when their claimed solution is to
make non-standard limited duplications of the functionality already
found on other machines.

The programs I write ARE easy to build, using ONLY a compiler.

You don't want to accept that, you'd rather it involved those
mountains of stuff.

/Please/ stop making stupid, exaggerated and incorrect claims about what
other people want or think.

I don't give a *beep* how easy or hard your programs are to compile -
they are utterly irrelevant to me.  I don't have reason to believe they
are very relevant to anyone else either.  But even if they were useful
to me, or at least of interest to me, it does not matter to me if they
need a whole range of standard utilities to build - because every system
I have, or ever have had, has the standard utilities.

Why is it so difficult for you to understand the concept of not caring?
It is absurd to suggest I /want/ your programs to need "make" or other
utilities to compile - I *do* *not* *care* if it needs them or not.
There is no advantage or disadvantage to me if it uses make, sed, awk,
bash, date.  There is no advantage or disadvantage to me if it does not
need them either.  It is irrelevant.

It /would/ be an inconvenience to me if it required some obscure and
rarely used compiler like your own tools.  TCC is also pretty obscure,
but Debian has it in it's repositories.  Needing an invasive tool that
screws up your system, like MSVC, would also be a pain, as would
anything that required very specific versions of tools.  But that would
only matter if your programs were of interest.

And of course I accept that /you/ think it is important that you don't
use tools that everyone else finds convenient and useful.  I don't
understand your reasons for that

Because they don't work. Things like makefiles, even designed to work on >Windows, had a 50% failure rate.

Another number pulled out from your backside.

But then you're just trolling.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 19/01/2024 18:05, bart wrote:

On 19/01/2024 16:32, Janis Papanagnou wrote:

And as we see nothing helps if folks grew up and didn't leave
that bubble, didn't even dare to have a look outside and try
to grasp what's going on. Yet continuing uninformed rants about
something they never experienced nor understood to a minimum
extent.

It's not me who's in the bubble. How about that giant bubble called
'Linux'?

I suppose from inside your bubble, it looks like you are the only
sensible person and everyone else is in the bubble. Everyone is
marching out of step, except you.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 19/01/2024 19:28, bart wrote:

On 19/01/2024 17:12, David Brown wrote:

And of course I accept that /you/ think it is important that you don't
use tools that everyone else finds convenient and useful.  I don't
understand your reasons for that

Because they don't work. Things like makefiles, even designed to work on Windows, had a 50% failure rate.

And you have statistics to back that up? Other than personal anecdotes,
of course. (And before you get carried away, stack overflow questions
might show a non-zero failure rate, but not a 50% rate.)

Claims made without evidence or reason can be dismissed without evidence
or reason. /You/ have trouble building software - we know that, and no
one's arguing against that.

Apparently it is inconceivable to you to have an application written in
C say, that can be compiled either on Linux or Windows using only a C compiler.

I'll give you /one/ last chance to stop imaging what you think I am
saying and fighting against your ridiculous straw-man arguments.
Whenever you find yourself writing "You seem to think...", "You
want...", "You prefer...", stop and delete the paragraph. You are wrong
every single time.

But I will leave this alone now.

OK.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Keith Thompson <[email protected]> writes:

[...] Just including <unistd.h> has undefined behavior as far as
ISO C is concerned, [...]

Not true. The behavior of #include <unistd.h> is defined in
section 6.10.2 p2. One of two things is true: either the header
named is part of the implementation, or it isn't. If the named
header is part of the implementation, then it constitutes a
language extension, and so it must be documented (and defined).
If the named header is not part of the implementation, it still
must be a header that the implementation can process (because of
the constraint in 6.10.2 p1), and it must be processed the same
way as a header that is part of the implementation (because of
how the behavior is defined in 6.10.2 p2). Implementations are
not at liberty to do anything they want just because the header
named is not part of the implementation; such headers must be
processed in just the same way as standard or extension headers,
no matter how it is that they happen to be in the set of places
the implementation has defined (and documented) to hold headers.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 17/01/2024 18:47, Kaz Kylheku wrote:

On 2024-01-17, bart <[email protected]> wrote:

The only reason to use the shell for larger coding tasks that go
beyonod process control is that is that it's the only language you can
rely on being installed.

If we're going to be dealing with C sources, then I guess we can assume
a C compiler is going to be available, otherwise we might as well pack
up and go home.

So everthing needed could be done in C code with a C compiler being the
only dependency. If done nicely, the user gets one single C file to
compile and run, which will build and install the main app as needed.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 2024-01-20, Tim Rentsch <[email protected]> wrote:

Keith Thompson <[email protected]> writes:

[...] Just including <unistd.h> has undefined behavior as far as
ISO C is concerned, [...]

Not true. The behavior of #include <unistd.h> is defined in
section 6.10.2 p2. One of two things is true: either the header
named is part of the implementation, or it isn't. If the named
header is part of the implementation, then it constitutes a
language extension, and so it must be documented (and defined).

The problem with this reasoning is

1. Implementations in fact have internal headers that are not
documented, and which are not supposed to be included directly.
You will not get documentation for every single header that
is accessible via #include, and it is not reasonable for ISO C to
require it. I don't see where it does.

2. A documented extension continues to be undefined behavior.
The behavior is "defined", but not "ISO C defined". So even
if all the implementation's internal headers were documented
as extensions, their use would still be UB.

Undefined behavior is for which "this document imposes not
requirements", right?

It is not behavior for which "this document, together with the
ocumentation accompanying a given implementation, imposes
no requirements". Just "this document" (and no other).

If "this document" imposes no requirements, it's "undefined behavior",
no matter who or what imposes additional requirements!

Intuitively, a header which is part of an implementation can do
anything. For instance #include <pascal.h> can cause the rest of the translation unit to be analyzed as Pascal syntax, and not C.

An implementation can provide a header <reboot.h>, including
which causes a reboot at compile time, link time, or
execution time.

If such headers happen to exist, what in the standard is violated?

I used to experience a lot of push-back against the above views,
but I'm seeing that people are coming around.

--
TXR Programming Language: http://nongnu.org/txr
Cygnal: Cygwin Native Application Library: http://kylheku.com/cygnal
Mastodon: @[email protected]
NOTE: If you use Google Groups, I don't see you, unless you're whitelisted.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 1/20/24 23:46, Kaz Kylheku wrote:

On 2024-01-20, Tim Rentsch <[email protected]> wrote:

...

named is part of the implementation, or it isn't. If the named
header is part of the implementation, then it constitutes a
language extension, and so it must be documented (and defined).

The problem with this reasoning is
1. Implementations in fact have internal headers that are not
documented, and which are not supposed to be included directly. You
will not get documentation for every single header that
is accessible via #include, and it is not reasonable for ISO C to
require it. I don't see where it does.

"An implementation shall be accompanied by a document that defines all implementation-defined and locale-specific characteristics and all
extensions." 4p9

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Initially, I accidentally sent my response as private e-mail to Kaz
rather than to the group. With his permission, here's the response he sent:

On 1/21/24 01:37, Kaz Kylheku wrote:

On 2024-01-20 21:50, James Kuyper wrote:

"An implementation shall be accompanied by a document that defines all
implementation-defined and locale-specific characteristics and all
extensions." 4p9

That sentence says something subtly different from something like
"an implementation shall document everything that looks stable enough
to be an extension".

It is saying that there is required to be a document, and that in
that document there may be a list of one or more extensions.

The standard is defining the *fact* that this list is exhaustive:
it comprises all the extensions that are offered in the contract
between implementor and programmer.

Thus, for instance, if programmers empirically discover a behavior
which is not defined by ISO C, and which is not in that list,
it is not an extension. The standard states that that list has
all the extensions, and that discovered feature is not on it.

The sentence does not require implementors to document,
as an extension, every header file that is reachable by an #include directive.

The standard doesn't provide a definition for "extension", though it
makes many uses of the term, identifying a variety of things as possible
or common extensions to C. What you're saying is, essentially, that
extensions are defined as such by the fact that they are listed as such
in that document. The biggest problem I have with that is that ISO has a convention that allows them to say just that - all they would have had
to do is put "extension" in italics in 4p9, and that would identify the sentence in which it occurs as the definition of the term. They didn't
choose to do so. I concede that they might not have thought of doing so.

However, it seems more reasonable to me that whether or not something is
an extension is not supposed to be up to the implementor to decide.
Instead, anything that is an extension must be listed. This would be an
easier interpretation to defend if there were any explicit definition of "extension" in the standard.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 2024-01-21, James Kuyper <[email protected]> wrote:

However, it seems more reasonable to me that whether or not something is
an extension is not supposed to be up to the implementor to decide.
Instead, anything that is an extension must be listed. This would be an easier interpretation to defend if there were any explicit definition of "extension" in the standard.

The implication is that anything that works by accident must be listed
as an extension. If function arguments happen to be evaluated left to
right, with all side effects complete between them, this has to be
listed as an extension. Then in the future when the vendor finds that inconvenient for further compiler work, they have to take away the
extension.

I don't see how it can not be the implementor's privilege to assert what
is reliable for use and documented, versus what is not.

Unless they have some legal contract with particular customers,
requiring certain things be provided.

--
TXR Programming Language: http://nongnu.org/txr
Cygnal: Cygwin Native Application Library: http://kylheku.com/cygnal
Mastodon: @[email protected]
NOTE: If you use Google Groups, I don't see you, unless you're whitelisted.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Keith Thompson <[email protected]> writes:

Tim Rentsch <[email protected]> writes:

Keith Thompson <[email protected]> writes:

Tim Rentsch <[email protected]> writes:

Janis Papanagnou <[email protected]> writes:

This is a CPP question that arose last month. It's not about an
actual issue with the software, just out of curiosity and to be sure >>>>> it works reliable (it seemingly does).

In a C99 program on Linux (Ubuntu) I intended to use usleep() and
then also strnlen().

When I added usleep() and its include file I got an error and was
asked to define the CPP tag '_BSD_SOURCE'. I did so, and because I
wanted side effects of that tag kept as small as possible I
prepended it just before the respective #include and put it at the
end of my #include list

...other #includes...
#define _BSD_SOURCE
#include <unistd.h>

But as got obvious *that* way there had been side-effects and I
had to put the tag at the beginning of all include files (which
astonished me)

#define _BSD_SOURCE
#include <unistd.h>
...other #includes here...

For the strnlen() function I needed another CPP tag, '_GNU_SOURCE'.
So now I have both CPP tag definitions before the includes

I second the recommendations of Lowell Gilbert and others not to
define _BSD_SOURCE or _GNU_SOURCE (especially not _GNU_SOURCE)
but instead seek alternatives, which are readily available for
the two functionalities being sought in this case.

#define _GNU_SOURCE /* necessary for strnlen() in string.h */
#define _BSD_SOURCE /* necessary for usleep() in unistd.h */
...all #includes here...

For strnlen(), put an inline definition in a header file:

#ifndef HAVE_strnlen_dot_h_header
#define HAVE_strnlen_dot_h_header

#include <stddef.h>

static inline size_t
strnlen( const char *s, size_t n ){
extern void *memchr( const void *, int, size_t );
const char *p = memchr( s, 0, n );
return p ? (size_t){ p-s } : n;
}

#include <string.h>

#endif

Disclaimer: this code has been compiled but not tested.

strnlen() is specified by POSIX. It might make sense to
re-implement it if your code needs to work on a non-POSIX system
(that doesn't also provide it). Why would you want to do so
otherwise?

I'm trying to provide a helpful answer to the person I was
responding to, not espouse a philosophical viewpoint. Why do you
feel the need to start a style debate?

I don't. I simply asked you a question. You've refused to answer
it, and I won't waste my time asking again.

I did answer your question. My answer is "I'm trying to provide a
helpful answer to the person I was responding to [...]". I don't
know why you think that wasn't an answer.

memchr() is declared in <string.h>. Why would you duplicate its
declaration rather than just using `#include <string.h>`?

I had a specific reason for writing the code the way I did.
It wasn't important to explain that so I didn't.

Unsurprisingly, you refuse to do so even when asked directly.

You need to learn that declining is not refusing. Providing a
more complete explanation would uselessly muddy the waters. You
are completely free to ask any questions you want. You have no
right to demand answers, especially when my judgment is that what
you think of as an answer would be a waste of time. Stop being so self-centered.

For usleep(), define an alternate function usnooze(), to be used
in place of usleep(). In header file usnooze.h:

[snip]

If your code doesn't need to be portable to systems that don't
provide usleep(), you can just use usleep(). If it does, its
probably better to modify the code so it uses nanosleep().

Not everyone agrees with that opinion. Again, I'm just trying to
provide an answer helpful to OP, not advance an agenda. Like I
said in the part of my posting that you left out, I don't want to
get involved in a style war. If OP wants to modify his code to
use nanosleep(), I'm fine with that. If want wants to keep using
usleep() or switch to using usnooze(), I'm fine with that too. I
think it's more important in this case to provide options than to
try to change someone's point of view.

As usual, you vaguely denigrate my opinion without sharing your own.

I'm not denigrating your opinion. I'm simply pointing out that
it is an opinion, and that other people have different opinions.
I'm not presenting my opinion (even assuming I have one on this
subject, which is not guaranteed), because my purpose in posting
was to provide options to the OP, so they could make a decision
based on /their/ needs and their own opinions. I didn't consider,
or even start to consider, what my own opinions on the question
might be.

I have a general observation. In giving your opinions, often they
include a degree of argument or justification for why the views
expressed are a good idea. I have very little interest in getting
into an argument over personal opinions. If you want to hear more
of my opinions, probably it would help if you could focus on the
opinions more, and on the justifications or arguments less. If
and when I feel like it would be useful to express an opinion,
that does not automatically mean I think it would be useful to
explain it or justify it, or have any interest in doing so. For
me the first step is always understanding what it is the other
person is thinking (and hopefully vice versa); anything past
that is optional, and in most cases not worth pursuing.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 1/21/24 12:55, Kaz Kylheku wrote:

On 2024-01-21, James Kuyper <[email protected]> wrote:

However, it seems more reasonable to me that whether or not something is
an extension is not supposed to be up to the implementor to decide.
Instead, anything that is an extension must be listed. This would be an
easier interpretation to defend if there were any explicit definition of
"extension" in the standard.

The implication is that anything that works by accident must be listed
as an extension. If function arguments happen to be evaluated left to
right, with all side effects complete between them, this has to be
listed as an extension. Then in the future when the vendor finds that inconvenient for further compiler work, they have to take away the
extension.

No, that's unspecified behavior, if 4p9 were intended to be understood
as mandating documentation of all unspecified behavior, it would make
the category of implementation-defined behavior redundant.

Since extensions are also explicitly prohibited from changing the
behavior of strictly conforming code, I think that in order for
something qualify as an extension, it has to define behavior that the
standard leaves undefined. In a certain sense, every implementation
implicitly defines that behavior - whatever it is that actually happens
when the behavior is undefined is that definition. However, I think an extension should have to be explicitly activated by some deliberate user choice, such as a compiler option or by defining the behavior of some
kinds of syntax not allowed by the C standard. That's just IMHO, of
course - in the absence of a explicit definition in the standard, it's
hard to be sure what the committee intended.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

James Kuyper <[email protected]> writes:

On 1/21/24 12:55, Kaz Kylheku wrote:

On 2024-01-21, James Kuyper <[email protected]> wrote:

However, it seems more reasonable to me that whether or not
something is an extension is not supposed to be up to the
implementor to decide. Instead, anything that is an extension
must be listed. This would be an easier interpretation to defend
if there were any explicit definition of "extension" in the
standard.

The implication is that anything that works by accident must be
listed as an extension. If function arguments happen to be
evaluated left to right, with all side effects complete between
them, this has to be listed as an extension. Then in the future
when the vendor finds that inconvenient for further compiler work,
they have to take away the extension.

No, that's unspecified behavior, if 4p9 were intended to be
understood as mandating documentation of all unspecified behavior,
it would make the category of implementation-defined behavior
redundant.

Quite so.

Since extensions are also explicitly prohibited from changing the
behavior of strictly conforming code, I think that in order for
something qualify as an extension, it has to define behavior that
the standard leaves undefined.

The essential property of an extension is that it must specify a
language feature or library feature that is not specified in the C
standard. Implementations are free to /define/ undefined behavior
any way they want, and doing so doesn't require an extension; the
point of documenting an extension is to /specify what happens/ in
certain cases, which also means giving a guarantee that what is
documented is what will happen (with the understanding that the
guarantee is only that the implementation will make its best
efforts to do so, because some results are outside of an
implementation's ability to control).

(I note in passing that an odd consequence of how the C standard
uses certain terminology is that "defining" something doesn't stop
it from being "undefined". The term "undefined behavior" is thus
something of a misnomer. But I digress.)

Conversely, an extension can specify a feature that is not, or
might not be, undefined behavior, but still needs to be documented
as an extension. For example

#include <foo.h>

is not undefined behavior, but must be documented as an extension
if the header <foo.h> is part of the implementation, because what
is in the header <foo.h> is not specified in the C standard.
Similarly, a declaration like

typedef __uint128_t U128;

is not necessarily undefined behavior, because implementations are
free to define reserved identifiers any way they wish. But if it's
important that it work, then it must be documented as an extension,
as otherwise an implementation is free to reject it by virtue of
using a language feature not specified in the C standard (which
therefore means the program is not strictly conforming, and so can
be rejected).

In a certain sense, every
implementation implicitly defines that behavior - whatever it is
that actually happens when the behavior is undefined is that
definition. However, I think an extension should have to be
explicitly activated by some deliberate user choice, such as a
compiler option or by defining the behavior of some kinds of
syntax not allowed by the C standard. That's just IMHO, of course
- in the absence of a explicit definition in the standard, it's
hard to be sure what the committee intended.

That's a QOI issue. I'm not convinced that it's a good idea in
all cases. For example, either of the two cases mentioned above:

#include <foo.h>

typedef __uint128_t U128;

do not IMO need an explicit user action to activate, because it's
obvious they are making use of extensions, and are pretty unlikely
to occur by accident. I concede however that other people may
reasonably hold other views on that question.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Kaz Kylheku <[email protected]> writes:

On 2024-01-21, James Kuyper <[email protected]> wrote:

However, it seems more reasonable to me that whether or not something is
an extension is not supposed to be up to the implementor to decide.
Instead, anything that is an extension must be listed. This would be an
easier interpretation to defend if there were any explicit definition of
"extension" in the standard.

The implication is that anything that works by accident must be
listed as an extension. If function arguments happen to be
evaluated left to right, with all side effects complete between
them, this has to be listed as an extension. Then in the future
when the vendor finds that inconvenient for further compiler work,
they have to take away the extension.

I don't see how it can not be the implementor's privilege to
assert what is reliable for use and documented, versus what is
not.

It's important to understand what constitutes an extension. And
there are different kinds of extensions.

If an implementation chooses, say, to evaluate function arguments
always left-to-right, that is perfectly okay (and need not be an
extension). But if an there is to be a /guarantee/ that function
arguments will always be evaluated left-to-right, that means
providing a guarantee that the C standard does not; thus we have an
extension (to the requirements in the C standard), and the extension
must be documented. This case is one kind of extension.

If an implementation chooses to alter the semantics of, for example,
an extern declaration inside a function body, so that the declared
identifier has file scope rather than block scope, that is a
different kind of extension. At the point of the extern declaration
we can't actually detect any difference. A subsequent use, however,
outside the function body, would normally be a constraint violation
and so require a diagnostic, but under the altered semantics the
identifier has already been declared and so no diagnostic is needed.
(Note that this behavior is one of the cases listed in Annex J.5,
"Common extensions".) This example illustrates a second kind of
extension, and they always must be documented as such.

If an implementation chooses to define, for example, __uint128_t to
be the name of an integer type, that represents a third kind of
extension. (Annex J.5 also mentions such definitions as an example
on its list of "Common extensions".) Such cases must be documented
as extensions because, one, the expected default is that there be no
definition (which normally would cause a diagnostic because of some
constraint violation), and two, only the implementation is in a
position to know if the symbol in question was defined by the
implementation or by something else. Clearly any definition the
implementation provides signals a change from the expected default,
which by any reasonable definition of the word constitutes an
extension, and hence must be documented.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 31/01/2024 22:41, Keith Thompson wrote:

Tim Rentsch <[email protected]> writes:

Kaz Kylheku <[email protected]> writes:
It's important to understand what constitutes an extension. And
there are different kinds of extensions.

If an implementation chooses, say, to evaluate function arguments
always left-to-right, that is perfectly okay (and need not be an
extension). But if an there is to be a /guarantee/ that function
arguments will always be evaluated left-to-right, that means
providing a guarantee that the C standard does not; thus we have an
extension (to the requirements in the C standard), and the extension
must be documented. This case is one kind of extension.

If an implementation chooses to guarantee left-to-right evaluation, I
don't see anything in the standard that requires that guarantee to be documented. (Of course it can and should be.)

I would say that a "guarantee" is a promise - in this case, from the
compiler writers to compiler users. It's not a guarantee if they don't
tell anyone! Then it's just an implementation detail. But I don't see
that it has to be documented in any particular way, or called an
"extension". IIRC MSVC's "guarantee" that it won't use type-based alias analysis for optimisation (and thus casting between pointer types will
work as some people think they should work) is "documented" in a blog
post by one of the compiler developers.

Of course it is up to the user to decide how much they trust the
guaranteed additional behaviour. A mailing list post with "We'll
evaluate left to right, or your money back!" or a note in a blog page
would probably not inspire as much confidence as clear information in
the main reference documentation for a compiler.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Kaz Kylheku <[email protected]> writes:

On 2024-01-20, Tim Rentsch <[email protected]> wrote:

Keith Thompson <[email protected]> writes:

[...] Just including <unistd.h> has undefined behavior as far as
ISO C is concerned, [...]

Not true. The behavior of #include <unistd.h> is defined in
section 6.10.2 p2. One of two things is true: either the header
named is part of the implementation, or it isn't. If the named
header is part of the implementation, then it constitutes a
language extension, and so it must be documented (and defined).

The problem with this reasoning is

1. Implementations in fact have internal headers that are not
documented, and which are not supposed to be included directly.
You will not get documentation for every single header that
is accessible via #include, and it is not reasonable for ISO C to
require it. I don't see where it does.

First, James Kuyper already identified section 4 paragraph 9.

Second, implementations do have lots of internal headers that are
not meant to be included directly, but just because such headers
exist doesn't mean they can be #include'd. Consider these lines
at the start of <bits/byteswap.h>

#if !defined _BYTESWAP_H && !defined _NETINET_IN_H && !defined _ENDIAN_H
# error "Never use <bits/byteswap.h> directly; include <byteswap.h> instead."
#endif

Clearly implementations can and do distinguish between headers
that are meant to be user #include-able and those that are not,
and take steps to protect the hidden ones. It seems obvious
that implementations consider it reasonable to document headers
that are meant to be user #include-able, and to protect the
hidden headers so they can't be #included directly, because
that is what existing implementations do.

2. A documented extension continues to be undefined behavior.
The behavior is "defined", but not "ISO C defined". So even
if all the implementation's internal headers were documented
as extensions, their use would still be UB.

Undefined behavior is for which "this document imposes not
requirements", right?

It is not behavior for which "this document, together with the
ocumentation accompanying a given implementation, imposes
no requirements". Just "this document" (and no other).

If "this document" imposes no requirements, it's "undefined
behavior", no matter who or what imposes additional requirements!

Your logic here is all messed up. The very first sentence uses
circular reasoning. Next you ignore the point that the "define" in
section 4 paragraph 9 is a Standard-imposed requirement, and surely
the Standard means to require that implementations obey their own
definitions, because that's what "define" means. The idea that
having to document extensions doesn't imply an ISO C requirement is
just being obtuse.

Perhaps a more fundamental flaw is you have the key implication
backwards. IF using a particular program construct or data value
has been identified as undefined behavior, THEN the C standard
imposes no requirements on those uses. The implication doesn't go
the other way. For example, the C standard imposes no requirements
for what happens on Tuesdays. That does not mean that compiling a
program on a Tuesday is undefined behavior. The universe of
discourse is program constructs and data values ("values" here also
includes things such as trap representations). Saying "an unknown
header is undefined behavior" is meaningless, because it's outside
the universe of discourse, just like Tuesdays are. The C construct
in question is "#include <unistd.h>", and the C standard defines
behavior for that construct.

Intuitively, a header which is part of an implementation can do
anything. For instance #include <pascal.h> can cause the rest of
the translation unit to be analyzed as Pascal syntax, and not C.

An implementation can provide a header <reboot.h>, including
which causes a reboot at compile time, link time, or
execution time.

If such headers happen to exist, what in the standard is violated?

More bad logic. Of course the contents of a header or #include'd
file can have, for example, syntax errors, that result in crossing
the line into undefined behavior. The question is not whether an
unknown header /can/ cross the line into undefined behavior but
whether it /must/ cross that line. Whether a #include of an unknown
header encounters undefined behavior depends on the contents of the
header, and nothing else. A #include <unistd.h> MIGHT cross the
line into UB land, but there is nothing that says it MUST cross that
line.

Note by the way that exactly the same reasoning applies to an
unknown source file, such as #include "foo.h". If we don't know
what's in foo.h (maybe it was left by a hacker in a little-used
byway of where the implementation looks for #include'd source
files), then undefined behavior is possible, but whether UB
actually happens depends only on the contents of the file, not on
whether we know what's in it.

I used to experience a lot of push-back against the above views,
but I'm seeing that people are coming around.

I expect that is simply a consequence of your dogged persistence
and the brighter people dropping out of the conversations. It's
not whether some people start to be convinced, but rather which
people are convinced, and how firmly convinced, and why.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Thu, 18 Jan 2024 19:40:44 -0000 (UTC), Kaz Kylheku <[email protected]> wrote:

On 2024-01-18, bart <[email protected]> wrote:

All I know about PowerShell is that instead of typing 'prog' to run the 'prog.exe' you've just created, you have to do '.\prog' just like you
have to do './prog' in Linux.

That's not true for 'prog', but is true for any name of a PS cmdlet or
alias. In that case you must use a pathname (which can be EITHER
.\name OR ./name) OR name.exe.

CMD has some builtins which similarly make program files inaccessible
by simple name, but fewer. The ones I recall off the top of my head
are cd pushd popd dir mkdir md rmdir rd erase type set rem. And here
.\name or name.exe works but not ./name.

I don't know anything about PowerShell. In the case of the POSIX-like
shells, this is just a consequence of the . directory not being listed
in the PATH variable, which is an end-user configuration matter.

If you care about the convenience of just typing "prog", more than
about the security aspect, you can just add . to your PATH.

No. In PS (_and_ in CMD) current directory aka dot is _always_ tried
even if it's not in PATH (which by default it isn't). But cmdlets and
aliases or builtins are tried first and override any file, per above.

Unix shells similarly won't find by simple name a program in . even
when . IS in PATH if the name is a builtin or keyword like 'cd' or
'if' or 'test' (probably the most popular name to encounter this
error), or a function or alias (shells don't come with lots of aliases predefined like PS, but many distros or users add them).

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

[email protected] writes:

On Thu, 18 Jan 2024 19:40:44 -0000 (UTC), Kaz Kylheku ><[email protected]> wrote:

On 2024-01-18, bart <[email protected]> wrote:

All I know about PowerShell is that instead of typing 'prog' to run the
'prog.exe' you've just created, you have to do '.\prog' just like you
have to do './prog' in Linux.

That's not true for 'prog', but is true for any name of a PS cmdlet or
alias. In that case you must use a pathname (which can be EITHER
.\name OR ./name) OR name.exe.

Actually, on linux, one can just do 'prog', if PATH includes
an path element containing a single dot. One generally doesn't
do this, but it is certainly possible.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Keith Thompson <[email protected]> writes:

[...]

P.S. My apologies for not responding to your posting earlier.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Keith Thompson <[email protected]> writes:

Tim Rentsch <[email protected]> writes:

Kaz Kylheku <[email protected]> writes:
It's important to understand what constitutes an extension. And
there are different kinds of extensions.

If an implementation chooses, say, to evaluate function arguments
always left-to-right, that is perfectly okay (and need not be an
extension). But if an there is to be a /guarantee/ that function
arguments will always be evaluated left-to-right, that means
providing a guarantee that the C standard does not; thus we have an
extension (to the requirements in the C standard), and the extension
must be documented. This case is one kind of extension.

If an implementation chooses to guarantee left-to-right evaluation, I
don't see anything in the standard that requires that guarantee to be documented. (Of course it can and should be.)

It's not entirely clear to me exactly what must or must not be
considered to be an "extension" as the C standard uses the term. The standard doesn't show the word "extension" in italics or provide a
definition in section 3.

Unless your point is that it's not a guarantee unless it's documented?
But I don't see that that documentation is required *by the standard*.

It seems likely that we have different notions of what "a guarantee"
is. As I am using the term it does not mean a statement of what
does happen but a promise for what will happen. Consulting some
online dictionaries, I find the following definitions (among others
that for the most part are not relevant). Note that all of these
are for "guarantee" used as a noun (presented in the order of
shortest first):

an assurance for the fulfillment of a condition

Something that assures a particular outcome or condition.

A pledge that something will be performed in a specified
manner.

an unconditional commitment that something will happen or
that something is true

a written assurance that some product or service will be
provided or will meet certain specifications

A promise or assurance, especially one given in writing, that
attests to the quality or durability of a product or service.

a promise or assurance, especially one in writing, that
something is of specified quality, content, benefit, etc.,
or that it will perform satisfactorily for a given length of
time: "a money-back guarantee".

In the context of a C implementation, for some condition to be a
guarantee I would say it must be written down (which is to say,
documented), as otherwise it doesn't qualify as a guarantee. In
any case that is how I am using the term.

Incidentally, as best I can determine the C standard uses the
term "guarantee" as a noun in only one place in normative text
(6.5.2.3 p6) and in two places in informative text (5.1.2.4 p23
and a footnote to 7.22.2.1 p2). Various forms of "guarantee"
used as a verb appear in the C standard in lots of places. I am
specifically using the noun form in my comments here.

I think most people would agree that any documented guarantee of
behavior beyond what the C standard requires of all implementations
(and is not part of the documentation for implementation-defined
behaviors) qualifies as an extension to the C language, and thus
should be considered an extension as the ISO C standard uses the
term, given that the C standard itself does not define the term
but (one assumes) uses the word in its ordinary English sense.

[...]

If an implementation chooses to define, for example, __uint128_t to
be the name of an integer type, that represents a third kind of
extension. (Annex J.5 also mentions such definitions as an example
on its list of "Common extensions".) Such cases must be documented
as extensions because, one, the expected default is that there be no
definition (which normally would cause a diagnostic because of some
constraint violation), and two, only the implementation is in a
position to know if the symbol in question was defined by the
implementation or by something else. Clearly any definition the
implementation provides signals a change from the expected default,
which by any reasonable definition of the word constitutes an
extension, and hence must be documented.

Again, that can and should be documented, but since any use of the
identifer __uint128_t has undefined behavior,

That isn't right. The C standard says that declaring or defining a
reserved identifier is undefined behavior. The C standard does NOT
say that using a reserved identifier is undefined behavior. If an implementation does not define an identifier like __uint128_t, then
any use in ordinary code (that is, not part of a pre-processor
directive) should produce a diagnostic due to a syntax or constraint
violation. If we don't get a diagnostic we know that the identifier
/must/ have been defined by the implementation, and because it is a
change in behavior over standard C it must be documented as an
extension.

(Note added during editing: "any use in ordinary code" is meant in
the sense of "a use that is not a declaration or definition".)

I don't see any
requirement in the standard that it must be documented.

It must be documented because it represents a change in behavior
over what the C standard requires, and any such change constitutes
an extension to the language, and the C standard requires extensions
to be documented.

(Aside: gcc has an extension adding __int128 as a keyword, supporting
types "__int128" and "unsigned __int128", but only on some target
systems. These do not qualify as extended integer types. I understand
that "__uint128_t" was a hypothetical example.)

On the systems I use the identifiers __int128_t and __uint128_t are
both predefined type names (and not keywords), under both gcc and
clang. I see some support for __int128 as a keyword, but the
predefined type names seem to be more reliable (at least in my
environments).

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

[email protected] (Otto J. Makela) writes:

Janis Papanagnou <[email protected]> wrote:

On 16.01.2024 19:03, David Brown wrote:

[...], because they know that Norwegians are superior to Swedes in
every way...

I just wanted to reply on that but then I saw your email address... :-)

A Finn smirking from the sidelines.

As if you have no rivalry with Swedes. What's the score? 5-1? Ooops, now
it's 5-6. We have a great view here from Estonia.

/* Mail: Mechelininkatu 26 B 27, FI-00100 Helsinki */

Send my regards to Vastarannan Kiiski.

Phil
--
We are no longer hunters and nomads. No longer awed and frightened, as we have gained some understanding of the world in which we live. As such, we can cast aside childish remnants from the dawn of our civilization.
-- NotSanguine on SoylentNews, after Eugen Weber in /The Western Tradition/

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)