On 2023-12-31, Lawrence D'Oliveiro <ldo@nz.invalid> wrote:
> On Sun, 31 Dec 2023 16:25:08 +0100, David Brown wrote:
>
>> I realise that you (and possibly others) might find it useful for a tool
>> to replace typedef identifiers with their definitions, but it could only
>> be done for some cases, and is not as simple as macro substitution.
>
> String-based macros are nothing but trouble. Typedefs are scoped, string
> macros are not.
>
> If you want to see the right way to do macros, look at LISP, where they
> are token-based, and much more robust as as result. I think they even
> manage to apply scoping rules to macro definitions as well.

By the way, I'm not sure what system you are referring to by
"string-based macros", but in case you might be thinking of C
preprocessing, be advised that it's token-based.

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

On Tue, 2 Jan 2024 12:24:45 +0000, Bart wrote:

> You're going to defend this to the death aren't you? Be funny if at some
> point some GMP II was produced whose main new benefit was a vastly
> simplified build!

Well, you can go back to dreaming if you wish. It’s not like this project
was just created yesterday: if it was going to pay more serious attention
to Microsoft Windows, it would have done so already. Clearly the need
isn’t there.

> By doing searches, I found a bunch of libxxx.a files with today's date
> in various locations.

I would say you forgot to do the “make install” bit. That would put the
build products in some sensible place, like /usr/local.

> So the outputs are archive files for gcc, I guess intended for static
> linking.

As I mentioned, the build script has options for both static and dynamic
builds. Maybe you chose the wrong one. Tip: try “./configure --help” for a
quick summary of the build options.

> The INSTALL file talks about reading detailed instructions in gmp_info,
> but this file is gobbledygook. You need to view the instructions using a
> program called 'info' - a Linux utility that doesn't exist on Windows.

Again, that’s the fault of Windows for being such a poverty-stricken OS.

Remember, Windows is designed as a platform on which users will not do
their own programming, but instead they will buy programs from software
vendor organizations. All the tooling is centred around that, and is built
on the assumption that Microsoft will provide the core development tools.

> So I need Linux even just to look at a bunch of instructions?

You need Linux to do any kind of serious open-source or cross-platform
development work, yes.

> What, God forbid, if 'gcc -E' was not supported?

What, indeed. I _did_ mention, did I not, that this project has a lot of
support for obsolete, proprietary Unix systems with their own peculiar
quirks. Certainly enough users must still care about those for this
support for them to be retained in the project. Yet there are not enough
of these complaining Windows users (or should I say “sufferers”) for them
to be catered to.

> And why aren't these checks everytime you build /any/ program?

Different projects have different requirements. GNU autoconf has a whole
standard library of things to check for (and configure your build for),
and you can add new ones by writing suitable m4 definitions.

Here, you can read about it yourself:
<https://www.gnu.org/savannah-checkouts/gnu/autoconf/manual/autoconf-2.71/
autoconf.html>.

> What a total waste of time.

A good description of Microsoft Windows generally. That’s why those of us
who want to be productive tend to avoid it.

> GMP, when it's actually made available, is actually an incredibly fast
> library. Some talented people went into creating it. I can't say the
> same for those responsible for the build system who seem to have made it
> as complicated and convoluted as they possibly can.

You yourself said, it only took 5 minutes to build--on Linux.

As the Dilbert cartoon goes: “Here’s a nickel, kid. Get yourself a *real*
computer.”

On Tue, 2 Jan 2024 18:16:36 -0000 (UTC), Kaz Kylheku wrote:

> By the way, I'm not sure what system you are referring to by
> "string-based macros", but in case you might be thinking of C
> preprocessing, be advised that it's token-based.

Now go learn what “homoiconicity” means.

On 02.01.2024 17:38, Bart wrote:
> On 02/01/2024 15:10, Blue-Maned_Hawk wrote:
>> Bart wrote:
>>
>>> One complex expression that my compiler had trouble with, when expanded,
>>> resulted in a line hundreds of character long, and using 11 levels of
>>> nested parentheses, the most I've ever come across.
>>
>> Happen to remember particularly which that one was you?
>>
>>
>>
>
> No. You can have a look yourself if you like, just apply -E to the sources.
>
> Here's one with quite a long expansion but not too deeply nested. This
> is the line inside lvm.c at line 1463:
>
> op_arith(L, l_addi, luai_numadd);
>
> The expansion is:
>
> {TValue*v1=(&((base+((((int)((((i)>>((((0+7)+8)+1)))&((~((~
> (Instruction)0)<<(8)))<<(0)))))))))->val);TValue*v2=(&((base+((((int)
> ((((i)>>(((((0+7)+8)+1)+8)))&((~((~(Instruction)0)<<(8)))
> <<(0)))))))))->val);{StkId ra=(base+(((int)((((i)>>((0+7)))&((~((~
> (Instruction)0)<<(8)))<<(0)))))));if(((((v1))->tt_)==(((3)|((0)<<4))))&&
> ((((v2))->tt_)==(((3)|((0)<<4))))){lua_Integer i1=(((v1)->value_).i);
> lua_Integer i2=(((v2)->value_).i);pc++;{TValue*io=((&(ra)->val));
> ((io)->value_).i=(((lua_Integer)(((lua_Unsigned)(i1))+((lua_Unsigned)(i2)))));
>
> ((io)->tt_=(((3)|((0)<<4))));};}else{lua_Number n1;lua_Number
> n2;if((((((v1))->tt_)==(((3)|((1)<<4))))?((n1)=(((v1)->value_).n),1):
> (((((v1))->tt_)==(((3)|((0)<<4))))?((n1)=((lua_Number)
> (((((v1)->value_).i)))),1):0))&&(((((v2))->tt_)==(((3)|((1)<<4))))?
> ((n2)=(((v2)->value_).n),1):(((((v2))->tt_)==(((3)|((0)<<4))))?((n2)=
> ((lua_Number)(((((v2)->value_).i)))),1):0))){pc++;{TValue*io=
> ((&(ra)->val));((io)->value_).n=(((n1)+(n2)));((io)->tt_=(((3)|
> ((1)<<4))));};}};};};
>
> This is the definition of that macro:
>
> #define op_arith(L,iop,fop) { \
> TValue *v1 = vRB(i); \
> TValue *v2 = vRC(i); \
> op_arith_aux(L, v1, v2, iop, fop); }
>
> were 'op_arith_aux' is another macro. Actually, probably everything is.
>
> This looks fun to try to understand, debug, or port.
>
> Here you might well ask why inlined functions weren't better suited.

Cpp macros, inline functions, etc. - it's somehow funny, but probably
explainable because we're in a NG topical to the C language.

During the 1980's (when I learned quite some different language types)
we were taught that [these sorts of] optimizations are (or should be)
the task of the compilers not of the programmers; programmers should
(WRT optimizations) focus on the algorithmic complexity.

Here in CLC I'll probably get lapidated for (still) considering C as a
perfect [almost] machine independent assembler language (sort of). :-)

