On 08/01/2024 18:55, Bart wrote:
> 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.

Never mind. A is an int array not a char array. So it's size would be
4*SIZE_MAX; that apparently gives the given value when limited to 64 bits.

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

I see; I didn't know which gcc example you were referring to.

sizeof A would be 4*SIZE_MAX if that were possible. Mathematically,
SIZE_MAX is 0xffffffffffffffff for this implementation, and SIZE_MAX*4
would be 0x3fffffffffffffffc. Taking the lower 64 bits gives
0x3fffffffffffffffc, which is 18446744073709551612 in decimal.

The code exceeds a capacity limit. The standard doesn't explicitly say
that an object size can't exceed SIZE_MAX bytes, but I'd say the code
has undefined behavior at best.

--
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:
[...]
> Never mind. A is an int array not a char array. So it's size would be
> 4*SIZE_MAX; that apparently gives the given value when limited to 64
> bits.

And I should have read that before posting.

--
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 16:53, Bart wrote:
> 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.

Yes, the short-cut only works for the (by far) most common case.

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

I didn't like automatic dereferencing (but I could live with it -
overall I found Delphi a very productive tool). But that's a
preference, and it is no surprise that other people have different
preferences.

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

Not quite - that's an easy and common misunderstanding. (It is even
more understandable for you, since your language uses "ref" to mean what
is called a "pointer" in C and C++.) References in C++ are not
"auto-dereferenced pointers" - they are alternative names for objects.
It is better to think of references as being ways to identify objects,
and pointers as being indirect references. C++ references are /not/
pointers.

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

No, it's not worse - it's just a side-effect of the convenience of
notation. Disallowing some of the forms you show below would require
extra rules, adding complication to the standards, while allowing them
is harmless (since people would not use them in code).

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

On 08/01/2024 19:02, Bart wrote:
> 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];
>

That all seems fine to me - now you have typedefs of VLAs.

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

There's nothing wrong with the typedef, and I'd be surprised to see a
compiler that did not accept it even if the compiler did not claim to be
a full C compiler. Some people (such as myself) prefer to typedef
function pointer types, others prefer to typedef function types and
declare pointers to those typedefs. Each is valid, and it is a
stylistic choice.

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

Such compilers would be non-compliant - there is nothing in the syntax
and constraints of C that would allow such a syntax. In fact, under
6.9.1 "Function definitions", there is a footnote saying explicitly that
this is wrong :

typedef int F(void);
F f { /* */ } // WRONG: syntax/constraint error

(Again, the typedef is fine - the use of it in a function definition is
not.)

"Op add, sub, mult, div;" as a declaration of the functions is fine.

So whoever wrote those two compilers either failed to do even a basic
reading of fundamental parts of the C standards, or decided
intentionally that this would be a useful extension to add to their
compiler.

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

The most common case.

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

It all fits in the same way. Complicated structure would hinder
compiler optimisations such as combining stack manipulation. But
there's nothing to stop the compiler treating:

{
...
T xs[n];
...
}

as roughly :

{
...

const sizeof_t n_for_xs = n;
const void * old_sp = SP;
SP -= (n_for_xs * sizeof(T));
T * xs = SP;

...
SP = old_sp;
}

If there are a dozen VLA's (/highly/ unlikely), do this a dozen times.
Everything else, including these new secret variables, works as normal.

I agree that gotos could potentially cause trouble here. Fortunately,
the C standards committee thought so too, and "A goto statement shall
not jump from outside the scope of an identifier having a variably
modified type to inside the scope of that identifier." (6.8.6.1p1).

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

Putting VLA's on the heap would be a strange idea that would run
contrary to people's expectations (though I think the standards would
allow it - after all, the C standards don't require a stack at all).
Still, as you are the only user, that's up to you and your own preferences.

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

That means nothing at all. If you have got your "n" from some random
unchecked and unsanitized input, it's madness to use it - a factor of
1000 won't save you.

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

Let's say that I would not do so, unless it were appropriate for me to
specify that the function only has defined behaviour for certain ranges
of "n". Then the caller has full responsibility for making sure "n" is
appropriate, and if there is a crash from a bad "n", it is their fault
alone.

