On 05/01/2024 14:05, David Brown wrote:
> On 05/01/2024 02:53, Bart wrote:
>> On 04/01/2024 23:25, Lawrence D'Oliveiro wrote:
>>> On Thu, 4 Jan 2024 22:48:17 +0000, Bart wrote:
>>>
>>>> For 40 years 99% of my coding has been in a language where you just
>>>> write:
>>>>
>>>>       A.len
>>>
>>> Better still:
>>>
>>>      len(A)
>>>
>>> which is just a generic wrapper around
>>>
>>>      A.__len__()
>>>
>>> so it will work with your custom object types as well, all they have
>>> to do
>>> is define a method with that name.
>>
>> If a language has a built-in like A.len or len(A) or A'len and so on,
>> then it can choose to allow overloading for that operator. The syntax
>> chosen doesn't matter.
>>
>> It doesn't need to take a heavy-handed approach like C++ or Python.
>>
>
> One option for a useful array length operator/function/macro is a simple
> and limited feature that works for arrays of known size and gives a hard
> (compile-time) error when the size is not known.  The one you have in
> your own language covers most of that, except for the insanity of
> evaluating to 0 when given a pointer/reference to an "unbounded" array.
> The "ARRAY_SIZE" macro in Linux is almost perfect - the only
> disadvantage is that it relies on compiler extensions:
>
> #define ARRAY_SIZE(arr) (sizeof(arr) / sizeof((arr)[0]) +
> __must_be_array(arr))
>
> #define __same_type(a, b) __builtin_types_compatible_p(typeof(a),
> typeof(b)))
>
> #define __must_be_array(a)    BUILD_BUG_ON_ZERO(__same_type((a), &(a)[0]))
>
> #define BUILD_BUG_ON_ZERO(e)   (sizeof(struct { int:-!!(e); }))

At least Linux recognises some of the problems of the
sizeof(A)/sizeof(A[10]) idiom.

Which is more than can said for Scott, who can't see any possible issues
at all. Apparently writing B for one of those As is impossible:

"Any programmer will see that they don't match immediately. It is
obviously wrong."

No matter long or short or similar they are.

On 05/01/2024 16:58, Keith Thompson wrote:
> David Brown <david.brown@hesbynett.no> writes:
> [...]
>> One option for a useful array length operator/function/macro is a
>> simple and limited feature that works for arrays of known size and
>> gives a hard (compile-time) error when the size is not known. The one
>> you have in your own language covers most of that, except for the
>> insanity of evaluating to 0 when given a pointer/reference to an
>> "unbounded" array. The "ARRAY_SIZE" macro in Linux is almost perfect -
>> the only disadvantage is that it relies on compiler extensions:
>>
>> #define ARRAY_SIZE(arr) (sizeof(arr) / sizeof((arr)[0]) +
>> __must_be_array(arr))
>>
>> #define __same_type(a, b) __builtin_types_compatible_p(typeof(a),
>> typeof(b)))
>>
>> #define __must_be_array(a) BUILD_BUG_ON_ZERO(__same_type((a), &(a)[0]))
>>
>> #define BUILD_BUG_ON_ZERO(e) (sizeof(struct { int:-!!(e); }))
> [...]
>
> When you wrote "in Linux", I wondered if you were being imprecise, but
> in fact that code is in the Linux kernel.
>

I am perhaps being /too/ precise - "Linux" is technically the kernel,
rather than the rest of the system (including user C code). But yes, it
is in the headers for use when compiling the kernel, rather than for
user code compiled for Linux systems.

And yes, you can copy them (or variations of them) to your own code.

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

On 2024-01-05, Janis Papanagnou <janis_papanagnou+ng@hotmail.com> wrote:
> Why so paranoid defensive? :-)

For consistency with lengthy past history.

--
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 2024-01-05, Keith Thompson <Keith.S.Thompson+u@gmail.com> wrote:
> When you wrote "in Linux", I wondered if you were being imprecise, but
> in fact that code is in the Linux kernel.
>
> That means the macros aren't directly available to normal C code, but
> you can always copy their definitions (*if* you're using a compiler
> that supports the __builtin_types_compatible_p extension).

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

#ifdef __GNU__

// define array_size in the Linux kernel way

#else

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

#endif

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

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

--
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.

