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.

On Wed, 14 Feb 2024 21:54:32 GMT, Scott Lurndal wrote:

> Lawrence D'Oliveiro <ldo@nz.invalid> writes:
>
>>On Tue, 13 Feb 2024 14:19:20 -0800, Keith Thompson wrote:
>>
>>> But C has a *lot* of precedence levels, and they're not all obvious.
>>>
>>> If I see `a | b ^ c`, I'm not likely to remember off the top of my
>>> head ...
>>
>>So don’t remember “off the top of your head”: keep the docs handy.
>>That’s what I do.
>
> Why? The code is easier to read and maintain if the precedence is made
> explicit.

You’re assuming that the parenthesis clutter has negligible effect on
readability. That may be OK with one or two extraneous pairs, but typical
C code tends to end up with a lot more than that.

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.

If Marie Kondo were to learn C programming, what do you think she would
do?

On 14/02/2024 22:44, Lawrence D'Oliveiro wrote:
> On Mon, 12 Feb 2024 12:23:35 +0100, David Brown wrote:
>
>> Do you know what "incompatible types" are, and what they mean? Do you
>> realise that they cannot be swapped around as you suggest?
>
> And yet, all the examples posted so far have involved, not the actual
> types, but pointers to them.

Keith's post explains about pointers to incompatible types.

Compatibility is also relevant for declarations. All declarations of
the same function or object with external linkage must be the same
within a program. It is undefined behaviour to have this :

int foo(int);

and this :

int foo(long int);

in the same program. That is true even if "int" and "long int" have the
same size, or are passed using the same ABI conventions. Compilers will
complain if they are within the same translation unit, but it is
undefined (and usually not diagnosed) if they are in different
translation units.

There are /many/ situations where types must be compatible. I don't
want to try to list all the rules here - you can look them up yourself.

On 15/02/2024 08:56, Lawrence D'Oliveiro wrote:
> On Thu, 15 Feb 2024 01:07:33 +0000, bart wrote:
>
>> Bollocks it is.
>
> You keep insisting so. It would be simple enough to prove your point, by
> stripping out this “needless” complexity and proving you can build the
> code much more simply.
>
> Otherwise, you just fall into the “methinks he doth protest too much”
> school of Windows sufferers.

This is exactly what I started doing, with a view to extracting some
parts of it since I didn't need a 270Kloc library.

Below is as far as I got in about an hour. This reads a PGM file from
stdin, and writes a PGM file to stdout. This only does the headers. I
need to decide what processing to do on the image data read from stdin
before it's passed to stdout; I had in mind simply inverting the data.

However, I just didn't like how it was done. The following is distilled
quite a bit; if I wrote it, it would be a lot more compact. But
generally reading and writing files like PGM is so trivial, that it
would be easier to write it myself from scratch.

I also like to read an entire file into a buffer, and write out an
entire file, while this code prefers to do that serially. I gave an
example of how that works now for me:

a := bmload("test.pgm")
bmsave("itest.pgm", bmneg(a))

The point is, the C file below, even when completed, needs no special
configuration process, no scripts, no makefiles, you just use a C compiler:

c:\c>mcc inv
Compiling inv.c to inv.exe

c:\c>inv <test.pgm
P5
600 800
255

But perhaps /you/ can explain why such a INVERT tool would needs such an
elaborate process:

c:\net>mcc pnminvert.c
Compiling pnminvert.c to pnminvert.exe
netpbm/pm_config.h 18
Can't find include file in:netpbm/pm.h Line: 17

Even if I use WSL to get a pm_config.h file, it goes wrong on something
else.

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

#define PGM_MAGIC1 'P'
#define PGM_MAGIC2 '2'
#define RPGM_MAGIC2 '5'
#define PGM_FORMAT (PGM_MAGIC1 * 256 + PGM_MAGIC2)
#define RPGM_FORMAT (PGM_MAGIC1 * 256 + RPGM_MAGIC2)
#define PGM_TYPE PGM_FORMAT

void pm_error(char* mess) {
puts(mess);
exit(1);
}

void pm_error2(char* mess, int ich) {
printf(mess, ich);
exit(1);
}

