On 12/06/2021 17:12, Kaz Kylheku wrote:
> On 2021-06-12, Bart <bc@freeuk.com> wrote:

>> (1) I couldn't for the life of me figure out the type syntax.
>
> Right; that's why there is this comp.lang.c newsgroup where getting
> help with that is topical.
>
> You could make a typedef:
>
> typedef void (*any_fun_t)(int, int, int, ..., int);

Yes, that's what I did for the second example (well, I copied from yours).

> You're using a strawman example to make an unclear point.

My point (1) is that C type declarations are so crazy, they are not fit
for purpose. I shoudn't need to use external tools or workarounds like
typedefs to write a perfectly simple type that in my everyday language I
just write as '[]ref proc' (array of pointer to function).

(Has it never occurred to anyone here how absolutely bizarre it is to
have that array modifier '[]' /in the middle/ of
'void(*functable[])(void)'?)

>> typedef void(*fnptr)(int,int,int,int,int,int);
>>
>> fnptr functable[]={(fnptr)printf, (fnptr)malloc, (fnptr)fwrite};
>>
>> Except now gcc complains of casts between incompatible pointer types.
>> And it has a point.
>
> Now you're evidently just making things up:
>
> $ gcc -Wall -W -pedantic -ansi fptr.c -c
> $ gcc -Wall -W -pedantic -std=c99 fptr.c -c # silence
> $ cat fptr.c
> #include <stdio.h>
>
> void (*fptr)(void) = (void (*)(void)) printf;

I get this:

C:\c>gcc @w c.c
c.c:5:20: warning: cast between incompatible function types from 'int
(*)(const char * restrict, ..
..)' to 'void (*)(int, int, int, int, int, int)' [-Wcast-function-type]
5 | fnptr functable[]={(fnptr)printf, (fnptr)malloc, (fnptr)fwrite};
| ^
..... + 2 more identical warnings ....

'w' contains a long bunch of options I downloaded from somewhere. The
relevant one is '-Wbad-function-cast'.

But if you decide not to use it, then somebody else will, as I found out
what I used to post links to some of my generated code. Somebody would
always ramp up the warnings as a way to make out that my code was
rubbish. (The same program can generate from 0 lines of warnings, to
28,000 lines.)

However, I can use C compilers' typical laxity to my advantage, by
saying my code needs to be compiled with NO options except any necessary
ones to get the job done (eg. -O3, -m64, -o, and on Linux, -lm and -ldl).

Since apparently /I/ get to choose whether a program is correct or not
by the options I feed a compiler. So here /I/ decide that using void*
for function pointers is correct code. If someone doesn't agree, take it
up with the compiler writers.