Bart <bc@freeuk.cm> writes:
>On 05/01/2024 14:05, David Brown wrote:
>> On 05/01/2024 02:53, Bart wrote:
>>> On 04/01/2024 23:25, Lawrence D'Oliveiro wrote:
>>>> On Thu, 4 Jan 2024 22:48:17 +0000, Bart wrote:
>>>>
>>>>> For 40 years 99% of my coding has been in a language where you just
>>>>> write:
>>>>>
>>>>>       A.len
>>>>
>>>> Better still:
>>>>
>>>>      len(A)
>>>>
>>>> which is just a generic wrapper around
>>>>
>>>>      A.__len__()
>>>>
>>>> so it will work with your custom object types as well, all they have
>>>> to do
>>>> is define a method with that name.
>>>
>>> If a language has a built-in like A.len or len(A) or A'len and so on,
>>> then it can choose to allow overloading for that operator. The syntax
>>> chosen doesn't matter.
>>>
>>> It doesn't need to take a heavy-handed approach like C++ or Python.
>>>
>>
>> One option for a useful array length operator/function/macro is a simple
>> and limited feature that works for arrays of known size and gives a hard
>> (compile-time) error when the size is not known.  The one you have in
>> your own language covers most of that, except for the insanity of
>> evaluating to 0 when given a pointer/reference to an "unbounded" array.
>> The "ARRAY_SIZE" macro in Linux is almost perfect - the only
>> disadvantage is that it relies on compiler extensions:
>>
>> #define ARRAY_SIZE(arr) (sizeof(arr) / sizeof((arr)[0]) +
>> __must_be_array(arr))
>>
>> #define __same_type(a, b) __builtin_types_compatible_p(typeof(a),
>> typeof(b)))
>>
>> #define __must_be_array(a)    BUILD_BUG_ON_ZERO(__same_type((a), &(a)[0]))
>>
>> #define BUILD_BUG_ON_ZERO(e)   (sizeof(struct { int:-!!(e); }))
>
>At least Linux recognises some of the problems of the
>sizeof(A)/sizeof(A[10]) idiom.
>
>Which is more than can said for Scott, who can't see any possible issues
>at all. Apparently writing B for one of those As is impossible:

Even David has claimed to use the sizeof/sizeof[0] idiom.

>
>"Any programmer will see that they don't match immediately. It is
>obviously wrong."
>
>No matter long or short or similar they are.

There are thousands of ways programmers can introduce
bugs far more easily which are significantly harder
to find and fix; and yes, I expect programmers to
fully understand the code they're writing and test
their code to find bugs which they then will subsequently
fix.

Do lookup the word 'strawman' as it relates to discourse.

The use of that idiom is _not a problem_.

On 05/01/2024 09:03, Janis Papanagnou wrote:
> On 04.01.2024 21:17, Bart wrote:

> Specifically when discussing C there's IMO countless examples of what's
> missing, and what's wrongly designed, and whatnot. - Thus I am merely
> astonished that you fastened on that bit so vigorously, and also with
> so much text and repetitions.

Within one post or multiple? If I'm repeating myself it is either
because others do, or I'm being attacked on multiple fronts.

> There's (IMO) so much wrong with arrays in C that the discussed special
> case (which is also not generally applicable as pointed out repeatedly)
> is of little interest (for me; YMMV).

There is a huge amount wrong with C at this level of language, which is
about par with my own.

Many will just move on from C to modern alternatives, but they are
generally bigger, more complex, and cumbersome.

I like systems coding at this level. So as a long time user and
developer of my alternate language, I can give talk about 100-200
different aspects that I have made better. Most are microfeatures, but
some are big ones.

> Mind, I started with K&R C in the 1980's, at a time where much more
> sophisticated languages had already been present; the formally much
> more appealing Algol(68), the concepts-outstanding Simula(67), even
> Pascal

Mine has a syntax based largely on Algol and Pascal, notably Algol68.

Algol68 has LWB a and UPB a, I turned those into a.lwb and a.upb, and
added a.len. But my language was far simpler semantically.

> Above we identified a "resume" of the previous posts. Another one
> shall finalize this post; no one is forced to use C.

Neither was I, until 1992, then I needed to start interacting with
libraries defined via a C API. I was supposed to switch to using C (and
get a proper job using that), but I couldn't do it.

I realised my 'temporary' in-house language that I'd hacked together in
my spare time was actually better.

On 05/01/2024 18:44, Scott Lurndal wrote:
> Bart <bc@freeuk.cm> writes:
>> On 05/01/2024 14:05, David Brown wrote:

>>> One option for a useful array length operator/function/macro is a simple
>>> and limited feature that works for arrays of known size and gives a hard
>>> (compile-time) error when the size is not known.  The one you have in
>>> your own language covers most of that, except for the insanity of
>>> evaluating to 0 when given a pointer/reference to an "unbounded" array.
>>> The "ARRAY_SIZE" macro in Linux is almost perfect - the only
>>> disadvantage is that it relies on compiler extensions:
>>>
>>> #define ARRAY_SIZE(arr) (sizeof(arr) / sizeof((arr)[0]) +
>>> __must_be_array(arr))
>>>
>>> #define __same_type(a, b) __builtin_types_compatible_p(typeof(a),
>>> typeof(b)))
>>>
>>> #define __must_be_array(a)    BUILD_BUG_ON_ZERO(__same_type((a), &(a)[0]))
>>>
>>> #define BUILD_BUG_ON_ZERO(e)   (sizeof(struct { int:-!!(e); }))
>>
>> At least Linux recognises some of the problems of the
>> sizeof(A)/sizeof(A[10]) idiom.
>>
>> Which is more than can said for Scott, who can't see any possible issues
>> at all. Apparently writing B for one of those As is impossible:
>
> Even David has claimed to use the sizeof/sizeof[0] idiom.
>
>>
>> "Any programmer will see that they don't match immediately. It is
>> obviously wrong."
>>
>> No matter long or short or similar they are.
>
> There are thousands of ways programmers can introduce
> bugs far more easily which are significantly harder
> to find and fix; and yes, I expect programmers to
> fully understand the code they're writing and test
> their code to find bugs which they then will subsequently
> fix.
>
> Do lookup the word 'strawman' as it relates to discourse.