> or like this:
>
>     bool G(char* s) {
>         int A[strlen(s)];
>         ....
>

The same applies here. (There's a reason why people often prefer
memchr() to strlen() when the input is not known to be safe.)

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

I specify my functions. It is up to users to use them correctly,
according to the specifications - or the program will have undefined
behaviour. If I suspect that the users might be newbies, or incompetent
programmers, and the functions don't have to be optimally efficient,
then I might put in extra checks to ensure that the parameters are safe
and crash with debug information if not (i.e., I'd use something like an
assert()), if such checks are feasible.

On 08/01/2024 19:32, Keith Thompson wrote:
> 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.

That would have been a little odd, as the differences between
freestanding and hosted requirements are almost all a matter of library
support. But it is certainly possible.

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

This is also entirely possible. The C (and C++) standards have a some
absolute piddle as a result of trying to please Microsoft (such as the
madness of so many different character types, or Microsoft's attempts at
"safe" library functions in C).

But as I say, I don't know for sure - your guess is at least as good as
mine!

On 08/01/2024 19:50, David Brown wrote:
> On 08/01/2024 16:53, Bart wrote:

>> This can occur with reference parameters too: I believe you get the
>> same thing in C++.
>
> Not quite - that's an easy and common misunderstanding.  (It is even
> more understandable for you, since your language uses "ref" to mean what
> is called a "pointer" in C and C++.)  References in C++ are not
> "auto-dereferenced pointers" - they are alternative names for objects.
> It is better to think of references as being ways to identify objects,
> and pointers as being indirect references.  C++ references are /not/
> pointers.

They look like auto-dereferenced pointers to me:

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

void F1(int a) {a = a + 1;}
void F2(int* a) {*a = *a + 1;}
void F3(int &a) {a = a + 1;}

int main(void) {

int a=100, b=200, c=300;

F1(a);
F2(&b);
F3(c);

printf("a = %d, b = %d, c = %d\n", a, b, c);
} ---------------------------

This is C code except for F3 and the call to it. It was compiled as C++.

The output expected is '100 201 301'. F1 can't modify its caller's data.
F2 can do so via explicit pointers. F3 does it via references.

But notice the body of F3 is identical to F1's; and so is the passed
argument (doesn't need &).

You get the same behaviour as using pointers, but without explicit
address-of ops on arguments, and deref ops on parameters.

But also, there is that same hidden deref so that you can't tell exactly
what's going on unles you see that & in the argument list.

My languages use the same & in the argument list to indicate by-reference.

>> It's worse than that.
>
> No, it's not worse - it's just a side-effect of the convenience of
> notation.  Disallowing some of the forms you show below would require
> extra rules, adding complication to the standards,

My MCC compiler seems to manage it (I'm not sure how), and my main
compiler does even better: you can't even do the equivalent of (*F)(),
because F is not a pointer to anything and can't be dereferenced.

(Yes, F by itself is still equal to &F, but not F().)

Whatever extra rules or logic are involved, they are insignificant
compared to those for VLAs, or for mixed sign arithmetic, for the
minimum groupings of {} around init data, or the algorithm for searching
for includes files, ...

> while allowing them
> is harmless (since people would not use them in code).

I suggested using .len on my unbounded arrays were harmless because they
wouldn't be used; you disagreed...

It just looks sloppy to me that you can effectively dereference
something an unlimited number of times; where is the type system in this?

On 2024-01-08, David Brown <david.brown@hesbynett.no> wrote:
> On 08/01/2024 16:53, Bart wrote:
>> 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.
>
> Yes, the short-cut only works for the (by far) most common case.
>
>>
>>> 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.)
>>
>
> I didn't like automatic dereferencing (but I could live with it -
> overall I found Delphi a very productive tool). But that's a
> preference, and it is no surprise that other people have different
> preferences.
>
>>>   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++.
>
> Not quite - that's an easy and common misunderstanding. (It is even
> more understandable for you, since your language uses "ref" to mean what
> is called a "pointer" in C and C++.) References in C++ are not
> "auto-dereferenced pointers" - they are alternative names for objects.

There is no way to distinguish a C++ reference from an
"auto-dereferenced pointer", though.

Importantly, an "auto-dereferenced *constant* pointer".

References behave like aliases only in a lexical scope. In a lexical
scope, pointer variables can also disappear, particularly ones that
are initialized and never modified.

int a = 0, *const pa = &a;

#define b (*pa)

b now behaves like another name for a. The compiler can replace every
*pa with b.

References in other situations are necessarily real objects that
hold a pointer-like address.

int &ref = *new int;

// ...

delete &ref;

