On 2024-02-15, Lawrence D'Oliveiro <ldo@nz.invalid> wrote:
> On Tue, 13 Feb 2024 12:58:49 -0800, Keith Thompson wrote:
>
>> You're suggesting that correctness doesn't matter unless the software
>> controls nuclear missiles.
>
> I would be hoping that safety-critical software would be written to higher
> standards than military stuff.
>
> After all, in military operations, a “friendly fire” rate of, say, 10-25%,
> seems to be considered acceptable.

Using garbage collection in a missile should be entirely acceptable; use
it liberally in development, and then in deployment, have enough RAM
and tune the parameters so that it strikes the target before the first
GC cycle.

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

On 15/02/2024 16:40, Kaz Kylheku wrote:
> On 2024-02-15, bart <bc@freeuk.com> wrote:
>> On 15/02/2024 03:08, Kaz Kylheku wrote:
>>> On 2024-02-15, bart <bc@freeuk.com> wrote:
>>>> There appears to be nobody in Unix who questions such things; everyone
>>>> takes takes at face value. So long as it eventually produces a result,
>>>> no matter how long it takes or how torturous the process, nobody cares.
>>>
>>> This is false. There are many critics "in Unix", of Makefiles, GNU
>>> Autotools, the C language including its preprocessing, the shell
>>> language, various utilities, POSIX API's, and almost imaginable element
>>> of the whole cornucopia. Many are well-informed, experienced and have
>>> well-reasoned opinions.
>>>
>>
>> And yet I still can't trivially compile pnminvert.c into pnminvert.exe
>> using just a C compiler.
>
> Unsurprisingly, the existence of critics in the C and Unix world
> doesn't magically fix an obscure netpbm build problem.
>
>> make[2]: Leaving directory '/mnt/c/xxx/netpbm-10.86.40/lib/util'
>> cc -shared -Wl,--image-base=0x10000000 -Wl,--enable-auto-import
>
> Looks like the linker doesn't understand the --image-base option.
>
> That option exists somewhere for some good reason.
>
> I can't imagine why something like netpbm would need exotic linker
> options, but there is probably some reason it was introduced.

Quite. I can't imagine why it would need lots of other less exotic
things too. It's hard to think of a set of tasks that would be more
portable.

It's just more opportunities for failure and more limited portability.

> It would be more productive to take this up with the netpbm project
> than the comp.lang.c newsgroup.

This is not specific to that product, it's just something that came up,
which I decided to investigate. But it seems to be quite typical.

On 15/02/2024 16:36, bart wrote:
> On 15/02/2024 15:10, Scott Lurndal wrote:
>> bart <bc@freeuk.com> writes:
>>> On 14/02/2024 21:47, Scott Lurndal wrote:
>>
>>>> I've never read so many complaints from one person.
>>>
>>> Here's a challenge: give me a reason not to complain.
>>
>> Life is short and there are far better ways to spend
>> one's time.
>
> You've expressed my thoughts exactly. Why should I waste /my/ grappling
> with someone else's mess of a build process?

A lot of us wonder about that too. Even stranger, you don't waste your
time trying to understand the issues you are having, or fixing them, you
waste all of our times griping about them here - to people who didn't
make the build systems in question, who aren't in a position to fix
them, don't have the same problems themselves, and are not at all
interested in the software in question. And when we /do/ try to help,
you don't listen - you just whine more.

I recommend you think hard about what you are doing with all that, and
perhaps consider spending your time some other way. Like talking about
C, or asking questions about the many things you don't understand about
C. Even whining about the things you don't like about C would be better
than whining about things you don't like about build processes!

On 15/02/2024 18:29, Kaz Kylheku wrote:
> On 2024-02-15, Lawrence D'Oliveiro <ldo@nz.invalid> wrote:
>> On Tue, 13 Feb 2024 12:58:49 -0800, Keith Thompson wrote:
>>
>>> You're suggesting that correctness doesn't matter unless the software
>>> controls nuclear missiles.
>>
>> I would be hoping that safety-critical software would be written to higher
>> standards than military stuff.
>>
>> After all, in military operations, a “friendly fire” rate of, say, 10-25%,
>> seems to be considered acceptable.
>
> Using garbage collection in a missile should be entirely acceptable; use
> it liberally in development, and then in deployment, have enough RAM
> and tune the parameters so that it strikes the target before the first
> GC cycle.
>