And yet, despite it having no problems according to you, people still
feel the need to create macros like ARRAY_SIZE.

So I'm puzzled. Why do they do that? What imaginary problem (according
to you) do they solve?

Bart <bc@freeuk.cm> writes:
>On 05/01/2024 18:44, Scott Lurndal wrote:

>> Do lookup the word 'strawman' as it relates to discourse.
>
>And yet, despite it having no problems according to you, people still
>feel the need to create macros like ARRAY_SIZE.
>
>So I'm puzzled. Why do they do that? What imaginary problem (according
>to you) do they solve?

Why does anyone do anything?

It's possible they believe it is fewer characters to
to write. Some may find it more readable. Some may
find it less readable.

On 05/01/2024 14:05, David Brown wrote:
> On 05/01/2024 02:53, Bart wrote:

>> It doesn't need to take a heavy-handed approach like C++ or Python.
>>
>
> One option for a useful array length operator/function/macro is a simple
> and limited feature that works for arrays of known size and gives a hard
> (compile-time) error when the size is not known.  The one you have in
> your own language covers most of that, except for the insanity of
> evaluating to 0 when given a pointer/reference to an "unbounded" array.

It gives zero because that is actually the compile-time type of the
array. But it is low priority because it is never used that way.

I mentioned elsewhere another mechanism (slices) for dealing better with
arrays passed to functions.

C as it is now has worse problems than this with array handling.

> The "ARRAY_SIZE" macro in Linux is almost perfect - the only
> disadvantage is that it relies on compiler extensions:
>
> #define ARRAY_SIZE(arr) (sizeof(arr) / sizeof((arr)[0]) +
> __must_be_array(arr))
>
> #define __same_type(a, b) __builtin_types_compatible_p(typeof(a),
> typeof(b)))
>
> #define __must_be_array(a)    BUILD_BUG_ON_ZERO(__same_type((a), &(a)[0]))
>
> #define BUILD_BUG_ON_ZERO(e)   (sizeof(struct { int:-!!(e); }))
>
>
> The other option is a general mechanism for "length" as an
> operator/function/macro that can be applied to a wide range of types -
> including user-made types, assuming the language supports user-defined
> types.  Whether that is done by function overloads, custom methods,
> etc., is a design choice.
>

In my static language, '.len' works on two types (arrays and slices; for
the latter it happens at runtime).

In the dynamic one, '.len' works on 10 different types (list, array,
string, bit-array, bit-set, decimal, record, struct, range). That's
already enough to be dealing with. (Record types can have methods to
return such info.)

In C, sizeof() is usually compile-time, except when used on VLAs, and
here, as usual for VLAs, it is a lot more complicated than you'd think:

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

int main(void) {
int n=rand()+1;
typedef char (**T)[n];
n=-777;

T x;

printf("%zu\n", sizeof(**x));
} --------

This actually displays 42 (really!). 'x' is a pointer (to a pointer to
array). There is no actual array allocated. But it needs somewhere to
store the size of the type which is the target of those pointers.

I was hoping to do it without creating `x`, but I didn't know how. (I
couldn't do that in mine either; I'd need a way to get the target of a
pointer type T.)

Slices are child's play by comparison; they are basically:

struct {T* ptr; u64 length;};

-------
c:\c>gcc c.c && a
42

On 2024-01-05, Bart <bc@freeuk.cm> wrote:
> In my static language, '.len' works on two types (arrays and slices; for
> the latter it happens at runtime).

Yeah, but some widely-used languages also solve this.

Broadly speaking beyond the context of this array issue, those are your
competition, not C.

It's like you're dwelling in a room full of retards in order to feel
smart.

--
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.

Bart <bc@freeuk.cm> writes:
> On 05/01/2024 18:44, Scott Lurndal wrote:
[...]
>> There are thousands of ways programmers can introduce
>> bugs far more easily which are significantly harder
>> to find and fix; and yes, I expect programmers to
>> fully understand the code they're writing and test
>> their code to find bugs which they then will subsequently
>> fix.
>> Do lookup the word 'strawman' as it relates to discourse.
>
> And yet, despite it having no problems according to you, people still
> feel the need to create macros like ARRAY_SIZE.

Yes. That's how they use the idiom.

> So I'm puzzled. Why do they do that? What imaginary problem (according
> to you) do they solve?

I don't know what you're puzzled about.

Some programmers use the `sizeof arr / sizeof arr[0]` idiom by writing
it directly into an expression, presumably because they find it clear
enough. Others use it by defining a macro, probably with the intent of
making the code clearer to human readers. Others use an existing macro
if it happens to be defined in the project they're using.

