Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.c > #400007 > unrolled thread

Re: Co-routines (was Re: acquire + sleep + async)

Back to article view | Back to comp.lang.c

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.

Contents

  Re: Co-routines (was Re: acquire + sleep + async) Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-06-12 13:45 -0700
    Re: Co-routines (was Re: acquire + sleep + async) Bart <bc@freeuk.com> - 2026-06-13 01:03 +0100
      Re: Co-routines (was Re: acquire + sleep + async) Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-06-12 17:50 -0700
        Re: Co-routines (was Re: acquire + sleep + async) Bart <bc@freeuk.com> - 2026-06-13 11:03 +0100
          Re: Co-routines (was Re: acquire + sleep + async) tTh <tth@none.invalid> - 2026-06-13 12:14 +0200
            Re: Co-routines (was Re: acquire + sleep + async) Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-06-13 14:35 +0200
              Re: Co-routines (was Re: acquire + sleep + async) Bart <bc@freeuk.com> - 2026-06-13 14:38 +0100
                Re: Co-routines (was Re: acquire + sleep + async) Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-06-13 16:46 -0700
                  Re: Co-routines (was Re: acquire + sleep + async) Bart <bc@freeuk.com> - 2026-06-14 01:25 +0100
                    Re: Co-routines (was Re: acquire + sleep + async) Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-06-13 18:26 -0700
                      Re: Co-routines (was Re: acquire + sleep + async) Bart <bc@freeuk.com> - 2026-06-14 12:28 +0100
                        Re: Co-routines (was Re: acquire + sleep + async) Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-06-14 15:01 -0700
                Re: Co-routines (was Re: acquire + sleep + async) Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-06-22 19:46 +0200
                  Re: Co-routines (was Re: acquire + sleep + async) scott@slp53.sl.home (Scott Lurndal) - 2026-06-22 21:24 +0000
                    Re: Co-routines (was Re: acquire + sleep + async) Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-06-23 01:16 +0200
                    Re: Co-routines (was Re: acquire + sleep + async) Tim Rentsch <tr.17687@z991.linuxsc.com> - 2026-08-14 12:45 -0700
          Re: Co-routines (was Re: acquire + sleep + async) Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-06-13 03:48 -0700

#400007 — Re: Co-routines (was Re: acquire + sleep + async)

Bart <bc@freeuk.com> writes:
[...]
> It's still quite primitive.
>
> Some bits have been more standardised. Some 'improvements' have been
> done crudely and without touching the core language, for example by
> bolting on stuff via extra headers.

What you call "crude", I call taking advantage of existing language
features to add new functionality without having to change the
core language.

The uint32_t et al types could have been added as keywords
(even, as you would no doubt have preferred, with different
names), but it wasn't necessary to do so.  Defining them in
a header made it possible to duplicate the functionality for
use with pre-C99 compilers; see for example Doug Gwyn's q8,
<https://www.lysator.liu.se/c/q8/index.html>.  (And if you think the
fixed-width types are in some sense more fundamental than short,
int, long et al, and the former should be keywords and the latter
should be typedefs, that's a valid opinion, but C isn't going to
make that particular change.)

When C added complex number support, it was done as a core language
feature because the language didn't provide the facilities to define
it in a header.  C++ did it in a header, because it was possible
to do so.

[...]

> Regarding compound literals, why is one necessary when assigning to
> 'q' here:
>
>     typedef struct {double x, y;} Point;
>
>     Point p = {10, 20};
>     Point q;
>           q = (Point){30, 40};
>
> The initialisation of 'p' doesn't need it, so can't you just do this:
>
>           q = {30, 40};

Because an initializer is evaluated in a context that depends on the
type of the object being initialized, but an expression, even if it's
the RHS of an assignment, is not.