It is not uncommon in embedded systems for "malloc" to allocate directly
from a single block of memory with a single "next free byte" pointer,
while "free" does nothing. As long as malloc is used just for memory
allocations at startup, it all works fine.

On 15/02/2024 21:16, David Brown wrote:
> On 15/02/2024 16:36, bart wrote:
>> On 15/02/2024 15:10, Scott Lurndal wrote:
>>> bart <bc@freeuk.com> writes:
>>>> On 14/02/2024 21:47, Scott Lurndal wrote:
>>>
>>>>> I've never read so many complaints from one person.
>>>>
>>>> Here's a challenge: give me a reason not to complain.
>>>
>>> Life is short and there are far better ways to spend
>>> one's time.
>>
>> You've expressed my thoughts exactly. Why should I waste /my/
>> grappling with someone else's mess of a build process?
>
> A lot of us wonder about that too.  Even stranger, you don't waste your
> time trying to understand the issues you are having, or fixing them, you
> waste all of our times griping about them here - to people who didn't
> make the build systems in question, who aren't in a position to fix
> them, don't have the same problems themselves, and are not at all
> interested in the software in question.  And when we /do/ try to help,
> you don't listen - you just whine more.
>
> I recommend you think hard about what you are doing with all that, and
> perhaps consider spending your time some other way.  Like talking about
> C, or asking questions about the many things you don't understand about
> C.  Even whining about the things you don't like about C would be better
> than whining about things you don't like about build processes!
>
>

I was under the impression that applications and libraries that were
written in C, were written in C.

Apparently I was wrong. It seems almost unheard of to be able to create
a runnable version of a C program by simply compiling the source code.

Because there's some unwritten rule that they must use at least half the
features of Linux-Unix in order to achieve that.

How about that, a famously portable language that can only be built if
you have half of Linux to hand.

On 2024-02-15, bart <bc@freeuk.com> wrote:
> How about that, a famously portable language that can only be built if
> you have half of Linux to hand.

"I have long stated that 90% of the C programs I have on file will not
compile. Your estimate confirms my observation."

-- Scott Nudds, Feb 3, 1997

https://groups.google.com/g/comp.lang.c/c/J-FqEXoSVj8/m/xBhpjpCYB3cJ

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

On 2024-02-15, bart <bc@freeuk.com> wrote:
> On 15/02/2024 16:40, Kaz Kylheku wrote:
>> It would be more productive to take this up with the netpbm project
>> than the comp.lang.c newsgroup.
>
> This is not specific to that product, it's just something that came up,
> which I decided to investigate. But it seems to be quite typical.

I've never seen the above specific problem with the --image-base
passed to the linker.

There are many environments out there; and the people who make the
software only work with a few (sometimes only one). If you only build
your program on Linux, it might not work on WSL, MacOS, Cygwin or
Solaris or what have you.

It's not uncommon for people who build free software programs
("downstream people") into packages and distros to apply patches for one
reason or another.

One problem is that the downstream people don't always communicate
with the developers ("upstream people"). It's less effort to just patch
something in your world, and not inform upstream that you had to do
this.

Sometimes people have a negative experience reporting something
upstream, which results them in having spent extra effort, yet still
having to continue apply their rejected patch. That discourages them
from trying again the next time they have to patch something in the
same program or another.

I've caught distros patching some of my programs for this and that, by
peeking into their repos and bug reporting systems. I would secretly
fixd the problem, making sure to do in a way such that their patch would
not apply any more. Then watch them pick up a new release and remove the
patch. No e-mails or anything exchanged at all.

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

On Tue, 13 Feb 2024 17:52:31 +0100, Janis Papanagnou wrote:

> On 12.02.2024 02:13, Lawrence D'Oliveiro wrote:
>>
>> But boolean is a subtype of int anyway, so what’s the harm in
>> redefining conditional expressions to return bool instead?
>
> Well, no harm, but some useful constructs would probably not work any
> more.
>
> Just this morning I wrote[*], for example,
>
> size = (size+1+shift)%3; // cycle through three sizes
>
> where 'shift' is actually a boolean (with possible values 0 and 1).

But they are interconvertible anyway, so that will be fine.

> [*] Actually in Javascript, but the expression is also valid in C.

And that is valid in JavaScript. Just tried it:

>> 2 + 2
4
>> 2 + true
3
>> 2 + false
2

On Thu, 15 Feb 2024 15:16:22 GMT, Scott Lurndal wrote:

> Lawrence D'Oliveiro <ldo@nz.invalid> writes:
>
>>The first version of the C++ standard was C++98, and that had bool in
>>it.
>
> The first version of C++ was in the mid-80s and didn't have bool (c.f.
> cfront).

It wasn’t a “standard” back then.

On Thu, 15 Feb 2024 16:41:23 +0000, Malcolm McLean wrote:

> I can't remember the precedence relationships beyond a few very
> conventional and well known ones.

No need to. This is why we have documentation. Keep it handy, and don’t be
ashamed to refer to it often, even in the presence of colleagues.

On Thu, 15 Feb 2024 16:47:12 +0000, Malcolm McLean wrote:

> That is an issue. It's hard to match parentheses in long expressions.

I have a simple answer to that: take advantage of the two dimensions of
space available to you on the screen/page:

if
(
nrhistentries <= 4
||
nrpixels
/
(
nrpixels
-
(
histogram[0].count
+
histogram[1].count
+
histogram[2].count
+
histogram[3].count
)
) /* won't be zero */
>=
count_factor
)
{
...
} /*if*/

On Thu, 15 Feb 2024 14:23:57 +0100, David Brown wrote:

> On 15/02/2024 10:00, Lawrence D'Oliveiro wrote:
>
>> If Marie Kondo were to learn C programming, what do you think she would
>> do?
>
> So now ...

“Perfection is achieved, not when there is nothing more to add, but
when there is nothing left to take away.”
-- Antoine De Saint-Exupéry

On 2024-02-16, Lawrence D'Oliveiro <ldo@nz.invalid> wrote:
> On Thu, 15 Feb 2024 16:47:12 +0000, Malcolm McLean wrote:
>
>> That is an issue. It's hard to match parentheses in long expressions.
>
> I have a simple answer to that: take advantage of the two dimensions of
> space available to you on the screen/page:
>
> if
> (
> nrhistentries <= 4
> ||
> nrpixels
> /
> (
> nrpixels
> -
> (
> histogram[0].count
> +
> histogram[1].count
> +
> histogram[2].count
> +
> histogram[3].count
> )
> ) /* won't be zero */
> >=
> count_factor
> )
> {
> ...
> } /*if*/

At that point you start losing to Lisp. E.g. TXR Lisp:

(if (or (< hrhistentries 4)
(>= (/ nrpixels
(- nrpixels
(+ [histogram 0].count
[histogram 1].count
[histogram 2].count
[histogram 3].count)))
count-factor))
...)

This is idiomatic code, not a joke. I revisit code like this I've
written years ago, or that someone else wrote, and have no trouble
understanding it.

Everything is an expression in Lisp. 200 line function definition?
one giant expression. Breaking it into multiple lines follows
a simple algorithm, with a handful of cases.

Right inside this edit session for this Usenet article, I can do this:

(if (or (< hrhistentries 4)
(>= (/ nrpixels
(- nrpixels
(+ [histogram 0].count
[histogram 1].count
[histogram 2].count
[histogram 3].count)))
count-factor))
....)

Then turn on Lisp mode in Vim using :set lisp, visually select
the block and hit = to reindent it:

(if (or (< hrhistentries 4)
(>= (/ nrpixels
(- nrpixels
(+ [histogram 0].count
[histogram 1].count
[histogram 2].count
[histogram 3].count)))
count-factor))
...)