Like anything, it's possible to use it incorrectly. I recognize that it
can quietly fail if, for example, you mistype one of the occurrences of
"arr", or if you apply it to a pointer expression. I don't believe I've
ever seen such an error in practice. I suspect that 99% of C
programmers who know how the idiom works also know enough about C arrays
and pointers that they can avoid such errors.

In a previous job, I modified some existing code to use the
sizeof/sizeof idiom. Since I actually knew what I was doing, I didn't
introduce any errors (and IIRC I solved an existing off-by-one error).
What do you think I should have done, waited until it was added as an
extension by the compiler I was using, or as a language feature in C3X?

--
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 */

Bart <bc@freeuk.cm> writes:

> In C, sizeof() is usually compile-time, except when used on VLAs, and here,
> as usual for VLAs, it is a lot more complicated than you'd think:
>
> --------
> #include <stdio.h>
> #include <stdlib.h>
>
> int main(void) {
> int n=rand()+1;
> typedef char (**T)[n];
> n=-777;
>
> T x;
>
> printf("%zu\n", sizeof(**x));
> }
> --------
>
> This actually displays 42 (really!). 'x' is a pointer (to a pointer to
> array). There is no actual array allocated.

More to the point, x is uninitialised and thus evaluating sizeof **x is
undefined behaviour. gcc has some flags that could have helped you to
find that out.

> But it needs somewhere to store
> the size of the type which is the target of those pointers.
>
> I was hoping to do it without creating `x`, but I didn't know how.

You don't need to create an array, nor a pointer to one, nor a pointer
to a pointer to one, in order to show that the compiler must record the
size of a variably modified array type at runtime:

int n = rand() + 1;
typedef char T[n];
printf("%zu\n", sizeof (T));
n = 42;
printf("%zu\n", sizeof (T));

n is something of a red herring here. If you write the expression in
the typedef itself you might have been less surprised:

typedef char T[rand() + 1]; // the size obviously needs to be stored

--
Ben.

On 05/01/2024 22:50, Keith Thompson wrote:
> Bart <bc@freeuk.cm> writes:
>> On 05/01/2024 18:44, Scott Lurndal wrote:
> [...]
>>> There are thousands of ways programmers can introduce
>>> bugs far more easily which are significantly harder
>>> to find and fix; and yes, I expect programmers to
>>> fully understand the code they're writing and test
>>> their code to find bugs which they then will subsequently
>>> fix.
>>> Do lookup the word 'strawman' as it relates to discourse.
>>
>> And yet, despite it having no problems according to you, people still
>> feel the need to create macros like ARRAY_SIZE.
>
> Yes. That's how they use the idiom.
>
>> So I'm puzzled. Why do they do that? What imaginary problem (according
>> to you) do they solve?
>
> I don't know what you're puzzled about.

I'm puzzled because people like Scott are suggesting those macros are a
waste of time, and yet you find them in big, important software.

Actually, I'm not really puzzled, I know he's just being contrary to
wind me up, and I was trying to catch him out.

On 05/01/2024 23:02, Ben Bacarisse wrote:
> Bart <bc@freeuk.cm> writes:
>
>> In C, sizeof() is usually compile-time, except when used on VLAs,
and here,
>> as usual for VLAs, it is a lot more complicated than you'd think:
>>
>> --------
>> #include <stdio.h>
>> #include <stdlib.h>
>>
>> int main(void) {
>> int n=rand()+1;
>> typedef char (**T)[n];
>> n=-777;
>>
>> T x;
>>
>> printf("%zu\n", sizeof(**x));
>> }
>> --------
>>
>> This actually displays 42 (really!). 'x' is a pointer (to a pointer to
>> array). There is no actual array allocated.
>
> More to the point, x is uninitialised and thus evaluating sizeof **x is
> undefined behaviour. gcc has some flags that could have helped you to
> find that out.

I actually don't know if it's evaluating it or not. Why on earth should
it? If I change the program to print the original 'n', it is 42 too. So
it doesn't need to evaluate **x to get that dimension.

(When I implement sizeof(X), it works out the /type/ of X, at
compile-time. That should be the case with VLA types too, except the
type will involve that runtime element which is nothing to do with the
value of X or **x.)

>> But it needs somewhere to store
>> the size of the type which is the target of those pointers.
>>
>> I was hoping to do it without creating `x`, but I didn't know how.
>
> You don't need to create an array, nor a pointer to one, nor a pointer
> to a pointer to one, in order to show that the compiler must record the
> size of a variably modified array type at runtime:
>
> int n = rand() + 1;
> typedef char T[n];
> printf("%zu\n", sizeof (T));
> n = 42;
> printf("%zu\n", sizeof (T));
>
> n is something of a red herring here. If you write the expression in
> the typedef itself you might have been less surprised:
>
> typedef char T[rand() + 1]; // the size obviously needs to be stored
>