In almost all cases, the type and semantics of an expression (even if
it's a subexpression) are fully determined by the expression itself,
not by the context in which it appears.  42 is of type int, even when
it's assigned to a floating-point object; the assignment imposes a
conversion.

In `Point p = {10, 20};`, the initializer is evaluated in a context
where the compiler knows that the result type is Point.

In `p = {10, 20};`, if it weren't a syntax error, the compiler
would not (be required to) know that {10, 20} is being assigned
to an object of type Point.  It could be some other struct type,
or an array.

There are languages that work differently.  In Ada, for example, the
equivalent `P := (10, 20);` is valid, because the RHS is evaluated
in a context that takes the type of the LHS into account.  (10, 20)
is a valid expression in Ada, and its type depends on its context.
(Ada doesn't have expression statements, so there always a context.)

When compound literals were added to the language, there were several
options:

1. Rework expression evaluation so that the type of an expression
   depends on its context.  Specify that a braced-initializer is a
   kind of expression.  Write several pages of standardese specifying
   exactly when and how this happens.  Then `p = {10, 20};` is
   valid, and `{10, 20}` is of type Point.  Presumably an expression
   statement `{10, 20};` would be a constraint violation, because
   there's no context to determine its type.  Decide whether
   `ptr = &{10, 20};` determines the type of `{10, 20}` or not.
   Argue for years about whether this breaks existing code, and
   how much of a problem that is.

2. A special-case version of the above, where a braced initializer
   is an expression, and its type is determined by its context.
   Write several pages of standardese specifying exactly how
   the context determines the type and the cases where the type
   can't be determined and therefore a constraint is violated.
   Contexts include the RHS of an assignment, a function argument,
   and so on.  Specify that a braced initializer that is, or
   is part of, an initializer is *not* an expression (otherwise
   `int arr[2] = {10, 20};` would become invalid) -- but maybe
   a parenthesized braced-initializer expression can be used
   in an initializer?  Argue for years about that.

3. Make the syntax of a compound literal just a little more
   explicit, consisting of a parenthesized type name followed a
   braced initializer, so the type must be specified rather than
   inferred.

-- 
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
void Void(void) { Void(); } /* The recursive call of the void */

[toc] | [next] | [standalone]

#400014

On 12/06/2026 21:45, Keith Thompson wrote:
> Bart <bc@freeuk.com> writes:
> [...]
>> It's still quite primitive.
>>
>> Some bits have been more standardised. Some 'improvements' have been
>> done crudely and without touching the core language, for example by
>> bolting on stuff via extra headers.
> 
> What you call "crude", I call taking advantage of existing language
> features to add new functionality without having to change the
> core language.
> 
> The uint32_t et al types could have been added as keywords
> (even, as you would no doubt have preferred, with different
> names), but it wasn't necessary to do so.

It's a poor approach:

* Those types don't exist unless stdint.h is present. That means anyone
   could define their own non-compatible versions

* Even if stdint.h is used, people could still shadow the names for
   their own purposes

* Whether a particular stdint type is exactly compatible with a built-in
   type can vary between implementations, causing problems with _Generic
   for example

* There are problems with literals for such types, and printf support,
   necessitating an auxiliary intypes.h header with lots of ugly macros.

So, yeah it's crude. I also don't see the advantage of not changing the 
core language. Such changes were needed in C99 anyway in order to 
support VLA, variable modified types, compound literals, designated 
initialiser, probably some other stuff.

Building in those types was arguably simpler than most of those. And 
advantage could have been taken to introduce a built-in way of getting 
integer limits (say _Minvalue(T) and _Maxvalue(T)), or even _Minvalue(X) 
etc), instead of dedicated macros for every conceivable type.

And this is just one feature.


>  Defining them in
> a header made it possible to duplicate the functionality for
> use with pre-C99 compilers; see for example Doug Gwyn's q8,
> <https://www.lysator.liu.se/c/q8/index.html>.

Everyone made their arrangements anyway. Many still do.

   (And if you think the

>> Regarding compound literals, why is one necessary when assigning to
>> 'q' here:
>>
>>      typedef struct {double x, y;} Point;
>>
>>      Point p = {10, 20};
>>      Point q;
>>            q = (Point){30, 40};
>>
>> The initialisation of 'p' doesn't need it, so can't you just do this:
>>
>>            q = {30, 40};
> 
> Because an initializer is evaluated in a context that depends on the
> type of the object being initialized, but an expression, even if it's
> the RHS of an assignment, is not.

> In almost all cases, the type and semantics of an expression (even if
> it's a subexpression) are fully determined by the expression itself,
> not by the context in which it appears.  42 is of type int, even when
> it's assigned to a floating-point object; the assignment imposes a
> conversion.
> 
> In `Point p = {10, 20};`, the initializer is evaluated in a context
> where the compiler knows that the result type is Point.
> 
> In `p = {10, 20};`, if it weren't a syntax error,

It wouldn't be if allowed.

> the compiler
> would not (be required to) know that {10, 20} is being assigned
> to an object of type Point.  It could be some other struct type,
> or an array.

And?

I use the term 'closed' for an expression that occurs in a known 
context: something will be done with it and the type is known (pass to a 
function, assign to a variable, cast it to T etc).

And 'open' for an expression that is not used for anything and so there 
is no final type to conform too. Here:

    q = {30, 40};

The RHS is closed. By itself, it's some generic constructor, but it is 
being assigned to 'q', so it knows it is supposed to be a Point type.

> There are languages that work differently.  In Ada, for example, the
> equivalent `P := (10, 20);` is valid, because the RHS is evaluated
> in a context that takes the type of the LHS into account.  (10, 20)
> is a valid expression in Ada, and its type depends on its context.
> (Ada doesn't have expression statements, so there always a context.)
> 
> When compound literals were added to the language, there were several
> options:
> 
> 1. Rework expression evaluation so that the type of an expression
>     depends on its context.
?  Specify that a braced-initializer is a
>     kind of expression.  Write several pages of standardese specifying
>     exactly when and how this happens.  Then `p = {10, 20};` is
>     valid, and `{10, 20}` is of type Point.  Presumably an expression
>     statement `{10, 20};` would be a constraint violation, because
>     there's no context to determine its type.  Decide whether
>     `ptr = &{10, 20};` determines the type of `{10, 20}` or not.
>     Argue for years about whether this breaks existing code, and
>     how much of a problem that is.
> 
> 2. A special-case version of the above, where a braced initializer
>     is an expression, and its type is determined by its context.
>     Write several pages of standardese specifying exactly how
>     the context determines the type and the cases where the type
>     can't be determined and therefore a constraint is violated.

This need not be as hard as you make out.

{...} used for initialising is already different.

There is a possible ambiguity where {...} is used for a compound 
statement, but it could also be a data constructor. But I think that can 
be solved because {...} used for data happens in value-returning contexts.

>     Contexts include the RHS of an assignment, a function argument,
>     and so on.  Specify that a braced initializer that is, or
>     is part of, an initializer is *not* an expression (otherwise
>     `int arr[2] = {10, 20};` would become invalid) -- but maybe
>     a parenthesized braced-initializer expression can be used
>     in an initializer? 


I use parentheses (see below); it seems to work. One small issue is when 
there is only one data element, then I need to write (10,) instead of 
(10), which looks like a scalar expression.

That could probably be fixed, but it wouldn't happen with {10}.

------------------------------
     record point = (real x, y)

     point p := (10, 20)
     point q
           q := (30, 40)

[toc] | [prev] | [next] | [standalone]

#400017

Bart <bc@freeuk.com> writes:
> On 12/06/2026 21:45, Keith Thompson wrote:
>> Bart <bc@freeuk.com> writes:
>> [...]
>>> It's still quite primitive.
>>>
>>> Some bits have been more standardised. Some 'improvements' have been
>>> done crudely and without touching the core language, for example by
>>> bolting on stuff via extra headers.
>> What you call "crude", I call taking advantage of existing language
>> features to add new functionality without having to change the
>> core language.
>> The uint32_t et al types could have been added as keywords
>> (even, as you would no doubt have preferred, with different
>> names), but it wasn't necessary to do so.
>
> It's a poor approach:
>
> * Those types don't exist unless stdint.h is present. That means anyone
>   could define their own non-compatible versions

"Doctor, it hurts when I do this."

> * Even if stdint.h is used, people could still shadow the names for
>   their own purposes

"Doctor, it hurts when I do this."

Even if int32_t where a keyword (only on implementations with 32-bit
integers?), you could redefine it as a macro.  So don't do that.

Yes, there are some inconvenient issues.  We've been dealing with them
successfully for decades.

[SNIP]

>>> Regarding compound literals, why is one necessary when assigning to
>>> 'q' here:
>>>
>>>      typedef struct {double x, y;} Point;
>>>
>>>      Point p = {10, 20};
>>>      Point q;
>>>            q = (Point){30, 40};
>>>
>>> The initialisation of 'p' doesn't need it, so can't you just do this:
>>>
>>>            q = {30, 40};
>> Because an initializer is evaluated in a context that depends on the
>> type of the object being initialized, but an expression, even if it's
>> the RHS of an assignment, is not.
>
>> In almost all cases, the type and semantics of an expression (even if
>> it's a subexpression) are fully determined by the expression itself,
>> not by the context in which it appears.  42 is of type int, even when
>> it's assigned to a floating-point object; the assignment imposes a
>> conversion.
>> In `Point p = {10, 20};`, the initializer is evaluated in a context
>> where the compiler knows that the result type is Point.
>> In `p = {10, 20};`, if it weren't a syntax error,
>
> It wouldn't be if allowed.

No kidding.

>> the compiler
>> would not (be required to) know that {10, 20} is being assigned
>> to an object of type Point.  It could be some other struct type,
>> or an array.
>
> And?

And ... you should read what I wrote if you want to understand it?

> I use the term 'closed' for an expression that occurs in a known
> context: something will be done with it and the type is known (pass to
> a function, assign to a variable, cast it to T etc).
>
> And 'open' for an expression that is not used for anything and so
> there is no final type to conform too. Here:
>
>    q = {30, 40};
>
> The RHS is closed. By itself, it's some generic constructor, but it is
> being assigned to 'q', so it knows it is supposed to be a Point type.

That's nice.

As I said, in some languages the type and semantics of an expression
depend on its context.  C is not such a language.  You advocate a
radical change to the way C compilers handle expressions because
you find the syntax of compound literals (which works perfectly
well) icky.

No.

>> There are languages that work differently.  In Ada, for example, the
>> equivalent `P := (10, 20);` is valid, because the RHS is evaluated
>> in a context that takes the type of the LHS into account.  (10, 20)
>> is a valid expression in Ada, and its type depends on its context.
>> (Ada doesn't have expression statements, so there always a context.)
>> When compound literals were added to the language, there were
>> several
>> options:
>> 1. Rework expression evaluation so that the type of an expression
>>     depends on its context.
> ?  Specify that a braced-initializer is a
>>     kind of expression.  Write several pages of standardese specifying
>>     exactly when and how this happens.  Then `p = {10, 20};` is
>>     valid, and `{10, 20}` is of type Point.  Presumably an expression
>>     statement `{10, 20};` would be a constraint violation, because
>>     there's no context to determine its type.  Decide whether
>>     `ptr = &{10, 20};` determines the type of `{10, 20}` or not.
>>     Argue for years about whether this breaks existing code, and
>>     how much of a problem that is.
>> 2. A special-case version of the above, where a braced initializer
>>     is an expression, and its type is determined by its context.
>>     Write several pages of standardese specifying exactly how
>>     the context determines the type and the cases where the type
>>     can't be determined and therefore a constraint is violated.
>
> This need not be as hard as you make out.

It wasn't that hard, because the committee went with option 3,
the one you snipped.  (Which is not to suggest that they actually
considered option 1 or 2.)

> {...} used for initialising is already different.

Yes, of course it's different.  {...} is not an expression.

> There is a possible ambiguity where {...} is used for a compound
> statement, but it could also be a data constructor. But I think that
> can be solved because {...} used for data happens in value-returning
> contexts.

Fortunately, we didn't have to solve that problem, because the
actual syntax for compound literals is unambiguous.

[...]

>     record point = (real x, y)
>
>     point p := (10, 20)
>     point q
>           q := (30, 40)

Not C.  Don't care.

-- 
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
void Void(void) { Void(); } /* The recursive call of the void */

[toc] | [prev] | [next] | [standalone]

#400019

On 13/06/2026 01:50, Keith Thompson wrote:
> Bart <bc@freeuk.com> writes:
>> On 12/06/2026 21:45, Keith Thompson wrote:
>>> Bart <bc@freeuk.com> writes:
>>> [...]
>>>> It's still quite primitive.
>>>>
>>>> Some bits have been more standardised. Some 'improvements' have been
>>>> done crudely and without touching the core language, for example by
>>>> bolting on stuff via extra headers.
>>> What you call "crude", I call taking advantage of existing language
>>> features to add new functionality without having to change the
>>> core language.
>>> The uint32_t et al types could have been added as keywords
>>> (even, as you would no doubt have preferred, with different
>>> names), but it wasn't necessary to do so.
>>
>> It's a poor approach:
>>
>> * Those types don't exist unless stdint.h is present. That means anyone
>>    could define their own non-compatible versions
> 
> "Doctor, it hurts when I do this."


>> * Even if stdint.h is used, people could still shadow the names for
>>    their own purposes
> 
> "Doctor, it hurts when I do this."

Seriously? You have a language where you can literally do this:

   #include <stdint.h>
   int32_t int32_t;
   int32_t = 0;

and that is just fine; just "don't do it"! In that case, we might as 
well allow:

   int int;

Can you understand how crazy the above looks from outside?


> As I said, in some languages the type and semantics of an expression
> depend on its context.  C is not such a language.  You advocate a
> radical change to the way C compilers handle expressions because
> you find the syntax of compound literals (which works perfectly
> well) icky.

But it woud be nicer if they didn't need that cast, yes? So having to 
write it is less desirable.

>> {...} used for initialising is already different.
> 
> Yes, of course it's different.  {...} is not an expression.

Maybe that was the problem.

>> There is a possible ambiguity where {...} is used for a compound
>> statement, but it could also be a data constructor. But I think that
>> can be solved because {...} used for data happens in value-returning
>> contexts.
> 
> Fortunately, we didn't have to solve that problem, because the
> actual syntax for compound literals is unambiguous.

Sure:

   int a;
   a = (int){123.45};
   a = (int)(123.45);

Nothing to see here.


> [...]
> 
>>      record point = (real x, y)
>>
>>      point p := (10, 20)
>>      point q
>>            q := (30, 40)
> 
> Not C.  Don't care.


And yet you said this:

"In Ada, for example, the equivalent `P := (10, 20);` is valid, because 
the RHS is evaluated...".

My language is much closer to C, and it doesn't have much problem with 
it. I was merely asking why you have to write:

     DrawLine((Point){x1, y1}, (Point){x2, y2});

rather than:

     DrawLine({x1, y1}, {x2, y2});

I know the {} are necessary in part because of the 'comma' operator, 
which stops you being able to use (x1, y1) here, or A[i, j] for 2D indexing.

[toc] | [prev] | [next] | [standalone]

#400020

On 6/13/26 12:03, Bart wrote:

> Seriously? You have a language where you can literally do this:
> 
>    #include <stdint.h>
>    int32_t int32_t;
>    int32_t = 0;
> 
> and that is just fine; just "don't do it"! In that case, we might as 
> well allow:
> 
>    int int;
> 
> Can you understand how crazy the above looks from outside?

    In our technical jargon, we have the perfect acronym to
    describe this kind of programming: GIGO. Look at wikipedia
    for an astounding description of that syndrom.

    https://en.wikipedia.org/wiki/Garbage_in,_garbage_out

-- 
**                                                            **
*                      tTh des Bourtoulots                     *
*                  http://maison.tth.netlib.re/                *
**                                                            **

[toc] | [prev] | [next] | [standalone]

#400027

On 2026-06-13 12:14, tTh wrote:
> On 6/13/26 12:03, Bart wrote:
> 
>> Seriously? You have a language where you can literally do this:
>>
>>    #include <stdint.h>
>>    int32_t int32_t;
>>    int32_t = 0;
>>
>> and that is just fine; just "don't do it"! In that case, we might as 
>> well allow:
>>
>>    int int;
>>
>> Can you understand how crazy the above looks from outside?

Yes. (And I suppose everyone here understands that!)

Languages have various possibilities to define their lexical rules,
their syntax, and their semantics.

It's certainly quite common to have _reserved words_ that may only
be used in certain syntactical contexts. But there's also languages
that allow context-depending placement of names that happen to be
also tokens of the language.

Consider, for example, in shell:   for for in in do ; do : ; done

Such pieces of code are a result of a programmer's sick brain and
not the problem of a language.

Keith already noted: "Doctor, it hurts when I do this."

And tTh said:

>     In our technical jargon, we have the perfect acronym to
>     describe this kind of programming: GIGO. Look at wikipedia
>     for an astounding description of that syndrom.
> 
>     https://en.wikipedia.org/wiki/Garbage_in,_garbage_out

Bart, do you understand these hints? When will you recognize that
"the problem" is your personal thing? (That's all just rhetorical;
we know the answer: "Never!")

Janis

[toc] | [prev] | [next] | [standalone]

#400031

On 13/06/2026 13:35, Janis Papanagnou wrote:
> On 2026-06-13 12:14, tTh wrote:
>> On 6/13/26 12:03, Bart wrote:
>>
>>> Seriously? You have a language where you can literally do this:
>>>
>>>    #include <stdint.h>
>>>    int32_t int32_t;
>>>    int32_t = 0;
>>>
>>> and that is just fine; just "don't do it"! In that case, we might as 
>>> well allow:
>>>
>>>    int int;
>>>
>>> Can you understand how crazy the above looks from outside?
> 
> Yes. (And I suppose everyone here understands that!)

Thank you for at least acknowledging that.

> Languages have various possibilities to define their lexical rules,
> their syntax, and their semantics.
> 
> It's certainly quite common to have _reserved words_ that may only
> be used in certain syntactical contexts. But there's also languages
> that allow context-depending placement of names that happen to be
> also tokens of the language.
> 
> Consider, for example, in shell:   for for in in do ; do : ; done

In the case of 'int32_t' this is supposedly a core C type but it is 
quite unknown to the language until you include a particular header.

But my example highlighted the fact that you can do this:

    Point Point;

provided the first Point is a user-defined type defined in an outer 
scope. Further:

   Point typedef Point;       // new scope starts at that 'typedef'
   {Point Point;}

> Such pieces of code are a result of a programmer's sick brain and
> not the problem of a language.
Such pieces of code are 100% *enabled* by the language so, yes, you can 
blame the language. These examples are not possible in mine for example, 
due to different scoping rules.

So someone using my product /has/ to write:

    type newPoint = Point

'type' has to be on the left, and the alias has to have a different name.

Quite draconian, I know! A programmer can still do 'crazy' stuff, but 
they have to work harder.

The attitude here seems to be, if you can write nonsense in any language 
anyway, then why bother making it harder to do so? Let's have fewer 
rules and make it easier!

> Keith already noted: "Doctor, it hurts when I do this."
> 
> And tTh said:
> 
>>     In our technical jargon, we have the perfect acronym to
>>     describe this kind of programming: GIGO. Look at wikipedia
>>     for an astounding description of that syndrom.
>>
>>     https://en.wikipedia.org/wiki/Garbage_in,_garbage_out
> 
> Bart, do you understand these hints? When will you recognize that
> "the problem" is your personal thing? (That's all just rhetorical;
> we know the answer: "Never!")


What problem are we talking about?

I'd merely commented that some of the 'huge improvements' made to C were 
done very crudely. And actually it was Keith who brought up stdint.h types.

[toc] | [prev] | [next] | [standalone]

#400043

Bart <bc@freeuk.com> writes:
> On 13/06/2026 13:35, Janis Papanagnou wrote:
>> On 2026-06-13 12:14, tTh wrote:
>>> On 6/13/26 12:03, Bart wrote:
>>>> Seriously? You have a language where you can literally do this:
>>>>
>>>>    #include <stdint.h>
>>>>    int32_t int32_t;
>>>>    int32_t = 0;
>>>>
>>>> and that is just fine; just "don't do it"! In that case, we might
>>>> as well allow:
>>>>
>>>>    int int;
>>>>
>>>> Can you understand how crazy the above looks from outside?
>> Yes. (And I suppose everyone here understands that!)
>
> Thank you for at least acknowledging that.

You seem think that acknowledgement is important.  Upthread, you
asked a question.  I spent substantial time and effort answering
it.  You have not acknowledged that.  I don't think you've ever
acnowledged it when I've answered one of your questions.  Why is
that?

(I don't expect acknowledgement from you.  I enjoyed writing the
explanation, and I hope that others might benefit from it, or at
least find it interesting.)

[...]

> In the case of 'int32_t' this is supposedly a core C type but it is
> quite unknown to the language until you include a particular header.

Who said it was a "core C type"?  What does "core C type" even mean?
(It's not mentioned in 6.2.3, "Types".)

Not all implementations necessarily even define int32_t.

Yes, it's defined in a header.  Everyone knows that.  And everyone
knows that you don't like it.

> But my example highlighted the fact that you can do this:
>
>    Point Point;
>
> provided the first Point is a user-defined type defined in an outer
> scope. Further:
>
>   Point typedef Point;       // new scope starts at that 'typedef'
>   {Point Point;}

Yet again, "Doctor, it hurts when I do this."

No language makes it impossible to write ugly code.

Perhaps C has some features that make it easier to write ugly code
in some cases.  "Fixing" those features would make the language more
complicated and break existing code, including code that isn't ugly
at all.

[...]

> The attitude here seems to be, if you can write nonsense in any
> language anyway, then why bother making it harder to do so? Let's have
> fewer rules and make it easier!

No, that's what the attitude here seems *to you* to be.  As usual,
you've misunderstood what everyone else here thinks.

[...]

-- 
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
void Void(void) { Void(); } /* The recursive call of the void */

[toc] | [prev] | [next] | [standalone]

#400044

On 14/06/2026 00:46, Keith Thompson wrote:
> Bart <bc@freeuk.com> writes:
>> On 13/06/2026 13:35, Janis Papanagnou wrote:
>>> On 2026-06-13 12:14, tTh wrote:
>>>> On 6/13/26 12:03, Bart wrote:
>>>>> Seriously? You have a language where you can literally do this:
>>>>>
>>>>>     #include <stdint.h>
>>>>>     int32_t int32_t;
>>>>>     int32_t = 0;
>>>>>
>>>>> and that is just fine; just "don't do it"! In that case, we might
>>>>> as well allow:
>>>>>
>>>>>     int int;
>>>>>
>>>>> Can you understand how crazy the above looks from outside?
>>> Yes. (And I suppose everyone here understands that!)
>>
>> Thank you for at least acknowledging that.
> 
> You seem think that acknowledgement is important.  Upthread, you
> asked a question.  I spent substantial time and effort answering
> it.  You have not acknowledged that.  I don't think you've ever
> acnowledged it when I've answered one of your questions.  Why is
> that?

You seem touchy about this. Sometimes I write considerable amounts only 
for people to complete ignore the content, or just snip it. It happens. 
I can't remember anyone thanking me for anything.

Regarding your comments about why compound literals look like they do, 
it sounded like speculation on your part. Not much for me to say about 
it other than putting another POV on some parts.

It still came across as excuses for something that you clearly think is 
a trivial matter. I consider cleaner, less cluttered code important.


> (I don't expect acknowledgement from you.  I enjoyed writing the
> explanation, and I hope that others might benefit from it, or at
> least find it interesting.)
> 
> [...]
> 
>> In the case of 'int32_t' this is supposedly a core C type but it is
>> quite unknown to the language until you include a particular header.
> 
> Who said it was a "core C type"?  What does "core C type" even mean?
> (It's not mentioned in 6.2.3, "Types".)

It came up in a thread last year where it was suggested that stdint 
types were pretty much of the same rank as 'char short int long' etc. 
I'm not going to trawl through of posts to try and find it.

Of course I don't agree that they are a core type; they are usually 
typedefs around 'char short' etc.

>> But my example highlighted the fact that you can do this:
>>
>>     Point Point;
>>
>> provided the first Point is a user-defined type defined in an outer
>> scope. Further:
>>
>>    Point typedef Point;       // new scope starts at that 'typedef'
>>    {Point Point;}
> 
> Yet again, "Doctor, it hurts when I do this."

And yet again on my part, why allow it in the first place?

C uses declarations where the type comes first. Now it is more 
fashionable for the type to come after the identifier being defined. 
Then my example changes from:

    Point [type] Point [var];     // [] annotations added

to:

    Point [var] : Point [type];

In the first, the scope for 'Point [var] starts just before that and 
shadows Point [type]. But in the second, it doesn't work: Point [var] 
shadows the other, then has to swap back for one token to allow Point 
[type] to be visible.

It suggests the concept is flawed if scope relies on a particular 
ordering of type/var.


>> The attitude here seems to be, if you can write nonsense in any
>> language anyway, then why bother making it harder to do so? Let's have
>> fewer rules and make it easier!
> 
> No, that's what the attitude here seems *to you* to be.  As usual,
> you've misunderstood what everyone else here thinks.

Countless posts here that people have made suggested exactly that.

[toc] | [prev] | [next] | [standalone]

#400047

Bart <bc@freeuk.com> writes:
> On 14/06/2026 00:46, Keith Thompson wrote:
>> Bart <bc@freeuk.com> writes:
>>> On 13/06/2026 13:35, Janis Papanagnou wrote:
>>>> On 2026-06-13 12:14, tTh wrote:
>>>>> On 6/13/26 12:03, Bart wrote:
>>>>>> Seriously? You have a language where you can literally do this:
>>>>>>
>>>>>>     #include <stdint.h>
>>>>>>     int32_t int32_t;
>>>>>>     int32_t = 0;
>>>>>>
>>>>>> and that is just fine; just "don't do it"! In that case, we might
>>>>>> as well allow:
>>>>>>
>>>>>>     int int;
>>>>>>
>>>>>> Can you understand how crazy the above looks from outside?
>>>> Yes. (And I suppose everyone here understands that!)
>>>
>>> Thank you for at least acknowledging that.
>> You seem think that acknowledgement is important.  Upthread, you
>> asked a question.  I spent substantial time and effort answering
>> it.  You have not acknowledged that.  I don't think you've ever
>> acnowledged it when I've answered one of your questions.  Why is
>> that?
>
> You seem touchy about this. Sometimes I write considerable amounts
> only for people to complete ignore the content, or just snip it. It
> happens. I can't remember anyone thanking me for anything.

Not the same thing.

I said "acknowledged", not "thanked".  And I wrote what I wrote in
direct response to a question that you asked.

Here's what you wrote:

"""
Regarding compound literals, why is one necessary when assigning to
'q' here:

    typedef struct {double x, y;} Point;

    Point p = {10, 20};
    Point q;
          q = (Point){30, 40};
"""

> Regarding your comments about why compound literals look like they do,
> it sounded like speculation on your part. Not much for me to say about
> it other than putting another POV on some parts.

I'd say my answer was *informed* speculation, based on the facts
about how compound literals are defined and my knowledge of the
implications of other possible definitions (in particular, that
a version without the type name probably couldn't be made to work
without radical and otherwise unnecessary changes to C).  If you
really want to know what the authors of the standard had in mind,
you can search through the committee's published documents as well
as I can.  I don't believe that's what you want to know.

Tell me this.  Were you really interested in an actual answer to your
question, or was it just a rhetorical method to complain yet again
about a feature of C that you don't like?  I foolishly assumed that
you wanted an answer.  All the evidence suggests that you didn't.

Should I assume that any time you ask a question about C, particularly
about why a feature you dislike is the way it is, that you really don't
care about the answer?

> It still came across as excuses for something that you clearly think
> is a trivial matter. I consider cleaner, less cluttered code
> important.

Explanations, not excuses, for a decision for which there were valid
reasons that you refuse to acknowledge or accept.

>> (I don't expect acknowledgement from you.  I enjoyed writing the
>> explanation, and I hope that others might benefit from it, or at
>> least find it interesting.)
>> [...]
>> 
>>> In the case of 'int32_t' this is supposedly a core C type but it is
>>> quite unknown to the language until you include a particular header.
>> Who said it was a "core C type"?  What does "core C type" even mean?
>> (It's not mentioned in 6.2.3, "Types".)
>
> It came up in a thread last year where it was suggested that stdint
> types were pretty much of the same rank as 'char short int long'
> etc. I'm not going to trawl through of posts to try and find it.

The word "rank" has a specific meaning; I presume that's not what
you meant.  If that other person did mean "rank" in that sense,
then it was likely to be a correct statement; if int32_t is a
typedef for int, then it has the same rank as int.

And I suppose I have to admit that my question was rhetorical.
Touché.

int32_t is not a "core C type", for any reasonable definition of that
vague phrase.  If someone said it is, I disagree, but I also am not
going to trawl through posts to find it.

> Of course I don't agree that they are a core type; they are usually
> typedefs around 'char short' etc.
>
>>> But my example highlighted the fact that you can do this:
>>>
>>>     Point Point;
>>>
>>> provided the first Point is a user-defined type defined in an outer
>>> scope. Further:
>>>
>>>    Point typedef Point;       // new scope starts at that 'typedef'
>>>    {Point Point;}
>> Yet again, "Doctor, it hurts when I do this."
>
> And yet again on my part, why allow it in the first place?

I could answer that, but I'm nearly certain you would not be
interested in the answer.

> C uses declarations where the type comes first. Now it is more
> fashionable for the type to come after the identifier being
> defined.

It is not "fashionable" in any sense relevant to the topic of this
newsgroup.  Yes, different languages have different declaration
syntax.  I'll even acknowledge that the declaration syntax of some
other languages has real advantages over C's.  But C is what we
try to discuss here.

[...]

>>> The attitude here seems to be, if you can write nonsense in any
>>> language anyway, then why bother making it harder to do so? Let's have
>>> fewer rules and make it easier!
>>
>> No, that's what the attitude here seems *to you* to be.  As usual,
>> you've misunderstood what everyone else here thinks.
>
> Countless posts here that people have made suggested exactly that.

You're wrong.  I won't bother to explain why.  I might if you could
convince me that the explanation would be of any interest to you,
but that seems unlikely.

-- 
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
void Void(void) { Void(); } /* The recursive call of the void */

[toc] | [prev] | [next] | [standalone]

#400048

On 14/06/2026 02:26, Keith Thompson wrote:
> Bart <bc@freeuk.com> writes:

>> Regarding your comments about why compound literals look like they do,
>> it sounded like speculation on your part. Not much for me to say about
>> it other than putting another POV on some parts.
> 
> I'd say my answer was *informed* speculation, based on the facts
> about how compound literals are defined and my knowledge of the
> implications of other possible definitions (in particular, that
> a version without the type name probably couldn't be made to work
> without radical and otherwise unnecessary changes to C).  If you
> really want to know what the authors of the standard had in mind,
> you can search through the committee's published documents as well
> as I can.  I don't believe that's what you want to know.
> 
> Tell me this.  Were you really interested in an actual answer to your
> question, or was it just a rhetorical method to complain yet again
> about a feature of C that you don't like?

Why is this such a big deal?

I find it annoying that one has to write 'a = (T){b}' instead of just 'a 
= {b}' (**)

I asked 'why' that was necessary. You gave a complicated response which 
boils down to it being too hard to do or not practical. Or maybe nobody 
cared enough about readability to try a bit harder.

I then questioned some of the responses as I think it /would/ have been 
possible.

Since I know the decision has been made, this is not going to change C. 
But it is interesting to me from a PL design POV.

I acknowledged it my making a reply; I could have decided to leave it there.

(** I have to write 'a := T(b)' in my scripting language, when T is 
record type, for example 'a := point(10, 20)'.

But there is a good reason: 'a' has a dynamic type so that info has to 
be provided as it cannot be infered from the type of 'a'.

But C is a statically typed language: it should not be necessary. You 
yourself gave examples where it wasn't, and I gave an example from mine 
for what is /basically the same language/, in type system and capabilities.)









   I foolishly assumed that
> you wanted an answer.  All the evidence suggests that you didn't.
> 
> Should I assume that any time you ask a question about C, particularly
> about why a feature you dislike is the way it is, that you really don't
> care about the answer?
> 
>> It still came across as excuses for something that you clearly think
>> is a trivial matter. I consider cleaner, less cluttered code
>> important.
> 
> Explanations, not excuses, for a decision for which there were valid
> reasons that you refuse to acknowledge or accept.
> 
>>> (I don't expect acknowledgement from you.  I enjoyed writing the
>>> explanation, and I hope that others might benefit from it, or at
>>> least find it interesting.)
>>> [...]
>>>
>>>> In the case of 'int32_t' this is supposedly a core C type but it is
>>>> quite unknown to the language until you include a particular header.
>>> Who said it was a "core C type"?  What does "core C type" even mean?
>>> (It's not mentioned in 6.2.3, "Types".)
>>
>> It came up in a thread last year where it was suggested that stdint
>> types were pretty much of the same rank as 'char short int long'
>> etc. I'm not going to trawl through of posts to try and find it.
> 
> The word "rank" has a specific meaning; I presume that's not what
> you meant.  If that other person did mean "rank" in that sense,
> then it was likely to be a correct statement; if int32_t is a
> typedef for int, then it has the same rank as int.
> 
> And I suppose I have to admit that my question was rhetorical.
> Touché.
> 
> int32_t is not a "core C type", for any reasonable definition of that
> vague phrase.  If someone said it is, I disagree, but I also am not
> going to trawl through posts to find it.
> 
>> Of course I don't agree that they are a core type; they are usually
>> typedefs around 'char short' etc.
>>
>>>> But my example highlighted the fact that you can do this:
>>>>
>>>>      Point Point;
>>>>
>>>> provided the first Point is a user-defined type defined in an outer
>>>> scope. Further:
>>>>
>>>>     Point typedef Point;       // new scope starts at that 'typedef'
>>>>     {Point Point;}
>>> Yet again, "Doctor, it hurts when I do this."
>>
>> And yet again on my part, why allow it in the first place?
> 
> I could answer that, but I'm nearly certain you would not be
> interested in the answer.
> 
>> C uses declarations where the type comes first. Now it is more
>> fashionable for the type to come after the identifier being
>> defined.
> 
> It is not "fashionable" in any sense relevant to the topic of this
> newsgroup.  Yes, different languages have different declaration
> syntax.  I'll even acknowledge that the declaration syntax of some
> other languages has real advantages over C's.  But C is what we
> try to discuss here.
> 
> [...]
> 
>>>> The attitude here seems to be, if you can write nonsense in any
>>>> language anyway, then why bother making it harder to do so? Let's have
>>>> fewer rules and make it easier!
>>>
>>> No, that's what the attitude here seems *to you* to be.  As usual,
>>> you've misunderstood what everyone else here thinks.
>>
>> Countless posts here that people have made suggested exactly that.
> 
> You're wrong.  I won't bother to explain why.  I might if you could
> convince me that the explanation would be of any interest to you,
> but that seems unlikely.
> 

[toc] | [prev] | [next] | [standalone]

#400056

Bart <bc@freeuk.com> writes:
> On 14/06/2026 02:26, Keith Thompson wrote:
[...]
>> Tell me this.  Were you really interested in an actual answer to your
>> question, or was it just a rhetorical method to complain yet again
>> about a feature of C that you don't like?
>
> Why is this such a big deal?

I might consider answering that if I thought you were actually
interested in an answer.

[...]

-- 
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
void Void(void) { Void(); } /* The recursive call of the void */

[toc] | [prev] | [next] | [standalone]

#400194

On 2026-06-13 15:38, Bart wrote:
> On 13/06/2026 13:35, Janis Papanagnou wrote:
>> On 2026-06-13 12:14, tTh wrote:
>>> On 6/13/26 12:03, Bart wrote:
>>>
>>>> Seriously? You have a language where you can literally do this:
>>>>
>>>>    #include <stdint.h>
>>>>    int32_t int32_t;
>>>>    int32_t = 0;
>>>>
>>>> and that is just fine; just "don't do it"! In that case, we might as 
>>>> well allow:
>>>>
>>>>    int int;
>>>>
>>>> Can you understand how crazy the above looks from outside?
>>
>> Yes. (And I suppose everyone here understands that!)
> 
> Thank you for at least acknowledging that.

Huh? - There's nothing to acknowledge here since it's obvious.

All I intended to say with that was that you are constructing
strange reasoning based on trivialities. - This is actually a
well known and often applied rhetoric move; hunt for agreement
by stating a triviality to get assurance for all the debatable
stuff.

> 
>> Languages have various possibilities to define their lexical rules,
>> their syntax, and their semantics.
>>
>> It's certainly quite common to have _reserved words_ that may only
>> be used in certain syntactical contexts. But there's also languages
>> that allow context-depending placement of names that happen to be
>> also tokens of the language.
>>
>> Consider, for example, in shell:   for for in in do ; do : ; done

> In the case of 'int32_t' this is supposedly a core C type but it is 
> quite unknown to the language until you include a particular header.

Yes. That's something that I (also?) don't think is good language
design. (Many things in "C" I actually consider to be kludges and
quirks; but so what?)

For what reason do you want to discuss all the design decisions of
the C-language? (I'm certainly not the appropriate partner for you
since, depending on the project, I either use "C" - as it is! - or
use another (for the respective task) more appropriate language.)

But, specifically, and for whatever product I develop, I wouldn't
use any proprietary, non-standard, home-brewed product. - So your
(repeated!) advertisement of your toys is meaningless.

> [...]

>> Such pieces of code are a result of a programmer's sick brain and
>> not the problem of a language.
 >
> Such pieces of code are 100% *enabled* by the language so, yes, you can 
> blame the language.

(My statement was on the shell-code. Your examples about "C". Just
noting.)

Since you might not have noticed; I don't write such shell-code.
And I also don't complain (in this respect) about shell's design.

It was about that there's different design options on that level.
What I said was that in either language you have to make decisions.

The shell-designers obviously didn't want to restrict use of values
and names, therefore they consider context.[*] In other languages
they may have different name spaces (cf. Algol 68 "stropping"), or
they use _reserved words_ (as already mentioned). The problem with
the former is that some people (like you) might not like "stropping".
Other folks might not like being restricted in their choice of names
to non-reserved words only. Languages like "C" have reduced these
reserved keywords; at the cost of other syntactic arguable choices,
choices that I personally don't like.

There's obviously no clear "design principle X is good" and "design
principle Y is bad" that fits everyone. (And I'm sure only your own
personal language designs are the only ones that fits your liking.
I'm fine with that.)

I, for example, would like to use common abbreviation for locally
scoped entities, like  'Interface if;'  or  'int if = 0;'  - but
I cannot do that; I have to follow to the rules that the language
designers have set. (And the 'if' example is not restricted to the
C-language, it's quite common to be a reserved word in languages!)

You cannot fundamentally change "C" as it is; not after more than
five decades (since its birth), and also not after it had been
standardized; it just makes no sense to even start an argument on
that. - If you think it's "bad" don't use it.

> These examples are not possible in mine for example, 
> due to different scoping rules.

That's fine. If you find someone who is interested in your language
he might appreciate it (or not; can't tell, and I don't care).

> [...]
> 
> Quite draconian, I know! A programmer can still do 'crazy' stuff, but 
> they have to work harder.

The point that had been tried to convey was that it's *not* in the
first place a language issue; it's an issue the programmer invented.

      Consider, example for, text this. From composed punctuation it
      language rules is the of words English and. Just not artifacts
      possible defined say would such English it to positive language
      badly the is create I that is because am you. Would the, text
      and rightly, of writer blame you so that.

Oh, wait! I'll translate that for you:

      Consider, for example, this text. It is composed of words and
      punctuation rules from the English language. I am positive you
      would not say that the English language is badly defined just
      because it is possible to create such artifacts. You would,
      and rightly so, blame the writer of that text.

I'm with you (of course) that a language should be safe, and clearly
defined. But your examples and personal problems [with "C"] are not
rooted in the language (that it allows writing stupid things) but in
the person who writes such code, either in practice or (as you) just
for purpose of an argument.

> 
> The attitude here seems to be, if you can write nonsense in any language 
> anyway, then why bother making it harder to do so? Let's have fewer 
> rules and make it easier!

Can't tell (and don't want to speak) about attitudes. What repeatedly
had been said here was that you cannot change the "C" language just
as you (or anyone else) would like. - "C" is not important enough for
me to engage here. But if you feel there's something essential that
should (and could, without breaking anything) be changed, I'd suggest
to contact the standards group and submit a proposal.

Janis

[*] But note that they also used 'do'...'done' instead of 'do'...'od'
because of existence of the Unix 'od' command.

> [...]

[toc] | [prev] | [next] | [standalone]

#400200

Janis Papanagnou <janis_papanagnou+ng@hotmail.com> writes:
>On 2026-06-13 15:38, Bart wrote:
>> On 13/06/2026 13:35, Janis Papanagnou wrote:
>>> On 2026-06-13 12:14, tTh wrote:
>>>> On 6/13/26 12:03, Bart wrote:
>>>>
>>>>> Seriously? You have a language where you can literally do this:
>>>>>
>>>>>    #include <stdint.h>
>>>>>    int32_t int32_t;
>>>>>    int32_t = 0;
>>>>>
>>>>> and that is just fine; just "don't do it"! In that case, we might as 
>>>>> well allow:
>>>>>
>>>>>    int int;
>>>>>
>>>>> Can you understand how crazy the above looks from outside?

 <pins>

>> In the case of 'int32_t' this is supposedly a core C type but it is 
>> quite unknown to the language until you include a particular header.
>
>Yes. That's something that I (also?) don't think is good language
>design. (Many things in "C" I actually consider to be kludges and
>quirks; but so what?)

Technically, the C language evolved, it wasn't designed per se.

And there are good reasons (backward compatability) for conditioning
support of the fixed size types on inclusion of <stdint.h> rather than
building them into the language.  Like it or not, it cannot be changed.

[toc] | [prev] | [next] | [standalone]

#400203

On 2026-06-22 23:24, Scott Lurndal wrote:
> Janis Papanagnou <janis_papanagnou+ng@hotmail.com> writes:
>> On 2026-06-13 15:38, Bart wrote:
>>> [...]

>>> In the case of 'int32_t' this is supposedly a core C type but it is
>>> quite unknown to the language until you include a particular header.
>>
>> Yes. That's something that I (also?) don't think is good language
>> design. (Many things in "C" I actually consider to be kludges and
>> quirks; but so what?)
> 
> Technically, the C language evolved, it wasn't designed per se.

Well, yes and no. For me the _original design_ is responsible also
for a lot that was (had to be) adjusted, fixed, and extended later.

> 
> And there are good reasons (backward compatability) for conditioning
> support of the fixed size types on inclusion of <stdint.h> rather than
> building them into the language. 

Sure.

> Like it or not, it cannot be changed.

That's what I'm also regularly saying. - In my longish post you may
have missed it:

You cannot fundamentally change "C" as it is; not after more than
five decades (since its birth), and also not after it had been
standardized; it just makes no sense to even start an argument on
that. - If you think it's "bad" don't use it.

Janis

[toc] | [prev] | [next] | [standalone]

#401171

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

[.. whether types like int32_t should be part of the base language ..]

> And there are good reasons (backward compatability) for conditioning
> support of the fixed size types on inclusion of <stdint.h> rather
> than building them into the language.  Like it or not, it cannot be
> changed.

It isn't necessary to use <stdint.h> to give names to fixed-width
integer types.  A lot of people do it but it isn't necessary.

[toc] | [prev] | [next] | [standalone]

#400022

Bart <bc@freeuk.com> writes:
[...]
> My language is much closer to C, and it doesn't have much problem with
> it. I was merely asking why you have to write:
>
>     DrawLine((Point){x1, y1}, (Point){x2, y2});
>
> rather than:
>
>     DrawLine({x1, y1}, {x2, y2});

You asked.  I answered.

[...]

-- 
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
void Void(void) { Void(); } /* The recursive call of the void */

[toc] | [prev] | [standalone]

Back to top | Article view | comp.lang.c

csiph-web