The ref entity is definitely not just an alias name. The name "ref"
doesn't even exist at run time. "ref" is the compile-time name of a
reference, and that reference is an entity that is somehow bound to the
object from operator new. That binding of ref to the allocated object
requires a pointer-like entity. What comes out of new is a pointer, and
what must go into delete is a pointer. What carries it in between those
is carrying a pointer, and we can get one out of it using the address-of
operator.

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

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

> On 01.01.2024 01:07, Tim Rentsch wrote:
>
>> [...]
>
> Thanks for your post and suggestions.
>
> Some have already been addressed (and some also answered) in
> this thread, [...]

I knew there was some overlap between my comments and
previous comments. I posted what I did both to add some
new information and to give some corrections in those
cases where there was overlap, phrased in a positive
way.

Kaz Kylheku <433-929-6894@kylheku.com> writes:

> There is no way to distinguish a C++ reference from an
> "auto-dereferenced pointer", though. [...]

Right. The C++ standard would have us believe a fiction
that a reference is not just an auto-dereferenced pointer.
It's an excellent example of the fantasy world in which the
C++ standard operates.

scott@slp53.sl.home (Scott Lurndal) writes:

[..concerning using a macro to determine the number of elements
in an array, eg

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

> Indeed. I do believe that absent standardization, using a macro
> adds a level of indirection that may adversely affect the code
> readability (whether it is ARRAY_SIZE, ARRAY_LENGTH, LENGTH, NUM_ELEMENTS,
> or whatever, I would need to refer to the macro definition to
> determine the intent of the programmer).

This reaction strikes me as being a bit nutty. I don't insist
that a macro be used in such cases, but I wouldn't object to it
either. It's much like the question of whether to wrap up
several statements in a separate function definition, or simply
write them inline. It's almost always true that either choice
is acceptable, depending on what the author wants to emphasize.
There are pluses and minuses on both sides.

There are situations for which using a macro rather than writing
out the code directly nearly always has a predominately negative
effect, but this case isn't one of them.

(To be clear, all of the above simply statements of my own
opinions.)

On 09/01/2024 02:05, Bart wrote:
> On 08/01/2024 19:50, David Brown wrote:
>> On 08/01/2024 16:53, Bart wrote:
>
>>> This can occur with reference parameters too: I believe you get the
>>> same thing in C++.
>>
>> Not quite - that's an easy and common misunderstanding.  (It is even
>> more understandable for you, since your language uses "ref" to mean
>> what is called a "pointer" in C and C++.)  References in C++ are not
>> "auto-dereferenced pointers" - they are alternative names for objects.
>> It is better to think of references as being ways to identify objects,
>> and pointers as being indirect references.  C++ references are /not/
>> pointers.
>
> They look like auto-dereferenced pointers to me:
>

I know they look like that at first glance, but they are not
auto-dereferenced pointers. It can sometimes be useful to understand
that when you move references around (such as for function parameters),
they are implemented as though they were a special kind of pointer -
that tells you how efficient they are. But conceptually, for their use
and understanding, I don't think it is helpful.