Yes, this why I set n to -777 to show that it has to capture the value
of n inside the typedef.

But in your example, the size of T /is/ the array dimension. In mine, T
is a pointer; how to double check what the value of n was:

int n=rand()+1;
typedef char (**T)[n];
n=-777;

The original value of n is lost. So how to print the dimension of the
array portion of that type, without creating an instance of the type?

The point of the example was to so show that mixing sizeof and VLAs can
get hairy.

Both gcc and tcc (and clang) seemed to work with my example.

lccwin32 crashed. When I hardcoded n to 4 or 5 (but still a VLA), then
the array size was reported as either 4 or 5, except by lccwin32 which
always said 8.

Initialising x to an actual pointer to pointer to array made no difference.

This compiler might be buggy, but it shows that VLAs can be difficult to
get right. My compiler doesn't even try.

I think my original point might have been that 'slices' are a modest
advance over plain arrays, which have to carry a length parameter. very
easy to understand and not hard to implement.

But C decided to skip such a feaure, and leap straight to the much
harder-to-implement VLAs.

Bart <bc@freeuk.cm> writes:
> On 05/01/2024 22:50, Keith Thompson wrote:
>> Bart <bc@freeuk.cm> writes:
>>> On 05/01/2024 18:44, Scott Lurndal wrote:
>> [...]
>>>> There are thousands of ways programmers can introduce
>>>> bugs far more easily which are significantly harder
>>>> to find and fix; and yes, I expect programmers to
>>>> fully understand the code they're writing and test
>>>> their code to find bugs which they then will subsequently
>>>> fix.
>>>> Do lookup the word 'strawman' as it relates to discourse.
>>>
>>> And yet, despite it having no problems according to you, people still
>>> feel the need to create macros like ARRAY_SIZE.
>> Yes. That's how they use the idiom.
>>
>>> So I'm puzzled. Why do they do that? What imaginary problem (according
>>> to you) do they solve?
>> I don't know what you're puzzled about.
>
> I'm puzzled because people like Scott are suggesting those macros are
> a waste of time, and yet you find them in big, important software.

Oh, so *that's* what you're complaining about.

I just took a look at Scott's article to which you replied, and its
parent, and so on all the way to the first article in this thread.
Nowhere did Scott suggest that those macros are a waste of time.

He did write some things that suggest that he considers the
`sizeof arr / sizeof arr[0]` idiom clear enough to be written directly
as part of an expression rather than as a macro (and I agree), but I
didn't see him objecting to the idea of using a macro.

I can't speak for him, but I think he was objecting to your insistence
that using the idiom directly is unacceptable, and you interpreted that
as him insisting that wrapping the idiom in a macro is useless. He
didn't say that.

I'm making an assumption here, that you find code that uses the idiom
directly more objectionable than code that wraps it in a macro.

Personally, I'd be likely to define a macro if I'm going to be using it
multiple times. In an example I mentioned recently, where I modified
some existing code to use `sizeof array / sizeof array[0]`, I was only
doing it once, so just wrote the expression directly. Either method is
fine with me, and I suspect Scott would agree.

[...]

--
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 05/01/2024 22:43, Kaz Kylheku wrote:
> On 2024-01-05, Bart <bc@freeuk.cm> wrote:
>> In my static language, '.len' works on two types (arrays and slices; for
>> the latter it happens at runtime).
>
> Yeah, but some widely-used languages also solve this.
>
> Broadly speaking beyond the context of this array issue, those are your
> competition, not C.

What, languages like Rust, Zig, Java, C#?

I don't think so. Even lesser known ones like C3 are pretty huge. The
nearest in scale to what I'm doing might be Hare.

C can be implemented [on and for x64] in under 200KB. Mine in something
over 300KB (but it is multipass; tcc is single pass). Most of those
others are 100MB and up.

I deliberately keep my systems language simple and low level, yet there
are lots of modest enhancements over C too.

> It's like you're dwelling in a room full of retards in order to feel
> smart.

I would have let my language die years ago. And yet, C is still
tremendously popular and widely used. It's something that people feel
they can master and be in control of, rather than be intimidated by.

But it's also full of terrible design choices.

So if there's a place for such a systems language, then mine is worth
maintaining too. The 'competitor' then is C.

Bart <bc@freeuk.cm> writes:
> On 05/01/2024 23:02, Ben Bacarisse wrote:
>> Bart <bc@freeuk.cm> writes:
>>> In C, sizeof() is usually compile-time, except when used on VLAs,
> and here,
>>> as usual for VLAs, it is a lot more complicated than you'd think:
>>>
>>> --------
>>> #include <stdio.h>
>>> #include <stdlib.h>
>>>
>>> int main(void) {
>>> int n=rand()+1;
>>> typedef char (**T)[n];
>>> n=-777;
>>>
>>> T x;
>>>
>>> printf("%zu\n", sizeof(**x));
>>> }
>>> --------
>>>
>>> This actually displays 42 (really!). 'x' is a pointer (to a pointer to
>>> array). There is no actual array allocated.
>>
>> More to the point, x is uninitialised and thus evaluating sizeof **x is
>> undefined behaviour. gcc has some flags that could have helped you to
>> find that out.
>
> I actually don't know if it's evaluating it or not. Why on earth
> should it? If I change the program to print the original 'n', it is 42
> too. So it doesn't need to evaluate **x to get that dimension.

