On 07/01/2024 03:32, Kaz Kylheku wrote:
> On 2024-01-06, Bart <bc@freeuk.cm> wrote:
>> 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.
>
> That exact reasoning can be used to reject new features from C,
> like an operator for the number of elements in an array.
>
> People have written billions of lines of C without it!
>

That's a feature for which there is a need.

The other is requiring a diagnostic, somewhat less useful if you just
want to loop over an array without it looking like a dog's dinner.

So, C has distinct concepts of 'zero-length' array and 'unbounded
array', so that sizeof/sizeof on the latter generates a diagnostic.

Great. But you don't get one here:

int a;
int* p=&a;

printf("%zu\n", sizeof(p)/sizeof(p[0]));

'p' is neither a zero-length nor unbounded array, but the array-length
idiom still works. This program will likely print '2' on 64-bit machines.

If I try the same thing:

int a
ref int p := &a

println p.len

it gives an error. But I can also get C's behaviour if I really wanted
to do that:

println p.bytes/p^.bytes

This shows '1' (int is 64 bits).

There /is/ a significant difference between sizeof and lengthof;
emulating the latter with sizeof doesn't really cut it.

On 07/01/2024 02:14, Lawrence D'Oliveiro wrote:
> On Sun, 7 Jan 2024 01:26:29 +0000, Bart wrote:
>
>> And then what? LIBFFI is still hard to use.
>
> Using Python’s ctypes module, which is basically built on top of libffi, I
> have not found to be that hard at all.
>
> Looking at the sizes of those particular Python wrappers I mentioned:
>
> Cairo graphics <https://gitlab.com/ldo/qahirah> -- 8500 lines
> D-bus <https://gitlab.com/ldo/dbussy/> -- 11,000 lines
> inotify <https://gitlab.com/ldo/inotipy> -- under 600 lines

While I have my own C alternative language, I also have my own Python
alternative language, although it is smaller, lower level and less
dynamic. On this scale:

C-1---2---------Python

my languages might occupy positions 1 and 2.

> Using Python’s ctypes module, which is basically built on top of
libffi, I
> have not found to be that hard at all.

OK, so you're using:

* A LIBFFI module that someone one else has written

* A language (Python) that someone else has implemented (and
originally, someone else has designed)

* An extension (Ctypes) that is already done by somebody

* A set of FFI bindings to some external library that someone has
already taken the trouble to create

* On top of that, you're probably using a C compiler that someone
else has implemented (used to build LIBFFI etc and which has
likely been used to build Python)

* Plus a bunch of dependencies that others have taken care of (build
systems etc)

So it is not surprising that:

> I have not found to be that hard at all.

Is there much left for you to do?

I find it a little bit harder because I design and implement my own
languages, I need to create my own bindings to libraries, and do all
that without any dependencies other than those libraries I'm trying to use.

And yet my dynamic language's FFI is much easier to use than most
scripting languages. The FFI is built in as is support the low-level
types needed. No extension module is needed.