char pm_getc(FILE * const fileP) {
int ich;
char ch;

ich = getc(fileP);
if (ich == EOF)
pm_error("EOF / read error reading a byte");
ch = (char) ich;

if (ch == '#') {
do {
ich = getc(fileP);
if (ich == EOF)
pm_error("EOF / read error reading a byte");
ch = (char) ich;
} while (ch != '\n' && ch != '\r');
}
return ch;
}

int pm_readmagicnumber(FILE * const ifP) {

int ich1, ich2;

ich1 = getc(ifP);

if (ich1 == EOF)
pm_error("Error reading first byte of what is expected to be "
"a Netpbm magic number. "
"Most often, this means your input file is empty");

ich2 = getc(ifP);

if (ich2 == EOF)
pm_error2("Error reading second byte of what is expected to be "
"a Netpbm magic number (the first byte was successfully "
"read as 0x%02x)", ich1);

return ich1 * 256 + ich2;
}

unsigned int pm_getuint(FILE * const ifP) {
char ch;
unsigned int i;

do {
ch = pm_getc(ifP);
} while (ch == ' ' || ch == '\t' || ch == '\n' || ch == '\r');

if (ch < '0' || ch > '9')
pm_error("junk in file where an unsigned integer should be");

i = 0;
do {
unsigned int const digitVal = ch - '0';

if (i > INT_MAX/10)
pm_error("ASCII decimal integer in file is "
"too large to be processed. ");

i *= 10;

if (i > INT_MAX - digitVal)
pm_error("ASCII decimal integer in file is "
"too large to be processed. ");

i += digitVal;

ch = pm_getc(ifP);
} while (ch >= '0' && ch <= '9');

return i;
}

void pgm_readpgminitrest(FILE * const fileP,
int * const colsP,
int * const rowsP,
int * const maxvalP) {

int maxval;

/* Read size. */
*colsP = (int)pm_getuint(fileP);
*rowsP = (int)pm_getuint(fileP);

/* Read maxval. */
maxval = pm_getuint(fileP);
*maxvalP = maxval;
}

void pgm_readpgminit(FILE * const fileP,
int * const colsP,
int * const rowsP,
int * const maxvalP,
int * const formatP) {

int realFormat;

/* Check magic number. */
realFormat = pm_readmagicnumber(fileP);

switch (realFormat) {
case PGM_TYPE:
*formatP = realFormat;
pgm_readpgminitrest(fileP, colsP, rowsP, maxvalP);
break;

default:
pm_error2("bad magic number 0x%x - not a PPM, PGM, PBM, or PAM
file",
realFormat);
}
}

void pgm_writepgminit(FILE * const fileP,
int const cols,
int const rows,
int const maxval,
int const binary) {

fprintf(fileP, "%c%c\n%d %d\n%d\n",
PGM_MAGIC1,
binary? PGM_MAGIC2 : RPGM_MAGIC2,
cols, rows, maxval );
}

int main(void) {
FILE* f = stdin;
FILE* g = stdout;
int rows, cols, format, maxval;

pgm_readpgminit(f, &cols, &rows, &maxval, &format);
pgm_writepgminit(g, cols, rows, maxval, 0);
//
// if (PNM_FORMAT_TYPE(format) == PBM_TYPE)
// /* Take fast path */
// invertPbm(ifP, stdout, cols, rows, format);
// else
// /* PPM , PGM (logic also works for PBM) */
// invertPnm(ifP, stdout, cols, rows, maxval, format);
//
// pm_close(ifP);
// pm_close(stdout);
fclose(f);
fclose(g);
}

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.