The C standard currently says:

The sizeof operator yields the size (in bytes) of its operand, which
may be an expression or the parenthesized name of a type. The size
is determined from the type of the operand. The result is an
integer. If the type of the operand is a variable length array type,
the operand is evaluated; otherwise, the operand is not evaluated
and the result is an integer constant.

The idea that the operand is "evaluated" is problematic. For example,
if the argument is a parenthesized type name, it's not clear what it
means to "evaluate" it. And there are cases (mostly contrived) where
the rule results in side effects that aren't actually necessary to
determine the size.

If I write:

int n = rand() % 10 + 1;
int vla[n];
printf("%zu\n", sizeof vla);

then the standard says that the expression `vla` is "evaluated". Since
it's of array type, that would logically involve retrieving the values
of each of its elements (there's no array-to-pointer conversion in this
context), which would have undefined behavior because they're
uninitialized. It's fairly clear that wasn't the intent; the only thing
that needs to be evaluated is the implicit metadata that gives the size
of the array.

Jens Gustedt has written a proposal to address this, probably in C26.
See <https://www.open-std.org/jtc1/sc22/wg14/www/docs/n3187.htm>.

In practice, applying sizeof to a VLA type, or to a named object of VLA
type, doesn't create any conceptual problems, and those are by far the
most common cases.

When a variable length array type is created, its length is determined
when execution reaches the definition, and the compiler generates code
to implicitly store that information somewhere for later use. If the
length expression happens to be the name of an object, any later changes
to the value of the object do not affect the VLA type or its size or
length; I suggest you stop being surprised by that fact. Applying sizeof
to a VLA type or object retrieves the stored size.

[...]

--
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 1/4/24 13:15, Bart wrote:
>
>    for (i = 0; i<N; ++N)
>      ... Do something with A ...

And do nothing for the first element, big win.

--
+---------------------------------------------------------------------+
| https://tube.interhacker.space/a/tth/video-channels |
+---------------------------------------------------------------------+

On 05/01/2024 19:42, Kaz Kylheku wrote:
> On 2024-01-05, Keith Thompson <Keith.S.Thompson+u@gmail.com> wrote:
>> When you wrote "in Linux", I wondered if you were being imprecise, but
>> in fact that code is in the Linux kernel.
>>
>> That means the macros aren't directly available to normal C code, but
>> you can always copy their definitions (*if* you're using a compiler
>> that supports the __builtin_types_compatible_p extension).
>
> You can always copy their definitions, if you're using a compiler
> that doesn't arbitrarily define __GNUC__ without providing the
> associated behaviors:
>
> #ifdef __GNU__
>
> // define array_size in the Linux kernel way
>
> #else
>
> #define arrray_size(x) (sizeof (x)/sizeof *(x))
>
> #endif
>
> If you regularly build the code with a compiler that provides GNU
> extensions (like as part of your CI), you're covered, even if you're
> going to production with something else.
>
> I use C++ this way in C projects; I have some macro features that
> provide extra checks under C++. I get the benefit even if I just
> compile the code as C++ only once before every release.
>

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

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

On 05/01/2024 20:33, Bart wrote:

>
> And yet, despite it having no problems according to you, people still
> feel the need to create macros like ARRAY_SIZE.
>
> So I'm puzzled. Why do they do that? What imaginary problem (according
> to you) do they solve?
>

People are different, and like to do things different ways. I would be
a boring world if everyone solved the same problems or challenges
identically! Some people put the milk in their cup before their tea,
and some people put the tea in before the milk. Some drink their tea
without milk, some drink just the milk, some vary their habits, some
care a great deal and some don't care at all. Would you expect a
tea-before-milk fanatic to justify how a milk-before-tea fanatic thinks?

This is no different. Some people like to use a macro. Some people
like to write it out explicitly in the code. Some people like to use
other methods, such as referring to the constant used to define the
array. Some people like to use a language that provides an operator for
the task, or where they can define their own functions for the job.

Has your use of your own personal languages and tools over the years
made you so insular that you can't understand that different people have
different preferences?

On 05/01/2024 23:19, Bart wrote:
> On 05/01/2024 14:05, David Brown wrote:
>> On 05/01/2024 02:53, Bart wrote:
>
>>> It doesn't need to take a heavy-handed approach like C++ or Python.
>>>
>>
>> One option for a useful array length operator/function/macro is a
>> simple and limited feature that works for arrays of known size and
>> gives a hard (compile-time) error when the size is not known.  The one
>> you have in your own language covers most of that, except for the
>> insanity of evaluating to 0 when given a pointer/reference to an
>> "unbounded" array.
>
> It gives zero because that is actually the compile-time type of the
> array. But it is low priority because it is never used that way.
>