In our role as C programmers we have to live with what we've got, and
tools (or later language extensions) help us...

That said; during my early K&R C era we had 'register' declarations,
but I rarely saw them, they seem to have quickly vanished from usage.
Now I've heard that 'inline' optimizations have been introduced in C.
Isn't that considered a task for the compiler? (I mean there's already
the -O option levels available. But, OTOH, I occasionally hear about
problems with some -O levels...)

Janis

On Tue, 2 Jan 2024 20:23:24 +0100, Janis Papanagnou wrote:

> That said; during my early K&R C era we had 'register' declarations, but
> I rarely saw them, they seem to have quickly vanished from usage. Now
> I've heard that 'inline' optimizations have been introduced in C. Isn't
> that considered a task for the compiler?

Kids’ stuff. Want to see how a _real_ compiler does it?
<https://gcc.gnu.org/onlinedocs/gcc-13.2.0/gcc/Attribute-Syntax.html>

On 02.01.2024 20:35, Lawrence D'Oliveiro wrote:
> On Tue, 2 Jan 2024 20:23:24 +0100, Janis Papanagnou wrote:
>
>> That said; during my early K&R C era we had 'register' declarations, but
>> I rarely saw them, they seem to have quickly vanished from usage. Now
>> I've heard that 'inline' optimizations have been introduced in C. Isn't
>> that considered a task for the compiler?
>
> Kids’ stuff. Want to see how a _real_ compiler does it?
> <https://gcc.gnu.org/onlinedocs/gcc-13.2.0/gcc/Attribute-Syntax.html>

What shall I infer from that statement and link? - Mind to elaborate?

My original question was related to compiler (as opposed to programmer)
doing optimizations. I recall from decades ago that compilers will do
optimizations e.g. on the attributed syntax tree level, while 'register'
or 'inline' seem very primitive constructs (on a comparable low level).
So I expressed my astonishment that 'inline' had been later introduced
in C, and I wonder why. (Note that the other poster also mentioned it
as a preferred way to replace [parameterized] macros, if I interpreted
him correctly.)

Janis

Lawrence D'Oliveiro <ldo@nz.invalid> writes:
>On Mon, 1 Jan 2024 11:56:00 +0000, Bart wrote:
>
>> On 01/01/2024 02:00, Lawrence D'Oliveiro wrote:
>>
>>> Those are just standard file-manipulation tools that any decent OS
>>> should provide.
>>
>> What's that got to do with building able to build programs easily?
>
>You have effectively answered that question yourself. Why were you trying
>to build GNU GMP on Windows? Isn’t there something equally capable and yet
>more, shall we say, “native” to Windows, that you can build and use in a
>more “Windows-native” fashion?

And the 'G' in GMP stands for GNU. Expecting FSF to do anything
to support windows is insane.

Bart <bc@freeuk.cm> writes:
>On 02/01/2024 06:47, Lawrence D'Oliveiro wrote:
>> On Tue, 2 Jan 2024 06:23:03 -0000 (UTC), Kaz Kylheku wrote:
>>
>>> On 2024-01-02, Lawrence D'Oliveiro <ldo@nz.invalid> wrote:
>>>
>>>> First of all, it includes code for building on a whole lot of
>>>> proprietary Unix systems with non-GCC compilers, some of which maybe
>>>> don’t quite conform to official C/C++ standards.
>>>
>>> When people use Autoconf to configure their program for building, the
>>> generated script includes cruft for platforms on which they never tested
>>> the program, and never will, and on which it won't work for reasons not
>>> related to those tests.
>>
>> This is a GNU project, so you can be sure they have done pretty good
>> testing on those platforms and those options. If they were no longer
>> supported, they would have been dropped from the code. This isn’t like
>> proprietary software, which tends to accumulate cruft that nobody dares
>> touch because they no longer understand what it does.
>>
>>>> Look at the ABI options: maybe you want a 32-bit build (where the CPU
>>>> supports it) rather than a 64-bit one; on some architectures, things
>>>> get a bit more complicated than just those two options.
>>>
>>> These kinds of options can be passed in by CFLAGS, LDFLAGS and LDLIBS.
>>> Support those three variables, and that's it.
>>
>> If you have a look, that’s what the script does. Only you just have to
>> specify one option, and it generates the right value for *all* the
>> relevant variables, instead of you having to specify them individually.
>
>
>You're going to defend this to the death aren't you? Be funny if at some
>point some GMP II was produced whose main new benefit was a vastly
>simplified build!

You still haven't provided a better system that accomplishes
everthing the existing system does.

Quit bitching about it and _do_ something about it. It's an open
source system, you are free to contribute a new build system for
it (which clearly needs to support all the capabilities of the
existing system otherwise you'll never have your suggestions
accepted).

Don't, however, expect anyone to cater to you.

>
>I tried to build gmp today using WSL. The process took just under five
>minutes. However, where and what is the output? For all the verbosity,
>that simple fact is omitted.

You presumably specified that on the ./configure with the --prefix
option. Or did you forget to RTFM first?

On 02/01/2024 17:34, David Brown wrote:
> On 02/01/2024 17:12, Bart wrote:

>> X-macro are ugly. They are unreadable.
>
> Speaking as someone who has used them in real code, rather than someone
> with a pathological hatred of macros and who prefers knee-jerk reaction
> to their uses instead of applying a few minutes objective thought,
> "x-macros" can make code significantly simpler, clearer, and much easier
> to maintain correctly.

I'm sorry, but I *DO* find them utterly impossible. This is a simple
example from Stackoverflow of someone wanting to define a set of enums
with an accompanying table, whose problem was in ensuring the two were
kept in sync.