It knows that if is an operator so the ... body is indented
by two, rather than lined up with (or ...). This is because
if is listed in the "lispwords" variable (:set lispwords=...).

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

On 15.02.2024 09:51, Lawrence D'Oliveiro wrote:
> On Thu, 15 Feb 2024 08:23:09 +0100, Janis Papanagnou wrote:
>
>> It's worth to add Awk to your list of script languages, since it's
>> standard on Unix, and its syntax largely resembles the syntax of C.
>
> Perl does everything Awk can do, and do it just as concisely, and it can
> do more besides.

You missed the point; it was about scripting languages and C syntax,
in context of someone trying to make a point whether special C-like
scripting languages were necessary (or C as a scripting language).

It was not about what some scripting language provides as features
or libraries. I wonder why you try to open a completely unnecessary
dispute like that, especially by trying to compare C with Perl.

Perl is not standard and has its own cryptic syntax deviating from C.
And Perl is not a terse language tool but more like a huge tractor.
You can master Awk in few hours, not so Perl. Why do you think that
anyone would feel a need to dispute language richness and compare
Perl with Awk.

Janis

On 15.02.2024 10:00, Lawrence D'Oliveiro wrote:
> On Thu, 15 Feb 2024 08:00:00 +0100, Janis Papanagnou wrote:
>
>> On 14.02.2024 21:52, Lawrence D'Oliveiro wrote:
>>
>>> On Wed, 14 Feb 2024 00:18:50 +0100, Janis Papanagnou wrote:
>>>
>>>> Though most precedence rules in C make parenthesis usually unnecessary
>>>> and expressions rarely need parenthesis to provide that certainty.
>>>
>>> And yet you were the one who added unnecessary ones in your example, I
>>> didn’t.
>>
>> Yes, and I explained that with the given rules you have no "clutter"
>> (as you called it) ...
>
> “Clutter” is when you put in ones you don’t need.

You seem to have some specific restricted definition for "need".
You may need it syntactically or not when you have a given semantics.
You may need it to clarify (or ascertain) something or not.

I certainly don't consider it "clutter" if I can make non-obvious
things clearer for the maintainers of a piece of code.

Janis

On 15.02.2024 14:34, David Brown wrote:
>
> Perhaps the most significant Pascal program is TeX, which was written in
> a combined documentation/coding language "Web" using Pascal as the
> programming language.

Oh, that's interesting! (I've never heard much about the TeX internals.)

Janis

On 15.02.2024 09:48, Lawrence D'Oliveiro wrote:
> On Tue, 13 Feb 2024 16:55:32 +0100, Janis Papanagnou wrote:
>
>> You are mistaken; C++ had no 'bool' type initially. It had been added
>> later.
>
> The first version of the C++ standard was C++98, and that had bool in it.

Yes. But my comment about the other poster being mistaken was where
he wrote about the time "When C++ was forked from C" (and not "When
C++ became standardized").

And then he squirmed by introducing vague terms to muddy this fault
("Pre-history vs history.")

The "fork from C" was (as BJ's book) in the 1980's, the standard in
the late 1990's.

And the other poster makes (obviously) a wrong claim about it being
in the first edition of Stroustrup's book.

(Is spreading "alternative facts" so established meanwhile?)

Janis

On 16.02.2024 02:09, Lawrence D'Oliveiro wrote:
>
> And that is valid in JavaScript. Just tried it:
>
> >> 2 + 2
> 4
> >> 2 + true
> 3
> >> 2 + false
> 2
>

Oh, I'm just programming in JS (since I've no web server running),
but I'm not the right one to discuss this language. (I would have
far too much to criticize and my "copious free time" is limited.)

Janis