That's the kind of potentially confusing short-cut you can make when
only you ever use the language. It is also fine for when people make
their own array_length macros for use in their own code. When you know
all the details of the operator/macro/function, and you are the only one
using it, it's okay if the specification is weird and unhelpful for some
cases. It's a different matter entirely if you are making something
that other people will use.

>
> In C, sizeof() is usually compile-time, except when used on VLAs, and
> here, as usual for VLAs, it is a lot more complicated than you'd think:
>

No it is not. I don't think "garbage in, garbage out" is a complicated
concept. You can write pathological shit in any language and get
meaningless results out - it has no bearing on anything in real code.
(It can be fun to play around with, but it does not mean there is a
problem with the language feature.)

On 06/01/2024 09:09, David Brown wrote:
> On 05/01/2024 23:19, Bart wrote:
>> On 05/01/2024 14:05, David Brown wrote:
>>> On 05/01/2024 02:53, Bart wrote:
>>
>>>> It doesn't need to take a heavy-handed approach like C++ or Python.
>>>>
>>>
>>> One option for a useful array length operator/function/macro is a
>>> simple and limited feature that works for arrays of known size and
>>> gives a hard (compile-time) error when the size is not known.  The
>>> one you have in your own language covers most of that, except for the
>>> insanity of evaluating to 0 when given a pointer/reference to an
>>> "unbounded" array.
>>
>> It gives zero because that is actually the compile-time type of the
>> array. But it is low priority because it is never used that way.
>>
>
> That's the kind of potentially confusing short-cut you can make when
> only you ever use the language.  It is also fine for when people make
> their own array_length macros for use in their own code.  When you know
> all the details of the operator/macro/function, and you are the only one
> using it, it's okay if the specification is weird and unhelpful for some
> cases.  It's a different matter entirely if you are making something
> that other people will use.
>
>>
>> In C, sizeof() is usually compile-time, except when used on VLAs, and
>> here, as usual for VLAs, it is a lot more complicated than you'd think:
>>
>
> No it is not.  I don't think "garbage in, garbage out" is a complicated
> concept.  You can write pathological shit in any language and get
> meaningless results out - it has no bearing on anything in real code.
> (It can be fun to play around with, but it does not mean there is a
> problem with the language feature.)

And yet, in my example, lccwin32 gave the wrong result, and in one case
crashed. (I no longer have other smaller C compilers to try out.)

It suggests the problem is not trivial.

The concept is not that easy to get your head around either, the idea
that the variable aspects of a VLA are associated with its type, not its
value or instance.

In my example, there were no instances of any actual arrays, not even if
I declared an instance of one of the pointers involved, yet space had to
be allocated for its size. And I kept the type simple.

I remember also trying out VLAs within a struct, and there I got a wider
variance of results.

You can keep saying that VLAs are trivial to understand and implement; I
won't believe you.

On 06/01/2024 09:09, David Brown wrote:
> On 05/01/2024 23:19, Bart wrote:
>> On 05/01/2024 14:05, David Brown wrote:
>>> On 05/01/2024 02:53, Bart wrote:
>>
>>>> It doesn't need to take a heavy-handed approach like C++ or Python.
>>>>
>>>
>>> One option for a useful array length operator/function/macro is a
>>> simple and limited feature that works for arrays of known size and
>>> gives a hard (compile-time) error when the size is not known.  The
>>> one you have in your own language covers most of that, except for the
>>> insanity of evaluating to 0 when given a pointer/reference to an
>>> "unbounded" array.
>>
>> It gives zero because that is actually the compile-time type of the
>> array. But it is low priority because it is never used that way.
>>
>
> That's the kind of potentially confusing short-cut you can make when
> only you ever use the language.

I spent 10 mins trying to fix this today. So that '.len' on bounds
specified as `[]` rather than `[0]`, and not later set by init data,
would be an error.

Then I got stuck on examples like '[]int a = ()' and realised it's
tricky. And then I thought, why the hell am I doing this? A language
I've already used for a million lines of code.

Because somebody on the internet (who has never created and implemented
a real language AFAIK) told me so?

I don't claim it to be perfect, just that it does a better job than C.

At least it has '.len' and quite a few extra bits to do with fixed-size
arrays:

'M' C

Value arrays Y N
Ptr to array params Y N (also Y but non-idiomatic)
Pass-by-reference Y N

Index a pointer N Y
Deref an array N Y

0-based arrays Y Y
1-based Y N
N-based Y N

Number of bytes X.bytes sizeof(X)
T.bytes sizeof(T)

Array Length X.len sizeof(X)/sizeof(X[0])
T.len ?

Array Lower Bound X.lwb 0
T.lwb 0

Array Upper Bound X.upb sizeof(X)/sizeof(X[0])-1
T.upb ?

Table Indexing A[i,j] A[i][j] or j[A[i]] or j[i[A]]

Loop over bounds For i in A.bounds do
for (int i=0;
i<sizeof(A)/sizeof(A[0]); ++i)