>> void (*osnos_os_getdllprocaddr(int64_t hinst,uint8_t * name))(void) {
>> static struct osnos_os_getdllprocaddr_rec table[23] = {
>> {(uint8_t*)"malloc",(void *)(&malloc)},
>> {(uint8_t*)"realloc",(void *)(&realloc)},
>> {(uint8_t*)"free",(void *)(&free)},
>
> This is supposed to show how to do it more succinctly with fewer casts?
>
> Why would you not just use "char *", for one thing.

Because literal strings in the original language have type 'ref u8' (the
nearest C type), and the generated code has to reflect what is in the
original source.

Literal strings in C would normally have type 'ref i8', but the reality
is even weirder: they have type 'ref ?8' where ? is either i or u, but
you can't specify which as ? is compatible with neither.

>> {(uint8_t*)"printf",(void *)(&printf)},
> ^ gratuitous operator
> ^ unnecessary parens

> The cast notation and & are both unary operators: they go on the left
> side of the operand and consequently associate right to left.
>
> Parentheses are never needed to disambiguate between the same category
> of operators; that's not what they are for.

You're nitpicking my C code generator. If I try and minimise the
generation of parentheses, I'm going to get it wrong (as I found out).

But in generated code, superfluous parentheses are harmeless. (You're
seeing here the results of an experiment to use uint8_t int64_t etc
instead of u8 and i64; the visual impact of those is greater.)

>> global function os_getdllprocaddr(intm hinst,ichar name)ref proc=
>> record rec=
>> ichar name
>> ref void addr
>> end
>
> Now *that*'s a low-effort way to write a table of function pointers in C.
> Write another language first, then capture the output.

Huh?

>
> Where is the risk in any of this code that a table entry could be called
> directly?

That's an old function that used 'ref proc' as a way to indicate a
generic function pointer. It may have had something to do with problems
generating C code if I'd used 'ref void'; I don't recall.

The current version uses 'ref void' (void*). I no longer support a C target.

> The gaping risk is that something will call the function to look up
> a name, and then misuse it by casting it to the wrong type before
> calling it.

They can always cast things in both languages.

> Obtaining an address from a name with the nicest C code is the least
> important aspect of the whole interpreter design situation.

Yes, that's the easy bit. The hard bit, calling the functions, in 'C'
usually involves a complicated library called LIBFF, which only works
with gcc or compatible compilers since it uses inline ASM.

Bart <bc@freeuk.com> writes:
[...]
> Alternatively we can go with your idea of using a function pointer
> type that cannot be called by accident:
>
> typedef void(*fnptr)(int,int,int,int,int,int);
>
> fnptr functable[]={(fnptr)printf, (fnptr)malloc, (fnptr)fwrite};
>
> Except now gcc complains of casts between incompatible pointer
> types.

That gives me a warning only if I enable gcc's "-Wcast-function-type"
option, which is included in "-Wextra". The code is valid (though as
Kaz points out, you have to store some other information to be able to
use the pointers safely).

Compilers are allowed to warn about anything they like.

> And it has a point. It needs to go through an intermediate
> type:
>
> fnptr functable[]={(fnptr)(uintptr_t)printf,
> (fnptr)(uintptr_t)malloc, (fnptr)(uintptr_t)fwrite};

No, you don't need to go through an intermediate type. The original
code is safe and portable. Your version with the intermediate type is
not (it would fail on an implementation where a function pointer can't
be converted to uintptr_t without loss of information). You've made the
code worse for the sake of avoiding a warning.

Your void* approach was actually better than your uintptr_t approach
(but still not 100% portable, but I know you don't care about that).

[...]

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

Bart <bc@freeuk.com> writes:
[...]
> (Has it never occurred to anyone here how absolutely bizarre it is to
> have that array modifier '[]' /in the middle/ of
> 'void(*functable[])(void)'?)
[...]

It's probably occurred to *everyone* here.

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

On 6/6/2021 5:16 AM, James Harris wrote:
> Does C, as a language, need to allow its structs to have tags?
>
> So could C's struct tags be omitted from the language? If not, what does
> a struct tag add? Is it something to do with forward declarations or
> syntactic consistency with union tags, etc?

The tag is absolutely necessary when you want to declare a
self-referential struct type, like a node in a linked list that must
contain a pointer to the same type.

Just try declaring a linked list node without using a tag. Report to the
forum.

--
Best regards,
Andrey Tarasevich

P.S. Of course, you can get around this by using `void *` pointers and
explicit type casts everywhere, but that would still represent a major
loss of language functionality.

On 17/06/2021 03:39, Andrey Tarasevich wrote:
> On 6/6/2021 5:16 AM, James Harris wrote:
>> Does C, as a language, need to allow its structs to have tags?
>>
>> So could C's struct tags be omitted from the language? If not, what
>> does a struct tag add? Is it something to do with forward declarations
>> or syntactic consistency with union tags, etc?
>
> The tag is absolutely necessary when you want to declare a
> self-referential struct type, like a node in a linked list that must
> contain a pointer to the same type.
>
> Just try declaring a linked list node without using a tag. Report to the
> forum.
>

It's not actually that hard, you just use void*, with the odd cast as
needed:

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

#define While for

typedef struct {
int data;
void* next;
} node;

node *head, *end;

void printlist(void) {
node* p=head;

While (;p; p=p->next) {
printf("%d\n",p->data);
}
}

void addnode(int x) {
node* p=malloc(sizeof(node));
p->data=x;
p->next=NULL;

if (head) {
end->next=p;
} else {
head=p;
}
end=p;
}

int main(void) {
node* p;

addnode(100);
addnode(200);
addnode(300);

printlist();
} ------------------------------------

When a cast is needed, you use (node*). No tags required. It's not as
type-safe, but then blame those stupid tags.

Bart <bc@freeuk.com> writes:

> On 17/06/2021 03:39, Andrey Tarasevich wrote:
>> On 6/6/2021 5:16 AM, James Harris wrote:
>>> Does C, as a language, need to allow its structs to have tags?
>>>
>>> So could C's struct tags be omitted from the language? If not, what does a struct tag add? Is it something to do with forward declarations
>>> or syntactic consistency with union tags, etc?
>> The tag is absolutely necessary when you want to declare a
>> self-referential struct type, like a node in a linked list that must contain a pointer to the same type.
>> Just try declaring a linked list node without using a tag. Report to the
>> forum.
>
> It's not actually that hard, you just use void*, with the odd cast as needed:

> typedef struct {
> int data;
> void* next;
> } node;

> When a cast is needed, you use (node*). No tags required. It's not as
> type-safe, but then blame those stupid tags.

The natural C definition is

struct node {
int data;
struct node *next;
};

Which has served me well for decades. But, if you don't want to call
the type by its natural name, just write

typedef struct node node;
struct node {
int data;
node *next;
};

and live happily ever after. Why would anyone use void * just to avoid
a single use of a struct tag?

--
Ben.

On 17/06/2021 11:50, Ben Bacarisse wrote:
> Bart <bc@freeuk.com> writes:
>
>> On 17/06/2021 03:39, Andrey Tarasevich wrote:
>>> On 6/6/2021 5:16 AM, James Harris wrote:
>>>> Does C, as a language, need to allow its structs to have tags?
>>>>
>>>> So could C's struct tags be omitted from the language? If not, what does a struct tag add? Is it something to do with forward declarations
>>>> or syntactic consistency with union tags, etc?
>>> The tag is absolutely necessary when you want to declare a
>>> self-referential struct type, like a node in a linked list that must contain a pointer to the same type.
>>> Just try declaring a linked list node without using a tag. Report to the
>>> forum.
>>
>> It's not actually that hard, you just use void*, with the odd cast as needed:
>
>> typedef struct {
>> int data;
>> void* next;
>> } node;
>
>> When a cast is needed, you use (node*). No tags required. It's not as
>> type-safe, but then blame those stupid tags.
>
> The natural C definition is
>
> struct node {
> int data;
> struct node *next;
> };
>
> Which has served me well for decades.

I've used linked lists without needing the concept of a 'tag' for
decades too.

But, if you don't want to call
> the type by its natural name, just write
>
> typedef struct node node;
> struct node {
> int data;
> node *next;
> };
>
> and live happily ever after. Why would anyone use void * just to avoid
> a single use of a struct tag?
>

I was responding to the "The tag is absolutely necessary ... " comment.

When I need to write actual C, then I use tags combined with typedef.
The tags are likely to be the same name as the typedef, but with a _ prefix.

When I generated C code, I used tags only without typedef.

When I don't write C, I don't use tags at all, and the language requires
a typedef equivalent. Here, I might occasionally use 'void*' for a
struct pointer when the struct-type involved is not visible.

On 17/06/2021 12:50, Ben Bacarisse wrote:
> Bart <bc@freeuk.com> writes:
>
>> On 17/06/2021 03:39, Andrey Tarasevich wrote:
>>> On 6/6/2021 5:16 AM, James Harris wrote:
>>>> Does C, as a language, need to allow its structs to have tags?
>>>>
>>>> So could C's struct tags be omitted from the language? If not, what does a struct tag add? Is it something to do with forward declarations
>>>> or syntactic consistency with union tags, etc?
>>> The tag is absolutely necessary when you want to declare a
>>> self-referential struct type, like a node in a linked list that must contain a pointer to the same type.
>>> Just try declaring a linked list node without using a tag. Report to the
>>> forum.
>>
>> It's not actually that hard, you just use void*, with the odd cast as needed:
>
>> typedef struct {
>> int data;
>> void* next;
>> } node;
>
>> When a cast is needed, you use (node*). No tags required. It's not as
>> type-safe, but then blame those stupid tags.
>
> The natural C definition is
>
> struct node {
> int data;
> struct node *next;
> };
>
> Which has served me well for decades. But, if you don't want to call
> the type by its natural name, just write
>
> typedef struct node node;
> struct node {
> int data;
> node *next;
> };
>
> and live happily ever after. Why would anyone use void * just to avoid
> a single use of a struct tag?
>

Or if the two declarations are bothersome:

typedef struct node {
int data;
struct node *next;
} node;

Or if the repeated "node" is troublesome :

#define Struct(N) typedef struct N N; struct N

Struct(node) {
int data;
node *next;
};

Of course, that won't work if your aim is to say how problematic C's
flexibility is. And it won't work if you have decided that macros
(except for the silly, confusing and useless "#define While for") are
not to be used.

On 17/06/2021 12:49, David Brown wrote:
> On 17/06/2021 12:50, Ben Bacarisse wrote:
>> Bart <bc@freeuk.com> writes:

>>> When a cast is needed, you use (node*). No tags required. It's not as
>>> type-safe, but then blame those stupid tags.
>>
>> The natural C definition is
>>
>> struct node {
>> int data;
>> struct node *next;
>> };
>>
>> Which has served me well for decades. But, if you don't want to call
>> the type by its natural name, just write
>>
>> typedef struct node node;
>> struct node {
>> int data;
>> node *next;
>> };
>>
>> and live happily ever after. Why would anyone use void * just to avoid
>> a single use of a struct tag?
>>
>
> Or if the two declarations are bothersome:
>
> typedef struct node {
> int data;
> struct node *next;
> } node;
>
>
> Or if the repeated "node" is troublesome :
>
> #define Struct(N) typedef struct N N; struct N
>
> Struct(node) {
> int data;
> node *next;
> };
>

This is good. With this macro, you're 1% along the path of creating a
new, improved language. Although not of course as good as a purpose-made
language, since it sits on top of C:

Your proposal still relies on struct tags. It creates 'node' in two
parallel namespaces. It allows both 'node X' and 'struct node Y'.

It's also not clear how well it works, if at all, with mutually
referential structs.

That is why such macro solutions don't really work. They also suffer
from the problem of everyone developing their own, incompatible workarounds.

> Of course, that won't work if your aim is to say how problematic C's
> flexibility is. And it won't work if you have decided that macros
> (except for the silly, confusing and useless "#define While for") are
> not to be used.

There was a discussion on Reddit about how the C-style loop:

for (A; B; C) D;

was not really equivalent to:

A;
while (B) {
D;
C;
}

because it had different behaviour with 'continue'; with 'for', it would
skip C, but with 'while', it would execute C.

I was saying most such loops, when not obviously performing iteration,
were really just while-loops and should be written as such.

To get around the problem with continue, I proposed a simple extension
to while-loops, acquiring one of the features of C for-loops, to make
them more attractive for such purposes. In my syntax (this wasn't a
specific C-language forum):

while B, C do
D
end

or:

while B do
D
step
C
end

I implemented both as proof-of-concept (and have retained the first as I
couldn't find a more suitable keyword for the second). In C syntax that
first might be:

while (B; C) D

Hence the reason I chose to use While to highlight that this is intended
as a while-loop, and not leave it to the reader to figure out what the
loop was supposed to do.

On 17/06/2021 14:39, Bart wrote:
> On 17/06/2021 12:49, David Brown wrote:
>> On 17/06/2021 12:50, Ben Bacarisse wrote:
>>> Bart <bc@freeuk.com> writes:
>
>>>> When a cast is needed, you use (node*). No tags required. It's not as
>>>> type-safe, but then blame those stupid tags.
>>>
>>> The natural C definition is
>>>
>>>    struct node {
>>>        int data;
>>>        struct node *next;
>>>    };
>>>
>>> Which has served me well for decades.  But, if you don't want to call
>>> the type by its natural name, just write
>>>
>>>    typedef struct node node;
>>>    struct node {
>>>         int data;
>>>         node *next;
>>>    };
>>>
>>> and live happily ever after.  Why would anyone use void * just to avoid
>>> a single use of a struct tag?
>>>
>>
>> Or if the two declarations are bothersome:
>>
>> typedef struct node {
>>     int data;
>>     struct node *next;
>> } node;
>>
>>
>> Or if the repeated "node" is troublesome :
>>
>> #define Struct(N) typedef struct N N; struct N
>>
>> Struct(node) {
>>      int data;
>>      node *next;
>> };
>>
>
> This is good. With this macro, you're 1% along the path of creating a
> new, improved language. Although not of course as good as a purpose-made
> language, since it sits on top of C:

I'm not interested in making a new language, and I don't see this syntax
as being either better or worse than that of C - such details are
irrelevant in practice. It's nothing more than showing how you can
declare recursive structures in C without having to repeat tag or type
names, if such repetition bothers you.

>
> Your proposal still relies on struct tags. It creates 'node' in two
> parallel namespaces. It allows both 'node X' and 'struct node Y'.

No one /cares/. This is not a problem - not in real life, for people
writing real code. It has been somewhat interesting to discuss why C is
the way it is here - history can often be interesting. But no one is
actually concerned about the practice, or thinks there are real
problems, or thinks there is scope for real improvement.

>
> It's also not clear how well it works, if at all, with mutually
> referential structs.
>
> That is why such macro solutions don't really work. They also suffer
> from the problem of everyone developing their own, incompatible
> workarounds.

Macros are fine for this kind of thing if you think it makes the code
clearer. They /do/ work. Of course unnecessary, gratuitous use will be
counter-productive - surely that goes without saying, as it can be
applied to /everything/ in programming, indeed, everything in life.

And I think every serious programmer will be far happier to deal with a
few odd and unnecessary C macros like this to work around "defects" in C
than an entire incompatible home-made language created to avoid such
imaginary defects in C.

>
>> Of course, that won't work if your aim is to say how problematic C's
>> flexibility is.  And it won't work if you have decided that macros
>> (except for the silly, confusing and useless "#define While for") are
>> not to be used.
>
> There was a discussion on Reddit about how the C-style loop:
>
>    for (A; B; C) D;
>
> was not really equivalent to:
>
>    A;
>    while (B) {
>       D;
>       C;
>    }
>
> because it had different behaviour with 'continue'; with 'for', it would
> skip C, but with 'while', it would execute C.

There are other differences.

>
> I was saying most such loops, when not obviously performing iteration,
> were really just while-loops and should be written as such.

If you want to write a "while" loop, C has a construct for that - it's
called "while".

It takes a special kind of perverse delight in causing confusion to
create a macro called "While" that has the meaning of "for" rather than
"while". Please do not do that unless it is in a thread about finding
confusing ways to write code - it just adds more work for others to try
to correct your misunderstandings and explain your mistakes and mixups
so that inexperienced C programmers don't confuse your posts with
reality or good advice.

On 17/06/2021 14:05, David Brown wrote:
> On 17/06/2021 14:39, Bart wrote:

>> This is good. With this macro, you're 1% along the path of creating a
>> new, improved language. Although not of course as good as a purpose-made
>> language, since it sits on top of C:
>
> I'm not interested in making a new language,

Everytime you respond to a flaw or omission by finding a macro
workaround, then you are creating new language elements.

>

>> Your proposal still relies on struct tags. It creates 'node' in two
>> parallel namespaces. It allows both 'node X' and 'struct node Y'.
>
> No one /cares/.

Well, the OP cares. Purists might care: C only has tags now because they
were there to start with. A proper typedef could have done away with
them. Now they're like one of Charles' carbuncles.

This is not a problem - not in real life, for people
> writing real code. It has been somewhat interesting to discuss why C is
> the way it is here - history can often be interesting. But no one is
> actually concerned about the practice, or thinks there are real
> problems, or thinks there is scope for real improvement.
>
>>
>> It's also not clear how well it works, if at all, with mutually
>> referential structs.
>>
>> That is why such macro solutions don't really work. They also suffer
>> from the problem of everyone developing their own, incompatible
>> workarounds.
>
> Macros are fine for this kind of thing if you think it makes the code
> clearer. They /do/ work. Of course unnecessary, gratuitous use will be
> counter-productive - surely that goes without saying, as it can be
> applied to /everything/ in programming, indeed, everything in life.
>
> And I think every serious programmer will be far happier to deal with a
> few odd and unnecessary C macros like this to work around "defects" in C
> than an entire incompatible home-made language created to avoid such
> imaginary defects in C.

Here's how my own 'macro' works, here defining mutually referential structs:

record node=
int data
ref node2 nextnode
end

record node2=
real data
ref node nextnode
end

It can be 'preprocessed' to normal C code full of struct tags and
whatnot. But:

* It uses syntax in line with the rest of the language
* It doesn't need to drag in a macro definition
* It only allows 'node' etc to be used, not 'struct node'
* It doesn't create a parallel 'node' symbol in another namespace
* It works fine with circular or mutual references (these can be in
either order)

> If you want to write a "while" loop, C has a construct for that - it's
> called "while".

Which hardly anybody uses! Nearly all for-loops I see that aren't
clearly an iteration are really just while-loops.

Most of them don't use 'continue' either so the minor discrepancy I
mentioned is not relevant.

> It takes a special kind of perverse delight in causing confusion

.... by writing an obvious while loop as a for-loop. The tweak I
suggested can encourage more people to use the more appropriate kind of
loop.

On 6/17/2021 3:29 AM, Bart wrote:
> On 17/06/2021 03:39, Andrey Tarasevich wrote:
>> On 6/6/2021 5:16 AM, James Harris wrote:
>>> Does C, as a language, need to allow its structs to have tags?
>>>
>>> So could C's struct tags be omitted from the language? If not, what
>>> does a struct tag add? Is it something to do with forward
>>> declarations or syntactic consistency with union tags, etc?
>>
>> The tag is absolutely necessary when you want to declare a
>> self-referential struct type, like a node in a linked list that must
>> contain a pointer to the same type.
>>
>> Just try declaring a linked list node without using a tag. Report to
>> the forum.
>>
>
> It's not actually that hard, you just use void*, with the odd cast as
> needed:

As I explicitly stated in the post you were responding to:

> P.S. Of course, you can get around this by using `void *` pointers
and explicit type casts everywhere, but that would still represent a
major loss of language functionality.

And that is basically the answer to the original question: C language
_needs_ struct tags to avoid having to "just use void*, with the odd
cast as needed". Having to do the latter would, of course, be an
abomination.

--
Best regards,
Andrey Tarasevich

Bart <bc@freeuk.com> writes:

> On 17/06/2021 11:50, Ben Bacarisse wrote:
>> Bart <bc@freeuk.com> writes:
>>
>>> On 17/06/2021 03:39, Andrey Tarasevich wrote:
>>>> On 6/6/2021 5:16 AM, James Harris wrote:
>>>>> Does C, as a language, need to allow its structs to have tags?
>>>>>
>>>>> So could C's struct tags be omitted from the language? If not, what does a struct tag add? Is it something to do with forward declarations
>>>>> or syntactic consistency with union tags, etc?
>>>> The tag is absolutely necessary when you want to declare a
>>>> self-referential struct type, like a node in a linked list that must contain a pointer to the same type.
>>>> Just try declaring a linked list node without using a tag. Report to the
>>>> forum.
>>>
>>> It's not actually that hard, you just use void*, with the odd cast as needed:
>>
>>> typedef struct {
>>> int data;
>>> void* next;
>>> } node;
>>
>>> When a cast is needed, you use (node*). No tags required. It's not as
>>> type-safe, but then blame those stupid tags.
>> The natural C definition is
>> struct node {
>> int data;
>> struct node *next;
>> };
>> Which has served me well for decades.
>
> I've used linked lists without needing the concept of a 'tag' for
> decades too.

But not in C, or do really use void * to avoid the canonical form?

>> But, if you don't want to call
>> the type by its natural name, just write
>> typedef struct node node;
>> struct node {
>> int data;
>> node *next;
>> };
>> and live happily ever after. Why would anyone use void * just to avoid
>> a single use of a struct tag?
>
> I was responding to the "The tag is absolutely necessary ... "
> comment.

I know. I just wanted to make sure no one took the void * idea
seriously by showing what everyone else does.

--
Ben.

On 2021-06-17, Andrey Tarasevich <andreytarasevich@hotmail.com> wrote:
> On 6/17/2021 3:29 AM, Bart wrote:
>> On 17/06/2021 03:39, Andrey Tarasevich wrote:
>>> On 6/6/2021 5:16 AM, James Harris wrote:
>>>> Does C, as a language, need to allow its structs to have tags?
>>>>
>>>> So could C's struct tags be omitted from the language? If not, what
>>>> does a struct tag add? Is it something to do with forward
>>>> declarations or syntactic consistency with union tags, etc?
>>>
>>> The tag is absolutely necessary when you want to declare a
>>> self-referential struct type, like a node in a linked list that must
>>> contain a pointer to the same type.
>>>
>>> Just try declaring a linked list node without using a tag. Report to
>>> the forum.
>>>
>>
>> It's not actually that hard, you just use void*, with the odd cast as
>> needed:
>
> As I explicitly stated in the post you were responding to:
>
> > P.S. Of course, you can get around this by using `void *` pointers
> and explicit type casts everywhere, but that would still represent a
> major loss of language functionality.
>
> And that is basically the answer to the original question: C language
> _needs_ struct tags to avoid having to "just use void*, with the odd
> cast as needed". Having to do the latter would, of course, be an
> abomination.

But that's literally untrue true.

C programs need struct tags according to the design of the C language
we are stuck with. The language doesn't need it; the design is not
necessary, and even the C++ dialect shows that:

struct node {
node *next, *prev; // not a reference to the tag namespace
};

While that is a valid point, it is nonproductive and off-topic.

BartC likes to turn every discussion into some unproductive banter with
no useful outcome, about how C could be (or could have been) something else,
but without any concrete action plan to do anything about it.

It is unclear what outcome he's looking for, but judging by the history,
he seems satisfied with amusing himself by insulting comp.lang.c users
by insisting that they do not know any other language and cannot imagine
language design variations or features outside of the C design due
to the proverbial blinders on their eyes, in contrast to his amazingly
broad perspective gained from working on his special language projects
(which have no public repo, no documentation, no test cases, no users).

When you make careless comments like that the C language needs tags for
self-reference in declarations, you're just playing into that.

--
TXR Programming Language: http://nongnu.org/txr
Cygnal: Cygwin Native Application Library: http://kylheku.com/cygnal

On 17/06/2021 15:34, Bart wrote:
> On 17/06/2021 14:05, David Brown wrote:
>> On 17/06/2021 14:39, Bart wrote:
>
>>> This is good. With this macro, you're 1% along the path of creating a
>>> new, improved language. Although not of course as good as a purpose-made
>>> language, since it sits on top of C:
>>
>> I'm not interested in making a new language,
>
> Everytime you respond to a flaw or omission by finding a macro
> workaround, then you are creating new language elements.

First, I am not responding to a "flaw" or an "omission" - I am
responding to your desires (or at least your post) to make linked lists
without struct tags. I don't see any flaws or omissions in the C
language here - people have used the language to make linked lists
without any trouble.

Secondly, macros are part of the language - they are not making "new
language elements" any more than defining a function would be.

>
>>
>
>>> Your proposal still relies on struct tags. It creates 'node' in two
>>> parallel namespaces. It allows both 'node X' and 'struct node Y'.
>>
>> No one /cares/.
>
> Well, the OP cares. Purists might care: C only has tags now because they
> were there to start with. A proper typedef could have done away with
> them. Now they're like one of Charles' carbuncles.
>

If the language had been designed differently, it would have been
different. Well, now we know that.

As for "purists" - pure what?

And no, the OP does not care if C has struct tags or not - he was
curious as to whether they are necessary or not, and why the language
has them. That is completely different. (I am often curious about why
C has or does not have particular features, even though I might be quite
happy either way.)

>   This is not a problem - not in real life, for people
>> writing real code.  It has been somewhat interesting to discuss why C is
>> the way it is here - history can often be interesting.  But no one is
>> actually concerned about the practice, or thinks there are real
>> problems, or thinks there is scope for real improvement.
>>
>>>
>>> It's also not clear how well it works, if at all, with mutually
>>> referential structs.
>>>
>>> That is why such macro solutions don't really work. They also suffer
>>> from the problem of everyone developing their own, incompatible
>>> workarounds.
>>
>> Macros are fine for this kind of thing if you think it makes the code
>> clearer.  They /do/ work.  Of course unnecessary, gratuitous use will be
>> counter-productive - surely that goes without saying, as it can be
>> applied to /everything/ in programming, indeed, everything in life.
>>
>> And I think every serious programmer will be far happier to deal with a
>> few odd and unnecessary C macros like this to work around "defects" in C
>> than an entire incompatible home-made language created to avoid such
>> imaginary defects in C.
>
> Here's how my own 'macro' works, here defining mutually referential
> structs:
>
>     record node=
>         int data
>         ref node2 nextnode
>     end
>
>     record node2=
>         real data
>         ref node nextnode
>     end
>
> It can be 'preprocessed' to normal C code full of struct tags and
> whatnot. But:
>
> * It uses syntax in line with the rest of the language
> * It doesn't need to drag in a macro definition
> * It only allows 'node' etc to be used, not 'struct node'
> * It doesn't create a parallel 'node' symbol in another namespace
> * It works fine with circular or mutual references (these can be in
> either order)
>

Oh, that's just incredible! I imagine your language features here have
saved at least /minutes/ of your programming life, compared to writing
them in C!

>
>> If you want to write a "while" loop, C has a construct for that - it's
>> called "while".
>
> Which hardly anybody uses! Nearly all for-loops I see that aren't
> clearly an iteration are really just while-loops.

Your opinions as to what you think people use in C are not something I
consider realistic or valuable.

>
> Most of them don't use 'continue' either so the minor discrepancy I
> mentioned is not relevant.
>
>> It takes a special kind of perverse delight in causing confusion
>
> ... by writing an obvious while loop as a for-loop. The tweak I
> suggested can encourage more people to use the more appropriate kind of
> loop.
>

If it is a while loop, write "while". That's what C programmers do.

On 17/06/2021 17:22, Kaz Kylheku wrote:
> On 2021-06-17, Andrey Tarasevich <andreytarasevich@hotmail.com> wrote:

> BartC likes to turn every discussion into some unproductive banter with
> no useful outcome, about how C could be (or could have been) something else,
> but without any concrete action plan to do anything about it.

(That is not true. I've created several alternatives over approx 40
years, for in-house or personal use. Although they weren't really
alternatives for at least the first 15 years.

The problem is no one is interested in alternatives, and I don't think
anyone here has to the power to actually change the language anyway.
(Besides, with C being so firmly ensconced as part of Unix and Linux, it
isn't going anywhere.)

But what some people might have been able to do far better than me - 20+
years ago would have been better - is to have created an up-to-date
systems language of a similar ilk, something I would have respected a
lot more, that would have become mainstream, and without losing many of
the traits that are needed.

Instead we end up with ones like Rust and Zig that things harder rather
than easier. Zig (2019 version) even banished newlines from source code!
(CRLF newlines weren't allowed; they had to be LF only. CRLF have since
been allowed; but it still bans hard tabs.))

> It is unclear what outcome he's looking for, but judging by the history,
> he seems satisfied with amusing himself by insulting comp.lang.c users

I make a point of never insulting anybody online unless they get personal.

> by insisting that they do not know any other language and cannot imagine
> language design variations or features outside of the C design due
> to the proverbial blinders on their eyes, in contrast to his amazingly
> broad perspective gained from working on his special language projects
> (which have no public repo, no documentation, no test cases, no users).
>
> When you make careless comments like that the C language needs tags for
> self-reference in declarations, you're just playing into that.

This was the challenge:

AT:
> Just try declaring a linked list node without using a tag. Report to
> the forum.

I responded to it, and supplied example /C/ code.

On 17/06/2021 17:35, David Brown wrote:
> On 17/06/2021 15:34, Bart wrote:

>> Which hardly anybody uses! Nearly all for-loops I see that aren't
>> clearly an iteration are really just while-loops.
>
> Your opinions as to what you think people use in C are not something I
> consider realistic or valuable.

It isn't what I think, it's what I see.

Not everyone writes code like David Brown. Or me.

> If it is a while loop, write "while". That's what C programmers do.

If only! Every time I look aat for-loop in other people's code, I have
to analyse it to figure exactly what it is. Here's a case in point:

for (n = num, len = 0; (! len && ! n) || n > 0; len++) {

Le 17/06/2021 à 17:22, Andrey Tarasevich a écrit :
> On 6/17/2021 3:29 AM, Bart wrote:
>> On 17/06/2021 03:39, Andrey Tarasevich wrote:
>>> On 6/6/2021 5:16 AM, James Harris wrote:
>>>> Does C, as a language, need to allow its structs to have tags?
>>>>
>>>> So could C's struct tags be omitted from the language? If not, what
>>>> does a struct tag add? Is it something to do with forward
>>>> declarations or syntactic consistency with union tags, etc?
>>>
>>> The tag is absolutely necessary when you want to declare a
>>> self-referential struct type, like a node in a linked list that must
>>> contain a pointer to the same type.
>>>
>>> Just try declaring a linked list node without using a tag. Report to
>>> the forum.
>>>
>>
>> It's not actually that hard, you just use void*, with the odd cast as
>> needed:
>
> As I explicitly stated in the post you were responding to:
>
> > P.S. Of course, you can get around this by using `void *` pointers
> and explicit type casts everywhere, but that would still represent a
> major loss of language functionality.
>
> And that is basically the answer to the original question: C language
> _needs_ struct tags to avoid having to "just use void*, with the odd
> cast as needed". Having to do the latter would, of course, be an
> abomination.

Yup. Using void * can be powerful but bypasses type checking, and not
only that, but you also lose the self-documentation a proper type provides.

Regarding casts, they are usually not needed though if you always assign
the void * pointer (for instance here, the 'next' member) to a pointer
to the struct, and conversely.

So if your pointer to node is 'Node', for instance, something like 'Node
= Node->next' is perfectly valid without any cast. Or 'Node2->next = Node1'.

Casts would be needed if you directly want to access a member from the
'next' pointer, but there are lots of ways to avoid that, so that point
is relatively moot.

On 2021-06-17, Bart <bc@freeuk.com> wrote:
> On 17/06/2021 17:22, Kaz Kylheku wrote:
>> On 2021-06-17, Andrey Tarasevich <andreytarasevich@hotmail.com> wrote:
>
>
>> BartC likes to turn every discussion into some unproductive banter with
>> no useful outcome, about how C could be (or could have been) something else,
>> but without any concrete action plan to do anything about it.
>
> (That is not true. I've created several alternatives over approx 40
> years, for in-house or personal use. Although they weren't really
> alternatives for at least the first 15 years.

That is not doing anything the problem of what C is, from the
perspective of people who are stuck using it, who come to the newsgroup
to discuss about how to use it.

> The problem is no one is interested in alternatives, and I don't think

No, that isn't the problem. People are absolutely keenly interested in
alternatives and using them. Anyone who is using Rust, or C++, or Go
is probably interested in C alternatives.

Some people using C are also interested in C alternatives, but
for whatever pragmatic reasons are using C anyway.

People don't go to a comp.lang.c newsgroup to discuss alternatives
though; we know where to find alternatives and get help.

> anyone here has to the power to actually change the language anyway.

If you don't seize the power, you will never have the power.

I believe I have the power to change C; if I really wanted to badly
enough, I could avail myself of that influence.

I would form a plan, identify the roadblocks in it and work on removing
them one by one.

Changing C is a procedure, a task. Every task has a finite number of
steps. First you have to figure out what they are. You might start with
the wrong ones. Once you are on the right track though, it's just a
matter of taking the first step, then the second and so on.

(If the change idea is unreasonable, though, there will likely be an
impassable roadblock. Changes are generally expected to be thoroughly
backward compatible, so that the vast majority existing programs compile
and have an unaltered behavior, and the remainder are only in some
dubious bucket we are willing to throw under the bus.)

> (Besides, with C being so firmly ensconced as part of Unix and Linux, it
> isn't going anywhere.)

That is false; the bleeding edge of C is changing, and the GNU C
Compiler Collection project is actively maintained, cranking out new
releases.

> But what some people might have been able to do far better than me - 20+
> years ago would have been better - is to have created an up-to-date

20 years ago isn't coming back though.

> Instead we end up with ones like Rust and Zig that things harder rather
> than easier.

These projects have their reasons though. They are real things in the
real world.

You can download them from a repo, build them, and run a test suite.

You can join a mailing list, web forum or IRC channel or whatever and
meet others users.

If you don't think Rust and Zig are the answer, the only way is to
compete with your own, join those projects to steer their direction, or
else forever be complaining that people are making all these various C
replacements, but not doing it how you would like.

--
TXR Programming Language: http://nongnu.org/txr
Cygnal: Cygwin Native Application Library: http://kylheku.com/cygnal

On 17/06/2021 18:53, Kaz Kylheku wrote:
> On 2021-06-17, Bart <bc@freeuk.com> wrote:

[C alternatives]

> If you don't think Rust and Zig are the answer, the only way is to
> compete with your own, join those projects to steer their direction, or
> else forever be complaining that people are making all these various C
> replacements, but not doing it how you would like.

It isn't really for me. I'm stuck with using my languages for the same
reason I'd be stuck working as self-employed, if I was still working.

But I constantly see the problems people have with C, not here much,
usenet is pretty much dead, but in places like reddit and others, a lot
of things which would otherwise have been a piece of cake if the
language had done things properly.

I just really feel sorry for them, as I can't help.

Many of these are small things that do not warrant switching to a
totally new and very different language (which would introduce 100 new
problems).

But let's take one example of something posted here, someone wanted to
print this:

printf("UINT64_MAX : %lld\n", UINT64_MAX);

C has made it fashionable to make this stuff much harder than it need be
(Zig is worse than C for printing). The full solution for this was (see
stdint.h thread):

#include <stdio.h> # needed for printf
#include <stdint.h> # needed for UINT64_MAX and for inttypes.h

printf("UINT64_MAX : " PRId64 "\n", UINT64_MAX);

(It will be something alone those lines; I'm not going to bother
checking it.)

Basically, they needed to print a number to the console, something that
in the 1970s would have been utterly trivial:

print x

On Thursday, 17 June 2021 at 23:27:54 UTC+3, Bart wrote:
> On 17/06/2021 18:53, Kaz Kylheku wrote:
> > On 2021-06-17, Bart <b...@freeuk.com> wrote:
>
> [C alternatives]
> > If you don't think Rust and Zig are the answer, the only way is to
> > compete with your own, join those projects to steer their direction, or
> > else forever be complaining that people are making all these various C
> > replacements, but not doing it how you would like.
> It isn't really for me. I'm stuck with using my languages for the same
> reason I'd be stuck working as self-employed, if I was still working.
>
> But I constantly see the problems people have with C, not here much,
> usenet is pretty much dead, but in places like reddit and others, a lot
> of things which would otherwise have been a piece of cake if the
> language had done things properly.
>
> I just really feel sorry for them, as I can't help.
>
> Many of these are small things that do not warrant switching to a
> totally new and very different language (which would introduce 100 new
> problems).
>
> But let's take one example of something posted here, someone wanted to
> print this:
>
> printf("UINT64_MAX : %lld\n", UINT64_MAX);
>
> C has made it fashionable to make this stuff much harder than it need be
> (Zig is worse than C for printing). The full solution for this was (see
> stdint.h thread):
>
> #include <stdio.h> # needed for printf
> #include <stdint.h> # needed for UINT64_MAX and for inttypes.h
>
> printf("UINT64_MAX : " PRId64 "\n", UINT64_MAX);
>
> (It will be something alone those lines; I'm not going to bother
> checking it.)

You did not use %:

printf("%" PRId64 "\n", UINT64_MAX);

Yes such not overly trivial way, but trivial enough.

> Basically, they needed to print a number to the console, something that
> in the 1970s would have been utterly trivial:
>
> print x

In the 1970s what is currently called 'UINT64_MAX' was utterly trivially
called 'x'? I think you misremember.

The trouble only starts when you output UINT64_MAX as you will see that
all these excels and libreoffices to where someone might want to paste
it fail to process it. They fail gracefully and silently by showing wrong
results. So you will need more C and more C.

On 18/06/2021 01:58, Öö Tiib wrote:
> On Thursday, 17 June 2021 at 23:27:54 UTC+3, Bart wrote:

>> But let's take one example of something posted here, someone wanted to
>> print this:
>>
>> printf("UINT64_MAX : %lld\n", UINT64_MAX);
>>
>> C has made it fashionable to make this stuff much harder than it need be
>> (Zig is worse than C for printing). The full solution for this was (see
>> stdint.h thread):
>>
>> #include <stdio.h> # needed for printf
>> #include <stdint.h> # needed for UINT64_MAX and for inttypes.h
>>
>> printf("UINT64_MAX : " PRId64 "\n", UINT64_MAX);
>>
>> (It will be something alone those lines; I'm not going to bother
>> checking it.)
>
> You did not use %:
>
> printf("%" PRId64 "\n", UINT64_MAX);
>
> Yes such not overly trivial way, but trivial enough.

You helped make my point for me. What a palaver to just print a number!
And so easy to get wrong.

>> Basically, they needed to print a number to the console, something that
>> in the 1970s would have been utterly trivial:
>>
>> print x
>
> In the 1970s what is currently called 'UINT64_MAX' was utterly trivially
> called 'x'? I think you misremember.

UINT64_MAX is just a number. That is not the main issue here. Given the
existence of such a value, you should be able to do:

print UINT64_MAX

plus whatever extra syntax the language requires. #includes, inttype.h,
"%" and "PRId64" is not mere syntax.

To get on to the MAX part, If I do this in my language, it is just:

println =u64.max

..max can be applied to any integer type or expression. The "=" adds the
label that is present in the C. The output is:

MAX(U64)= 18446744073709551615

> The trouble only starts when you output UINT64_MAX as you will see that
> all these excels and libreoffices to where someone might want to paste
> it fail to process it. They fail gracefully and silently by showing wrong
> results. So you will need more C and more C.

How is this relevant? A language shouldn't allow you to just write:

print(a)

because some extreme values of a, IF you were to paste them elsewhere,
might cause problems with buggy software? How would adding more C fix that?

When I paste this value, it is just a string anyway. BTW here's the next
one up:

println =u128.max

It shows:

MAX(U128)= 340282366920938463463374607431768211455

A u128 type is merely double the word size of the current crop of 64-bit
machines. A systems language should deal with this stuff effortlessly.

If I paste /that/ value into Google, I get a list of 128-bit resources.

John Bode <jfbode1029@gmail.com> writes:

[...]

> To reiterate a point I make a lot - typedef on its own creates leaky
> abstractions. If I need to know that I have to use the `.` or `->`
> operator on something, I'd rather have it declared as `struct A foo;` or
> `struct B *ptr;` instead of a type name that doesn't convey struct-ness
> at all. Same reason I don't like it when people hide pointers behind
> typedefs - I once spent half a day chasing my tail because somebody
> created a typedef name for a pointer type and used that as a template
> parameter for a vector in C++, such that when I was using an iterator
> I needed to write
>
> (*it)->do_something();
>
> However, since the typedef name didn't indicate pointer-ness *at all*, I
> wound up writing
>
> it->do_something();
>
> and g++ vomited up hundreds of incomprehensible error messages that
> basically boiled down to "you need to use a * here, dummy".

Sounds to me like the culprit is C++, not typedefs.

On Thursday, 24 June 2021 at 20:33:12 UTC+3, Tim Rentsch wrote:
> John Bode <jfbod...@gmail.com> writes:
>
> [...]
>
> > To reiterate a point I make a lot - typedef on its own creates leaky
> > abstractions. If I need to know that I have to use the `.` or `->`
> > operator on something, I'd rather have it declared as `struct A foo;` or
> > `struct B *ptr;` instead of a type name that doesn't convey struct-ness
> > at all. Same reason I don't like it when people hide pointers behind
> > typedefs - I once spent half a day chasing my tail because somebody
> > created a typedef name for a pointer type and used that as a template
> > parameter for a vector in C++, such that when I was using an iterator
> > I needed to write
> >
> > (*it)->do_something();
> >
> > However, since the typedef name didn't indicate pointer-ness *at all*, I
> > wound up writing
> >
> > it->do_something();
> >
> > and g++ vomited up hundreds of incomprehensible error messages that
> > basically boiled down to "you need to use a * here, dummy".
>
> Sounds to me like the culprit is C++, not typedefs.

It is good old issue of three star programmers (that both C and C++
share) and on given case it was additionally obfuscated by using typedef
of pointer. By most C coding guidelines I've seen it is advised not to
typedef pointers that are meant to be dereferenced.

On 6/24/21 12:33 PM, Tim Rentsch wrote:
> John Bode <jfbode1029@gmail.com> writes:
>
> [...]
>
>> To reiterate a point I make a lot - typedef on its own creates leaky
>> abstractions. If I need to know that I have to use the `.` or `->`
>> operator on something, I'd rather have it declared as `struct A foo;` or
>> `struct B *ptr;` instead of a type name that doesn't convey struct-ness
>> at all. Same reason I don't like it when people hide pointers behind
>> typedefs - I once spent half a day chasing my tail because somebody
>> created a typedef name for a pointer type and used that as a template
>> parameter for a vector in C++, such that when I was using an iterator
>> I needed to write
>>
>> (*it)->do_something();
>>
>> However, since the typedef name didn't indicate pointer-ness *at all*, I
>> wound up writing
>>
>> it->do_something();
>>
>> and g++ vomited up hundreds of incomprehensible error messages that
>> basically boiled down to "you need to use a * here, dummy".
>
> Sounds to me like the culprit is C++, not typedefs.
>

g++ doesn't handle errors in template parameters very well and generates
a *lot* of hard-to-follow error messages for relatively simple mistakes.
And at the time I was still relatively inexperienced with C++, which
didn't help.

But the typedef name (or, more properly, the incomplete and leaky
abstraction introduced by that typedef name) was the actual culprit.
Again, there was nothing to tell me that I was iterating over a vector
of *pointers*, not a vector of instances, which required me to use
different syntax.

With better error messages I would have figured it out in a few minutes
rather than half a day, but it was still time lost to a leaky
abstraction.

That was an egregious case, but far from the only one. Hiding pointers
and struct types behind typedefs without an API to handle pointer and
member selection operations for you is unambiguously bad practice, and
people need to stop doing it.