The X-macro solution was this, adapted from the first answer here
(https://stackoverflow.com/questions/6635851/real-world-use-of-x-macros);
assume those functions are in scope:

-------

#define STATE_TABLE \
ENTRY(STATE0, func0) \
ENTRY(STATE1, func1) \
ENTRY(STATE2, func2) \
ENTRY(STATE3, func3) \

enum
{ #define ENTRY(a,b) a,
STATE_TABLE
#undef ENTRY
NUM_STATES
};

void* jumptable[NUM_STATES] =
{ #define ENTRY(a,b) b,
STATE_TABLE
#undef ENTRY
};
-------

With my feature, it is merely this:

global enumdata []ref void jumptable =
(state1, func1), # comment 1
(state2, func2),
(state3, func3), # comment 3
(state4, func4),
end

Notice:

(1) I don't need any of those weird macros.

(2) I don't need those backslashes

(3) I can add comments to any entry in the table.

(4) The 'global' attribute means both enumeration names and the array
are exported to other modules. Doing the same in C is tricky.

But I'm wasting my time because you are never going to admit my feature
is superior to X-macros for this purpose.

(The author of this example goes on to say how it can also be used to
define a set of function prototypes. I can't do that with my feature.
But then I don't need function prototypes!)

>> At best, if someone has already done the hard work of setting up a
>> working set of macros, then you will be able to see how to modify, add
>> or delete entries.
>
> They are not hard.

Maybe not for you, but it would take me ages to come up with the right
incantations to make it work.

>> For the purposes of creating parallel sets of enums and associated
>> data, I use special syntax which makes for a clearer and simpler feature.
>
> And that is, obviously, utterly useless - because it is not C or even a
> commonly supported extension.  Oh, and even if it /were/ part of C, it
> would not help because that's not what I was doing.

I've given an example of a use-case for C macros which have a special
purpose feature in other languages. So of cause it's not in C.

>>
>> Have you ever considered that if C didn't have macros, or they weren't
>> powerful, then it could have evolved superior, built-in alternatives?
>>
>
> The C preprocessor is part of C - it is already built in.

You missed my point. Take a tiny feature like being able to easily get
the size of a fixed-length array. You commonly see macro like this:

#define LENGTH(a) (sizeof(a)/size(a[0]))

What incentive is there to properly add a built-in way to do that, when
it can be done, badly, and in 1000 different ways by each user, in a
one-line macro?

Another example is GETBIT(a, n).

>> It wasn't a compiler limit - it was mine! The resulting expression was
>> completely unreadable.
>
> I wonder if the code authors also found this expanded expression
> unreadable.

Look at the example I posted in reply to Blue-Maned_Hawk.

In particular consider my last comment.

> I guess not - because they used macros so that they could
> write it in a clear and understandable way, and never have to look at
> the expansion!  You don't seem to comprehend the point of macros at all.
>
>> In the end I resorted to looking at the AST as that was clearer than C
>> source code.
>>
>
> Why not just look at the code as written, if you want to understand it?

In my case I was debugging my C compiler. Then you need to examine the
actual expanded code in detail. Excessive use of macros makes that much
harder.

That example came from Lua 5.4, an interpeter whose performance on a par
with my own product running from HLL-only code. That doesn't doesn't use
deeply-nested macro like this, and it doesn't appear to suffer,.

> Or would doing something that sensible put a damper on your rants?

Look, I'm written a C preprocessor (I suspect you haven't). If I wanted,
I could adapt it to work on my own languages.

But I /don't/ want to. Obviously I see something undesirable about them
(I don't like metaprogramming in general; people get too carried away
with it and want to show off their skills).

Why can't you accept that?

>> Half my use-cases involve inline assembly.
>
> Why can't that be in inlined functions?

That doesn't work in inline assembly.

> Again, you are not showing that
> these limited macros have any benefits compared to what is found in C,

That's true. I can't write something like:

#define M a+b)*c

(M;

>> Macros are a C language artefact, and what they expand to is arbitrary
>> C syntax that can be meaningless elsewhere.
>
> Yes - C code is C code.  It is not Pascal, or Fortran, or Ada.  Should
> this be a surprise?

It's inconvenient. This is a macro from SDL2:

#define SDL_CompilerBarrier() \
{ SDL_SpinLock _tmp = 0; SDL_AtomicLock(&_tmp);
SDL_AtomicUnlock(&_tmp); }

Rather than declaring a function which resides in a language-neutral
DLL, it declares it here, in the form of actual C code.

Even given a language with an FFI that is capable of calling external
functions compiled as C, what are they supposed to do with this?

That example was in a conditional block; I don't know the context. But
here's a juicy one that is the result of an attempt to automatically
translate the C SDL2 API to my syntax:

global macro SDL_FOURCC(A,B,C,D) =
((SDL_static_cast(Uint32,SDL_static_cast(Uint8,(A)))<<0)|(SDL_static_cast(Uint32,SDL_static_cast(Uint8,(B)))<<8)|(SDL_static_cast(Uint32,SDL_static_cast(Uint8,(C)))<<16)|(SDL_static_cast(Uint32,SDL_static_cast(Uint8,(D)))<<24))

This also contains arbitrary C code; it needs a much more sophisticated
tool than one that just does declaration. Basically a transpiler from
C to the language one is writing bindinds for.

> You already have a habit of cherry-picking example code that is as
> "Bart-unfriendly" as you can find.

Try testing your own C compiler on just about any codebase. You don't
have to look far for extreme examples.

> I don't have your experience, but I find that /very/ hard to believe.  I
> should imagine it's primarily a matter of working through the
> "translation phases" and "preprocessing directives" described in the C
> standards, step by step.

The C standard has very little to say about. I once found a very, very
long article which went into considerably more detail, now lost.

But even 1/3 through I decided that it was impossible.

In 2017 when I created my CPP, many compilers would give different
results with various edge cases of macros. Which were right and which
were wrong? You'd think there'd be a definitive reference for it.

Here's an example I've just found:

#include <stdio.h>
int main(void) {

#define FOO
#define BAR defined(FOO)
#if BAR
puts("BAR");
#else
puts("FOO");
#endif
}

Most compilers will display BAR; MSVC I think is the only one showing
FOO. (Some smaller compilers I tried on godbolt.org failed to compile it.)

Mine showed BAR (obviously!)

On 02/01/2024 20:11, Scott Lurndal wrote:
> Bart <bc@freeuk.cm> writes:

>> You're going to defend this to the death aren't you? Be funny if at some
>> point some GMP II was produced whose main new benefit was a vastly
>> simplified build!
>
> You still haven't provided a better system that accomplishes
> everthing the existing system does.

I need some basic information about what's what about in the 26MB of
content in 4000 files spread over 190 directories.

But it's clear that it's not interested in making things simple. (The
nearest they've come is with the 'mini-gmp' version. But since the
performance of that is on a par with my own library, I'll stick with
mine, which also has a higher spec.)

I have done this exercise with projects like LIBJPEG, LUA5.4 and
TCC0.9.27. Long ago I did it with SEED7.

Once I can extract the necessary info - IT ALWAYS COMES DOWN TO A LIST
OF FILES TO SUBMIT TO A COMPILER FGS - then I can whizz through it easily.

> Quit bitching about it and _do_ something about it.

Funnily enough, I did. I wrote my own library, which I know is always
available, and has some unique features, eg. it uses decimal, and has a
single integer/float type.

I once linked to a C port of it.

It's not fast, but it's mine and it's in my language. (It accounts for
12KB of my interpreter.)

> It's an open
> source system, you are free to contribute a new build system for
> it (which clearly needs to support all the capabilities of the
> existing system otherwise you'll never have your suggestions
> accepted).
>
> Don't, however, expect anyone to cater to you.

There must be one person on the planet who understands how to produce a
Windows DLL of this thing. And funnily enough, a single 64-bit DLL is
all any Windows user on the planet needs (that and either gmp.h or
language-neutral docs).

>>
>> I tried to build gmp today using WSL. The process took just under five
>> minutes. However, where and what is the output? For all the verbosity,
>> that simple fact is omitted.
>
> You presumably specified that on the ./configure with the --prefix
> option. Or did you forget to RTFM first?

I following these instructions:

--------------
Here are some brief instructions on how to install GMP. First you need to
compile. Since you're impatient, try this

./configure
make
make check <= VERY IMPORTANT!!

I did the first two line before looking for the binaries.

On 1/2/2024 12:24 PM, Bart wrote:
> On 02/01/2024 17:34, David Brown wrote:
>> On 02/01/2024 17:12, Bart wrote:
>
>>> X-macro are ugly. They are unreadable.
>>
>> Speaking as someone who has used them in real code, rather than
>> someone with a pathological hatred of macros and who prefers knee-jerk
>> reaction to their uses instead of applying a few minutes objective
>> thought, "x-macros" can make code significantly simpler, clearer, and
>> much easier to maintain correctly.
>
>
> I'm sorry, but I *DO* find them utterly impossible. This is a simple
> example from Stackoverflow of someone wanting to define a set of enums
> with an accompanying table, whose problem was in ensuring the two were
> kept in sync.
>
> The X-macro solution was this, adapted from the first answer here
> (https://stackoverflow.com/questions/6635851/real-world-use-of-x-macros); assume those functions are in scope:
>
> -------
>
> #define STATE_TABLE \
>         ENTRY(STATE0, func0) \
>         ENTRY(STATE1, func1) \
>         ENTRY(STATE2, func2) \
>         ENTRY(STATE3, func3) \
>
> enum
> {
> #define ENTRY(a,b) a,
>     STATE_TABLE
> #undef ENTRY
>     NUM_STATES
> };
>
> void* jumptable[NUM_STATES] =
> {
> #define ENTRY(a,b) b,
>     STATE_TABLE
> #undef ENTRY
> };
> -------
>
>
> With my feature, it is merely this:
>
>     global enumdata []ref void jumptable =
>         (state1, func1),        # comment 1
>         (state2, func2),
>         (state3, func3),        # comment 3
>         (state4, func4),
>     end
>
> Notice:
>
> (1) I don't need any of those weird macros.
>
> (2) I don't need those backslashes
>
> (3) I can add comments to any entry in the table.
>
> (4) The 'global' attribute means both enumeration names and the array
>     are exported to other modules. Doing the same in C is tricky.
>
> But I'm wasting my time because you are never going to admit my feature
> is superior to X-macros for this purpose.
>
> (The author of this example goes on to say how it can also be used to
> define a set of function prototypes. I can't do that with my feature.
> But then I don't need function prototypes!)
>
>>> At best, if someone has already done the hard work of setting up a
>>> working set of macros, then you will be able to see how to modify,
>>> add or delete entries.
>>
>> They are not hard.
>
> Maybe not for you, but it would take me ages to come up with the right
> incantations to make it work.
>
>>> For the purposes of creating parallel sets of enums and associated
>>> data, I use special syntax which makes for a clearer and simpler
>>> feature.
>>
>> And that is, obviously, utterly useless - because it is not C or even
>> a commonly supported extension.  Oh, and even if it /were/ part of C,
>> it would not help because that's not what I was doing.
>
> I've given an example of a use-case for C macros which have a special
> purpose feature in other languages. So of cause it's not in C.
>
>>>
>>> Have you ever considered that if C didn't have macros, or they
>>> weren't powerful, then it could have evolved superior, built-in
>>> alternatives?
>>>
>>
>> The C preprocessor is part of C - it is already built in.
>
> You missed my point. Take a tiny feature like being able to easily get
> the size of a fixed-length array. You commonly see macro like this:
>
>    #define LENGTH(a) (sizeof(a)/size(a[0]))
>
> What incentive is there to properly add a built-in way to do that, when
> it can be done, badly, and in 1000 different ways by each user, in a
> one-line macro?
>
> Another example is GETBIT(a, n).
>
>>> It wasn't a compiler limit - it was mine! The resulting expression
>>> was completely unreadable.
>>
>> I wonder if the code authors also found this expanded expression
>> unreadable.
>
> Look at the example I posted in reply to Blue-Maned_Hawk.
>
> In particular consider my last comment.
>
>
>> I guess not - because they used macros so that they could write it in
>> a clear and understandable way, and never have to look at the
>> expansion!  You don't seem to comprehend the point of macros at all.
>>
>>> In the end I resorted to looking at the AST as that was clearer than
>>> C source code.
>>>
>>
>> Why not just look at the code as written, if you want to understand it?
>
> In my case I was debugging my C compiler. Then you need to examine the
> actual expanded code in detail. Excessive use of macros makes that much
> harder.
>
> That example came from Lua 5.4, an interpeter whose performance on a par
> with my own product running from HLL-only code. That doesn't doesn't use
> deeply-nested macro like this, and it doesn't appear to suffer,.
>
>
>> Or would doing something that sensible put a damper on your rants?
>
> Look, I'm written a C preprocessor (I suspect you haven't). If I wanted,
> I could adapt it to work on my own languages.
>
> But I /don't/ want to. Obviously I see something undesirable about them
> (I don't like metaprogramming in general; people get too carried away
> with it and want to show off their skills).
>
> Why can't you accept that?
>
>
>>> Half my use-cases involve inline assembly.
>>
>> Why can't that be in inlined functions?
>
> That doesn't work in inline assembly.
>
>> Again, you are not showing that these limited macros have any benefits
>> compared to what is found in C,
>
> That's true. I can't write something like:
>
>      #define M a+b)*c
>
>      (M;
>
>
>>> Macros are a C language artefact, and what they expand to is
>>> arbitrary C syntax that can be meaningless elsewhere.
>>
>> Yes - C code is C code.  It is not Pascal, or Fortran, or Ada.  Should
>> this be a surprise?
>
> It's inconvenient. This is a macro from SDL2:
>
>   #define SDL_CompilerBarrier()   \
>   { SDL_SpinLock _tmp = 0; SDL_AtomicLock(&_tmp);
> SDL_AtomicUnlock(&_tmp); }

Why in the world would a compiler barrier need any atomics? I need to
study up on this wrt SDL.

>
> Rather than declaring a function which resides in a language-neutral
> DLL, it declares it here, in the form of actual C code.
>
> Even given a language with an FFI that is capable of calling external
> functions compiled as C, what are they supposed to do with this?
>
> That example was in a conditional block; I don't know the context. But
> here's a juicy one that is the result of an attempt to automatically
> translate the C SDL2 API to my syntax:
>
> global macro  SDL_FOURCC(A,B,C,D) =
> ((SDL_static_cast(Uint32,SDL_static_cast(Uint8,(A)))<<0)|(SDL_static_cast(Uint32,SDL_static_cast(Uint8,(B)))<<8)|(SDL_static_cast(Uint32,SDL_static_cast(Uint8,(C)))<<16)|(SDL_static_cast(Uint32,SDL_static_cast(Uint8,(D)))<<24))
>
> This also contains arbitrary C code; it needs a much more sophisticated
> tool than one that just does declaration. Basically a transpiler from
> C to the language one is writing bindinds for.
>
>
>> You already have a habit of cherry-picking example code that is as
>> "Bart-unfriendly" as you can find.
>
> Try testing your own C compiler on just about any codebase. You don't
> have to look far for extreme examples.
>
>> I don't have your experience, but I find that /very/ hard to believe.
>> I should imagine it's primarily a matter of working through the
>> "translation phases" and "preprocessing directives" described in the C
>> standards, step by step.
>
> The C standard has very little to say about. I once found a very, very
> long article which went into considerably more detail, now lost.
>
> But even 1/3 through I decided that it was impossible.
>
> In 2017 when I created my CPP, many compilers would give different
> results with various edge cases of macros. Which were right and which
> were wrong? You'd think there'd be a definitive reference for it.
>
> Here's an example I've just found:
>
>  #include <stdio.h>
>  int main(void) {
>
>   #define FOO
>      #define BAR defined(FOO)
>      #if BAR
>          puts("BAR");
>      #else
>          puts("FOO");
>      #endif
>  }
>
> Most compilers will display BAR; MSVC I think is the only one showing
> FOO. (Some smaller compilers I tried on godbolt.org failed to compile it.)
>
> Mine showed BAR (obviously!)
>
>

On 1/2/2024 1:00 PM, Chris M. Thomasson wrote:
> On 1/2/2024 12:24 PM, Bart wrote:
>> On 02/01/2024 17:34, David Brown wrote:
>>> On 02/01/2024 17:12, Bart wrote:
>>
>>>> X-macro are ugly. They are unreadable.
>>>
>>> Speaking as someone who has used them in real code, rather than
>>> someone with a pathological hatred of macros and who prefers
>>> knee-jerk reaction to their uses instead of applying a few minutes
>>> objective thought, "x-macros" can make code significantly simpler,
>>> clearer, and much easier to maintain correctly.
>>
>>
>> I'm sorry, but I *DO* find them utterly impossible. This is a simple
>> example from Stackoverflow of someone wanting to define a set of enums
>> with an accompanying table, whose problem was in ensuring the two were
>> kept in sync.
>>
>> The X-macro solution was this, adapted from the first answer here
>> (https://stackoverflow.com/questions/6635851/real-world-use-of-x-macros); assume those functions are in scope:
>>
>> -------
>>
>> #define STATE_TABLE \
>>          ENTRY(STATE0, func0) \
>>          ENTRY(STATE1, func1) \
>>          ENTRY(STATE2, func2) \
>>          ENTRY(STATE3, func3) \
>>
>> enum
>> {
>> #define ENTRY(a,b) a,
>>      STATE_TABLE
>> #undef ENTRY
>>      NUM_STATES
>> };
>>
>> void* jumptable[NUM_STATES] =
>> {
>> #define ENTRY(a,b) b,
>>      STATE_TABLE
>> #undef ENTRY
>> };
>> -------
>>
>>
>> With my feature, it is merely this:
>>
>>      global enumdata []ref void jumptable =
>>          (state1, func1),        # comment 1
>>          (state2, func2),
>>          (state3, func3),        # comment 3
>>          (state4, func4),
>>      end
>>
>> Notice:
>>
>> (1) I don't need any of those weird macros.
>>
>> (2) I don't need those backslashes
>>
>> (3) I can add comments to any entry in the table.
>>
>> (4) The 'global' attribute means both enumeration names and the array
>>      are exported to other modules. Doing the same in C is tricky.
>>
>> But I'm wasting my time because you are never going to admit my
>> feature is superior to X-macros for this purpose.
>>
>> (The author of this example goes on to say how it can also be used to
>> define a set of function prototypes. I can't do that with my feature.
>> But then I don't need function prototypes!)
>>
>>>> At best, if someone has already done the hard work of setting up a
>>>> working set of macros, then you will be able to see how to modify,
>>>> add or delete entries.
>>>
>>> They are not hard.
>>
>> Maybe not for you, but it would take me ages to come up with the right
>> incantations to make it work.
>>
>>>> For the purposes of creating parallel sets of enums and associated
>>>> data, I use special syntax which makes for a clearer and simpler
>>>> feature.
>>>
>>> And that is, obviously, utterly useless - because it is not C or even
>>> a commonly supported extension.  Oh, and even if it /were/ part of C,
>>> it would not help because that's not what I was doing.
>>
>> I've given an example of a use-case for C macros which have a special
>> purpose feature in other languages. So of cause it's not in C.
>>
>>>>
>>>> Have you ever considered that if C didn't have macros, or they
>>>> weren't powerful, then it could have evolved superior, built-in
>>>> alternatives?
>>>>
>>>
>>> The C preprocessor is part of C - it is already built in.
>>
>> You missed my point. Take a tiny feature like being able to easily get
>> the size of a fixed-length array. You commonly see macro like this:
>>
>>     #define LENGTH(a) (sizeof(a)/size(a[0]))
>>
>> What incentive is there to properly add a built-in way to do that,
>> when it can be done, badly, and in 1000 different ways by each user,
>> in a one-line macro?
>>
>> Another example is GETBIT(a, n).
>>
>>>> It wasn't a compiler limit - it was mine! The resulting expression
>>>> was completely unreadable.
>>>
>>> I wonder if the code authors also found this expanded expression
>>> unreadable.
>>
>> Look at the example I posted in reply to Blue-Maned_Hawk.
>>
>> In particular consider my last comment.
>>
>>
>>> I guess not - because they used macros so that they could write it in
>>> a clear and understandable way, and never have to look at the
>>> expansion!  You don't seem to comprehend the point of macros at all.
>>>
>>>> In the end I resorted to looking at the AST as that was clearer than
>>>> C source code.
>>>>
>>>
>>> Why not just look at the code as written, if you want to understand it?
>>
>> In my case I was debugging my C compiler. Then you need to examine the
>> actual expanded code in detail. Excessive use of macros makes that
>> much harder.
>>
>> That example came from Lua 5.4, an interpeter whose performance on a
>> par with my own product running from HLL-only code. That doesn't
>> doesn't use deeply-nested macro like this, and it doesn't appear to
>> suffer,.
>>
>>
>>> Or would doing something that sensible put a damper on your rants?
>>
>> Look, I'm written a C preprocessor (I suspect you haven't). If I
>> wanted, I could adapt it to work on my own languages.
>>
>> But I /don't/ want to. Obviously I see something undesirable about
>> them (I don't like metaprogramming in general; people get too carried
>> away with it and want to show off their skills).
>>
>> Why can't you accept that?
>>
>>
>>>> Half my use-cases involve inline assembly.
>>>
>>> Why can't that be in inlined functions?
>>
>> That doesn't work in inline assembly.
>>
>>> Again, you are not showing that these limited macros have any
>>> benefits compared to what is found in C,
>>
>> That's true. I can't write something like:
>>
>>       #define M a+b)*c
>>
>>       (M;
>>
>>
>>>> Macros are a C language artefact, and what they expand to is
>>>> arbitrary C syntax that can be meaningless elsewhere.
>>>
>>> Yes - C code is C code.  It is not Pascal, or Fortran, or Ada.
>>> Should this be a surprise?
>>
>> It's inconvenient. This is a macro from SDL2:
>>
>>    #define SDL_CompilerBarrier()   \
>>    { SDL_SpinLock _tmp = 0; SDL_AtomicLock(&_tmp);
>> SDL_AtomicUnlock(&_tmp); }
>
> Why in the world would a compiler barrier need any atomics? I need to
> study up on this wrt SDL.

Compiler barriers are completely different than memory barriers.

[...]

On 2024-01-02, Lawrence D'Oliveiro <ldo@nz.invalid> wrote:
> On Tue, 2 Jan 2024 18:16:36 -0000 (UTC), Kaz Kylheku wrote:
>
>> By the way, I'm not sure what system you are referring to by
>> "string-based macros", but in case you might be thinking of C
>> preprocessing, be advised that it's token-based.
>
> Now go learn what “homoiconicity” means.

Homoiconicity is a term that was introduced in the TRAC project
in the 1960's, referring to procedures being retained in source
form in the image, so they could be edited online.

(I actually made updates to the Wikipedia page on that.
Until fairly recently it contained a huge gaffe, whereby the term
"homoiconic" was misattributed to Doug McIlroy. This was due to
referencing an end note in a certain book, where the person writing the
article conflated two consecutive unrelated endnotes as being a
single note.)

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

On 1/2/24 21:24, Bart wrote:
>
> You missed my point. Take a tiny feature like being able to easily get
> the size of a fixed-length array. You commonly see macro like this:
>
>    #define LENGTH(a) (sizeof(a)/size(a[0]))

And why is that bad? That's a real question.

--
+---------------------------------------------------------------------+
| https://wiki.interhacker.space/index.php?title=Techno-futilit%C3%A9 |
+---------------------------------------------------------------------+

Bart <bc@freeuk.cm> writes:
>On 02/01/2024 20:11, Scott Lurndal wrote:
>> Bart <bc@freeuk.cm> writes:
>
>>> You're going to defend this to the death aren't you? Be funny if at some
>>> point some GMP II was produced whose main new benefit was a vastly
>>> simplified build!
>>
>> You still haven't provided a better system that accomplishes
>> everthing the existing system does.
>
>I need some basic information about what's what about in the 26MB of
>content in 4000 files spread over 190 directories.
>
>But it's clear that it's not interested in making things simple. (The
>nearest they've come is with the 'mini-gmp' version. But since the
>performance of that is on a par with my own library, I'll stick with
>mine, which also has a higher spec.)
>
>I have done this exercise with projects like LIBJPEG, LUA5.4 and
>TCC0.9.27. Long ago I did it with SEED7.
>
>Once I can extract the necessary info - IT ALWAYS COMES DOWN TO A LIST
>OF FILES TO SUBMIT TO A COMPILER FGS - then I can whizz through it easily.
>
>
>> Quit bitching about it and _do_ something about it.
>
>Funnily enough, I did. I wrote my own library, which I know is always
>available, and has some unique features, eg. it uses decimal, and has a
>single integer/float type.
>
>I once linked to a C port of it.
>
>It's not fast, but it's mine and it's in my language. (It accounts for
>12KB of my interpreter.)
>
>
>> It's an open
>> source system, you are free to contribute a new build system for
>> it (which clearly needs to support all the capabilities of the
>> existing system otherwise you'll never have your suggestions
>> accepted).
>>
>> Don't, however, expect anyone to cater to you.
>
>There must be one person on the planet who understands how to produce a
>Windows DLL of this thing. And funnily enough, a single 64-bit DLL is
>all any Windows user on the planet needs (that and either gmp.h or
>language-neutral docs).
>
>>>
>>> I tried to build gmp today using WSL. The process took just under five
>>> minutes. However, where and what is the output? For all the verbosity,
>>> that simple fact is omitted.
>>
>> You presumably specified that on the ./configure with the --prefix
>> option. Or did you forget to RTFM first?
>
>
>I following these instructions:
>
>--------------
>Here are some brief instructions on how to install GMP. First you need to
>compile. Since you're impatient, try this
>
> ./configure
> make
> make check <= VERY IMPORTANT!!
>
>I did the first two line before looking for the binaries.

Try RTFM:

./configure --help

always useful.

On 02/01/2024 23:55, Scott Lurndal wrote:
> Bart <bc@freeuk.cm> writes:
>> On 02/01/2024 20:11, Scott Lurndal wrote:
>>> Bart <bc@freeuk.cm> writes:
>>
>>>> You're going to defend this to the death aren't you? Be funny if at some
>>>> point some GMP II was produced whose main new benefit was a vastly
>>>> simplified build!
>>>
>>> You still haven't provided a better system that accomplishes
>>> everthing the existing system does.
>>
>> I need some basic information about what's what about in the 26MB of
>> content in 4000 files spread over 190 directories.
>>
>> But it's clear that it's not interested in making things simple. (The
>> nearest they've come is with the 'mini-gmp' version. But since the
>> performance of that is on a par with my own library, I'll stick with
>> mine, which also has a higher spec.)
>>
>> I have done this exercise with projects like LIBJPEG, LUA5.4 and
>> TCC0.9.27. Long ago I did it with SEED7.
>>
>> Once I can extract the necessary info - IT ALWAYS COMES DOWN TO A LIST
>> OF FILES TO SUBMIT TO A COMPILER FGS - then I can whizz through it easily.
>>
>>
>>> Quit bitching about it and _do_ something about it.
>>
>> Funnily enough, I did. I wrote my own library, which I know is always
>> available, and has some unique features, eg. it uses decimal, and has a
>> single integer/float type.
>>
>> I once linked to a C port of it.
>>
>> It's not fast, but it's mine and it's in my language. (It accounts for
>> 12KB of my interpreter.)
>>
>>
>>> It's an open
>>> source system, you are free to contribute a new build system for
>>> it (which clearly needs to support all the capabilities of the
>>> existing system otherwise you'll never have your suggestions
>>> accepted).
>>>
>>> Don't, however, expect anyone to cater to you.
>>
>> There must be one person on the planet who understands how to produce a
>> Windows DLL of this thing. And funnily enough, a single 64-bit DLL is
>> all any Windows user on the planet needs (that and either gmp.h or
>> language-neutral docs).
>>
>>>>
>>>> I tried to build gmp today using WSL. The process took just under five
>>>> minutes. However, where and what is the output? For all the verbosity,
>>>> that simple fact is omitted.
>>>
>>> You presumably specified that on the ./configure with the --prefix
>>> option. Or did you forget to RTFM first?
>>
>>
>> I following these instructions:
>>
>> --------------
>> Here are some brief instructions on how to install GMP. First you need to
>> compile. Since you're impatient, try this
>>
>> ./configure
>> make
>> make check <= VERY IMPORTANT!!
>>
>> I did the first two line before looking for the binaries.
>
>
> Try RTFM:
>
> ./configure --help
>
> always useful.

As I said, I read the file called INSTALL and I did /exactly/ what it said.

You're telling me, when I'm questioning why I have to use build
instructions contained in a 10,000-page manual rather than a few sides
of A4 (that I can only use in a different country) that I should try
reading the guide to that manual!

You guys don't seem to get it.

The end-product will be a binary between 0.5 and 1.0MB. It is not a
170MB web browser.

I actually gave up being able to use this library years ago, so no
longer need it. If people really don't care about providing ready-to-use
libraries, then fuck 'em.

I now use my own library, which I can build into a DLL binary, like this:

c:\mx>mm -dll bignum
Compiling bignum.m------ to bignum.dll
Writing exports file to bignum.q

It takes 50msec. The secondary file it writes is a set of bindings to
use it from one of my other languages.

This stuff needs to be as effortless as this.

On Wed, 3 Jan 2024 02:08:40 +0000, Bart wrote:

> You guys don't seem to get it.

Another thing we do is, not to bother repeating work that others have
already done.

sudo apt-get install libgmp-dev

Job done.

On Wed, 3 Jan 2024 00:24:41 +0100, tTh wrote:

> On 1/2/24 21:24, Bart wrote:
>>
>>    #define LENGTH(a) (sizeof(a)/size(a[0]))
>
> And why is that bad? That's a real question.

Ignoring the typo? Not typesafe. If you pass something that it’s not
expecting, you will likely not get a nice, clear error message, but a
cryptic, not to say, irrelevant, one.

Also, would it be better as

#define LENGTH(a) (sizeof(a)/sizeof((a)[0]))

? Answers on a postcard, please.

On 2024-01-02, tTh <tth@none.invalid> wrote:
> On 1/2/24 21:24, Bart wrote:
>>
>> You missed my point. Take a tiny feature like being able to easily get
>> the size of a fixed-length array. You commonly see macro like this:
>>
>>    #define LENGTH(a) (sizeof(a)/size(a[0]))
>
> And why is that bad? That's a real question.

It fails miserably on pointers, and silently, if you don't have a newer
gcc that has a diagnostic specifically for this case.

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

On 1/1/2024 6:09 AM, David Brown wrote:
> On 31/12/2023 19:33, Scott Lurndal wrote:
>> Bart <bc@freeuk.cm> writes:
>>> On 31/12/2023 01:36, Lawrence D'Oliveiro wrote:
>>>> On Sat, 30 Dec 2023 01:58:53 +0000, Bart wrote:
>>>>
>>>>> So, why don't the vendors of the library do that exercise?
>>>>
>>>> Maybe because most of the “vendors” of proprietary libraries have gone
>>>> extinct. What we have now is “developers” and “contributors” to open-
>>>> source projects. And if you have a bright idea for how they can do
>>>> things
>>>> better, you are free to contribute it.
>>>
>>> I have plenty of ideas, but people are generally not interested.
>>
>> Perhaps they are not very good ideas, then....
>>
>> Frankly, your obsession with header files is puzzling.   99.9%
>> percent of C/C++ programmers don't care.
>
> Bart needs to care about the library header files when he is working on
> his C implementation, and it is understandable that he finds existing
> headers frustrating when he is trying to turn them into something his C
> implementation can use.  But you are absolutely correct that the huge
> majority of C programmers don't care what is in these headers.  So as I
> see it, the strange thing about Bart's view of library headers is not
> that /he/ is obsessed with them or frustrated by them, but that he
> apparently feels other people should also be bothered by them.
>
> The glibc (and other C library) developers have a responsibility to make
> headers that work correctly for C programmers, according to the C
> standards and their own documentation of extensions, and without
> significant measurable unnecessary inefficiency - beyond that, they can
> organise things in whatever way suits them and whatever way they find
> easiest.  They have no responsibility to make life easier for people
> making libraries, headers or compilers other than those they choose to
> work with.  Bart is right to think they /could/ have made it vastly
> easier to use their headers with other tools, such as his compiler - but
> wrong to think they /should/ have done so, and wrong to think that more
> than a tiny proportion of C programmers are bothered about it.
>

FWIW:
In my case, I am using a highly modified PDPCLIB (originally written, at
least in large part, by Paul Edwards). Looking at a few of the files, it
seems to identify as 2.01 from 2009 ...

My version has ended up changing a few parts:

stdio.h:
Somewhat modified, removed the "IBM mainframe" stuff, which was N/A for
my uses.

stdlib.h:
Switched over to my own malloc/free implementation, rewrote many of the
string and memory functions to "not be dead slow";

math.h:
Rewrote most of the math code, a lot of the original versions were slow
and/or prone to explode at random.
Mostly replaced a lot of the math functions with unrolled Taylor series
expansions and similar.

signal.h / locale.h / ...:
Added some of this (IIRC original versions were mostly no-op stubs).

Added some amount of C99 stuff and some C11 stuff.

Also added a lot of stuff from POSIX and similar as well.

One observation I have made is that often, the amount of code pulled in
from headers is larger than the amount of code present in a translation
unit, and so often "unity builds" are a net win for compilation time.

Though, the normal C library headers are not particularly big offenders
here, but more things like the OpenGL headers.

Or, in cases where I had crossed paths with "windows.h", the amount of
stuff this pulls in is "kinda absurd" (but, this is mostly N/A for my
current project; which makes no attempt to implement the Win32 API).

> C++ programmers (and C++ compiler writers) /do/ care a bit more about
> headers, though not the ones from the C standard library.  C++ headers
> are often very big and are a significant part of compile and build
> times.  Thus compilers often support pre-compiled headers, and one of
> the prime motivations of C++ modules in newer C++ standards is to be
> more efficient and cleaner than header files.
>

Yeah.

For plain C, things are a little more manageable.

Say, if I do (for compiling BGBCC via GCC):
time make -f Makefile.lnx
I get:
real 1m3.247s
user 0m59.688s
sys 0m3.297s

If I use Clang instead:
real 0m37.049s
user 0m33.938s
sys 0m2.000s

If compiling via MSVC, it is more around 20 seconds.

I have not tried to get my compiler to be self-hosting, but this is more
a case of me trying to compile stuff on my own platform being asking a
bit much at this stage (my compiler generally eats too much RAM, etc).

As noted, it doesn't really support x86 or ARM, since (as I see it)
these are served "well enough" by GCC/Clang/MSVC/etc.

If compiling GLQuake, my compiler seems to use around 230MB of RAM. With
the current version, with "compiler debug output" disabled, takes around
12 seconds on my Ryzen 2700X.

Assuming that compile time scales linearly with clock-speed, trying to
build GLQuake on a 50MHz CPU would take 15 minutes, but probably
significantly longer as it would also need to swap excessively.

These sorts of compile times seem likely unworkable.

Ideally, one would need a compiler that could compile something like
GLQuake in around 1 second (on a modern PC) at preferably under 40MB of RAM.

Note: For the GLQuake port, the compiler is compiling each C file as its
own translation unit. Also, this program is only 140 kLOC...

I guess, how quickly does GCC compile Quake?:
real 0m13.523s
user 0m7.781s
sys 0m5.281s

Though, this is the software version.

Hacking GLQuake into building:
real 0m17.777s
user 0m11.609s
sys 0m5.891s

Though, this isn't "actually working", just hacked stuff enough to get
it to build. This is on top of WSL.

....

On 02/01/2024 23:24, tTh wrote:
> On 1/2/24 21:24, Bart wrote:
>>
>> You missed my point. Take a tiny feature like being able to easily get
>> the size of a fixed-length array. You commonly see macro like this:
>>
>>     #define LENGTH(a) (sizeof(a)/size(a[0]))
>
>    And why is that bad? That's a real question.

Where do I start?

* Why is it necessary for a million programmers to each come up with
their own solutions for something so basic? Eg. they will all use
diferent names.

* What happens when you merge or copy&paste code form different sources,
which use different macros for the same thing?

How does it work in practice: does everyone have a personal header full
of this stuff (bits missing from the language)? That will make it
awkward to post short programs to forums as now they have this extra
dependendcy.

Personally I can never bothered to write such macros in throwaway
programs, I just either write the whole thing in situ, or hard-code the
size if I know what it is anyway:

char* names[] = {"one", "two", "three", "four"};

for (int i=0; i<4; ++i)
puts(names[i]);

Rather than write:

for (int i=0; i<sizeof(names)/sizeof(names[0]); ++i) puts(names[i]);

It's all just so messy and annoying.

How hard is it to make it built-in to the language? I tried it just now
and it was about 20 lines of code to allow me to instead write:

char* names[] = {"one", "two", "three", "four"};

for (int i=0; i<lengthof(names); ++i)
puts(names[i]);

It took about 20 minutes. This could have been done in 1972.

On 03/01/2024 02:40, Lawrence D'Oliveiro wrote:
> On Wed, 3 Jan 2024 02:08:40 +0000, Bart wrote:
>
>> You guys don't seem to get it.
>
> Another thing we do is, not to bother repeating work that others have
> already done.
>
> sudo apt-get install libgmp-dev
>
> Job done.

OK, I've done that. But it didn't take 5 minutes as it did to compile it.

So I guess it is installing ready-built binaries?

In that case, why are people having a go at me for suggesting they
should be available to Windows users? Why are Linux users so blessed?

I notice that it no longer matters whether string.h is available. (Nor
apparently, the exact capabilities of my processor.)

Why it was ever an issue not clear. But it seems it only matters when
building this product.

Once it is a binary, then it doesn't matter. All the more reason why
such fussy bits of software should be preprocessed centrally, so that I
either get a binary, or an easy-to-compile blob of C code.

On 03/01/2024 12:10, Bart wrote:
> On 03/01/2024 02:40, Lawrence D'Oliveiro wrote:
>> On Wed, 3 Jan 2024 02:08:40 +0000, Bart wrote:
>>
>>> You guys don't seem to get it.
>>
>> Another thing we do is, not to bother repeating work that others have
>> already done.
>>
>> sudo apt-get install libgmp-dev
>>
>> Job done.
>
> OK, I've done that. But it didn't take 5 minutes as it did to compile it.
>
> So I guess it is installing ready-built binaries?
>
> In that case, why are people having a go at me for suggesting they
should be available to Windows users? Why are Linux users so blessed?
>

It gets more puzzling: on Linux for which the build process was designed
to run on, and where it is likely to work, users don't even need to
bother to do it, as there may be a ready-to-use version available.

But on Windows, where it is impossible to build without using so many
Linux elements (even 'info' to read the docs, and remember that weird
'JUNCTION' header?), there is no official binary. (Just lots of dubious
gmp.dlls with unfeasibly small sizes from dodgy-looking DLL sites.)

It's almost like they did it on purpose. Then I came across this comment
from 2016:

"Worth noting that there's quite a bit of beef between GMP and MPIR.

The GMP devs hate Windows and anything Microsoft. It's quite obvious
from the tone of language in their mailing lists.

This hostility towards Windows is why MPIR was made. So then the GMP
devs started hating on MPIR probably because it became a competitor."

This is just sad. It does sound as though the GMP people crammed in as
many Linux dependencies as possible just to spite MS.

I remember similar attitudes from the creators of Zig: they deliberately
chose not to support source files with CRLF line endings, because they
hated MS. Although later they did allow them.

(I remember needing to write a CRLF to LF conversion tool just to be
able to compile hello.zig.)

Bart <bc@freeuk.cm> writes:
>On 02/01/2024 23:24, tTh wrote:
>> On 1/2/24 21:24, Bart wrote:
>>>
>>> You missed my point. Take a tiny feature like being able to easily get
>>> the size of a fixed-length array. You commonly see macro like this:
>>>
>>>     #define LENGTH(a) (sizeof(a)/size(a[0]))
>>
>>    And why is that bad? That's a real question.
>
>Where do I start?
>
>* Why is it necessary for a million programmers to each come up with
> their own solutions for something so basic? Eg. they will all use
> diferent names.

Why is it necessary to exaggerate?

I've not seen that particular macro in the last forty years, myself.

LENGTH isn't even the proper macro name in this case; QUANTITY or NUM_ELEMENTS
would likely be more appropriate.

I have, of course, seen the idiom used often - it's quite normal and
standard.

e.g.
/*
* Table of Pentium MSR's to allow the Guest to access directly.
*
* XXX - Note that if the guest is allowed to access these MSR's
* directly, then they must be preserved and restored when the
* guest is migrated to a different core.
*/
static int pentium_msr_passthrough[] = {
MSR_SYSENTER_CS,
MSR_SYSENTER_EIP,
MSR_SYSENTER_ESP,
};
static const size_t PENTIUM_MSR_PT_CNT =
sizeof(pentium_msr_passthrough) / sizeof(pentium_msr_passthrough[0]);

/*
* Table of K6 MSR's to allow the guest to access directly.
*
* See caveat above.
*/
static int k6_msr_passthrough[] = {
MSR_KERN_GS_BASE,
MSR_USER_GS_BASE,
MSR_FS_BASE,
MSR_STAR,
MSR_LSTAR,
MSR_CSTAR,
MSR_SFMASK,
MSR_TSC_AUX,
};

static const unsigned int K6_MSR_PT_CNT =
sizeof(k6_msr_passthrough) / sizeof(k6_msr_passthrough[0]);

Bart <bc@freeuk.cm> writes:
>On 03/01/2024 02:40, Lawrence D'Oliveiro wrote:
>> On Wed, 3 Jan 2024 02:08:40 +0000, Bart wrote:
>>
>>> You guys don't seem to get it.
>>
>> Another thing we do is, not to bother repeating work that others have
>> already done.
>>
>> sudo apt-get install libgmp-dev
>>
>> Job done.
>
>OK, I've done that. But it didn't take 5 minutes as it did to compile it.
>
>So I guess it is installing ready-built binaries?
>
>In that case, why are people having a go at me for suggesting they
>should be available to Windows users? Why are Linux users so blessed?

Because linux is open source and the GNU team doesn't support closed-source
source operating environments like Windows.