Loop over values For x in A do
For i,x in A do # (both)
for (int i=0;
i<sizeof(A)/sizeof(A[0]); ++i) {
T x = A[i]; ...

Zero array clear A memset(A, 0, sizeof(A)/sizeof(A[0]));

Slices Y N

On 06/01/2024 12:53, Bart wrote:
> On 06/01/2024 09:09, David Brown wrote:
>> On 05/01/2024 23:19, Bart wrote:

> At least it has '.len' and quite a few extra bits to do with
fixed-size arrays:
>
> 'M' C
>
> Value arrays Y N
> Ptr to array params Y N (also Y but non-idiomatic)
> Pass-by-reference Y N
>
> Index a pointer N Y
> Deref an array N Y
>
> 0-based arrays Y Y
> 1-based Y N
> N-based Y N
>
> Number of bytes X.bytes sizeof(X)
> T.bytes sizeof(T)
>
> Array Length X.len sizeof(X)/sizeof(X[0])
> T.len ?
>
> Array Lower Bound X.lwb 0
> T.lwb 0
>
> Array Upper Bound X.upb sizeof(X)/sizeof(X[0])-1
> T.upb ?
>
> Table Indexing A[i,j] A[i][j] or j[A[i]] or j[i[A]]
>
> Loop over bounds For i in A.bounds do
> for (int i=0;
i<sizeof(A)/sizeof(A[0]); ++i)
>
> Loop over values For x in A do
> For i,x in A do # (both)
> for (int i=0;
i<sizeof(A)/sizeof(A[0]); ++i) {
> T x = A[i]; ...
>
> Zero array clear A memset(A, 0, sizeof(A)/sizeof(A[0]));

The C is wrong; it should be just sizeof(A).

You can see how sizeof or sizeof/sizeof features quite a bit in the
right-hand column, but even the shorter .len is little seen on the left.

It's easy to get it wrong or nor immediately notice (unless your
initials are SL of course).

On 06/01/2024 11:27, Bart wrote:
> On 06/01/2024 09:09, David Brown wrote:
>> On 05/01/2024 23:19, Bart wrote:
>>> On 05/01/2024 14:05, David Brown wrote:
>>>> On 05/01/2024 02:53, Bart wrote:
>>>
>>>>> It doesn't need to take a heavy-handed approach like C++ or Python.
>>>>>
>>>>
>>>> One option for a useful array length operator/function/macro is a
>>>> simple and limited feature that works for arrays of known size and
>>>> gives a hard (compile-time) error when the size is not known.  The
>>>> one you have in your own language covers most of that, except for
>>>> the insanity of evaluating to 0 when given a pointer/reference to an
>>>> "unbounded" array.
>>>
>>> It gives zero because that is actually the compile-time type of the
>>> array. But it is low priority because it is never used that way.
>>>
>>
>> That's the kind of potentially confusing short-cut you can make when
>> only you ever use the language.  It is also fine for when people make
>> their own array_length macros for use in their own code.  When you
>> know all the details of the operator/macro/function, and you are the
>> only one using it, it's okay if the specification is weird and
>> unhelpful for some cases.  It's a different matter entirely if you are
>> making something that other people will use.
>>
>>>
>>> In C, sizeof() is usually compile-time, except when used on VLAs, and
>>> here, as usual for VLAs, it is a lot more complicated than you'd think:
>>>
>>
>> No it is not.  I don't think "garbage in, garbage out" is a
>> complicated concept.  You can write pathological shit in any language
>> and get meaningless results out - it has no bearing on anything in
>> real code. (It can be fun to play around with, but it does not mean
>> there is a problem with the language feature.)
>
>
> And yet, in my example, lccwin32 gave the wrong result, and in one case
> crashed. (I no longer have other smaller C compilers to try out.)
>
> It suggests the problem is not trivial.

So what you are telling us is that a relatively simple and little-used
compiler has bugs in dealing with pathological cases of code
intentionally designed to be difficult and be far from any kind of
realistic code? Are we supposed to be surprised? I'm sure the lccwin32
author will be interested in the test case, because such extreme
corner-case testing is useful for finding bugs in software - but it is
only of interest to him and not to anyone actually writing C code. (And
in this case, since your code has UB, there is no such thing as a
correct result - and therefore no possibility of a wrong result.)

>
> The concept is not that easy to get your head around either, the idea
> that the variable aspects of a VLA are associated with its type, not its
> value or instance.

If you find VLA's difficult, don't use them. Even if you were
interested in making your tools compliant, they are optional from C11
onwards. Since you are the only person who uses your tools, and you
won't write C code with VLAs, you have nothing to lose by ignoring them
entirely.

>
> In my example, there were no instances of any actual arrays, not even if
> I declared an instance of one of the pointers involved, yet space had to
> be allocated for its size. And I kept the type simple.
>
> I remember also trying out VLAs within a struct, and there I got a wider
> variance of results.
>
> You can keep saying that VLAs are trivial to understand and implement; I
> won't believe you.
>

OK. Don't believe me.