I need X, Y and Z to do so under WSL, and it still doesn't work. The
following is after going through an interactive configure process
(apparently I need half a dozen existing image DLLs already installed
(isn't this supposed to replace them?), plus Libxml2, plus flex, plus my
mingw installation apparently doesn't support all needed features.

Even the message from the config process says, Do not be surprised if
make fails.

(This stuff always reminds me of the Tootsie-Frootsie sketch from the
Marx Bros' A Day at the Races. You start with a simple requirement then
end up with a massive pile of junk that in the end is unusable.)

-----------------------
.....
make[2]: Leaving directory '/mnt/c/xxx/netpbm-10.86.40/lib/util'
cc -shared -Wl,--image-base=0x10000000 -Wl,--enable-auto-import
-Wl,--export-all-symbols \
-Wl,-soname,libnetpbm10.dll \
-Wl,--output-def,libnetpbm10.def \
-Wl,--out-implib,libnetpbm.dll.a -o libnetpbm10.dll \
libpm.o pmfileio.o fileio.o colorname.o libpamd.o libpbm1.o
libpbm2.o libpbm3.o libpbmfont0.o libpbmfont1.o libpbmfont2.o
pbmfontdata0.o pbmfontdata1.o pbmfontdata2.o libpgm1.o libpgm2.o
libppm1.o libppm2.o libppmcmap.o libppmcolor.o libppmfuzzy.o libppmd.o
ppmdfont.o standardppmdfont.o path.o libppmfloyd.o libpnm1.o libpnm2.o
libpnm3.o libpam.o libpamread.o libpamwrite.o libpamn.o libpammap.o
libpamcolor.o libsystem.o util/bitio.o util/filename.o util/io.o
util/mallocvar.o util/matrix.o util/nsleep.o util/nstring.o
util/runlength.o util/shhopt.o util/token.o util/vasprintf.o
/usr/bin/ld: unrecognized option '--image-base=0x10000000'
/usr/bin/ld: use the --help option for usage information
collect2: error: ld returned 1 exit status
make[1]: *** [/mnt/c/xxx/netpbm-10.86.40//lib/Makefile:143:
libnetpbm10.dll] Error 1
make[1]: Leaving directory '/mnt/c/xxx/netpbm-10.86.40/lib'
make: *** [/mnt/c/xxx/netpbm-10.86.40/common.mk:573: lib/all] Error 2

On 15/02/2024 07:37, Tim Rentsch wrote:
> scott@slp53.sl.home (Scott Lurndal) writes:
>
>> Lawrence D'Oliveiro <ldo@nz.invalid> writes:
>>
>>> On Tue, 13 Feb 2024 14:19:20 -0800, Keith Thompson wrote:
>>>
>>>> But C has a *lot* of precedence levels, and they're not all
>>>> obvious.
>>>>
>>>> If I see `a | b ^ c`, I'm not likely to remember off the top of my
>>>> head ...
>>>
>>> So don't remember off the top of your head, [just] keep the docs
>>> handy. That's what I do.
>>
>> Why? The code is easier to read and maintain if the precedence is
>> made explicit.
>
> Every serious C developer should know all the operator precedence
> relationships without having to look them up.
>

<https://en.wikipedia.org/wiki/No_true_Scotsman>

/Serious/ developers write code that is as clear as they can. They know
where references are for when they need them, but do not waste cognitive
effort memorising things that are better expressed in a different way
(such as by using parentheses or breaking expressions into parts).

> In cases where it is still felt necessary to indicate how different
> operators parse with respect to one another, it's better to do that
> using spacing than with parentheses, as for example
>
> a | b^c
>
> or
>
> alpha | beta ^ gamma
>

No, that is the silliest thing to do. Don't write code that looks like
what you think it should mean - even if it happens to match the somewhat
arbitrary choices of a language. Write code that does exactly what you
mean, clearly and unequivocally, and requires the minimum of cognitive
effort on the part of the reader.

People make mistakes, even if they are "serious C developers". And if
you start using spaces to make it look like you are correct, neither you
nor others looking at the code will notice mistakes like :

alpha ^ beta | gamma

If you use parentheses for less common operator precedence cases, as
Keith suggests, your code will be clear and there will be an obvious and
immediate match between what the programmer intended, what the compiler
does, and what any reader (experienced or not) will see.

On 15/02/2024 09:59, Lawrence D'Oliveiro wrote:
> On Wed, 14 Feb 2024 21:54:32 GMT, Scott Lurndal wrote:
>
>> Lawrence D'Oliveiro <ldo@nz.invalid> writes:
>>
>>> On Tue, 13 Feb 2024 14:19:20 -0800, Keith Thompson wrote:
>>>
>>>> But C has a *lot* of precedence levels, and they're not all obvious.
>>>>
>>>> If I see `a | b ^ c`, I'm not likely to remember off the top of my
>>>> head ...
>>>
>>> So don’t remember “off the top of your head”: keep the docs handy.
>>> That’s what I do.
>>
>> Why? The code is easier to read and maintain if the precedence is made
>> explicit.
>
> You’re assuming that the parenthesis clutter has negligible effect on
> readability. That may be OK with one or two extraneous pairs, but typical
> C code tends to end up with a lot more than that.

He was assuming the programmer used parentheses without it being "clutter".

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.

So now we are going to have to introduce terms like Lawrence-Clutter to
go along with Malcolm-functions?

>
> If Marie Kondo were to learn C programming, what do you think she would
> do?

On 15/02/2024 07:54, Janis Papanagnou wrote:
> On 14.02.2024 15:29, David Brown wrote:
>> On 14/02/2024 13:26, Janis Papanagnou wrote:
>>> On 14.02.2024 09:46, David Brown wrote:
>>>>
>>>> I hadn't done much with C++ before then. At that time, most of my
>>>> professional programming was in assembly (on small microcontrollers) and
>>>> Pascal, with only some C.
>>>
>>> I'm surprised that Pascal was in professional use back then.[*]
>>> Pascal had always been derided as "academic" or "toy" language.
>>
>> In the DOS/Windows world, Pascal was a major language for a long time -
>> starting with Turbo Pascal, then Borland Pascal for DOS then Windows,
>> then Delphi. Delphi's descendants are still in heavy use for Windows
>> development. (And dotnet came from Delphi and related projects.)
>
> Yes, I'm aware of the "popularity" (as Michael called it) of especially
> the Turbo and Borland Pascal dialects [on DOS]. Being platform specific
> (for a "personal computer" platform) and being dialects they have never
> really been an option for our usage; popularity in general - and surely
> in DOS contexts! - was never a criterion for us. (Using standards was,
> though!) Yet, beyond popularity on DOS, I haven't heared much about it.
> Other languages of the Pascal languages branch, like Ada, certainly had
> their professional application areas (in aeronautics, for example)! But
> Pascal?
>

I agree that standard Pascal was not (AFAIK) hugely significant as a
development language outside of academia until the Turbo Pascal version
and its descendants in DOS/Windows. In particular, standard Pascal was
quite limited for "real" programs, so I believe that most people used
extended versions of various kinds. UCSD "p-System" Pascal was the most
popular version until Turbo Pascal.

Perhaps the most significant Pascal program is TeX, which was written in
a combined documentation/coding language "Web" using Pascal as the
programming language.

On 14/02/2024 22:53, Scott Lurndal wrote:
>
> OTOH, all the systems the code in question run typedef uint64_t to unsigned
> long, so the 'ul' suffix works correctly in all forseeable usages in this
> application. And it's less to type than casting. Granted it's not
> particularly meaningful in the 0ul case, but it's a habit that does
> come in handy in expressions like
>
> uint64_t address;
> address = (0xcul << 44) | ((uint64_t)node << 44) | (device << 32) | register_offset;
>
> Yes, a cast on the constant would work as well. And yes, a good compiler
> will warn if the suffix is missing from the first constant value.

It would be better to use "ull", since there are lots of systems that
have 32-bit "long", but "long long" is always going to be at least
64-bit (and I have never heard of any where it is longer than that).

On 15/02/2024 13:20, David Brown wrote:
> On 15/02/2024 07:37, Tim Rentsch wrote:
>> scott@slp53.sl.home (Scott Lurndal) writes:
>>
>>> Lawrence D'Oliveiro <ldo@nz.invalid> writes:
>>>
>>>> On Tue, 13 Feb 2024 14:19:20 -0800, Keith Thompson wrote:
>>>>
>>>>> But C has a *lot* of precedence levels, and they're not all
>>>>> obvious.
>>>>>
>>>>> If I see `a | b ^ c`, I'm not likely to remember off the top of my
>>>>> head ...
>>>>
>>>> So don't remember off the top of your head, [just] keep the docs
>>>> handy.  That's what I do.
>>>
>>> Why?  The code is easier to read and maintain if the precedence is
>>> made explicit.
>>
>> Every serious C developer should know all the operator precedence
>> relationships without having to look them up.
>>
>
> <https://en.wikipedia.org/wiki/No_true_Scotsman>
>
> /Serious/ developers write code that is as clear as they can.  They know
> where references are for when they need them, but do not waste cognitive
> effort memorising things that are better expressed in a different way
> (such as by using parentheses or breaking expressions into parts).
>
>> In cases where it is still felt necessary to indicate how different
>> operators parse with respect to one another, it's better to do that
>> using spacing than with parentheses, as for example
>>
>>      a | b^c
>>
>> or
>>
>>      alpha   |   beta ^ gamma
>>
>
> No, that is the silliest thing to do.  Don't write code that looks like
> what you think it should mean - even if it happens to match the somewhat
> arbitrary choices of a language.  Write code that does exactly what you
> mean, clearly and unequivocally, and requires the minimum of cognitive
> effort on the part of the reader.
>
> People make mistakes, even if they are "serious C developers".  And if
> you start using spaces to make it look like you are correct, neither you
> nor others looking at the code will notice mistakes like :
>
>     alpha   ^   beta | gamma
>
> If you use parentheses for less common operator precedence cases, as
> Keith suggests, your code will be clear and there will be an obvious and
> immediate match between what the programmer intended, what the compiler
> does, and what any reader (experienced or not) will see.

You have to wonder why the creators of C thought it was a good idea in
the first place to have so many precedence levels, if you're going to
end up using parentheses anyway to disambiguate.

There are 10 levels for binary operators (excl. augmented assignment);
for the same set of operators, I have only 5 for example.

I don't know about other languages, but splitting == != < <= >= > into
two levels is surely an odd thing to do, for a start.

Keith Thompson <Keith.S.Thompson+u@gmail.com> writes:

> Tim Rentsch <tr.17687@z991.linuxsc.com> writes:
>
>> Michael S <already5chosen@yahoo.com> writes:
>
> [...]
>
>> Here is another way to think about it.
>>
>> C (and many or most other languages) are fairly strict about what
>> is allowed on the left-hand side of an assignment. For example,
>>
>> a + b += c;
>>
>> is not allowed. Neither is
>>
>> (a + b) += c;
>>
>> although the reasoning is a little different in the two cases,
>> neither is allowed, because neither one makes sense.
>>
>> By analogy with the second example, the statement
>>
>> (a += b) += c;
>>
>> isn't allowed, because the left-hand side is wrong. So if we
>> see
>>
>> a += b += c;
>>
>> it would be silly to parse it as
>>
>> (a += b) += c;
>>
>> because that's illegal. The only other way to parse it, viz.,
>>
>> a += (b += c);
>>
>> passes the semantic prerequisites. Since it's the only way that
>> makes sense, it seems natural that (without any parentheses) the
>> syntax should reflect that.
>
> I don't think that reasoning is entirely solid.

My comments aren't meant as reasoning. They are meant to offer a
way of thinking that might help Michael S change his intuition
about how C assignment operators work. Personally I have no
problem with how assignment operators work in C. I was used to
expression languages for years before the original K&R came out,
and I had already internalized how cascading assignments work. At
some point I did read the syntax rules in C for assignment
operators, but I didn't really need them, because by that time it
already felt natural to me that assignment proceeds right-to-left.
And that has to be true for compound assignment operators as well
as simple assignment, because compound assignment is simply a
syntactic sugaring (with a small semantic adjustment) over the
usual kind of assignment. Until I saw Michael's message it never
would have occurred to me that someone (especially someone with his
level of experience, which obviously is considerable) would find it
confusing.

Janis Papanagnou <janis_papanagnou+ng@hotmail.com> writes:

> On 12.02.2024 02:17, Lawrence D'Oliveiro wrote:
>
>> You seem to be saying that something like
>>
>> bool a = b == c;
>>
>> should not be allowed.
>
> I have the habit to write such specific expressions with parenthesis
>
> a = (b == c);
>
> for own convenience or better maintainability. (Just BTW.)

My practice is to avoid redundant parentheses. If it's important
to emphasize the precedence relationships, in most cases I would
do that something like this:

a = b == c;

I find using spacing in such cases to be a better impedance match
to human eye hardware than using redundant parentheses.

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.

Lawrence D'Oliveiro <ldo@nz.invalid> writes:
>On Wed, 14 Feb 2024 15:29:00 +0100, David Brown wrote:
>
>
>The UCSD p-system pioneered the concept of “write once, run anywhere”, by
>defining a standardized p-code interpreter that could be implemented
>across a whole range of different processor architectures. Once you had
>done that, plus some basic OS routines, the main part of the software,
>written in Pascal, should port straight across.

I used UCSD pascal on a Terek box in 1979. And haven't even seen
a reference to UCSD pascal since.

Lawrence D'Oliveiro <ldo@nz.invalid> writes:
>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.

The first version of C++ was in the mid-80s and didn't have bool (c.f. cfront).

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?

They invent loads of UNNECESSARY extra hoops to jump through, and expect
everyone else, even those using different systems that don't even have
those hoops, to do the same.

You suggested netpbm to avoid reinventing wheels. Sure, if you can
actually access the wheels and get them to turn!

I take it however that you would never waste your time overhauling any
process, any product, to make it smaller, tidier, nippier and generally
more aesthetic?

There is no satisfaction in producing something to be proud of,
something elegant, instead of taking a big mess of a distribution,
cramming it into box and scrawling 'makefile' on the side?

Lawrence D'Oliveiro <ldo@nz.invalid> writes:

> On Wed, 14 Feb 2024 14:38:01 -0800, Keith Thompson wrote:
>
>> Lawrence D'Oliveiro <ldo@nz.invalid> writes:
>>
>>> And yet, all the examples posted so far have involved, not the actual
>>> types, but pointers to them.
>>
>> Because pointers to incompatible types are a good way to demonstrate
>> incompatibility.
>
> But it was those types I was talking about, not pointers to them.

You seem to be arguing just for the sake it now since you pointedly
refuse to answer Keith's question:

"Do you understand that int and long are incompatible even though
they're implicitly convertible, even if they happen to have the same
size and representation?"

--
Ben.

Lawrence D'Oliveiro <ldo@nz.invalid> writes:
> On Wed, 14 Feb 2024 14:38:01 -0800, Keith Thompson wrote:
>> Lawrence D'Oliveiro <ldo@nz.invalid> writes:
>>> And yet, all the examples posted so far have involved, not the actual
>>> types, but pointers to them.
>>
>> Because pointers to incompatible types are a good way to demonstrate
>> incompatibility.
>
> But it was those types I was talking about, not pointers to them.

I'll assume either that you understand type compatibility, or you don't
care.

If that's not the case and you have questions, feel free to ask.

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

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.

I have this in the man page for ld:

--image-base value
Use value as the base address of your program or dll. This
is the lowest memory location that will be used when your
program or dll is loaded. To reduce the need to relocate
and improve performance of your dlls, each should have a
unique base address and not overlap any other dlls. The
default is 0x400000 for executables, and 0x10000000 for
dlls. [This option is specific to the i386 PE targeted
port of the linker]

It looks like stray cruft to me, and the value they are using is
the documented default one anyway.

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

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

On 15/02/2024 13:20, David Brown wrote:
> On 15/02/2024 07:37, Tim Rentsch wrote:
>> scott@slp53.sl.home (Scott Lurndal) writes:
>>
>>> Lawrence D'Oliveiro <ldo@nz.invalid> writes:
>>>
>>>> On Tue, 13 Feb 2024 14:19:20 -0800, Keith Thompson wrote:
>>>>
>>>>> But C has a *lot* of precedence levels, and they're not all
>>>>> obvious.
>>>>>
>>>>> If I see `a | b ^ c`, I'm not likely to remember off the top of my
>>>>> head ...
>>>>
>>>> So don't remember off the top of your head, [just] keep the docs
>>>> handy.  That's what I do.
>>>
>>> Why?  The code is easier to read and maintain if the precedence is
>>> made explicit.
>>
>> Every serious C developer should know all the operator precedence
>> relationships without having to look them up.
>>
>
> <https://en.wikipedia.org/wiki/No_true_Scotsman>
>
> /Serious/ developers write code that is as clear as they can.  They know
> where references are for when they need them, but do not waste cognitive
> effort memorising things that are better expressed in a different way
> (such as by using parentheses or breaking expressions into parts).
>

I can't remember the precedence relationships beyond a few very
conventional and well known ones. I don't see that as a strength. But it
does mean that I am forced to use parentheses where it might not be
strictly necessary.

--
Check out Basic Algorithms and my other books:
https://www.lulu.com/spotlight/bgy1mm

On 15/02/2024 08:59, Lawrence D'Oliveiro wrote:
> On Wed, 14 Feb 2024 21:54:32 GMT, Scott Lurndal wrote:
>
>> Lawrence D'Oliveiro <ldo@nz.invalid> writes:
>>
>>> On Tue, 13 Feb 2024 14:19:20 -0800, Keith Thompson wrote:
>>>
>>>> But C has a *lot* of precedence levels, and they're not all obvious.
>>>>
>>>> If I see `a | b ^ c`, I'm not likely to remember off the top of my
>>>> head ...
>>>
>>> So don’t remember “off the top of your head”: keep the docs handy.
>>> That’s what I do.
>>
>> Why? The code is easier to read and maintain if the precedence is made
>> explicit.
>
> You’re assuming that the parenthesis clutter has negligible effect on
> readability. That may be OK with one or two extraneous pairs, but typical
> C code tends to end up with a lot more than that.
>
That is an issue. It's hard to match parentheses in long expressions. On
the other hand odd spacing can also make text harder to read. Then if
parentheses are also used for casts, or in C++ for access functions,
that can also add to the overall burden.
--
Check out Basic Algorithms and my other books:
https://www.lulu.com/spotlight/bgy1mm

Malcolm McLean <malcolm.arthur.mclean@gmail.com> writes:
>On 15/02/2024 08:59, Lawrence D'Oliveiro wrote:
>> On Wed, 14 Feb 2024 21:54:32 GMT, Scott Lurndal wrote:
>>
>>> Lawrence D'Oliveiro <ldo@nz.invalid> writes:
>>>
>>>> On Tue, 13 Feb 2024 14:19:20 -0800, Keith Thompson wrote:
>>>>
>>>>> But C has a *lot* of precedence levels, and they're not all obvious.
>>>>>
>>>>> If I see `a | b ^ c`, I'm not likely to remember off the top of my
>>>>> head ...
>>>>
>>>> So don’t remember “off the top of your head”: keep the docs handy.
>>>> That’s what I do.
>>>
>>> Why? The code is easier to read and maintain if the precedence is made
>>> explicit.
>>
>> You’re assuming that the parenthesis clutter has negligible effect on
>> readability. That may be OK with one or two extraneous pairs, but typical
>> C code tends to end up with a lot more than that.
> >
>That is an issue. It's hard to match parentheses in long expressions.

Not if you're using an editor like vim, which highlights the matching
paranthesis/brace/bracket automatically, if configured to do so.

On 2024-02-15, Lawrence D'Oliveiro <ldo@nz.invalid> 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

Nope! E.g. remove duplicate lines:

awk '!s[$0]++'

Perl requires a clump of options to get into an Awk-style loop, and
requires $ sigils on all variables. The positional fields are accessed
in some F array, rather than $1, $2.

Do you now the following famous quote from Larry Wall?
Something along the lines, 'I still say "awk { print $1 }" a lot'.

> , and it can
> do more besides.

GNU Awk can be extended with C, so you can do just about anything, in
theory. It's not easy though. The language has a lot of shortcomings,
like not being able to return an array from a function, or use [] indexing
on strings, and having to represent local variables as exta unused
parameters.

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