>
>>> It's worse than that.
>>
>> No, it's not worse - it's just a side-effect of the convenience of
>> notation.  Disallowing some of the forms you show below would require
>> extra rules, adding complication to the standards,
>
> My MCC compiler seems to manage it (I'm not sure how), and my main
> compiler does even better: you can't even do the equivalent of (*F)(),
> because F is not a pointer to anything and can't be dereferenced.

How is that in any way "better"? You have gone out of your way to make
your compiler non-conforming for the sake of stopping something no one
would ever write? It all sounds a bit pointless (but harmless) to me.

>
> (Yes, F by itself is still equal to &F, but not F().)
>
> Whatever extra rules or logic are involved, they are insignificant
> compared to those for VLAs, or for mixed sign arithmetic, for the
> minimum groupings of {} around init data, or the algorithm for searching
> for includes files, ...

Whataboutism is a strong sign that the person arguing has lost track of
their point.

On Mon, 8 Jan 2024 13:50:08 +0100, David Brown wrote:

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

Ada tries to pretend there is no difference. There is mostly no ambiguity,
except potentially in something like

a := b;

where “a” and “b” are both pointers to some common type. In this case, the
meaning is not to dereference the pointers; to force a dereference, you
write

a.all := b.all;

On 09/01/2024 07:30, David Brown wrote:
> On 09/01/2024 02:05, Bart wrote:
>> On 08/01/2024 19:50, David Brown wrote:
>>> On 08/01/2024 16:53, Bart wrote:
>>
>>>> This can occur with reference parameters too: I believe you get the
>>>> same thing in C++.
>>>
>>> Not quite - that's an easy and common misunderstanding.  (It is even
>>> more understandable for you, since your language uses "ref" to mean
>>> what is called a "pointer" in C and C++.)  References in C++ are not
>>> "auto-dereferenced pointers" - they are alternative names for
>>> objects. It is better to think of references as being ways to
>>> identify objects, and pointers as being indirect references.  C++
>>> references are /not/ pointers.
>>
>> They look like auto-dereferenced pointers to me:
>>
>
> I know they look like that at first glance, but they are not
> auto-dereferenced pointers.  It can sometimes be useful to understand
> that when you move references around (such as for function parameters),
> they are implemented as though they were a special kind of pointer -
> that tells you how efficient they are.  But conceptually, for their use
> and understanding, I don't think it is helpful.
>
>>
>>>> It's worse than that.
>>>
>>> No, it's not worse - it's just a side-effect of the convenience of
>>> notation.  Disallowing some of the forms you show below would require
>>> extra rules, adding complication to the standards,
>>
>> My MCC compiler seems to manage it (I'm not sure how), and my main
>> compiler does even better: you can't even do the equivalent of (*F)(),
>> because F is not a pointer to anything and can't be dereferenced.
>
> How is that in any way "better"?  You have gone out of your way to make
> your compiler non-conforming for the sake of stopping something no one
> would ever write?  It all sounds a bit pointless (but harmless) to me.
>
>>
>> (Yes, F by itself is still equal to &F, but not F().)
>>
>> Whatever extra rules or logic are involved, they are insignificant
>> compared to those for VLAs, or for mixed sign arithmetic, for the
>> minimum groupings of {} around init data, or the algorithm for
>> searching for includes files, ...
>
> Whataboutism is a strong sign that the person arguing has lost track of
> their point.

Not at all. You are defending some crazy anomaly, that you find nowhere
else, for some insubstantial reason.

It works like that because the language was poorly designed in the first
place and nobody thought it worthwhile fixing it.

So it's just another quirk.

I quite like the idea that if you want to do *X, then it better have a
type like T*. Then the result of *X, ie. dereferencing X, will be T.

Now C does something odd: if T happens to be a function type, it
immediately turns that result back into *T.

I used to have some rules (not in C but expressed as C) where, if F is
an actual function and has function type:

Type Action

&F func* Evaluate function reference
F func Same as F()
F(...) func Call the function (yielding func ret type)
*F --- Error, not a pointer

I changed that to be more C-like: I always need () to call the function
even if there are no arguments, while F and &F are equivalent.

This required an extra bit of logic. As far as explaining it goes:

&F func* Evaluate function reference
F func* Evaluate function reference
F(...) func Call the function
*F --- Error, not a pointer

It's not that hard, it just introduced one small anomaly where F and F&
are the same.

On 09/01/2024 12:11, Bart wrote:
> On 09/01/2024 07:30, David Brown wrote:
>> On 09/01/2024 02:05, Bart wrote:
>>> On 08/01/2024 19:50, David Brown wrote:
>>>> On 08/01/2024 16:53, Bart wrote:
>>>
>>>>> This can occur with reference parameters too: I believe you get the
>>>>> same thing in C++.
>>>>
>>>> Not quite - that's an easy and common misunderstanding.  (It is even
>>>> more understandable for you, since your language uses "ref" to mean
>>>> what is called a "pointer" in C and C++.)  References in C++ are not
>>>> "auto-dereferenced pointers" - they are alternative names for
>>>> objects. It is better to think of references as being ways to
>>>> identify objects, and pointers as being indirect references.  C++
>>>> references are /not/ pointers.
>>>
>>> They look like auto-dereferenced pointers to me:
>>>
>>
>> I know they look like that at first glance, but they are not
>> auto-dereferenced pointers.  It can sometimes be useful to understand
>> that when you move references around (such as for function
>> parameters), they are implemented as though they were a special kind
>> of pointer - that tells you how efficient they are.  But conceptually,
>> for their use and understanding, I don't think it is helpful.
>>
>>>
>>>>> It's worse than that.
>>>>
>>>> No, it's not worse - it's just a side-effect of the convenience of
>>>> notation.  Disallowing some of the forms you show below would
>>>> require extra rules, adding complication to the standards,
>>>
>>> My MCC compiler seems to manage it (I'm not sure how), and my main
>>> compiler does even better: you can't even do the equivalent of
>>> (*F)(), because F is not a pointer to anything and can't be
>>> dereferenced.
>>
>> How is that in any way "better"?  You have gone out of your way to
>> make your compiler non-conforming for the sake of stopping something
>> no one would ever write?  It all sounds a bit pointless (but harmless)
>> to me.
>>
>>>
>>> (Yes, F by itself is still equal to &F, but not F().)
>>>
>>> Whatever extra rules or logic are involved, they are insignificant
>>> compared to those for VLAs, or for mixed sign arithmetic, for the
>>> minimum groupings of {} around init data, or the algorithm for
>>> searching for includes files, ...
>>
>> Whataboutism is a strong sign that the person arguing has lost track
>> of their point.
>
> Not at all. You are defending some crazy anomaly, that you find nowhere
> else, for some insubstantial reason.

I'm saying it doesn't matter. I have never heard it mentioned,
anywhere, except by you. It is completely irrelevant.

>
> It works like that because the language was poorly designed in the first
> place and nobody thought it worthwhile fixing it.

It works like that because the language was /well/ designed, for its
purpose at the time, with the requirements and limitations of the time.
Remember, as you always seem to forget, C was not designed with the sole
purpose of making /your/ life as easy as possible, or suiting /your/
particular preferences. The "(***foo)" anomaly is a side-effect of the
way functions work in C. Leaving it in costs nothing, removing it would
be an effort and an inconvenience.

Do you /really/ think that, if this were important, no one would have
suggested disallowing it? Do you /really/ think that, if this were
leading to poor code, misunderstandings or mistakes, that compiler
writers would not be able to add warnings about it? Do you /really/
think you are so vastly superior to everyone else in the C world that
you alone see the problem?

Sometimes you are like that old joke of the guy driving the wrong way
down the motorway, complaining that everyone else is wrong.

On 09/01/2024 14:56, David Brown wrote:
> On 09/01/2024 12:11, Bart wrote:

>> Not at all. You are defending some crazy anomaly, that you find
>> nowhere else, for some insubstantial reason.
>
> I'm saying it doesn't matter.  I have never heard it mentioned,
> anywhere, except by you.  It is completely irrelevant.

So you see this in code:

(*F)(x);

and don't assume that F must be a pointer to function; why not? I
thought you wanted that transparency?

>>
>> It works like that because the language was poorly designed in the
>> first place and nobody thought it worthwhile fixing it.
>
> It works like that because the language was /well/ designed, for its
> purpose at the time, with the requirements and limitations of the time.

Poppycock.

What limitations were there? These were people who were well funded to
do exactly this work, and had decent equipment like DEC minicomputers to
work with.

My language a decade later was done in my spare time on an 8-bit
machine. There was no funding for that, and I wasn't an academic.

But it didn't the same plethora of quirks as C. Most languages don't.

> Remember, as you always seem to forget, C was not designed with the sole
> purpose of making /your/ life as easy as possible, or suiting /your/
> particular preferences.  The "(***foo)" anomaly is a side-effect of the
> way functions work in C.  Leaving it in costs nothing, removing it would
> be an effort and an inconvenience.

Really? I didn't have much trouble.

> Do you /really/ think that, if this were important, no one would have
> suggested disallowing it?  Do you /really/ think that, if this were
> leading to poor code, misunderstandings or mistakes, that compiler
> writers would not be able to add warnings about it?  Do you /really/
> think you are so vastly superior to everyone else in the C world that
> you alone see the problem?
>
> Sometimes you are like that old joke of the guy driving the wrong way
> down the motorway, complaining that everyone else is wrong.

Would you design a language like that today?

I could list dozens of howlers within the language.

I've long thought that C was an elaborate joke that escaped from the
lab. Possibly it is, and no one has yet owned up to it.

But people actually take it seriously and even defend all this stuff.

YOU would be the guy driving along the motorway in a Model T Ford,
backed up by a 40-foot truck containing all the advanced equipment
needed to work around all its shortcomings.

Behind them would be a further fleet of trucks containing the
environment that you insist on being available.

Oh, sorry, I forgot that in 2023 it acquired new door handles. Yeah,
that makes a difference.

On 2024-01-09, Bart <bc@freeuk.cm> wrote:
> Now C does something odd: if T happens to be a function type, it
> immediately turns that result back into *T.

That's one way to have distinct concepts of function type and pointer to
that type, while preserving most the assembly language semantics of
working with functions as addresses.

In declarations, other than of a function parameter, a function type
is distinct from a pointer to that function type.

But in all the places where the rhetorical rubber meets the proverbial
pavement, functions are manipulated as pointers, like in machine
languages.

Thus we have decay rules similar to the array ones: parameter of
function type adjusted to pointer; expressions of function type
converted to pointer.

It poses fewer difficulties for functions, in comparison to arrays;
it is hardly noticeable.

--
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 09/01/2024 18:46, Bart wrote:
> On 09/01/2024 14:56, David Brown wrote:
>> On 09/01/2024 12:11, Bart wrote:
>
>>> Not at all. You are defending some crazy anomaly, that you find
>>> nowhere else, for some insubstantial reason.
>>
>> I'm saying it doesn't matter.  I have never heard it mentioned,
>> anywhere, except by you.  It is completely irrelevant.
>
> So you see this in code:
>
>    (*F)(x);
>
> and don't assume that F must be a pointer to function; why not? I
> thought you wanted that transparency?

Yes, I assume F is a pointer to a function - because I assume, unless
proven otherwise, that the author of the code is not a complete moron or
an evil maniac doing his or her best to confuse people.

(I haven't bothered responding to the rest of your post, because I can't
see a realistic and accurate response without sounding nasty, and I
don't want to do that. Suffice to say that C is inordinately successful
as a language, and your language is not - perhaps there are good reasons
for that.)

On 2024-01-09, Bart <bc@freeuk.cm> wrote:
> On 09/01/2024 14:56, David Brown wrote:
>> On 09/01/2024 12:11, Bart wrote:
>
>>> Not at all. You are defending some crazy anomaly, that you find
>>> nowhere else, for some insubstantial reason.
>>
>> I'm saying it doesn't matter.  I have never heard it mentioned,
>> anywhere, except by you.  It is completely irrelevant.
>
> So you see this in code:
>
> (*F)(x);
>
> and don't assume that F must be a pointer to function; why not? I
> thought you wanted that transparency?

The use of (*pf)(args, ...) is unnecessary and in my experience, rare.

It's a style used to emphasize that this is an indirect call.

I probably first saw that ages ago in some XWindow sources or examples.

I don't think I've ever seen that used on a function, as in

(*strcmp)(str, "foo")

which would be a kind of misuse, like a deliberately misleading comment.

(Was that explicit dereference ever required in some versions of C or C
compilers?)

(*pf)(args, ...) style for indirections does have something
to recommend it. If it is consistently and appropriately used, it
clearly indicates the function indirections.

--
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 09/01/2024 19:20, Kaz Kylheku wrote:
> On 2024-01-09, Bart <bc@freeuk.cm> wrote:
>> On 09/01/2024 14:56, David Brown wrote:
>>> On 09/01/2024 12:11, Bart wrote:
>>
>>>> Not at all. You are defending some crazy anomaly, that you find
>>>> nowhere else, for some insubstantial reason.
>>>
>>> I'm saying it doesn't matter.  I have never heard it mentioned,
>>> anywhere, except by you.  It is completely irrelevant.
>>
>> So you see this in code:
>>
>> (*F)(x);
>>
>> and don't assume that F must be a pointer to function; why not? I
>> thought you wanted that transparency?
>
> The use of (*pf)(args, ...) is unnecessary and in my experience, rare.
>
> It's a style used to emphasize that this is an indirect call.
>
> I probably first saw that ages ago in some XWindow sources or examples.
>
> I don't think I've ever seen that used on a function, as in
>
> (*strcmp)(str, "foo")
>
> which would be a kind of misuse, like a deliberately misleading comment.
>
> (Was that explicit dereference ever required in some versions of C or C
> compilers?)
>
> (*pf)(args, ...) style for indirections does have something
> to recommend it. If it is consistently and appropriately used, it
> clearly indicates the function indirections.
>

This is the funny thing about C (well one of many funny things):

* It has types which are pointers to Arrays, Structs and Functions

* It has formal syntax to dereference all of those

* But, that syntax is never used!

This is what I mean:

Type Formal Syntax Idiomatic Use

A Pointer to Array (*A)[i] A[i]

P Pointer to Struct (*P).m P->m

F Pointer to Function (*F)(x) F(x)

You only ever see syntax in the last column, hardly ever that formal style.

Which is probably just as well, as it's pretty ugly, and harder to type.

With arrays, people don't even bother with actual array pointers.
Structs have that funny -> operator, and Functions have those special rules.

At least, with P->m, you know that P must be a pointer to a struct, but
you can't tell with those others.

Bart <bc@freeuk.cm> writes:
> On 09/01/2024 14:56, David Brown wrote:
>> On 09/01/2024 12:11, Bart wrote:
>
>>> Not at all. You are defending some crazy anomaly, that you find
>>> nowhere else, for some insubstantial reason.
>> I'm saying it doesn't matter.  I have never heard it mentioned,
>> anywhere, except by you.  It is completely irrelevant.
>
> So you see this in code:
>
> (*F)(x);
>
> and don't assume that F must be a pointer to function; why not? I
> thought you wanted that transparency?

In terms of the C abstract machine, if that code is valid (and isn't
playing stupid macro tricks), yes, F must be an expression that
evaluates to a result of a pointer-to-function type. That's equally
true whether F is the name of an object of pointer-to-function type or
the name of a function.

If F is a pointer object, the author was probably trying to make that
explicit. If F is a function name, the author was probaby writing
deliberation obfuscated code (something that's not particularly
difficult in any language I've seen).

The language defines an implicit conversion of an expression of function
type to pointer-to-function type, similar to the array-to-pointer
conversion. This conversion occurs in most but not all contexts,
basically whenever it's not the operand of unary "&". (sizeof and
_Alignof also inhibit the conversion, so that `sizeof func` is an error,
not an expression that yields the size of a function pointer).

The language requires a pointer-to-function expression as the prefix of
a function call.

A result of this is that (******func)() is a valid call. Note also that
(+ + + + + + + + + 42) is a valid expression, and I don't see anyone
saying compilers should go out of their way to forbid it.

It *could* have required a function designator as the prefix of a
function call and dropped the function-to-pointer conversion. Then
ordinary function calls would look the same as they do now, and indirect
function calls would have to be written as (*funcptr)().

Personally, I might have preferred that approach, though it's likely
there are ramifications I haven't thought of.

My personal reaction has been to spend a few minutes thinking that this
is slightly ugly and counterintuitive, followed by several decades just
quietly accepting and using it.

[...]

> Would you design a language like that today?

Probably not. C is quirky, and I personally dislike a lot of its
quirks. But they're mostly straightforward quirks once you understand
them.

> I could list dozens of howlers within the language.

I'm sure you could. So could most of us. Pleaser don't bother.

> I've long thought that C was an elaborate joke that escaped from the
> lab. Possibly it is, and no one has yet owned up to it.
>
> But people actually take it seriously and even defend all this stuff.

Any time someone says "This is how C is defined", you interpret it as
"This is how C is defined, and it's the best possible way it could have
been defined". Nobody actually says that. You're arguing against a
strawman.

[...]

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

Kaz Kylheku <433-929-6894@kylheku.com> writes:
> On 2024-01-09, Bart <bc@freeuk.cm> wrote:
>> Now C does something odd: if T happens to be a function type, it
>> immediately turns that result back into *T.
>
> That's one way to have distinct concepts of function type and pointer to
> that type, while preserving most the assembly language semantics of
> working with functions as addresses.

On my x86_64 system with gcc, these lines of C:
func();
funcptr();
result in these call instructions:
call func
call *%rdx

I don't know what the corresponding machine code looks like, but for an
ordinary function call, any treatment of the function name as an address
appears to be implicit even in assembly language, at least in this
implementation.

--
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 09/01/2024 18:56, David Brown wrote:
> On 09/01/2024 18:46, Bart wrote:
>> On 09/01/2024 14:56, David Brown wrote:
>>> On 09/01/2024 12:11, Bart wrote:
>>
>>>> Not at all. You are defending some crazy anomaly, that you find
>>>> nowhere else, for some insubstantial reason.
>>>
>>> I'm saying it doesn't matter.  I have never heard it mentioned,
>>> anywhere, except by you.  It is completely irrelevant.
>>
>> So you see this in code:
>>
>>     (*F)(x);
>>
>> and don't assume that F must be a pointer to function; why not? I
>> thought you wanted that transparency?
>
> Yes, I assume F is a pointer to a function - because I assume, unless
> proven otherwise, that the author of the code is not a complete moron or
> an evil maniac doing his or her best to confuse people.

Maybe F used to be a pointer, but is now a normal function, and the code
was not updated. Or maybe a normal function named F is now shadowing the
more global function pointer F.

>
> (I haven't bothered responding to the rest of your post, because I can't
> see a realistic and accurate response without sounding nasty, and I
> don't want to do that.  Suffice to say that C is inordinately successful
> as a language, and your language is not - perhaps there are good reasons
> for that.)

There's being successful, and there's being right.

/I/ can write:

println 0123

and get the expected output. C would give you 83.

Don't tell me: gcc has some option to warn of using octal literals. So
your 'successful' language relies on extensive extra tools (all the
stuff in that support truck) to keep it useable.

BTW here's an exchange from a few days ago:

DB:
>>> .. the insanity of evaluating to 0 when given a pointer/reference
to an "unbounded" array.
>>
BC:
>> ..it is low priority because it is never used that way.
>>
DB:
> That's the kind of potentially confusing short-cut you can make when
only you ever use the language.

I made the argument you gave - no one would do that - but when I do it,
it makes things confusing.

I did then try to fix that, but stopped because of interactions with
actual zero-length arrays (I would need to be fully immersed to make the
changes).

Then the next day I found that C doesn't even /have/ zero-length arrays:
you can't have an empty array; how about that? I thought C was zero-based!

As for things that are insane, how about:

int spam() {
spam: spam(spam, spam(), spam(spam(spam)), spam);
}

I can't write that in my language, as it won't accept complete
gobbledygook. Of course, it's not as 'successful' as C, so what do I know.

Bart <bc@freeuk.cm> writes:
> On 09/01/2024 19:20, Kaz Kylheku wrote:
>> On 2024-01-09, Bart <bc@freeuk.cm> wrote:
>>> On 09/01/2024 14:56, David Brown wrote:
>>>> On 09/01/2024 12:11, Bart wrote:
>>>
>>>>> Not at all. You are defending some crazy anomaly, that you find
>>>>> nowhere else, for some insubstantial reason.
>>>>
>>>> I'm saying it doesn't matter.  I have never heard it mentioned,
>>>> anywhere, except by you.  It is completely irrelevant.
>>>
>>> So you see this in code:
>>>
>>> (*F)(x);
>>>
>>> and don't assume that F must be a pointer to function; why not? I
>>> thought you wanted that transparency?
>> The use of (*pf)(args, ...) is unnecessary and in my experience,
>> rare.
>> It's a style used to emphasize that this is an indirect call.
>> I probably first saw that ages ago in some XWindow sources or
>> examples.
>> I don't think I've ever seen that used on a function, as in
>> (*strcmp)(str, "foo")
>> which would be a kind of misuse, like a deliberately misleading
>> comment.
>> (Was that explicit dereference ever required in some versions of C
>> or C
>> compilers?)
>> (*pf)(args, ...) style for indirections does have something
>> to recommend it. If it is consistently and appropriately used, it
>> clearly indicates the function indirections.
>>
>
> This is the funny thing about C (well one of many funny things):
>
> * It has types which are pointers to Arrays, Structs and Functions
>
> * It has formal syntax to dereference all of those
>
> * But, that syntax is never used!
>
> This is what I mean:
>
> Type Formal Syntax Idiomatic Use
>
> A Pointer to Array (*A)[i] A[i]
>
> P Pointer to Struct (*P).m P->m
>
> F Pointer to Function (*F)(x) F(x)

In all three cases, neither is more formal or idiomatic than the other.

The -> operator is syntactic sugar (and yes, we could imagine a
different syntax in which it wouild't be necessary). BTW, it applies to
both structs and unions. (The standard doesn't even define -> in terms
of . and *, though it could have.)

The [], ->, and () operators all require a pointer expression on the
LHS (or as one of the operands in the case of []). The unary * operand
requires an operand of pointer type.

For [], the pointer operand is very commonly the name of an array
object, which decays to a pointer to the array's initial element.

For (), the pointer operand is very commonly the name of a function,
which decays to a pointer to the function.

That's how the language is defined. Do not assume that I am expressing
an opinion about whether it's good or bad. I probably wouldn't have
designed it that way, but I'm no Dennis Ritchie. What I'm suggesting is
that, even if you don't like it, it's helpful to understand the language
on its own terms.

[...]

--
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:
[...]
> I did then try to fix that, but stopped because of interactions with
> actual zero-length arrays (I would need to be fully immersed to make
> the changes).
>
> Then the next day I found that C doesn't even /have/ zero-length
> arrays: you can't have an empty array; how about that? I thought C
> was zero-based!
[...]

Have you considered learning the language before trying to implement 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 */