On 15.02.2024 18:29, Kaz Kylheku wrote:
> On 2024-02-15, Lawrence D'Oliveiro <ldo@nz.invalid> wrote:
>> On Tue, 13 Feb 2024 12:58:49 -0800, Keith Thompson wrote:
>>
>>> You're suggesting that correctness doesn't matter unless the software
>>> controls nuclear missiles.
>>
>> I would be hoping that safety-critical software would be written to higher
>> standards than military stuff.
>>
>> After all, in military operations, a “friendly fire” rate of, say, 10-25%,
>> seems to be considered acceptable.
>
> Using garbage collection in a missile should be entirely acceptable; use
> it liberally in development, and then in deployment, have enough RAM
> and tune the parameters so that it strikes the target before the first
> GC cycle.

Great! :-)

Janis

On 2/15/2024 7:14 PM, Janis Papanagnou wrote:
> On 15.02.2024 18:29, Kaz Kylheku wrote:
>> On 2024-02-15, Lawrence D'Oliveiro <ldo@nz.invalid> wrote:
>>> On Tue, 13 Feb 2024 12:58:49 -0800, Keith Thompson wrote:
>>>
>>>> You're suggesting that correctness doesn't matter unless the software
>>>> controls nuclear missiles.
>>>
>>> I would be hoping that safety-critical software would be written to higher
>>> standards than military stuff.
>>>
>>> After all, in military operations, a “friendly fire” rate of, say, 10-25%,
>>> seems to be considered acceptable.
>>
>> Using garbage collection in a missile should be entirely acceptable; use
>> it liberally in development, and then in deployment, have enough RAM
>> and tune the parameters so that it strikes the target before the first
>> GC cycle.
>
> Great! :-)

Wow! GC cycles can lose a war? ;^)

On Thu, 15 Feb 2024 21:29:17 +0000, bart wrote:

> Apparently I was wrong. It seems almost unheard of to be able to create
> a runnable version of a C program by simply compiling the source code.

For some reason, you seem to be particularly obsessed with C programs that
you perceive to have this characteristic.

Here’s some simple advice: avoid those C programs, and stick to ones
written for Microsoft Windows. Problem solved.

On Thu, 15 Feb 2024 11:44:58 +0000, bart wrote:

> I need X, Y and Z to do so under WSL, and it still doesn't work.

You have to give Microsoft a chance. WSL2 came out less than 5 years ago,
so you can understand it still has a few bugs in it. You can’t expect WSL
to be the sole focus of its attention, giving it is also trying to port
Windows to ARM, and acquire game-development companies, and also building
some kind of AI functionality into Windows.

Wait for the next version, and see if that’s any better.

On Fri, 16 Feb 2024 03:37:34 +0100, Janis Papanagnou wrote:

> You can master Awk in few hours, not so Perl.

You can figure out those same functions in Perl in the same amount of
time. I would say that is time better spent.

On 2024-02-16, Lawrence D'Oliveiro <ldo@nz.invalid> wrote:
> On Thu, 15 Feb 2024 21:29:17 +0000, bart wrote:
>
>> Apparently I was wrong. It seems almost unheard of to be able to create
>> a runnable version of a C program by simply compiling the source code.
>
> For some reason, you seem to be particularly obsessed with C programs that
> you perceive to have this characteristic.
>
> Here’s some simple advice: avoid those C programs, and stick to ones
> written for Microsoft Windows. Problem solved.

... and have fun opening their Visual Studio 2005 project file in Visual
Studio 2022. :)

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

On 16/02/2024 02:16, Lawrence D'Oliveiro wrote:
> On Thu, 15 Feb 2024 16:41:23 +0000, Malcolm McLean wrote:
>
>> I can't remember the precedence relationships beyond a few very
>> conventional and well known ones.
>
> No need to. This is why we have documentation. Keep it handy, and don’t be
> ashamed to refer to it often, even in the presence of colleagues.

Agreed. Fill your brain with useful things, rather than things that you
rarely need and can easily look up. Or in the case of precedence for
the less commonly used operators, use parentheses or break expressions
into parts. Extra local variables are free.

And use good tools, such as an IDE that gives you suggestions and
auto-completion. Some people are dyslexic - a tool that helps you spell
your identifiers correctly, or tells you the name of function parameters
when you type a function name (so you can get the order right) saves you
effort and lets you concentrate on the important things.