I can do this from interpreted, dynamic code (the printf is predefined
but I'm showing here how it is predefined:

importdll msvcrt =
func printf(stringz, ...)int32
end

printf("Hello, World!\n")

(When I used to run it on Linux, the 'msvcrt' library was mapped
internally to 'libc.so.6').

On 07/01/2024 01:58, Lawrence D'Oliveiro wrote:
> On Sat, 06 Jan 2024 16:40:03 -0800, Keith Thompson wrote:
>
>> C uses a "declaration follows usage" rule (though not with 100%
>> consistency).
>
> And putting the function result before the argument types turns out to
> cause trouble when carried over to C++, when you try to express
> dependencies between them. So they had to add a Pascal-style alternative
> syntax, with the function result declared after the arguments.
>
> Even pointer dereferencing should have been done with a postfix, not a
> prefix operator. Consider why you need “->”: it’s purely syntactic sugar
> to make things like
>
> (*a).b
>
> less awkward as
>
> a->b
>
> Whereas in Pascal, for example, there is no need for any alternative
> syntax to
>
> a^.b

There are two kinds of programming languages. There are ones that that
exist long enough and are popular enough for people to see that the
original design was not perfect and could have been done differently,
and languages that die away to irrelevance before long. No one thinks
the C way of doing things, or its syntax, is perfect - but a lot of
people think it is good enough that they can live with it.

A language has to either stick with the sub-optimal choices it made long
ago, as C has done, or it can try to make changes and suffers from
having to support new and old ideas, as C++ has done. Each technique
has its advantages and disadvantages.

On 07/01/2024 03:28, Keith Thompson wrote:
> Bart <bc@freeuk.cm> writes:

>> You might call it metadata, but being a type doesn't come to
>> mind. What would be the point of that; what could you do with that
>> type?
>
> You could define objects of the type,

Only if accessible. You say typeof isn't available.

> you could apply sizeof to it,

Same here, but sizeof can also apply to the expression.

> you
> could define a type that points to it, or that's an array of it. You
> know, all the stuff you can normally do with a type

My example stored 'with the variable' has an anonymous type. If might be
something that only exists within the compiler, a generic 'VLA' type
since the size is not known until runtime.

It would be extraordinary for C to actually have tangible type objects
at runtime since for me, types in C are a compile-time concept.

But we're talking about a number.

You claim that conceptually, that number is considered part of the type.

>> Suppose you had a counted string variable S, currently set to "ABC" so
>> that its length (which you say is naturally part its type) is 3.
>
> What exactly do you mean by a "counted string variable"? If you mean
> you have a variable whose current value is "ABC", and you can update it
> so its value becomes "ABCDEF", > then of course the count has to be associated with the object.

It could be fixed or variable. But it's interesting that you consider
the two to be different.

Why can't you then consider a VLA that is capable of changing its size,
but happens to keep the same one over its lifetime. Why should that then
change that size from variable-associated to type-associated?

> typedef int rvla[rand() % 10 + 1];
> rvla A;
> rvla B;
>
> A and B are of the same type and therefore have the same length.

I'm sorry, it's still bizarre to me. I consider a length to be part of a
type when it's compile-time fixed value, /and is also defined with the
type/, for example:

type float vector[4];

But never when the size is variable, whether that means determined at
runtime and never changes, or determined at runtime but can grow. What
might be recorded is the fact that the size is a variable quantity that
needs further input.

> The
> obvious way to implement that would be to store the length in an
> anonymous object associated with the type. You're saying you'd expect
> the size be associated with A and with B, not with the type.
>
> Given:
>
> int row_count = 1000;
> int col_count = 2000;
> int vla_2d[row_count][col_count];
>
> you have 1000 rows of 2000 elements each. Would you expect to create
> 1000 implicit objects, one for each row, each holding the value 2000?

I don't know. I haven't implemented VLAs, and I don't have an equivalent
feature at this level of language.

At the next level up, if row_count and col_count are really not known
until runtime (your example would be better off as enums), then yes,
there would be 1000 rows, and each row is a 2000-element array
containing its length.

(Since in that language, each row can be a different length, or even a
different type entirely.)

What I would look at would be a special multi-dimensional type (say like
a 2D slice), which stores 2 or more dimensions, and which would allow
all the data to be allocated in a contiguous block.

I don't support that right now. But don't feel so smug, because when I
tried your example, it crashed.

Since that data structure needs 8MB of stack. Here you could anticipate
that; but often you can't. That's one big problem with VLAs.

After scaling down the task to 100x200, then gcc and tcc gave me a size
of 80,000. lccwin gave me 320,000.

Meanwhile my dynamic language can effortlessly create that 1000 x 2000 x
int32 data structure, even though it uses 8048048 bytes in all instead
of C's 8000000 plus whatever overheads the VLA needs, assuming a big
enough stack, or a smart enough implementation that will switch to heap
as needed.

On 07/01/2024 14:48, David Brown wrote:
> On 07/01/2024 01:58, Lawrence D'Oliveiro wrote:
>> On Sat, 06 Jan 2024 16:40:03 -0800, Keith Thompson wrote:
>>
>>> C uses a "declaration follows usage" rule (though not with 100%
>>> consistency).
>>
>> And putting the function result before the argument types turns out to
>> cause trouble when carried over to C++, when you try to express
>> dependencies between them. So they had to add a Pascal-style alternative
>> syntax, with the function result declared after the arguments.
>>
>> Even pointer dereferencing should have been done with a postfix, not a
>> prefix operator. Consider why you need “->”: it’s purely syntactic sugar
>> to make things like
>>
>>     (*a).b
>>
>> less awkward as
>>
>>      a->b
>>
>> Whereas in Pascal, for example, there is no need for any alternative
>> syntax to
>>
>>      a^.b
>
> There are two kinds of programming languages.  There are ones that that
> exist long enough and are popular enough for people to see that the
> original design was not perfect and could have been done differently,
> and languages that die away to irrelevance before long.  No one thinks
> the C way of doing things, or its syntax, is perfect - but a lot of
> people think it is good enough that they can live with it.
>
> A language has to either stick with the sub-optimal choices it made long
> ago, as C has done, or it can try to make changes and suffers from
> having to support new and old ideas, as C++ has done.  Each technique
> has its advantages and disadvantages.

I used to have that a^.b syntax (deref pointer then index).

But for a few years I've relaxed that so that the deref is done
automatically:

a^.b becomes a.b
a^[b] becomes a[b]
a^(b) becomes a(b)

AFAICS, C can could also relax the (*a).b or a->b synax so that you just
do a.b. You could do that today, and nothing changes. (Of course it
would need a compiler update).

The others don't affect C so much: pointers to arrays, that would
require (*a)[i], are rarely used. Everybody uses a[i] anyway with 'a'
being a pointer to the first element.

And it already allows, via some mysterious rules, for (*a)(b) to be
written as a(b).

On Sun, 7 Jan 2024 12:14:24 +0000, Bart wrote:

> Is there much left for you to do?

Yes. Make it work as though it were written for Python programmers.

For example, the Cairo graphics API requires you to pass X- and Y-
coordinates as separate arguments to every function. I wrap them up into a
single “Vector” type, with its own arithmetic operators. For example,
compare what you would have to do in C:

x0 = 0;
y0 = scope_radius;
x1 = x0 * cos(- trace_width_angle) - y0 * sin(- trace_width_angle);
y1 = x0 * sin(- trace_width_angle) + y0 * cos(- trace_width_angle);
cairo_line_to(ctx, x1, y1);

with what my Python wrapper allows:

ctx.line_to(Vector(0, - scope_radius).rotate(- trace_width_angle))

I had to write the code to do that.

On 07/01/2024 19:29, Lawrence D'Oliveiro wrote:
> On Sun, 7 Jan 2024 12:14:24 +0000, Bart wrote:
>
>> Is there much left for you to do?
>
> Yes. Make it work as though it were written for Python programmers.
>
> For example, the Cairo graphics API requires you to pass X- and Y-
> coordinates as separate arguments to every function. I wrap them up into a
> single “Vector” type, with its own arithmetic operators. For example,
> compare what you would have to do in C:
>
> x0 = 0;
> y0 = scope_radius;
> x1 = x0 * cos(- trace_width_angle) - y0 * sin(- trace_width_angle);
> y1 = x0 * sin(- trace_width_angle) + y0 * cos(- trace_width_angle);
> cairo_line_to(ctx, x1, y1);
>
> with what my Python wrapper allows:
>
> ctx.line_to(Vector(0, - scope_radius).rotate(- trace_width_angle))
>
> I had to write the code to do that.

I was interested in the FFI used by CPython as I'd never seen it in
action. The setup, as used in your link, is something like this:

cairo = ct.cdll.LoadLibrary(LIBNAME["cairo"]) # LIBNAME is a dict
...
cairo.cairo_line_to.argtypes = (ct.c_void_p, ct.c_double, ct.c_double)
cairo.cairo_line_to.restype = None
...

c_double etc are from 'ctypes', and 'ct' is an alias for that module.

So it's all done with libraries, classes, tuples and attributes.

But so far, no need for LIBFFI; that's only needed when you call that
function.

In my dynamic language, the equivalent set up code is:

type cairo_t = ref void # I guess cairo_t is opaque

importdll cairo = # don't know the exact dll name
...
proc cairo_line_to(cairo_t ctx, r64 x, y)
...
end

This is called as 'cairo_line_to(...)'. Actually the syntax used in this
example is exactly the same as my static language.

I'm using parameter names so that, with more elaborate functions, I can
use keyword arguments. I can also define default values so that not all
arguments need be supplied.

In the dynamic version, both DLL and individual functions are loaded
on-demand; that is, the first time a library or function is needed. The
code runs even without the DLL if I don't call any functions from it.

---

So, this is what /I/ do, provide simple, easy-to-use features that other
languages make a bit of a meal over.

From your library:

def line_to(self, p) :
...
#end line_to

I see you have the same opinion of Python block syntax as I do. Nim does
the same thing; I had to add exactly those #end comments as I kept
getting things lined up wrong.

Bart <bc@freeuk.cm> writes:
> On 07/01/2024 03:32, Kaz Kylheku wrote:
>> On 2024-01-06, Bart <bc@freeuk.cm> wrote:
>>> 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.
>> That exact reasoning can be used to reject new features from C,
>> like an operator for the number of elements in an array.
>> People have written billions of lines of C without it!
>
> That's a feature for which there is a need.

Not really. It would be convenient. It's not absolutely *needed*, as
demonstrated by the fact that "People have written billions of lines of
C without it!".

> The other is requiring a diagnostic, somewhat less useful if you just
> want to loop over an array without it looking like a dog's dinner.
>
> So, C has distinct concepts of 'zero-length' array and 'unbounded
> array', so that sizeof/sizeof on the latter generates a diagnostic.

No, it doesn't. C doesn't have zero-length arrays. A fixed-length
array with a length of 0:
int arr[0];
is a constraint violation. A VLA with a length of 0:
int n = 0;
int vla[n];
has undefined behavior. (You can probably find compilers that support
either or both as an extension.)

I don't know what you mean by "unbounded array".

Every array object has a length that's determined no later than when the
object's lifetime begins, and that cannot be changed during the object's
lifetime. All C array objects are bounded.

> so that sizeof/sizeof on the latter generates a diagnostic.
>
> Great. But you don't get one here:
>
> int a;
> int* p=&a;
>
> printf("%zu\n", sizeof(p)/sizeof(p[0]));
>
> 'p' is neither a zero-length nor unbounded array, but the array-length
> idiom still works. This program will likely print '2' on 64-bit
> machines.

Yes, we've discussed that issue repeatedly in this thread.

[information about your own language snipped]

Yes, some languages other than C have better support for this than C
does.

> There /is/ a significant difference between sizeof and lengthof;
> emulating the latter with sizeof doesn't really cut it.

#define LENGTHOF(arr) (sizeof (arr) / sizeof (arr)[0] )

This works perfectly well if the programmer ensures that it's applied
only to an array expression, typically the name of an array object.
I've used it myself, either via a similar macro or directly, and never
had a problem with it.

Yes, it fails to diagnose an error and gives a bogus result if you apply
it to a pointer object or expression. This issue has been repeatedly
acknowledged in this thread, including discussions of how to fix it if
you can use a gcc-specific extension. What more is there to say about
it?

--
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 07/01/2024 22:41, Keith Thompson wrote:
> Bart <bc@freeuk.cm> writes:

>> So, C has distinct concepts of 'zero-length' array and 'unbounded
>> array', so that sizeof/sizeof on the latter generates a diagnostic.

> No, it doesn't. C doesn't have zero-length arrays. A fixed-length
> array with a length of 0:
> int arr[0];
> is a constraint violation.

So you can't have an array with an empty initialiser list either?

I must say you have to try quite hard to get a diagnostic for those!

So what happens if you have a generated data block for example,
containing N items; it only works when N is at least 1? What are you
supposed to do when N is zero?

It sounds quite a limitation.

> I don't know what you mean by "unbounded array".

One without a bound specified? C might call it 'incomplete', even though
the syntax is common; this is one example of many:

void F(int A[]) {}

On Sun, 7 Jan 2024 22:41:11 +0000, Bart wrote:

> I'm using parameter names so that, with more elaborate functions, I can
> use keyword arguments. I can also define default values so that not all
> arguments need be supplied.

Python has all that as standard.

But you can’t define custom overloads for operators as in Python, can you?
That’s important to the definitions of my “Vector” and “Matrix” types,
just for example.

> importdll cairo = # don't know the exact dll name

On Linux, that‘s “libcairo.so.2”. Note the “.2” on the end. That gets
incremented if there are any incompatible ABI changes made. Windows seems
to have no mechanism for this.

> From your library:
>
> def line_to(self, p) :
> ...
> #end line_to
>
> I see you have the same opinion of Python block syntax as I do.

I have custom Emacs commands to jump between lines with the same
indentation level. That lets me move quickly between the beginning and
ending of a nested block. I also have commands to jump to the beginning/
end of the next outer indentation level.

Bart <bc@freeuk.cm> writes:
> On 07/01/2024 03:28, Keith Thompson wrote:
>> Bart <bc@freeuk.cm> writes:
>>> You might call it metadata, but being a type doesn't come to
>>> mind. What would be the point of that; what could you do with that
>>> type?
>> You could define objects of the type,
>
> Only if accessible. You say typeof isn't available.

The C standard says typeof isn't available. It has nothing to do with
me.

>> you could apply sizeof to it,
>
> Same here, but sizeof can also apply to the expression.

Yes. So what? You asked what you could do with the type. Perhaps
there was some other point to your question that I missed.

>> you
>> could define a type that points to it, or that's an array of it. You
>> know, all the stuff you can normally do with a type
>
> My example stored 'with the variable' has an anonymous type. If might
> be something that only exists within the compiler, a generic 'VLA'
> type since the size is not known until runtime.
>
> It would be extraordinary for C to actually have tangible type objects
> at runtime since for me, types in C are a compile-time concept.

Nobody said anything about "tangible type objects".

Yes, types in C are a compile-time concept. But VLA types have
information associated with them that is available only during
execution.

> But we're talking about a number.
>
> You claim that conceptually, that number is considered part of the type.

Yes, that's clear from how VLAs are specified by the standard.

>>> Suppose you had a counted string variable S, currently set to "ABC" so
>>> that its length (which you say is naturally part its type) is 3.
>> What exactly do you mean by a "counted string variable"? If you mean
>> you have a variable whose current value is "ABC", and you can update
>> it so its value becomes "ABCDEF",
> then of course the count has to be associated with the object.
>
> It could be fixed or variable. But it's interesting that you consider
> the two to be different.

You've lost me. Again, please explain what you mean by "counted string
variable".

> Why can't you then consider a VLA that is capable of changing its
> size, but happens to keep the same one over its lifetime.

I honestly don't know what that means.

When you say "a VLA", are you talking about an object or a type?

I can certainly consider a VLA-like object that's "capable of changing
its size" (C++'s std::vector is something like that), but C has no such
feature, so there's no point in discussing it here.

> Why should
> that then change that size from variable-associated to
> type-associated?

Again, the length of a VLA type is logically associated with the type.
An implementation could associate it, at run time, with each individual
object, but that would be inefficient in many cases, such as when there
are multiple objects of the same VLA type. I can see no benefit at all
in associating the length with each object rather than with the type.

And that association isn't even visible to the programmer. `sizeof vla`
and `sizeof (vla_type)` just work; I don't need to care how.

>> typedef int rvla[rand() % 10 + 1];
>> rvla A;
>> rvla B;
>> A and B are of the same type and therefore have the same length.
>
> I'm sorry, it's still bizarre to me. I consider a length to be part of
> a type when it's compile-time fixed value, /and is also defined with
> the type/, for example:
>
> type float vector[4];
>
> But never when the size is variable, whether that means determined at
> runtime and never changes, or determined at runtime but can grow. What
> might be recorded is the fact that the size is a variable quantity
> that needs further input.

Why?

C *does not have* VLAs whose type is "determined at runtime but can
grow". Logically associating the length of a VLA type with the type
*works*.

Here's a small non-executable example:

#include <stddef.h>

size_t foo_size;
size_t bar_size;

void func(void) {
int n = 42;
typedef int vla[n];
vla foo;
vla bar;
foo_size = sizeof foo;
bar_size = sizeof bar;
}

When I compile it with "gcc -S", I get assembly code that appears to
store the value 42 just once:
movl $42, -52(%rbp)
and retrieves that value from the same place to copy it to foo_size and
bar_size. (I'm not an expert in x86_64 assembly language, but I'm
fairly sure that's what's going on.) Please take a look at the
generated assembly code yourself, using any C compilers you like. Do
any of them store the sizes of foo and bar separately? Why do you think
it would be better to do so?

Remember that since foo and bar are of the same type, it is not possible
for them to have different lengths, so compilers don't need to allow
for that possibility.

>> The
>> obvious way to implement that would be to store the length in an
>> anonymous object associated with the type. You're saying you'd expect
>> the size be associated with A and with B, not with the type.
>> Given:
>> int row_count = 1000;
>> int col_count = 2000;
>> int vla_2d[row_count][col_count];
>> you have 1000 rows of 2000 elements each. Would you expect to
>> create
>> 1000 implicit objects, one for each row, each holding the value 2000?
>
> I don't know. I haven't implemented VLAs, and I don't have an
> equivalent feature at this level of language.

So you don't really understand C's VLAs. That's fine, but then why do
you insist on a specific implementation technique, one that in practice
doesn't make sense?

If some non-C language supports dynamic array objects whose size can change
during their lifetime, then of course the size would be associated with
the object, not with the type. C has no such feature.

> At the next level up, if row_count and col_count are really not known
> until runtime (your example would be better off as enums), then yes,
> there would be 1000 rows, and each row is a 2000-element array
> containing its length.

If row_count and col_count were enums, they would be constants, and
vla_2d would not be a VLA. The whole point is that we're talking about
VLAs.

So you think each of the 1000 rows needs to store its own length of 2000
separately? All 1000 rows are of the same type, and are guaranteed to
have the same length. All the elements of *any* C array are of the same
type and have the same size.

> (Since in that language, each row can be a different length, or even a
> different type entirely.)

What language?

Did you think I was talking about some hypothetical C-like language?
I'm talking about C, and only C; my only assumption is that the
implementation supports VLAs, which are an optional feature in C11 and
later. My example is pure C code.

> What I would look at would be a special multi-dimensional type (say
> like a 2D slice), which stores 2 or more dimensions, and which would
> allow all the data to be allocated in a contiguous block.
>
> I don't support that right now. But don't feel so smug, because when I
> tried your example, it crashed.
>
> Since that data structure needs 8MB of stack. Here you could
> anticipate that; but often you can't. That's one big problem with
> VLAs.

Ok, that's a valid point. Many C implementations place relatively small
limits on stack size (in C terms, the space allocated for objects with
automatic storage duration). I didn't think of that when I wrote my
3-line example. (8,000,000 bytes happens to be barely within the stack
size limit on my system.)

(You can also allocate VLAs on the heap, which typically has less
stringent restrictions, but let's not get into that.)

Yes, VLAs can result in stack overflows. So can ordinary fixed-length
arrays. If you define a VLA that you know can't be longer than N
elements, then that's no more dangerous that defining an ordinary array
with a length of exactly N.

> After scaling down the task to 100x200, then gcc and tcc gave me a
> size of 80,000. lccwin gave me 320,000.

OK, here's a complete program with the VLA scaled down. (200 int
objects shouldn't exceed the stack size limit on any reasonable
implementation.)

#include <stdio.h>
int main(void) {
int row_count = 10;
int col_count = 20;
int vla_2d[row_count][col_count];
printf("sizeof vla_2d[0][0] = %zu\n", sizeof vla_2d[0][0]);
printf("sizeof vla_2d[0] = %zu\n", sizeof vla_2d[0]);
printf("sizeof vla_2d = %zu\n", sizeof vla_2d);
printf("rows : %zu\n",
sizeof vla_2d / sizeof vla_2d[0]);
printf("elements per row : %zu\n",
sizeof vla_2d[0] / sizeof vla_2d[0][0]);
printf("Total elements : %zu\n",
sizeof vla_2d / sizeof vla_2d[0][0]);
}

Bart <bc@freeuk.cm> writes:
> On 07/01/2024 22:41, Keith Thompson wrote:
>> Bart <bc@freeuk.cm> writes:
>
>>> So, C has distinct concepts of 'zero-length' array and 'unbounded
>>> array', so that sizeof/sizeof on the latter generates a diagnostic.
>
>> No, it doesn't. C doesn't have zero-length arrays. A fixed-length
>> array with a length of 0:
>> int arr[0];
>> is a constraint violation.
>
> So you can't have an array with an empty initialiser list either?

An empty initializer list is a syntax error. (It will be allowed in
C23.)

> I must say you have to try quite hard to get a diagnostic for those!

Why must you say that when it isn't true?

$ cat c.c
int arr[] = {};
$ gcc -c c.c
$ gcc -std=c17 -pedantic c.c
c.c:1:13: warning: ISO C forbids empty initializer braces [-Wpedantic]
1 | int arr[] = {};
| ^
c.c:1:5: error: zero or negative size array ‘arr’
1 | int arr[] = {};
| ^~~
$

> So what happens if you have a generated data block for example,
> containing N items; it only works when N is at least 1?

Yes.

> What are you
> supposed to do when N is zero?

Something else, I suppose.

> It sounds quite a limitation.

Since I have no agenda here, I won't try to quantify how much of a
limitation it is.

>> I don't know what you mean by "unbounded array".
>
> One without a bound specified? C might call it 'incomplete', even
> though the syntax is common; this is one example of many:
>
> void F(int A[]) {}

That's a particularly bad example, since A, being a parameter, is of
pointer type.

int[] is an incomplete type. You can't create objects of incomplete
types, and you can't apply sizeof to incomplete types.

The C standard uses the word "unbounded" a few times, but only in
reference to mathematical functions, not arrays.

Incomplete array types have no particular relationship to VLAs.

When you brought up "unbounded arrays", you seemed to be talking about
array objects whose length can change during their lifetime. C has no
such feature. Do you understand that?

--
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 07/01/2024 23:51, Keith Thompson wrote:
> Bart <bc@freeuk.cm> writes:

> Here's a small non-executable example:
>
> #include <stddef.h>
>
> size_t foo_size;
> size_t bar_size;
>
> void func(void) {
> int n = 42;
> typedef int vla[n];
> vla foo;
> vla bar;

This isn't how VLAs are typically used. I think there are three kinds of
people when it comes to VLAs:

(1) Those who don't know about them and only inadvertently create
them because the dimension is a variable not a compiler-time
expression

(2) Those who know about VLAs, but who will supply the dimensions to
the variable declaration

(3) A minority who know that VLA dimensions can also be used in
typedefs.

In the case of (2), what happens is that some storage is reserved for a
size. A clever compiler can use one lot of storage if it realises
multiple variables use that same size.

But whatever it is, you saying that bit of storage is to do with the
type; I'm saying it's to do with the instance of that type. In the end
it probably doesn't matter.

It does however still bother me that a mere typedef, not actually used
for anything, could take up runtime resources.

>> At the next level up, if row_count and col_count are really not known
>> until runtime (your example would be better off as enums), then yes,
>> there would be 1000 rows, and each row is a 2000-element array
>> containing its length.
>
> If row_count and col_count were enums, they would be constants, and
> vla_2d would not be a VLA. The whole point is that we're talking about
> VLAs.

This is actually an important point. Many examples of VLAs I've seen are
exactly like your example, due to point (1) above.

> Yes, VLAs can result in stack overflows. So can ordinary fixed-length
> arrays.

VLAs can do so much more easily:

void F(int n) { int A[n];}

What are the likely values of n? Without VLAs you have to knowingly use
large fixed values of n, and/or rely on deep recursion, to get overflow.

> If you define a VLA that you know can't be longer than N
> elements, then that's no more dangerous that defining an ordinary array
> with a length of exactly N.

The compiler likely doesn't know. Some compilers (like gcc on Windows)
use a call like __checkstk() to allocate local storage which it either
knows will exceed 4KB, or it might do (like a VLA, even if n turns out
to be only 3).

> This is clearly a bug in lccwin. Feel free to report it to jacob navia
> and/or post to comp.compilers.lcc. I don't think he'd be interested in
> hearing about it from me.

This is important too. If someone that experienced with implementing C
has some trouble, then I've got no chance.

(BTW why did VLAs become optional from C11?)

>> Meanwhile my dynamic language [...]
>
> is irrelevant. If you want to discuss it, I suggest starting a thread
> in comp.lang.misc. I might even participate. (Your point in bringing
> up your own languages seems to be that other languages do some things
> better than C does.

Actually I was pointing out a deficiency in both my languages in lack of
support for multi-dimensional arrays of runtime dimensions, so that the
data cannot be allocated in a single block.

C apparently allows this in VLAs, and in passing such arrays to
functions where the dimensions are provided via parameters.

I consider this complex and out of place at this level of language.
(Especially given there more basic features that are missing.)

Bart <bc@freeuk.cm> writes:
> On 07/01/2024 23:51, Keith Thompson wrote:
>> Bart <bc@freeuk.cm> writes:
>
>> Here's a small non-executable example:
>> #include <stddef.h>
>> size_t foo_size;
>> size_t bar_size;
>> void func(void) {
>> int n = 42;
>> typedef int vla[n];
>> vla foo;
>> vla bar;
>
> This isn't how VLAs are typically used. I think there are three kinds
> of people when it comes to VLAs:
>
> (1) Those who don't know about them and only inadvertently create
> them because the dimension is a variable not a compiler-time
> expression
>
> (2) Those who know about VLAs, but who will supply the dimensions to
> the variable declaration
>
> (3) A minority who know that VLA dimensions can also be used in
> typedefs.

I haven't seen enough VLA-using code "in the wild" to know what kind of
usage is typical. (The fact that they were made optional in C11 might
suggest that there wasn't much demand for the feature, or at least that
the committee thought so.)

I do suspect, without evidence, that something like:
const int len = 100;
int arr[len];
is fairly common (len is not a constant expression but some programmers
might think it is).

But I'm mainly concerned with what usages are supported by the language.

> In the case of (2), what happens is that some storage is reserved for
> a size. A clever compiler can use one lot of storage if it realises
> multiple variables use that same size.

Especially if multiple variables are of the same type.

> But whatever it is, you saying that bit of storage is to do with the
> type; I'm saying it's to do with the instance of that type. In the end
> it probably doesn't matter.
>
> It does however still bother me that a mere typedef, not actually used
> for anything, could take up runtime resources.

It's not the typedef that takes up runtime resources. It's the array
type to which the typedef refers.

Consider this:
printf("%zu\n", sizeof (int[rand() % 10 } 1]);
That's a perfectly valid usage. The result of the length expression has
to be stored somewhere, and there is no object it can be associated
with.

Any time you define a VLA type, the length has to be determined and
stored. Since the compiler has to generate code to do that anyway, why
on Earth do you think it would be useful to *also* associate the length
with individual objects?

Earlier in this thread, you seemed to have the misconception that the
length of a VLA object could change during the object's lifetime. If
that were the case, then the length would have be associated with the
object -- but it isn't.

>>> At the next level up, if row_count and col_count are really not known
>>> until runtime (your example would be better off as enums), then yes,
>>> there would be 1000 rows, and each row is a 2000-element array
>>> containing its length.
>> If row_count and col_count were enums, they would be constants, and
>> vla_2d would not be a VLA. The whole point is that we're talking about
>> VLAs.
>
> This is actually an important point. Many examples of VLAs I've seen
> are exactly like your example, due to point (1) above.
>
>> Yes, VLAs can result in stack overflows. So can ordinary fixed-length
>> arrays.
>
> VLAs can do so much more easily:
>
> void F(int n) { int A[n];}
>
> What are the likely values of n? Without VLAs you have to knowingly
> use large fixed values of n, and/or rely on deep recursion, to get
> overflow.

So don't do that.

An int parameter can have a value up to INT_MAX. If you don't want a
stack overflow, then *write your code* so that n can't be too big.

malloc() can take any value up to SIZE_MAX. Don't write code that
can actually attempt to allocate that that much memory.

>> If you define a VLA that you know can't be longer than N
>> elements, then that's no more dangerous that defining an ordinary array
>> with a length of exactly N.
>
> The compiler likely doesn't know. Some compilers (like gcc on Windows)
> use a call like __checkstk() to allocate local storage which it either
> knows will exceed 4KB, or it might do (like a VLA, even if n turns out
> to be only 3).

It's the programmer's resposibility to avoid allocating too much memory,
either in fixed-length array, a VLA, or a call to malloc(). Which also
means having an idea of what "too much" is, which can vary depending on
the system and on whether you're using the stack or the heap, or static
storage. Yes, programming is hard.

>> This is clearly a bug in lccwin. Feel free to report it to jacob navia
>> and/or post to comp.compilers.lcc. I don't think he'd be interested in
>> hearing about it from me.
>
> This is important too. If someone that experienced with implementing C
> has some trouble, then I've got no chance.

No chance of what? Were you planning to implement C VLAs? You don't
seem to understand them well enough to use them, let alone to implement
them.

I seriously urge you to contact jacob navia, the author and maintainer
of lcc-win, and let him know about this bug. A web search for "lcc-win"
will lead you to a web page that has his email address. I'd contact him
myself, but that hasn't worked well in the past for reasons I won't go
into here.

> (BTW why did VLAs become optional from C11?)

I honestly don't know. I personally disagreed with the decision.
Perhaps making them optional for freestanding implementations would have
made more sense.

[...]

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

On 2024-01-07, Keith Thompson <Keith.S.Thompson+u@gmail.com> wrote:
> C *does not have* VLAs whose type is "determined at runtime but can
> grow". Logically associating the length of a VLA type with the type
> *works*.
>
> Here's a small non-executable example:
>
> #include <stddef.h>
>
> size_t foo_size;
> size_t bar_size;
>
> void func(void) {
> int n = 42;
> typedef int vla[n];
> vla foo;
> vla bar;
> foo_size = sizeof foo;
> bar_size = sizeof bar;
> }
>
> When I compile it with "gcc -S", I get assembly code that appears to
> store the value 42 just once:
> movl $42, -52(%rbp)
> and retrieves that value from the same place to copy it to foo_size and
> bar_size. (I'm not an expert in x86_64 assembly language, but I'm
> fairly sure that's what's going on.) Please take a look at the
> generated assembly code yourself, using any C compilers you like. Do
> any of them store the sizes of foo and bar separately? Why do you think
> it would be better to do so?

The movl instruction most likely stores 42 in n.

If sizeof (int) > 1, it's unlikely that 42 is copied to foo_size or bar_size,
because (sizeof foo) and (sizeof bar) are (42 * sizeof (int)).

On 07/01/2024 16:34, Bart wrote:
> On 07/01/2024 14:48, David Brown wrote:
>> On 07/01/2024 01:58, Lawrence D'Oliveiro wrote:
>>> On Sat, 06 Jan 2024 16:40:03 -0800, Keith Thompson wrote:
>>>
>>>> C uses a "declaration follows usage" rule (though not with 100%
>>>> consistency).
>>>
>>> And putting the function result before the argument types turns out to
>>> cause trouble when carried over to C++, when you try to express
>>> dependencies between them. So they had to add a Pascal-style alternative
>>> syntax, with the function result declared after the arguments.
>>>
>>> Even pointer dereferencing should have been done with a postfix, not a
>>> prefix operator. Consider why you need “->”: it’s purely syntactic sugar
>>> to make things like
>>>
>>>     (*a).b
>>>
>>> less awkward as
>>>
>>>      a->b
>>>
>>> Whereas in Pascal, for example, there is no need for any alternative
>>> syntax to
>>>
>>>      a^.b
>>
>> There are two kinds of programming languages.  There are ones that
>> that exist long enough and are popular enough for people to see that
>> the original design was not perfect and could have been done
>> differently, and languages that die away to irrelevance before long.
>> No one thinks the C way of doing things, or its syntax, is perfect -
>> but a lot of people think it is good enough that they can live with it.
>>
>> A language has to either stick with the sub-optimal choices it made
>> long ago, as C has done, or it can try to make changes and suffers
>> from having to support new and old ideas, as C++ has done.  Each
>> technique has its advantages and disadvantages.
>
> I used to have that a^.b syntax (deref pointer then index).
>
> But for a few years I've relaxed that so that the deref is done
> automatically:
>
>     a^.b     becomes    a.b
>     a^[b]    becomes    a[b]
>     a^(b)    becomes    a(b)
>
> AFAICS, C can could also relax the (*a).b or a->b synax so that you just
> do a.b. You could do that today, and nothing changes. (Of course it
> would need a compiler update).

You could, in the sense that (AFAICS) there would be no situation where
in code today "a.b" and "a->b" were both syntactically and semantically
correct but meant different things. Then you could have a compiler
treat the syntax or constraint error "a.b" as intending to mean "a->b".

I don't think it would be a good idea - I think it just adds confusion
because you easily lose track of what are structs and what are pointers
to structs. I'd rather it be an error when you get these wrong in the
code. I remember from programming in Delphi (and Borland Object Pascal)
it could often be hard to figure out what was a pointer to an object,
and what was a "real" object, since dereferencing was automatic in some
circumstances. My personal preference is either to say that everything
is always a reference (like Python), or everything is always a value
(like C) and do the dereferencing explicitly. Other people make think
such automatic dereferencing is a good idea, but I personally don't.

>
> The others don't affect C so much: pointers to arrays, that would
> require (*a)[i], are rarely used. Everybody uses a[i] anyway with 'a'
> being a pointer to the first element.
>
> And it already allows, via some mysterious rules, for (*a)(b) to be
> written as a(b).
>

Think of it rather as C allows you to write function calls like
"foo(x)", and that considering function names as being function pointers
is a natural view that is easy to implement in compilers and keeps the C
to assembly conversion as lean as possible - it means "foo" is the
address of the function, rather than being the function itself. Being
able to write "foo(x)" as "(*foo)(x)" is just a byproduct of this - it
would need extra rules added to C to disallow it.

On 08/01/2024 04:35, Keith Thompson wrote:
> Bart <bc@freeuk.cm> writes:

>> It does however still bother me that a mere typedef, not actually used
>> for anything, could take up runtime resources.
>
> It's not the typedef that takes up runtime resources. It's the array
> type to which the typedef refers.
>
> Consider this:
> printf("%zu\n", sizeof (int[rand() % 10 } 1]);

(Tested as:) printf("%zu\n", sizeof (int[rand() % 10 + 1]));

> That's a perfectly valid usage.

I don't consider it a reasonable one.

At least I've learnt some things from this thread:

* Within an elaborate type-chain of pointers and arrays, VLA
dimensions need to be managed by the impementation at each point
along the chain.

* But actual VLA data allocations are only managed at the top level.
That's if an actual object is created at all. VLA data further
along (eg. as a pointer target) is still managed by the programmer.

So, to switch to LTR declarations for a second as C's syntax is still
beyond me, here:

[x][y]**[z]int A # array x of array x of ptr to ptr to array z ..

If x,y,z were all variable dimensions, then the [x][y] is allocated
for you, but not the [z]. However all x,y,z sizes are stored.

* I'm never going to implement VLAs as defined by C, as I don't
agree with how they work, even if I fully understood them. Your
example demonstrates that well.

Actually I can't even emulate your example with my higher level
scripting language. It's just not a good fit for such a lower level one.

> Earlier in this thread, you seemed to have the misconception that the
> length of a VLA object could change during the object's lifetime.

No; you made a remark that if it could change, then you'd agree the
dimension could switch from being stored from the type, to the instance.

I suggested, why not pretend the dimension could change (even it you had
no intention of that), then storing dimensions with the variable could
work just as well.

> So don't do that.

Was it you who keeps saying that or is someone else?

It is akin to saying: 'So don't have any bugs'. VLAs /do/ make it more
likely to have stack overflows.

> An int parameter can have a value up to INT_MAX. If you don't want a
> stack overflow, then *write your code* so that n can't be too big.
>
> malloc() can take any value up to SIZE_MAX.

* Typical heap space might be 1000 times bigger than stack space

* Asking for too much heap doesn't cause a crash; it returns a failure
code

* You can check whether the allocation was successful then decide what
to do next, including making a graceful exit

> Don't write code that
> can actually attempt to allocate that that much memory.

This is interesting:

unsigned long long int n=SIZE_MAX;
int A[n];

printf("%zu\n",sizeof(A));
printf("%zu\n",SIZE_MAX);

This outputs (with gcc):

18446744073709551612
18446744073709551615

It goes wrong if you try to write to A beyond whatever the stack size is.

> No chance of what? Were you planning to implement C VLAs? You don't
> seem to understand them well enough to use them, let alone to implement
> them.

EXACTLY. And I'm a fairly experienced compiler writer of this level of
language. How many C users do you think understand all the ins and outs?

> I seriously urge you to contact jacob navia, the author and maintainer
> of lcc-win, and let him know about this bug.

I doubt it is still under active development. I'm also sure he would
have heard about any problems by now.

It's not even clear if it is actually wrong in your example other than
using more memory than expected. Look at the output of the gcc example
above: what's with the missing 3 bytes?

On 08/01/2024 02:32, Bart wrote:
> On 07/01/2024 23:51, Keith Thompson wrote:
>> Bart <bc@freeuk.cm> writes:
>
>> Here's a small non-executable example:
>>
>> #include <stddef.h>
>>
>> size_t foo_size;
>> size_t bar_size;
>>
>> void func(void) {
>>      int n = 42;
>>      typedef int vla[n];
>>      vla foo;
>>      vla bar;
>
> This isn't how VLAs are typically used. I think there are three kinds of
> people when it comes to VLAs:
>
> (1) Those who don't know about them and only inadvertently create
>     them because the dimension is a variable not a compiler-time
>     expression
>
> (2) Those who know about VLAs, but who will supply the dimensions to
>     the variable declaration
>
> (3) A minority who know that VLA dimensions can also be used in
>     typedefs.
>

I would have thought that a majority of C programmers know that an array
size can be used in a typedef. If they also know that array sizes can
be non-constant (not every C programmer knows VLAs exist), it seems a
small step to know that you can use typedef with VLAs.

I think quite a lot of VLAs are of sizes that are known at compile time,
but are not "constants" according to C's strict definitions. For example :

void foo(void) {
const int rows = 10;
const int cols = 20;
const int entries = rows * cols;
int data[entries];
}

"data" is a VLA in C - yet its dimension can be fully established at
compile-time. (It would be legal in C++, where there are no C-style
VLAs but where a wider range of things can be view as "constant enough"
to be the size of an array.)

If I want to make a VLA of size based on a variable, I'll define it
directly. If I want to make several VLA's of the same size, I might use
a typedef - or I might define them all directly, whatever is (IMHO)
clearest in the code. I don't expect the compiler to treat them
differently. Far and away the most common situation, I think, is that
you have just one VLA.

> In the case of (2), what happens is that some storage is reserved for a
> size. A clever compiler can use one lot of storage if it realises
> multiple variables use that same size.
>

An even cleverer compiler usually doesn't need to store the size at all,
anywhere. A typical real-world implementation of a VLA like "T xs[n]"
will mean preserving the current stack pointer, then subtracting
sizeof(T) * n. The new stack pointer is the address of xs, and if you
need its size, it is available as "n". It is only if the variable "n"
is later changed - which would likely be a silly way to write your code,
but people do silly things - that the compiler has to preserve the
original "n" in some way. But it will do that as though you had written
"const sizeof_t original_n = n;" at the VLA definition. Storing on the
stack, or in a register, or combining with other things, is just part of
the daily grind for a compiler, optimised as well or as badly as it does
for anything else.

You seem to imagine this is all special, and complicated, and difficult,
full of corner cases. It is not - it needs nothing more than a local
constant variable that is hidden from the user. Everything else is
normal compiler work. (Optimising register allocation, stack slot
usage, variable lifetimes, etc., - /that/ is hard work. Adding an
another constant variable to the function is not.)

> But whatever it is, you saying that bit of storage is to do with the
> type; I'm saying it's to do with the instance of that type. In the end
> it probably doesn't matter.

It doesn't matter to the VLA user, certainly. And since each variable
has a type, the compiler could attach information about the type to each
instance of that type - but it would probably be an unhelpful way to
think about things.

After all, having types that are anonymous and only ever used once is
not new in C :

struct { int a; int b; } x;
struct { int a; int b; } y;

x and y are different types, used only once, and with no way to refer to
the type again (until C23 "typeof").

>
> It does however still bother me that a mere typedef, not actually used
> for anything, could take up runtime resources.

That's a matter of implementation quality. Lots of things that are not
actually used can take up runtime resources, from debug information
taking up run-time memory to unoptimised code that does calculations or
has variables or stage usage that never actually affects the outcome of
the program.

>
>
>>> At the next level up, if row_count and col_count are really not known
>>> until runtime (your example would be better off as enums), then yes,
>>> there would be 1000 rows, and each row is a 2000-element array
>>> containing its length.
>>
>> If row_count and col_count were enums, they would be constants, and
>> vla_2d would not be a VLA. The whole point is that we're talking about
>> VLAs.
>
> This is actually an important point. Many examples of VLAs I've seen are
> exactly like your example, due to point (1) above.
>

I agree that many uses of VLA's are actually with sizes that are known
at compile time. A good compiler will not need to store the size
anywhere, a less optimising compiler might store the size somewhere.

(Since you are not trying to make a conforming compiler, you could quite
reasonably allow such VLA's, treating them identically to normal arrays,
while disallowing VLA's whose size is not known until compile time.)

>
>> Yes, VLAs can result in stack overflows.  So can ordinary fixed-length
>> arrays.
>
> VLAs can do so much more easily:
>
>     void F(int n) { int A[n];}
>
> What are the likely values of n? Without VLAs you have to knowingly use
> large fixed values of n, and/or rely on deep recursion, to get overflow.
>

This is a myth that is regularly trotted out by people who, for unknown
reasons, don't like VLAs. They pretend that somehow heap allocation is
"safer" because malloc will return 0 if an allocation fails, while VLA's
have no such mechanism. In reality, if you were to write "malloc(n)"
with no idea what "n" might be, your program is as hopelessly unsound as
one that writes "int A[n];" with no idea what "n" might be. If you are
writing a good, safe program, you know the range for "n", and know
whether it makes sense for a VLA. Sanitizing your inputs is one of the
first lessons in programming. So please, let this be the last time this
silly complaint about VLAs turns up.

>> If you define a VLA that you know can't be longer than N
>> elements, then that's no more dangerous that defining an ordinary array
>> with a length of exactly N.
>
> The compiler likely doesn't know. Some compilers (like gcc on Windows)
> use a call like __checkstk() to allocate local storage which it either
> knows will exceed 4KB, or it might do (like a VLA, even if n turns out
> to be only 3).
>

Keith wrote "that /you/ know can't be longer than N". The programmer is
responsible for writing correct code, not the compiler.

>
>> This is clearly a bug in lccwin.  Feel free to report it to jacob navia
>> and/or post to comp.compilers.lcc.  I don't think he'd be interested in
>> hearing about it from me.
>
> This is important too. If someone that experienced with implementing C
> has some trouble, then I've got no chance.

/You/ are experienced in implementing C. But both you and Jacob suffer
from the same problem here - you are trying to do everything yourself.
Most people understand that they can make mistakes or misunderstanding,
and for something as advanced and complicated as a compiler, it is
usually better to be more than one person. Jacob is a smart guy, but he
is only one person, and only human - mistakes in his tools are not a
surprise.

>
> (BTW why did VLAs become optional from C11?)

I don't know for sure. But I do know that not all C implementations use
a stack, and for some targets a "true VLA" (as distinct from a VLA where
the size is known at compile time) would be extremely inefficient to
implement. It is possible that this has something to do with it.

On 08/01/2024 12:50, David Brown wrote:
> On 07/01/2024 16:34, Bart wrote:

>> I used to have that a^.b syntax (deref pointer then index).
>>
>> But for a few years I've relaxed that so that the deref is done
>> automatically:
>>
>>      a^.b     becomes    a.b
>>      a^[b]    becomes    a[b]
>>      a^(b)    becomes    a(b)
>>
>> AFAICS, C can could also relax the (*a).b or a->b synax so that you
>> just do a.b. You could do that today, and nothing changes. (Of course
>> it would need a compiler update).
>
> You could, in the sense that (AFAICS) there would be no situation where
> in code today "a.b" and "a->b" were both syntactically and semantically
> correct but meant different things.  Then you could have a compiler
> treat the syntax or constraint error "a.b" as intending to mean "a->b".
>
> I don't think it would be a good idea - I think it just adds confusion
> because you easily lose track of what are structs and what are pointers
> to structs.

Yet this is exactly what happens with those other examples: you don't
know if the X in X[i] has type T[] or T*. (The use of (*X)[i] when X is
of type T(*)[] is rare.)

And you don't know if the F in F(x) is an actual function, or a pointer
to a function.

The "->" alternate is anyway a little strange:

(*P).m can be written as P->m
(**Q).m can only be reduced to (*Q)->m

So it only works on the last lot of indirection. There is also no
euivalent of just (*P), "->" needs to specify a member name as it
combines two operations.

> I'd rather it be an error when you get these wrong in the
> code.

I had the same misgivings: there is a loss of transparency, but after I
started using the auto-deref, the benefits outweighed that:

Code was remarkably free of clutter. (And in my case, I had sections of
code that could often be ported as-is to/from my other language that
didn't need those derefs.)

>  My personal preference is either to say that everything
> is always a reference (like Python), or everything is always a value
> (like C) and do the dereferencing explicitly.  Other people make think
> such automatic dereferencing is a good idea, but I personally don't.

This can occur with reference parameters too: I believe you get the same
thing in C++.

>>
>> The others don't affect C so much: pointers to arrays, that would
>> require (*a)[i], are rarely used. Everybody uses a[i] anyway with 'a'
>> being a pointer to the first element.
>>
>> And it already allows, via some mysterious rules, for (*a)(b) to be
>> written as a(b).
>>
>
> Think of it rather as C allows you to write function calls like
> "foo(x)", and that considering function names as being function pointers
> is a natural view that is easy to implement in compilers and keeps the C
> to assembly conversion as lean as possible - it means "foo" is the
> address of the function, rather than being the function itself.  Being
> able to write "foo(x)" as "(*foo)(x)" is just a byproduct of this - it
> would need extra rules added to C to disallow it.

It's worse than that. Given an actual function:

void F(void){}

all of these calls are valid:

(&F)();
F();
(*F)();
(**F)();
(***F)();
(****F)(); // etc

across the half-dozen compilers I tried. Except for my 'mcc' which only
allows up to (*F), and not (**F)() or beyond. I just thought it was silly.

Ike Naar <ike@sdf.org> writes:
> On 2024-01-07, Keith Thompson <Keith.S.Thompson+u@gmail.com> wrote:
[...]
>> Here's a small non-executable example:
>>
>> #include <stddef.h>
>>
>> size_t foo_size;
>> size_t bar_size;
>>
>> void func(void) {
>> int n = 42;
>> typedef int vla[n];
>> vla foo;
>> vla bar;
>> foo_size = sizeof foo;
>> bar_size = sizeof bar;
>> }
>>
>> When I compile it with "gcc -S", I get assembly code that appears to
>> store the value 42 just once:
>> movl $42, -52(%rbp)
>> and retrieves that value from the same place to copy it to foo_size and
>> bar_size. (I'm not an expert in x86_64 assembly language, but I'm
>> fairly sure that's what's going on.) Please take a look at the
>> generated assembly code yourself, using any C compilers you like. Do
>> any of them store the sizes of foo and bar separately? Why do you think
>> it would be better to do so?
>
> The movl instruction most likely stores 42 in n.
>
> If sizeof (int) > 1, it's unlikely that 42 is copied to foo_size or bar_size,
> because (sizeof foo) and (sizeof bar) are (42 * sizeof (int)).

I believe you're right. I'll investigate further.

--
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 08/01/2024 15:00, David Brown wrote:
> On 08/01/2024 02:32, Bart wrote:
>> On 07/01/2024 23:51, Keith Thompson wrote:
>>> Bart <bc@freeuk.cm> writes:
>>
>>> Here's a small non-executable example:
>>>
>>> #include <stddef.h>
>>>
>>> size_t foo_size;
>>> size_t bar_size;
>>>
>>> void func(void) {
>>>      int n = 42;
>>>      typedef int vla[n];
>>>      vla foo;
>>>      vla bar;
>>
>> This isn't how VLAs are typically used. I think there are three kinds
>> of people when it comes to VLAs:
>>
>> (1) Those who don't know about them and only inadvertently create
>>      them because the dimension is a variable not a compiler-time
>>      expression
>>
>> (2) Those who know about VLAs, but who will supply the dimensions to
>>      the variable declaration
>>
>> (3) A minority who know that VLA dimensions can also be used in
>>      typedefs.
>>
>
> I would have thought that a majority of C programmers know that an array
> size can be used in a typedef.

Even that, having a fixed size array as a type, would be unusual, and
typically used for small arrays with special uses, for example:

typedef float vector[4];
typedef float matrix[4][4];
typedef quad byte[4]; // an actual one of mine

I can't even think of a use for such an array to have a size known at
runtime, unless somebody does this:

const int size = 4;
typedef float vector[size];
typedef float matrix[size][size];

(How many even know that you can typedef an actual function, not just a
function pointer:

#include <stdio.h>

typedef int Op(int a, int b);

Op add {return a+b;}
Op sub {return a-b;}
Op mul {return a*b;}
Op div {return a/b;}

int main(void) {
printf("%d\n", add(2, mul(3,4)));
}

Here, most compilers accept that typedef. However only two allow you to
use that typedef in the way shown, to provide a common template for a
function signature: Tiny C, and mine. Those produce a program that
displays 14.)
> An even cleverer compiler usually doesn't need to store the size at all,
> anywhere.  A typical real-world implementation of a VLA like "T xs[n]"
> will mean preserving the current stack pointer, then subtracting
> sizeof(T) * n.

That seems simple enough with one VLA in a function, and well structured
flow.

In practice there could be a dozen active VLAs, there could be loops so
that some VLAs are destroyed and recreated as a different size; there
could be gotos in and out of blocks [jump into a VLA scope is an error;
jumping out isn't, but a compiler needs to detect all this], early
returns and so on.

>(Optimising register allocation, stack slot
> usage, variable lifetimes, etc., - /that/ is hard work.  Adding an
> another constant variable to the function is not.)

That's also optional; you can make that as complex or simple as you
like. With a VLA the options are fewer.

> (Since you are not trying to make a conforming compiler, you could quite
> reasonably allow such VLA's, treating them identically to normal arrays,
> while disallowing VLA's whose size is not known until compile time.)

Any VLAs I might implement would use heap allocation (but that
introduces other matters of implicit calls to support functions that I
would prefer to keep out of a C implementation).

>> What are the likely values of n? Without VLAs you have to knowingly
>> use large fixed values of n, and/or rely on deep recursion, to get
>> overflow.
>>
>
> This is a myth that is regularly trotted out by people who, for unknown
> reasons, don't like VLAs.  They pretend that somehow heap allocation is
> "safer" because malloc will return 0 if an allocation fails, while VLA's
> have no such mechanism.  In reality, if you were to write "malloc(n)"
> with no idea what "n" might be, your program is as hopelessly unsound as
> one that writes "int A[n];" with no idea what "n" might be.

Except that the memory that malloc can draw on can be 1000 times larger
than stack memory.

In an earlier example, creating a VLA with int A[SIZE_MAX] didn't fail
(it would only do so if trying to write beyond the stack size), but
malloc(SIZE_MAX) did return NULL.

> Keith wrote "that /you/ know can't be longer than N".  The programmer is
> responsible for writing correct code, not the compiler.

Say you write a library function that looks like this:

int F(int n) {
int A[n];
....

or like this:

bool G(char* s) {
int A[strlen(s)];
....

You don't know who or what will call your function; what checks would
you insert?

What should your docs say about the range of n? You'd want the range to
be as high as possible, or to work with as long strings as possible.

At the same time, you want them to be efficient when n or strlen(s) is
small, which may be most of the time; you don't want the extra overheads
of VLAs, and on gcc-Windows, there can be extra overheads.

(My solution to those examples is extra code to either use a small,
fixed-length array, or use the heap, depending on N.)

> /You/ are experienced in implementing C.  But both you and Jacob suffer
> from the same problem here - you are trying to do everything yourself.

Above you say that VLAs are simple to implement. Here you suggest it
might be too much for an individual.

Although two persons who don't know how it works won't help! You
probably mean looking for existing solutions and implementations from
somebody who eventually figured it out.

I prefer language features that don't present difficulties. The only
open-ended aspect of compilation I will acknowledge, is back-end
optimisation. And I said that there, you can go as far as you like.

Bart <bc@freeuk.cm> writes:
> On 08/01/2024 04:35, Keith Thompson wrote:
>> Bart <bc@freeuk.cm> writes:
>
>>> It does however still bother me that a mere typedef, not actually used
>>> for anything, could take up runtime resources.
>> It's not the typedef that takes up runtime resources. It's the
>> array
>> type to which the typedef refers.
>> Consider this:
>> printf("%zu\n", sizeof (int[rand() % 10 } 1]);
>
> (Tested as:) printf("%zu\n", sizeof (int[rand() % 10 + 1]));

Yes, sorry about the typo.

>> That's a perfectly valid usage.
>
> I don't consider it a reasonable one.

And yet a conforming compiler must cover reasonable and unreasonable
usages.

The example was obviously contrived; there are few good reasons to
create an array with a random length. But it would be perfectly
reasonable to define a typedef for a VLA type with some length
determined at run time.

If you're implementing VLAs in a C compiler, you can either associate
the length with the type, or you can associate it with each object *and*
add a bunch of special cases.

In the 2-dimensional VLA example I posted earlier, you want to store the
length with *each* row of the array. How would that memory be
allocated? (It can't be within the array, which must be contiguous.)

> At least I've learnt some things from this thread:
>
> * Within an elaborate type-chain of pointers and arrays, VLA
> dimensions need to be managed by the impementation at each point
> along the chain.

The length of each VLA type must be managed with that type.

> * But actual VLA data allocations are only managed at the top level.
> That's if an actual object is created at all. VLA data further
> along (eg. as a pointer target) is still managed by the programmer.
>
> So, to switch to LTR declarations for a second as C's syntax is still
> beyond me, here:
>
> [x][y]**[z]int A # array x of array x of ptr to ptr to array z ..
>
> If x,y,z were all variable dimensions, then the [x][y] is allocated
> for you, but not the [z]. However all x,y,z sizes are stored.
>
> * I'm never going to implement VLAs as defined by C, as I don't
> agree with how they work, even if I fully understood them. Your
> example demonstrates that well.
>
> Actually I can't even emulate your example with my higher level
> scripting language. It's just not a good fit for such a lower level
> one.
>
>
>> Earlier in this thread, you seemed to have the misconception that the
>> length of a VLA object could change during the object's lifetime.
>
> No; you made a remark that if it could change, then you'd agree the
> dimension could switch from being stored from the type, to the
> instance.

That remark was in response to something you had said.

> I suggested, why not pretend the dimension could change (even it you
> had no intention of that), then storing dimensions with the variable
> could work just as well.

No, it really doesn't.

>> So don't do that.
>
> Was it you who keeps saying that or is someone else?
>
> It is akin to saying: 'So don't have any bugs'. VLAs /do/ make it more
> likely to have stack overflows.
>
>
>> An int parameter can have a value up to INT_MAX. If you don't want a
>> stack overflow, then *write your code* so that n can't be too big.
>> malloc() can take any value up to SIZE_MAX.
>
> * Typical heap space might be 1000 times bigger than stack space
>
> * Asking for too much heap doesn't cause a crash; it returns a failure
> code
>
> * You can check whether the allocation was successful then decide what
> to do next, including making a graceful exit

Unfortunately, that's not always true. The standard requires malloc()
to return a null pointer if it can't allocate the memory, but on Linux
it typically returns a non-null pointer to a block of virtual memory
that triggers the OOM killer (Google it if you're curious) when you try
to access it.

>> Don't write code that
>> can actually attempt to allocate that that much memory.
>
> This is interesting:
>
> unsigned long long int n=SIZE_MAX;
> int A[n];
>
> printf("%zu\n",sizeof(A));
> printf("%zu\n",SIZE_MAX);
>
> This outputs (with gcc):
>
> 18446744073709551612
> 18446744073709551615
>
> It goes wrong if you try to write to A beyond whatever the stack size is.
>
>> No chance of what? Were you planning to implement C VLAs? You don't
>> seem to understand them well enough to use them, let alone to implement
>> them.
>
> EXACTLY. And I'm a fairly experienced compiler writer of this level of
> language. How many C users do you think understand all the ins and
> outs?

I don't know how many understand *all* the ins and outs. I think a lost
of C programmers understand VLAs well enough to use them. (Most C
programmers don't look for ways to make things more difficult than they
need to be.)

>> I seriously urge you to contact jacob navia, the author and maintainer
>> of lcc-win, and let him know about this bug.
>
> I doubt it is still under active development. I'm also sure he would
> have heard about any problems by now.

It's likely that he hasn't heard about a bug with 2-dimensional VLAs.

But if you don't want to contact him, I'll do it myself. I'll post to
comp.compilers.lcc, which he followed as of a few years ago. I can
credit you for finding the bug or leave you out of it, whichever you
prefer.

> It's not even clear if it is actually wrong in your example other than
> using more memory than expected. Look at the output of the gcc example
> above: what's with the missing 3 bytes?

What missing 3 bytes? The gcc output looked correct to me.

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

David Brown <david.brown@hesbynett.no> writes:
> On 08/01/2024 02:32, Bart wrote:
[...]
>> (BTW why did VLAs become optional from C11?)
>
> I don't know for sure. But I do know that not all C implementations
> use a stack, and for some targets a "true VLA" (as distinct from a VLA
> where the size is known at compile time) would be extremely
> inefficient to implement. It is possible that this has something to
> do with it.

I'm skeptical that that's the reason. Almost all C implementations do
use a "stack", in the sense of a contiguously allocated region of memory
in which automatic objects are allocated, with addresses uniformly
increasing or decreasing for new allocations. (All C implementations
use a "stack" in the sense of a last-in/first-out data structure.) I'm
not aware that any implementers of non-stack implementations objected to
VLAs. For that matter, I don't know why VLAs would be extremely
inefficient in such an implementation. They need to have the ability to
allocate new stack frames anyway, and determining the allocation size at
run time shouldn't be a huge burden.

I've seen suggestions that the intent was to make it possible to create
conforming C implementations for small embedded processors. That might
make sense, but it could have been addressed by making VLAs optional
only for freestanding implementations.

I think Microsoft has chosen not to implement VLAs in their C compiler.

--
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:
[...]
> (How many even know that you can typedef an actual function, not just
> a function pointer:

I know that, and I've used it.

> #include <stdio.h>
>
> typedef int Op(int a, int b);
>
> Op add {return a+b;}
> Op sub {return a-b;}
> Op mul {return a*b;}
> Op div {return a/b;}
>
> int main(void) {
> printf("%d\n", add(2, mul(3,4)));
> }
>
> Here, most compilers accept that typedef.

Most? Are there any that don't? Any conforming C compiler must accept
that typedef.

> However only two allow you
> to use that typedef in the way shown, to provide a common template for
> a function signature: Tiny C, and mine. Those produce a program that
> displays 14.)

Probably because the language doesn't permit using a function typedef in
a function definition. Apparently Tiny C and your compiler provide this
as an extension -- which is fine, as long as they either issue a
diagnostic in conforming mode or don't claim to be fully conforming.

[...]

--
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 08/01/2024 18:25, Keith Thompson wrote:
> Bart <bc@freeuk.cm> writes:

>> This is interesting:
>>
>> unsigned long long int n=SIZE_MAX;
>> int A[n];
>>
>> printf("%zu\n",sizeof(A));
>> printf("%zu\n",SIZE_MAX);
>>
>> This outputs (with gcc):
>>
>> 18446744073709551612
>> 18446744073709551615
>>
>> It goes wrong if you try to write to A beyond whatever the stack size is.

> But if you don't want to contact him, I'll do it myself. I'll post to
> comp.compilers.lcc, which he followed as of a few years ago. I can
> credit you for finding the bug or leave you out of it, whichever you
> prefer.

Best not to mention me; I'm already well-known to him as a bug-finder.

>> It's not even clear if it is actually wrong in your example other than
>> using more memory than expected. Look at the output of the gcc example
>> above: what's with the missing 3 bytes?
>
> What missing 3 bytes? The gcc output looked correct to me.

Look carefully at the last digit. It should be '5' for SIZE_MAX, but
sizeof() reports a value with '2' at the end.

This is a complete program:

#include <stdio.h>
#include <stdint.h>

int main(void) {
unsigned long long int n=SIZE_MAX;
int A[n];

printf("%zu\n",sizeof(A));
printf("%zu\n",SIZE_MAX);
}