On 20/10/2026 16:11, bart wrote:

The other was C. There, several choices were made:

* To start with that Fortran style except that [] are used

* To decree that that 'A[20]' syntax is supposed to match indexing of
ÿ A as it might appear in an expression

* To introduce "*" as a prefix dereference operator in expressions ...

* ... which then means that a prefix "*" appears in the declaration too

* A further complication was to allow function pointers within that a
ÿ declaration list

I don't see a problem with that. If you need to declare a function
pointer, you need to declare it in a declaration list.

To me, the big disadvantage of C's declaration syntax is that it lets
you declare things of different (but related) types in the same
declaration. I don't have a problem with :

int (*my_func_pointer)(int);
int my_array[20];

but I /do/ have a problem with :

int (*my_func_pointer)(int), my_array[20];

or, more common and therefore worse :

int * a, b;

The way to deal with this is, of course, simply not writing such mixed declarations. But some people /do/ - living with other peoples' code is
the bane of all programmers.

I am confident that there could have been a nicer syntax, and function
pointer (or function type) syntax is particularly ugly. But it works
well enough in practice that I cannot see it as a problem or even inconvenience.

* Yet one more which came later was to add 'const', where placement now
ÿ gets confusing

Some people do find it hard to understand the difference between :

const int * p;
int * const q;
const int * const r;

I note that this is despite the clear left-to-right nature of "const" here.

Many newbie mistakes with const will be caught by the compiler, and once
you get used to it, you should be fine.

But to stay with pointers, take this expression:

ÿÿ *A[i]

C precedence rules mean this is parsed as *(A[i]), which means that a
type written as 'T *A[N]' must be an array of pointers to T (I had to
think for a few seconds!).

If you instead forget that you can declare more than one thing in one declaration, you can write :

T* A[i];

Then it is quite clear.

But suppose you wanted a pointer to array of T? The expression for that would be:

ÿÿÿ (*A)[i]

And so the declaration has to be 'T (*A)[N]' too.

Yes. Declaration syntax follows usage. (If you don't like the operator precedence, or the fact that dereferencing is pre-fix in C, unlike, say, Pascal, then that's an orthogonal dislike.)

So it is unfortunate that parentheses used to control precedence in an expression now also have to appear in type declarations (where they are often next to () used for parameter lists, for further confusion).

You know how to use typedefs to make code clearer.

Complicated types are a minority. Most object declarations are either
things, arrays of things, or pointers to things - not combinations of
these. And most function declarations are just function declarations,
not arrays of function pointers or other complex types.

==============================================

So, what would have happened with a postfix deref op? (Ignore whether
'*' would still be a good choice.) My first example would be this:

ÿÿ A*[i]

Here, it would mean that A is dereferenced, then indexed; A must then be
a pointer to an array of T.

But suppose we wanted the original array of pointers to T, where you
index first then dereference. That is written like this:

ÿÿ A[i]*

You simply swap the order of [] and *.

So, PARENTHESES HAVE BEEN ELIMINATED for purpose of disambiguating array/pointer and pointer/array, both within expressions and within type-declarations.

Agreed.

But does that make a significant difference? I don't think so. I'd
have to see a lot more real-life examples to get a feeling for whether
postfix dereference would be better or worse than prefix - saving the occasional parentheses is not sufficient.

How about that? Further, most of the type-spec is now LTR; only the base-type has to stay on the left. Access terms in expressions will be
fully LTR.

IMO C suffers because typedef was added late in the game and
function prototypes are much later.ÿ Prototypes need types and
to get it one needs "hole" in variable declaration.ÿ Where the
hole should be is specified by the C syntax, but placement of
hole is probably least clear aspect of declarations.

I thought that 'hole' was where 'int A[10]' mean one thing in normal declaration but another within a parameter list.

That's a different thing entirely. (And while I don't find it confusing
that array and pointer parameters mean the same thing in C, I do see it
as a wasted opportunity for better static checking and optimisation of
code.)

IMO C declaration syntax was a mistake, but as real life shows
it was not a fatal mistake, people can adapt.

A mistake that could so easily have been avoid by choosing a different precedence as shown above. Did none of the thousand people working at
Bell Labs (according to a comment in DC's follow-ip) spot this and say anything?

I suspect the folks at Bell Labs were too busy writing real code to be bothered by how confused you would be with artificially complex types.

Life is full of little decisions that, with hindsight, might have been sub-optimal choices but are nonetheless good enough in practice. C's declaration syntax is one of those decisions. It's worth learning from
that and picking a clearer syntax for new languages, but it is not worth obsessing over its use in existing languages.

Had no-one even glanced at a Pascal spec, if there was no working copy?
It would have transformed C type syntax.

(ACTUALLY IT IS NOT TOO LATE. A secondary postfix deref op could have
been added. This could have been done 50 years ago, with the original eventually deprecated.

It /is/ too late - far, far too late. It would be a terrible idea to
add a new postfix dereference operator to give two different operators
with no benefit other than very occasionally reducing the need for parentheses. If "*p" really bothers you, write "p[0]" instead (in expressions, not type declarations).

But this is a common theme of mine whether I perceive a problem that
people grudgingly admit might not be idea. But nothing was ever done to
fix it even after decades.)

What is the common theme? You pick something that lots of people
consider as "it's maybe uglier than it need be, but it works fine in
practice" and pretend that you alone discovered the issue? Then you go completely haywire about how terrible and unbelievable it is, call the C designers idiots and claim to be a genius because your irrelevant
language does something different? Then comes the paranoia, and claims
that no one will "admit there is a problem", and the absurd insistence
that we all "do something about it". Eventually the thread dies away,
until you bring up the same shit half a year later. For years, and
years, and years. Is that the common theme you are talking about?



--- PyGate Linux v1.5.19
* Origin: Dragon's Lair, PyGate NNTP<>Fido Gate (3:633/10)

On 20/10/2026 16:56, Janis Papanagnou wrote:

On 2026-10-20 10:25, David Brown wrote:

On 19/10/2026 23:27, Janis Papanagnou wrote:

On 2026-10-19 21:35, Michael S wrote:

[...]

I'm sorry, these are (AFAICT) common terms, and I thought obvious.

I am afraid your terminology is further from common use than you thought.

I'm afraid you are wrong here; in several ways. I'll expand below.

You don't need to be defensive here - I am trying to help you see /why/
your terms might not have been the best choices. It is not criticism of
your post, just advice on your terminology so that it does not detract
from understanding the content.

(It is already clear that they were not good choices - Michael has long experience in software development of many types, and if they were not
obvious to him in the context of your posts, they were not good terms to
use.)

You post a lot of interesting things. You made a post with unnecessary convoluted terminology that distracted from the content of your post,
perhaps based on the particular usage of particular terms in the
particular computer science courses you took.

So my apologies for trying to be helpful!

(And do look up "monads" and "monadic operations" - they are all the
rage in many programming languages these days.)


--- PyGate Linux v1.5.19
* Origin: Dragon's Lair, PyGate NNTP<>Fido Gate (3:633/10)

In article <11b7k22$2v8e5$1@dont-email.me>, bart <bc@freeuk.com> wrote:

On 20/10/2026 09:01, David Brown wrote:

On 19/10/2026 23:28, bart wrote:

(Funny that when I suggest that nested loop breaks are uncommon,
everyone says I'm wrong! Some even write 200-line made-up examples to
prove their point.)

I don't remember "everyone" saying you were wrong to say that nested
loop breaks are uncommon - in fact, I don't remember /anyone/ saying
that was wrong.

(There was a LOT of antipathy towards my idea to fix the common case of >'loop-break' clashing with 'switch-break', BECAUSE it did not fix the >problem of nested loop-break, which is uncommon, even though that wasn't
the aim.)

Those are two different things. No one disagrees with you that
"nested break from a switch inside of a loop" is relatively more
common than other variants.

Using that as an excuse not to provide a more general mechanism
because you already have a proposal for the specific case is
what I and others took you to task for. I find this ironic,
since you rail against things in C that you do not like, citing
the most ridiculous examples you can think of that do not show
up in actual programs, yet for something where it is pointed out
to you that your solution does not generalize, you claim that it
does not need to because ... the general case rarely shows up in
a real program.

There is no reason to abstract away that function pointer type.

You probably do so in C /because/ the type involves * () and [] but
have somehow persuaded yourself that it just better that way.

Do you hear that whooshing noise?ÿ It is the sound of the point flying
far above your head.

Here is an example of some sensible function typedefs, all from third-
party code (so not my "peculiar" style)

typedef void (*TimerCallbackFunction_t)( TimerHandle_t xTimer );

TimerHandle_t xTimerCreate(ÿ const char * const pcTimerName,
ÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿ TickType_t xTimerPeriodInTicks,
ÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿ UBaseType_t uxAutoReload,
ÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿ void * pvTimerID,
ÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿ TimerCallbackFunction_t pxCallbackFunction );

typedef void (*lwip_thread_fn)(void *arg);
typedef void (*tcpip_init_done_fn)(void *arg);
typedef void (*tcpip_callback_fn)(void *ctx);
typedef void (* sys_timeout_handler)(void *arg);
typedef void (*dns_found_callback)(const char *name,
ÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿ const ip_addr_t *ipaddr, void *callback_arg);

This is the kind of C I find hard to read. There are lots of typedefs
but few uses of those typedefs that I can see, so I don't know how much >difference they make.

You again missed the entire point. You may not see many uses
of them, but as David says, the `typedef`s give you
domain-specific *names* understandable to the programmer: a
programmer can see the `sys_timeout_handler` type instantly know
that this has a different function than the,
`tcpip_callback_fn`, despite the having the same type.

The other point is that the ridiculous examples you make up to
illustrate your distaste for C declaration syntax basically do
not appear in real programs.

[snip]
I've left in the regular parameter names, even though C doesn't need
them, but they are quite heavy - you don't really need those
Hungarian-style prefixes.)

Well, I guess this buys you one thing: the parameter name for the last >parameter is to the right of its type, rather than be inside it. But a C >expert should not be fazed by that.

Here is the same function as I might write it in an alternative syntax.

I've kept the same names, but changed case-style and removed prefixes
and suffixes. I've capitalised user-type names:

func TimerCreate( # (retain case if FFI import)
ichar timername,
Ticktype timerperiodinticks,
Ubasetype autoreload,
ref void timerid,
ref proc(Timerhandle) callbackfn)

In this form, it's hard to see what benefit a typedef would give for
that last parameter; it is simple enough.

What is your point? Do you have one? If you don't want to use
C, don't use C.

There are plenty of languages that can do this kind of thing
that are not C and have syntax and semantics closer to what you
seem to want. Here's an example in Rust:

pub trait TimerHandle { ... }

fn CreateTimer<T>(
timer_name: &str,
period: std::time::Duration,
auto_reload: bool,
timer_id: T,
handler: fn(&dyn TimerHandle),
) -> Result<Timer<T>, TimerError>

I didn't know what an `UBaseType_t` is, and while "autoreload"
sounded pretty intuitive, I wasn't sure about the semantics, so
I looked it up (the example comes from `FreeRTOS`). In this
context, it is a boolean saying whether the timer should repeat
with the given periodicity, or whether it is a one-shot.

The timer_id is opaque to the timer, and it looks like it's used
to facilitating the handler accessing timer-specific data. In
C, passing it as a `void *` is used as a way to get a poor-man's
overloading. But Rust has generics, I just made it generic over
some type T.

If I were writing this from scratch in Rust, a language that has
generics, closures, and so sum types, I'd do the whole thing
differently; see the end for an example.

But I digress. The point here is, Bart, that alternatives exist
if you don't like C. You don't have to keep posting, over and
over again, in comp.lang.c of all places, about how oh so
terribly awful C is. If you don't want to program in C, simply
don't program in C.

Ask yourself why the typedefs are used.ÿ Look at the /names/.ÿ Those
last four are all from the same network stack library, and are all
typedefs for "void (*)(void*)".

Until you mentioned it, I hadn't noticed. So typedef has done a good job
of hiding that useful fact! But looking more closely, it is the first
four of the last five.

Let's take one:

typedef void (*lwip_thread_fn)(void *arg);

That 'arg' is not much use for a start (other than being a hint that
this particular (...) is where the parameters go).

So, maybe this is used like this:

void F(lwip_thread_fn lwip_thread_callback);

I have no idea what you're trying to say here. The obvious (and
honestly, excusable) syntax error aside, what is F? It's a
function that, what, takes two function pointers?

The type defined by `lwip_thread_fn` is a pointer to a function
that takes a void pointer (`void *`) as its sole arugment, and
returns `void` (that is, has no meaningful return value).

Intuitively, the name implies that this is the function run as
some thread, so we'd pass it to a thread creation function. The
usual shape of those things is to give them a pointer to some
function to run in the new thread, and a pointer to some
arguments to be passed to that function. For example:

void
whatever(void *argp)
{
struct Args *args = argp;
while (keep_running()) {
// Do the thing the thread is supposed to do.
}
thread_exit(SUCCESS);
}

thread_t *
start_the_whatever_thread(void)
{
struct Args *args = malloc(sizeof(*args));
if (args == NULL) abort();
memset(args, 0, sizeof(*args));
args->whatever = something();
// etc...
thread_t *thr = thread_create(whatever, args);
if (thr == NULL) abort();
return thr;
}

Something could start this as:

thread_t *whatever_id = start_the_whatever_thread();

At some point later, if you want to wait for the thread to
exit, you'd run:

(void)thread_join(whatever_id);

Note this is decently complex behavior, but it's actually quite
intuitive from the name and the type.

Here you have two identifiers imparting the sort kind of information; a >tautology.

That's not what a tautology is.

If that function pointer pattern is common, or recurs in a suite of >functions, I might also have used a typedef, but with a common name.

Then you loose the domain specificity; you can't tell from the
name whether you need an LwIP thread, or a callback, or a
something run in a different thread, or just a plain 'ol
function you want to apply to run every now and again for a side
effect.

Then only one would be needed, say:

typedef void (*stack_callbackfn)(void);

I might have done the same in that alternate syntax as it would start to
get cluttery: 'ref proc(ref void)', but also in order to define that
common pattern in one place.

I dunno. Sounds like you have no idea what the code that David
posted is meant to do. But that's a "you" problem.

Note that 'pcl' in my example /is/ a typedef; here it makes sense as
it is used in 100s of places. This function pointer occurs in only one
place.

I'm sorry, I had mistaken you for a programmer who wanted to write good,
clear programs.ÿ Naming things is not a shortcut to save keypresses.

Isn't that one of the main uses of typedefs? So as to give a handy, >'euphonious' one-token alias to an elaborate typedef.

It also allows you to change the type in one place without having to
update hundreds of instances.

It also allows the type to be opaque.

The point is that the name you chose is meaningless to anyone
other than you. What's a PCL? Phase Control Line? Printer
Command Language? Photon Compressor Loop?

Saving keypresses is bonus benefit, but if it is shorter, then it can
also help readability as other critical elements are not overshadowed.

So I'm not sure what objection you have to this particular use of it.

Have you ever written a large program that was maintained by
anyone other than yourself?

Here is the one place I do remember using typedef for a function pointer >(from an old project, not in C):

type fnptr = ref proc

repeat
(fnptr(pcptr^))^()
until stopped

It's used as a cast, but reason I have it is because with simple cast >syntax, which is 'T(X)', the meaning without it would be ambiguous (a >grammar issue that I might fix one day).

Rather than fallback to standard cast syntax (which is 'cast(X, T)'),
this was tidier.

I can only guess at what this may mean. Hazarding a guess,
`pcptr` is a "pointer to a program counter", which is a
reference type to some type that represents some executable
memory location in the program. You then have a loop that runs
until "stopped" is true where you indirect the program counter
pointer, cast it to a pointer to a function, and then invoke
the function, right? One presumes you have the, "PC Pointer"
because it changes over time, otherwise, you'd just give
whatever it points to a name and call it.

More generally, I fail to see what this is trying to
demonstrate. If it's to show some sort of imagined superiority
over C, I don't see it; that's sort of thing is easy enough to
write:

typedef void (*fnptr)(void);

// Assume uintptr_t *pcptr is declared somewhere.
do {
((fnptr)*pcptr)();
} while (!stopped);

E.g.,

```
term% cat b.c
#include <stdbool.h>
#include <stddef.h>
#include <stdint.h>
#include <stdio.h>

static void first(void);

typedef void (*fnptr)(void);
bool stopped = false;
uintptr_t pc = (uintptr_t)first;
uintptr_t *pcptr = &pc;

void
done(void)
{
printf("done\n");
stopped = true;
}

void
second(void)
{
printf("second\n");
*pcptr = (uintptr_t)done;
}

void
first(void)
{
printf("first\n");
*pcptr = (uintptr_t)second;
}

void
run(void)
{
do {
((fnptr)*pcptr)();
} while (!stopped);
}

int
main(void)
{
run();
return 0;
}
term% gcc-16 -std=c11 -pedantic -o b b.c
term% ./b
first
second
done
term%
```

BTW what name would be given to such a function pointer type?

I have no idea what your code is supposed to do,

It's a table of function pointers! All sharing the same signature.

That's pretty generic. Is it really that hard to guess? You don't need
to know what they do, other than at some point they will be called as >handlertable[i](arg).

That part is fine.

What's utterly mystifying is what you are trying to show, if
anything, by posting it. Is this supposed to prove some kind of
point? Your code is not _a priori_ easier to understand than
the equivalent C code; if anything, it is harder to understand
because of your poorly chosen names.

- Dan C.

Rust implementation of Timers, mentioned above<--

As mentioned above, if I were providing the FreeRTOS timers API
in an alternative language, I'd write it differently from the
start. In particular, I'd use an enumeration to describe the
behavior with respect to repeating, and I'd use a closure to
obviate the need for the opaque id. Something that isn't easy
to express in the original API is a type of repeating timer that
waits for the initial period, and then repeats with some
different period.

Something like this:

```rust
pub mod timer {
use std::sync::atomic::{AtomicBool, Ordering};
use std::time::Duration;

/// Errors that may occur when working with timers.
#[derive(Clone, Copy, Debug)]
pub enum Error {
Running,
CantStop,
WontStop,
}

/// Describes the kind of a timer, as defined by its
/// periodicity.
///
/// A timer can either be a `OneShot` timer, which fires
/// once, after its timeout expires, or it may be a Repeating
/// timer, which will automatically reset after its handler
/// is run and continue firing at the rate defined by the
/// initial timeout, or it can be a periodic timer, that
/// will fire the first time at the initial timeout, and
/// then repeatedly a potentially different timeout. This
/// use case can be simulated by a OneShot timer that
/// creates a repeating Timer, but
///
/// Once started, Repeating and Periodic timers continue
/// firing until explicitly stopped.
#[derive(Clone, Copy, Debug)]
pub enum Kind {
OneShot,
Repeating,
Periodic(Duration),
}

/// A named timer, that is handled by the given callback.
pub struct Timer<'a, F> {
pub name: &'a str,
pub kind: Kind,
pub timeout: Duration,
callback: F,
running: AtomicBool,
// Whatever other innards...
// ...
}

/// A read-only "view" into the timer.
pub trait TimerView {
fn name(&self) -> &str;
fn kind(&self) -> Kind;
fn timeout(&self) -> Duration;
}

impl<'a, F: Fn(&dyn TimerView)> Timer<'a, F> {
/// Creates a new named timer of the given kind with an
/// initial timeout. When the timeout expires, it will
/// automatically invoke the given handler.
pub fn new(
name: &'a str,
timeout: Duration,
kind: Kind,
callback: F,
) -> Timer<'a, F> {
let running = AtomicBool::new(false);
Self {
name,
kind,
callback,
timeout,
running,
}
}

/// Starts the timer.
pub fn start(&self) -> Result<(), Error> {
if self.running.swap(true, Ordering::AcqRel) {
return Err(Error::Running);
}
self.arm(self.timeout)?;
Ok(())
}

/// Stops the timer.
///
/// Note that this inherently races with the timer firing,
/// and a timer event that occurs while we are disabling
/// the timer may still invoke `fired` after this returns.
///
/// Callers are advised to determine definitively that
/// there are no events pending for this timer before
/// destroying the `Timer` object.
pub fn stop(&self) -> Result<(), Error> {
let was_running = self.running.swap(false, Ordering::AcqRel);
if !was_running {
return Err(Error::WontStop);
}
self.disarm();
Ok(())
}

// Automatically called when the timeout fires.
//
// # Safety
//
// Nothing may be mutably borrowing a reference to the
// Timer object when this is called.
pub(super) unsafe fn fired(&self) -> Result<(), Error> {
if !self.running.load(Ordering::Acquire) {
return Ok(());
}
(self.callback)(self);
match self.kind {
Kind::OneShot => Ok(()),
Kind::Repeating => self.arm(self.timeout),
Kind::Periodic(period) => self.arm(period),
}
}

// Arranges for `self.fired(self)` to be called when
// the given timeout expires.
fn arm(&self, timeout: Duration) -> Result<(), Error> {
// Does whatever one does here to actually arm the
// timer (e.g., calls a HAL to actually program a
// physical timer to interrupt after the amount of
// time specified by `Duration`, for example).
// ...
Ok(())
}

// Disables an armed timer, so that it does not fire
// after this returns.
fn disarm(&self) -> Result<(), Error> {
// whatever one does here to disarm an active timer
// ...
Ok(())
}
}

impl<F> TimerView for Timer<'_, F> {
fn name(&self) -> &str { self.name }
fn kind(&self) -> Kind { self.kind }
fn timeout(&self) -> Duration { self.timeout }
}
}
```

One might use this with something like,

```
let value = 42;
let cb = move |timer: &dyn timer::TimerView| {
println!(
"Timer '{}' fired; value is {} and duration was {} ms",
timer.name(),
value,
timer.timeout().as_millis()
);
};
let timeout = std::time::Duration::from_millis(100);
let timer = timer::Timer::new("timer", timeout, timer::Kind::OneShot, &cb);
timer.start().expect("Timer started");
//... at some point the timer fires and prints,
// 'Timer 'timer1' fired; value is 42 and duration was 100 ms'
}
```

--- PyGate Linux v1.5.19
* Origin: Dragon's Lair, PyGate NNTP<>Fido Gate (3:633/10)

On 20/10/2026 16:02, David Brown wrote:

On 20/10/2026 16:11, bart wrote:

The other was C. There, several choices were made:

* To start with that Fortran style except that [] are used

* To decree that that 'A[20]' syntax is supposed to match indexing of
ÿÿ A as it might appear in an expression

* To introduce "*" as a prefix dereference operator in expressions ...

* ... which then means that a prefix "*" appears in the declaration too

* A further complication was to allow function pointers within that a
ÿÿ declaration list

I don't see a problem with that.ÿ If you need to declare a function
pointer, you need to declare it in a declaration list.

To me, the big disadvantage of C's declaration syntax is that it lets
you declare things of different (but related) types in the same
declaration.

Yes, but that doesn't bite so much because it is uncommon.

or, more common and therefore worse :

ÿÿÿÿint * a, b;

(See below.)

* Yet one more which came later was to add 'const', where placement now
ÿÿ gets confusing

Some people do find it hard to understand the difference between :

ÿÿÿÿconst int * p;
ÿÿÿÿint * const q;
ÿÿÿÿconst int * const r;

I note that this is despite the clear left-to-right nature of "const" here.

I was going to say it was right-to-left, but it can be considered both
and thus not clear:

const int const * const p;
1 2 3

const 1 applies to the basetype to its right.
const 2 applies to the basetype to its left.

(Both also can be in the middle with compound types like 'long long'!)

const 3 is tricky: I think it applies to the * to its left, since it
says that the pointer value itself is const. But 'p' has type 'pointer
to', so it could apply to that directly.

What about this however:

int * const * p;

1 2 3

I think here, const 2 applies to * 1, which is to it's left, and can't
apply to 'p' as that is the other side of the * 3.

Fair to say that is a complete mess, and it is error prone.

With a LTR syntax that a postfix deref would achieve, 'const' would
always be written immediately to the left of any * modifiers. (It is meaningless for arrays and functions.)

It is never applied directly to a variable name.

For base types, it can be applied on the left, but C would still allow
it on the right or in the middle, or all three with duplicates.

That means there would be an ambiguity here where there is no identifier between 'int' and 'const':

(const int const *)

For such reasons I would restrict base type const to be only on the left.)

Complicated types are a minority.

I've showed even simple types or trying to use 'const' get becomes
confusing.

So, PARENTHESES HAVE BEEN ELIMINATED for purpose of disambiguating
array/pointer and pointer/array, both within expressions and within
type-declarations.

Agreed.

But does that make a significant difference?ÿ I don't think so.

It would make a HUGE difference:

(1) It helps to fix that confusion above

(2) You don't need parentheses so no need to remember if you want
(*A)[] or *A[]. Those will disappear from expressions too; less
clutter all round.

(3) It simplifies indexing of pointer-to-array from (*A)[i] to A*[i], so
that actual array pointers, which are more type-safe, could start to
appear more in C rather than the current T* idiom

(4) For pointers to structs, these are the patterns:

prefix * With -> With postfix *

(*P).m P->m P*.m
(**P).m (*P)->m P**.m
(***P).m (**P)->m P***.m

Which column looks the tidiest?

(5) With prefix *, a pointer type looks like 'T*'; notice the * is on
the right, not left! With postfix *, it would all be consistent. You
also wouldn't have 'T*A'; that would be an error (T* only happens
when there is no name)

(6) Your 'int * a, b' example would become:

int a *, b;

Much easier, even with that space, to see that '*' does not belong to
the base type but is a modifier for that variable.

It doesn't fix everything, so you'd still have this:

int p* = &a;
p* = a;

To fix this requires that all modifiers apply to the base type. But this
would be a massive change. The above is merely what happens when *
becomes postfix.

A mistake that could so easily have been avoid by choosing a different
precedence as shown above. Did none of the thousand people working at
Bell Labs (according to a comment in DC's follow-ip) spot this and say
anything?

I suspect the folks at Bell Labs were too busy writing real code to be bothered by how confused you would be with artificially complex types.

So you agree the process was very different compared to that which lead
to Ada for example? Just a couple of guys left to do their own thing.

(Maybe they were respected enough that no one dared to offer any
constructive criticism, or if they did then it was dismissed. As happens here.)

(ACTUALLY IT IS NOT TOO LATE. A secondary postfix deref op could have
been added. This could have been done 50 years ago, with the original
eventually deprecated.

It /is/ too late - far, far too late.ÿ It would be a terrible idea to
add a new postfix dereference operator to give two different operators
with no benefit other than very occasionally reducing the need for parentheses.

But a special operator P->m to do the same job as (*P).m was fine! The
new op would eliminate the need for ->.



--- PyGate Linux v1.5.19
* Origin: Dragon's Lair, PyGate NNTP<>Fido Gate (3:633/10)

On 20/10/2026 20:24, Dan Cross wrote:

In article <11b7k22$2v8e5$1@dont-email.me>, bart <bc@freeuk.com> wrote:

The point is that the name you chose is meaningless to anyone
other than you. What's a PCL? Phase Control Line? Printer
Command Language? Photon Compressor Loop?

Within the context of that application then it would be clear. You're
just being overly hostile.

(Within the app, PCL is the name of a bytecode language, and 'pcl' is a reference to a specific instruction.

Next time I'll just use T for such examples, since the type is not
relevant to the point. Although that didn't stop you seizing upon my F function.)

Here is the one place I do remember using typedef for a function pointer
(from an old project, not in C):

type fnptr = ref proc

repeat
(fnptr(pcptr^))^()
until stopped

More generally, I fail to see what this is trying to
demonstrate.

Not much. It is just a rare example of my using aliases for function
pointers. Because I suggested such aliases are often unnecessary and
partly used in C to get around the fiddly type syntax that would arise.



--- PyGate Linux v1.5.19
* Origin: Dragon's Lair, PyGate NNTP<>Fido Gate (3:633/10)

On Tue, 20 Oct 2026 15:11:35 +0100
bart <bc@freeuk.com> wrote:

On 20/10/2026 02:03, Waldek Hebisch wrote:

bart <bc@freeuk.com> wrote:

OK. But they HAD to create C? There were quite a few languages in
the early 70s too: like Pascal, Fortran, PL/I, Coral-66, plus of
course BCPL and B. So why a new one?

You ignore fact that Ritche wanted reasonably fast code from
very simple compiler.

According to DC's quote from HOPL, it was also more fun to create a
new language.

PL/I had most needed features. But PL/I was a big language,
to run on small machine they would have to take tiny subset
and then add extentions. Basicaly they would end up with a
language which is very far from PL/I.

There were PL/360 and PL/M, although those were more specific, more 'machine-oriented' languages. (I implemented one for PDP10 but it was
a port of a systems language from a GEC machine.)

PL/M is approximately contemporary to C, most likely Ritchie had first
compiler working few months before Kildall. But input language of the
early C compilers was likely further away from what it evolved later
than early PL/M to later its variant.
C was self-hosted on minicomputer from the beginning.
PL/M originally required more powerful and expensive host. Eventually
PL/M host requirements were reduced below those of C, but it took couple
of years.

Anyway, a more general subset could have been used.

I suppose that you wholeheartedly agree. I don't. I never found computer language design fun.

Similarly, BCPL was too complicated, B and C were simplifications
and adaptations small machine.

I think that Pascal was too late: nominally it was created earlier
but I think that it was available to Bell Labs only after they
did initial work leading to C. And Pascal shared problem of
speed on small machines. Note that later UCSD Pascal which
run on micros compiled to interpreted bytecode, which significantly
reduced performance.

It would not have been hard to use Pascal as a starting point for a
workable systems language. Wirth wouldn't have approved, but his
languages were too pure, too academic; some of us had things we
needed to get done!

Here I mean adapting Pascal for a competing systems language.

Pascal without several extensions does not seem suitable for system programming.

In my hands some aspects would be simplified (eg. no nested
functions, no closures), thus making it easier to generate decent
code with a simple compiler.

But then, it's not Pascal. And still needs extensions.

FORTRAN syntax looked nothing like C! Unless you mean the general
pattern of 'INTEGER A, B' which was shared by half of all
languages.

I think more pattern of

INTEGER A(20), B

which has similar structure to C variable declarations.

OK. That was typical for the time. But in Fortran it didn't get much
more complicated than that. Maybe 2D arrays and so on.

Of course,
FORTRAN had no pointers (and structures or unions), so Ritche had
to invent syntax for them.

There were three languages from that era that I know had pointers or references, and which allowed composing arbitrary types with arrays
and pointers, two of which were Algol68 and Pascal.

Both used a 100% LTR form.

The other was C. There, several choices were made:

* To start with that Fortran style except that [] are used

* To decree that that 'A[20]' syntax is supposed to match indexing of
A as it might appear in an expression

* To introduce "*" as a prefix dereference operator in expressions ...

* ... which then means that a prefix "*" appears in the declaration
too

* A further complication was to allow function pointers within that a
declaration list

* Yet one more which came later was to add 'const', where placement
now gets confusing

But to stay with pointers, take this expression:

*A[i]

C precedence rules mean this is parsed as *(A[i]), which means that a
type written as 'T *A[N]' must be an array of pointers to T (I had to
think for a few seconds!).

But suppose you wanted a pointer to array of T? The expression for
that would be:

(*A)[i]

And so the declaration has to be 'T (*A)[N]' too.

So it is unfortunate that parentheses used to control precedence in
an expression now also have to appear in type declarations (where
they are often next to () used for parameter lists, for further
confusion).

==============================================

So, what would have happened with a postfix deref op? (Ignore whether
'*' would still be a good choice.) My first example would be this:

A*[i]

Here, it would mean that A is dereferenced, then indexed; A must then
be a pointer to an array of T.

But suppose we wanted the original array of pointers to T, where you
index first then dereference. That is written like this:

A[i]*

You simply swap the order of [] and *.

So, PARENTHESES HAVE BEEN ELIMINATED for purpose of disambiguating array/pointer and pointer/array, both within expressions and within type-declarations.

How about that? Further, most of the type-spec is now LTR; only the base-type has to stay on the left. Access terms in expressions will
be fully LTR.

IMO C suffers because typedef was added late in the game and
function prototypes are much later. Prototypes need types and
to get it one needs "hole" in variable declaration. Where the
hole should be is specified by the C syntax, but placement of
hole is probably least clear aspect of declarations.

I thought that 'hole' was where 'int A[10]' mean one thing in normal declaration but another within a parameter list.

IMO C declaration syntax was a mistake, but as real life shows
it was not a fatal mistake, people can adapt.

A mistake that could so easily have been avoid by choosing a
different precedence as shown above. Did none of the thousand people
working at Bell Labs (according to a comment in DC's follow-ip) spot
this and say anything?

Methinks there were less than 100 people exposed to C before it became
too late. May be, just 50.

Had no-one even glanced at a Pascal spec, if there was no working
copy? It would have transformed C type syntax.

(ACTUALLY IT IS NOT TOO LATE. A secondary postfix deref op could have
been added. This could have been done 50 years ago, with the original eventually deprecated.

But this is a common theme of mine whether I perceive a problem that
people grudgingly admit might not be idea. But nothing was ever done
to fix it even after decades.)

It was. There are many new languages.
Today, C sees little use outside of small to mid-sized mocrocontrollers
and OS kernels.
Most user-layer applications on general purpose computers are written
in newer languages.


--- PyGate Linux v1.5.19
* Origin: Dragon's Lair, PyGate NNTP<>Fido Gate (3:633/10)

In article <11b8j17$3btus$1@dont-email.me>, bart <bc@freeuk.com> wrote:

On 20/10/2026 20:24, Dan Cross wrote:

In article <11b7k22$2v8e5$1@dont-email.me>, bart <bc@freeuk.com> wrote:

The point is that the name you chose is meaningless to anyone
other than you. What's a PCL? Phase Control Line? Printer
Command Language? Photon Compressor Loop?

Within the context of that application then it would be clear. You're
just being overly hostile.

Not really. You are, I presume, posting that code to try and
make some kind of point about how "readable" it is. But it's
not readable unless you already know what it does.

On the other hand, the code David posted _is_ readable, because
it uses the language to encode domain-specific information into
type names.

(Within the app, PCL is the name of a bytecode language, and 'pcl' is a >reference to a specific instruction.

Next time I'll just use T for such examples, since the type is not
relevant to the point. Although that didn't stop you seizing upon my F >function.)

You just don't get it. I suspect you have no idea what the
`typedef`s David posted actually represent.

Here is the one place I do remember using typedef for a function pointer >>> (from an old project, not in C):

type fnptr = ref proc

repeat
(fnptr(pcptr^))^()
until stopped

More generally, I fail to see what this is trying to
demonstrate.

Not much. It is just a rare example of my using aliases for function >pointers. Because I suggested such aliases are often unnecessary and
partly used in C to get around the fiddly type syntax that would arise.

Yeah, you really just don't get it.

- Dan C.


--- PyGate Linux v1.5.19
* Origin: Dragon's Lair, PyGate NNTP<>Fido Gate (3:633/10)

On 20/10/2026 22:44, Dan Cross wrote:

In article <11b8j17$3btus$1@dont-email.me>, bart <bc@freeuk.com> wrote:

On 20/10/2026 20:24, Dan Cross wrote:

In article <11b7k22$2v8e5$1@dont-email.me>, bart <bc@freeuk.com> wrote:

The point is that the name you chose is meaningless to anyone
other than you. What's a PCL? Phase Control Line? Printer
Command Language? Photon Compressor Loop?

Within the context of that application then it would be clear. You're
just being overly hostile.

Not really. You are, I presume, posting that code to try and
make some kind of point about how "readable" it is. But it's
not readable unless you already know what it does.

What it does not relevant. This is simply defining an array of T. But
because T happens to be a function pointer, DB insists that an alias
must be created, and a new name invented.

Why? Probably because in C, the syntax for function pointers gets hairy.

On the other hand, the code David posted _is_ readable, because
it uses the language to encode domain-specific information into
type names.

Maybe we should create aliases for function signatures more often then,
then we can encode that extra info.

So that instead of, for example:

void SomeFunc(int x, int y) {printf("%d %d\n", x, y);}

you do:

typedef void Take2Ints(int x, int y);

Take2Ints SomeFunc {printf("%d %d\n", x, y);}

If you have a suite of functions sharing the signature, then it might be
a good idea. But funnily enough, you never see this being done.

(I don't know if this is legal C; but it works fine with my compiler:

c:\m>type fred.c
#include <stdio.h>

typedef void Take2Ints(int x, int y);

Take2Ints SomeFunc{printf("%d %d\n", x, y);}

int main(void) { SomeFunc(10, 20); }

c:\m>bcc -r -q fred
10 20

)

Yeah, you really just don't get it.

One of us doesn't get it.

--- PyGate Linux v1.5.19
* Origin: Dragon's Lair, PyGate NNTP<>Fido Gate (3:633/10)

On 20/10/2026 21:33, Michael S wrote:

On Tue, 20 Oct 2026 15:11:35 +0100
bart <bc@freeuk.com> wrote:

I suppose that you wholeheartedly agree. I don't. I never found computer language design fun.

The fun part is afterwards when you use your very own language. Quite a
way to get there though.

Methinks there were less than 100 people exposed to C before it became
too late. May be, just 50.

Were you there? You seem confident of those figures! I've no idea what
went on, myself; I can only speculate.

Had no-one even glanced at a Pascal spec, if there was no working
copy? It would have transformed C type syntax.

(ACTUALLY IT IS NOT TOO LATE. A secondary postfix deref op could have
been added. This could have been done 50 years ago, with the original
eventually deprecated.

But this is a common theme of mine whether I perceive a problem that
people grudgingly admit might not be idea. But nothing was ever done
to fix it even after decades.)

It was. There are many new languages.
Today, C sees little use outside of small to mid-sized mocrocontrollers
and OS kernels.
Most user-layer applications on general purpose computers are written
in newer languages.

I still see C everywhere, for example in the APIs of libraries like SDL,
STB, GTK, OpenGL, Raylib, GMP, plus the APIs for many Windows
subsystems, plus Linux.

It's also popular as a target language for compilers (when LLVM is too
much). Amateur compiler writers also seem to love creating C or C subset compilers more than any other language (they perceive it as simpler than
it really is).

And many language projects are still written in C, or at bootstrapped
with C.

This is all desktop machines still. Of course many are also migrating to products like Rust, Go and Zig.

For me, the fact that there's still an appetite for a language of this
class is one reason I still persist with mine.




--- PyGate Linux v1.5.19
* Origin: Dragon's Lair, PyGate NNTP<>Fido Gate (3:633/10)

antispam@fricas.org (Waldek Hebisch) writes:

Tim Rentsch <tr.17687@z991.linuxsc.com> wrote:

antispam@fricas.org (Waldek Hebisch) writes:

Lawrence D?Oliveiro <ldo@nz.invalid> wrote:

On Tue, 13 Oct 2026 07:23:40 -0000 (UTC), Waldek Hebisch wrote:

So what those counts indicate: majority of loops is simple, that is >>>>> have no early exit. Vast majority of early exits is done via
'return'.

My experience in my own C code is quite the opposite. Lots of loops
have exits in the middle, leading me to use forms like ?for (;;)?. I
also try to avoid putting ?return? anywhere other than the end of a
function, to make it easier to see the flow of control.

Well, usually there is a lot of loops. Those with exit in the
middle are still significant.

Concernig 'return', having it in place where all work inside function
is done help me to see flow control and avoids complications. In
case of search functions it means return from the middle of the loop.
IMO possible alternatives like flag variables or break and retrun
after loop are worse.

I rarely use 'break' to exit a loop. Part of this is that I try to
write standard loops so that they complete as part of the loop test
(i.e., in while() or for() control expressions). That isn't the
whole story though so let me talk about 'return'.

I counted various constructs in a small suite of 2 programs (1306
lines in 3 files). There are 4 breaks outside switches and 32
loops in total. My gut feeling is that this proportion is
reasonable close to typical in my code. For comparison, there
are 67 functions and 70 'if'-s.

Probably that is close to what I see for my own code, if we
count 'return' out of a loop.

Most of the functions I write have exactly one return, at the end of
the function. I estimate this pattern accounts for around 85% of
all functions, let's say plus or minus 5%.

In code above about half of functions is 'void' and there are 34
explicit returns (of which at least 2 are early returns).

I almost never use void functions. I'm used to a functional style,
and it's natural to return something in almost all cases.

Sometimes functions have early returns for errors or exceptional
conditions.

Code above contains 16 occurences of 'exit(1)'. One of those is
in a macro that is used 10 times, so actually there are 25 places
which call 'exit(1)'. That is related to the programs being
simple utilities, there is no attempt to error recovery, on error
programs simply print error message and exit.

okay. I don't use exit() often but I have no problem with that.

Early returns are easily seen to lie outside the main
body of function processing so they don't interfere with
understanding what the rest of the function is doing or how it
works.

A fairly common sub-pattern are functions most of whose body is a
switch() statement, with all of the switch() cases being a simple
return.

Code above has 2 switches, both are in parsing functions, where
cases either move to next state or signal error. Parsing functions
also open file and close it when finished and return data structure
with parsed info.

In other kinds of code I might use switch() more often. Maybe I
can try putting together a small application where switch() is more
likely and see what I get.

It does sometimes happen that a function will have a loop with a
return in the middle, and also a return at the end for what to do if
the loop terminates. To me having an in-loop return looks better
than using an assignment and a break.

A fairly rare but important pattern is what I might call vectoring
or decomposition. Here the function body serves to distinguish and
separate out different regimes of subprocessing. To continue
processing in a particular regime, a return is used not to directly
yield a value but rather to call a further function to handle that
sub-domain. The benefit here is both to keep function bodies small
and to allow re-use of commonly called sub-functions.

Two aspects are important for having these different styles work
together. One is that it's easy to distinguish the different kinds
of patterns, and by far the most simple pattern is the most common.
The other is to be sure to keep function bodies small. Keeping
function bodies small goes a long way in making them easy to
understand, which obviously is a key property in writing good code.
Also keeping function bodies small effectively prevents mixing
different styles in a single function, serving to reinforce point
one.

I think that in general my C code has similar characteristics.

Yes it sounds that way.

But
let me note that while I have a lot of small functions, I also have
some which are bigger. I suspect that 10% or more of my code is
in functions that are bigger then 30 lines. Such functions
frequently have several variables and there is setup stage to
initialize things, actual processing and final part (cleanups,
possibly extraction of result). Stages are clearly sepatated
by their position inside function, OTOH are strongly coupled due
to use of variables. My feeling here is that in case of strongly
coupled code with no reusable parts keeping it inside single
function is more managable than trying to split it into smaller
functions.

It's natural for me not to let functions get too large, which means
more than about 60 lines of code. But beyond that wanting to write
small functions doesn't mean only tiny functions. My "10% or more"
function size may be a little smaller than yours, but not much
smaller. Also I observe empirically an interesting property, which
is that if we multiply the number of functions of size N by N, the
result is roughly constant across the range of function sizes. So
for example if there are three functions whose bodies have 50 lines
then there are roughly 50 functions whose bodies have three lines.
And that holds approximately across the whole range of function
sizes (with a standard deviation about half the average). So there
are lots of little functions but also functions of sizes in the
20s, 30s, 40s and 50s. Does that sound similar to your own code?

--- PyGate Linux v1.5.19
* Origin: Dragon's Lair, PyGate NNTP<>Fido Gate (3:633/10)

David Brown <david.brown@hesbynett.no> writes:
[...]

Without typedef's, that function signature would be something like :

signed char dns_gethostbyname(const char *hostname, struct ip_addr
*addr, void (*found)(const char *name, const struct ip_addr
*ipaddr, void *callback_arg), void *callback_arg);

I might write that as:

signed char dns_gethostbyname(
const char *hostname,
struct ip_addr *addr,
void (*found)(
const char *name,
const struct ip_addr *ipaddr,
void *callback_arg
),
void *callback_arg
);

so the indentation and structure reflects the semantics. I find
that much clearer than your version. (I'm not commenting on the
merits of typedefs.)

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

--- PyGate Linux v1.5.19
* Origin: Dragon's Lair, PyGate NNTP<>Fido Gate (3:633/10)

In article <11b8qqg$3ejlp$1@dont-email.me>, bart <bc@freeuk.com> wrote:

On 20/10/2026 22:44, Dan Cross wrote:

In article <11b8j17$3btus$1@dont-email.me>, bart <bc@freeuk.com> wrote:

On 20/10/2026 20:24, Dan Cross wrote:

In article <11b7k22$2v8e5$1@dont-email.me>, bart <bc@freeuk.com> wrote: >>>
The point is that the name you chose is meaningless to anyone
other than you. What's a PCL? Phase Control Line? Printer
Command Language? Photon Compressor Loop?

Within the context of that application then it would be clear. You're
just being overly hostile.

Not really. You are, I presume, posting that code to try and
make some kind of point about how "readable" it is. But it's
not readable unless you already know what it does.

What it does not relevant. This is simply defining an array of T. But >because T happens to be a function pointer, DB insists that an alias
must be created, and a new name invented.

Why? Probably because in C, the syntax for function pointers gets hairy.

I dunno; your syntax didn't seem any clearer to me.

On the other hand, the code David posted _is_ readable, because
it uses the language to encode domain-specific information into
type names.

Maybe we should create aliases for function signatures more often then,
then we can encode that extra info.

So that instead of, for example:

void SomeFunc(int x, int y) {printf("%d %d\n", x, y);}

you do:

typedef void Take2Ints(int x, int y);

Take2Ints SomeFunc {printf("%d %d\n", x, y);}

If you have a suite of functions sharing the signature, then it might be
a good idea. But funnily enough, you never see this being done.

Yeah, you really don't get it.

You remind me of the guy at Google who objected to importing the
`std::` namespace in C++ into the default scope; "oh, so what;
we should all write ::std::whatever::foo<::std::blah>(...)?!" as
if finding the most stupidly extreme example was somehow a
useful technical argument. He also spent all his time on
mailing lists arguing about how everybody else Got It Wrong. He
got fired a few months later.

(I don't know if this is legal C; but it works fine with my compiler:

c:\m>type fred.c
#include <stdio.h>

typedef void Take2Ints(int x, int y);

Take2Ints SomeFunc{printf("%d %d\n", x, y);}

int main(void) { SomeFunc(10, 20); }

c:\m>bcc -r -q fred
10 20
)

Yeah, I gues running it through `gcc` is a really heavy lift.
<eyeroll>

Yeah, you really just don't get it.

One of us doesn't get it.

I'm glad you can admit it.

- Dan C.


--- PyGate Linux v1.5.19
* Origin: Dragon's Lair, PyGate NNTP<>Fido Gate (3:633/10)

On 20/10/2026 13:58, David Brown wrote:

On 20/10/2026 13:41, bart wrote:

But let us take a concrete example.ÿ These network functions are from
the LWIP network stack, which is designed to be used on small embedded systems that may not have any kind of OS - so it uses call-backs for asynchronous programming.

An example API function is this :

err_t dns_gethostbyname(const char *hostname, ip_addr_t *addr,
ÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿ dns_found_callback found, void *callback_arg)

The returned "err_t" can be "ERR_OK" (indicating the "hostname" is in
the DNS cache and *addr is set to the IP), "ERR_ARG" for argument
errors, or "ERR_INPROGRESS" to indicate that the stack is looking up the
DNS name, and will call the callback when there is a final result or timeout.

Without typedef's, that function signature would be something like :

signed char dns_gethostbyname(const char *hostname, struct ip_addr
ÿÿÿÿ*addr, void (*found)(const char *name,ÿÿÿ const struct ip_addr
ÿÿÿÿ*ipaddr, void *callback_arg), void *callback_arg);

Do you expect anyone to believe you if you claim this is easier to read
than the real declaration using typedefs?ÿ I'll believe you if you say
you find the original hard to read - but not if you claim the
"untypedef'ed" version is clearer.

Neither are great. But let's first lay them out better:

err_t
dns_gethostbyname(
const char *hostname,
ip_addr_t *addr,
dns_found_callback found,
void *callback_arg
);

Here, one problem is that there are 3 types that I don't know and would
have to look up. The long version at least has all the info in one place:

signed char
dns_gethostbyname(
const char *hostname,
struct ip_addr *addr,
void (*found)(const char *name, const struct ip_addr *ipaddr,
void *callback_arg),
void *callback_arg
);

That signed char return is unusual; why not 'int'? (How would you even
print an 'err_t' value anyway)?

That 'ip_addr_t' turns out to be a struct. For those I would use
typedefs anyway; I rarely use struct tags and you have to invent an
identifier in either case.

Then we come to the function pointer, which is a quite a chunky one, but
let's work with it. Here, I would question whether you really need those
types in there, and especially those names.

Presumably you have a regular function of your own with the same
signature? You anyway never directly 'call' this parameter with
arguments; you just pass it the address of your handler.

Or do you use that typedef as documentation?

Where does the info come from anyway; does the library export a suitable typedef? In that case you might as well use it. But if not, info must
come from elsewhere.

Anyway with some tweaks in place, using the struct typedef and using an
inline function pointer type, it would look like this:

signed char
dns_gethostbyname(
const char *hostname,
IP_addr *addr,
void (*found)(char*, IP_addr*, void *),
void *arg
);

In this form, it is not wildly different from your short version.

So I would look at other ways of tidying up before resorting to
extraneous typedefs.

But here, there may well be an extra reason to use a callback typedef; I
don't have the full details.



--- PyGate Linux v1.5.19
* Origin: Dragon's Lair, PyGate NNTP<>Fido Gate (3:633/10)

David Brown <david.brown@hesbynett.no> writes:

On 19/10/2026 23:27, Janis Papanagnou wrote:

[...]

ÿ * a bÿÿÿÿ PN (Polish Notation)

There is no term "Polish Notation" - except as occasionally used to
mean /postfix/ as a short form of "Reverse Polish Notation". RPN was invented, or at least popularised, by the Polish logician Jan
?ukasiewicz (I admit to looking that up on Wikipedia!). There is no
"PN" opposite.

Yes, there most certainly is, and "* a b" is a good example of it.

https://en.wikipedia.org/wiki/Polish_notation

Jan ?ukasiewicz invented what we now call Polish notation in 1924.
`+ 3 4` is an example (which yields 7). Lisp syntax is more or
less Polish notation with added parentheses. (I'm sure the phrase
"more or less" is doing a lot of work.)

Reverse Polish Notation, RPN, is very well known because it's
used by some calculators, particularly those made by HP. It's a
postfix notation. An example of RPN is `3 4 +` (which also yields 7).

I've never seen the term "Polish Notation", without "Reverse", used
to refer to postfix notation. PN is prefix; RPN is postfix.

I see that Janis already pointed out your error. I'm disappointed
that your followup did not acknowledge it. (I'm not commenting on the
rest of what Janis wrote.)

[...]

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

--- PyGate Linux v1.5.19
* Origin: Dragon's Lair, PyGate NNTP<>Fido Gate (3:633/10)

On 21/10/2026 01:56, Dan Cross wrote:

In article <11b8qqg$3ejlp$1@dont-email.me>, bart <bc@freeuk.com> wrote:

On 20/10/2026 22:44, Dan Cross wrote:

In article <11b8j17$3btus$1@dont-email.me>, bart <bc@freeuk.com> wrote: >>>> On 20/10/2026 20:24, Dan Cross wrote:

In article <11b7k22$2v8e5$1@dont-email.me>, bart <bc@freeuk.com> wrote: >>>>
The point is that the name you chose is meaningless to anyone
other than you. What's a PCL? Phase Control Line? Printer
Command Language? Photon Compressor Loop?

Within the context of that application then it would be clear. You're
just being overly hostile.

Not really. You are, I presume, posting that code to try and
make some kind of point about how "readable" it is. But it's
not readable unless you already know what it does.

What it does not relevant. This is simply defining an array of T. But
because T happens to be a function pointer, DB insists that an alias
must be created, and a new name invented.

Why? Probably because in C, the syntax for function pointers gets hairy.

I dunno; your syntax didn't seem any clearer to me.

Yeah, the C is so much clearer. Of course, you would all lie through
your teeth anyway before you'd admit mine might be simpler.

I've just defined three entities: a variable, a function pointer, and a function, in both my syntax and in C's.

Here are the first tokens of the C versions:

int
int
int

Can you guess which one is which yet?

Here are the first three tokens in my syntax:

int
func
ref

Any easier? This is like PL Design 101.



--- PyGate Linux v1.5.19
* Origin: Dragon's Lair, PyGate NNTP<>Fido Gate (3:633/10)

bart <bc@freeuk.com> writes:
[...]

Yeah, the C is so much clearer. Of course, you would all lie through
your teeth anyway before you'd admit mine might be simpler.

[...]

You preemptively accuse someone of being a liar, and then you wonder
why people are hostile to you.

Tone down the insults and hyperbole.

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

--- PyGate Linux v1.5.19
* Origin: Dragon's Lair, PyGate NNTP<>Fido Gate (3:633/10)

In article <11b954e$3hjvi$1@dont-email.me>, bart <bc@freeuk.com> wrote:

On 21/10/2026 01:56, Dan Cross wrote:

In article <11b8qqg$3ejlp$1@dont-email.me>, bart <bc@freeuk.com> wrote:

On 20/10/2026 22:44, Dan Cross wrote:

In article <11b8j17$3btus$1@dont-email.me>, bart <bc@freeuk.com> wrote: >>>>> On 20/10/2026 20:24, Dan Cross wrote:

In article <11b7k22$2v8e5$1@dont-email.me>, bart <bc@freeuk.com> wrote: >>>>>
The point is that the name you chose is meaningless to anyone
other than you. What's a PCL? Phase Control Line? Printer
Command Language? Photon Compressor Loop?

Within the context of that application then it would be clear. You're >>>>> just being overly hostile.

Not really. You are, I presume, posting that code to try and
make some kind of point about how "readable" it is. But it's
not readable unless you already know what it does.

What it does not relevant. This is simply defining an array of T. But
because T happens to be a function pointer, DB insists that an alias
must be created, and a new name invented.

Why? Probably because in C, the syntax for function pointers gets hairy.

I dunno; your syntax didn't seem any clearer to me.

Yeah, the C is so much clearer. Of course, you would all lie through
your teeth anyway before you'd admit mine might be simpler.

Oh, grow up.

- Dan C.


--- PyGate Linux v1.5.19
* Origin: Dragon's Lair, PyGate NNTP<>Fido Gate (3:633/10)

In article <11b963d$3h5oi$2@kst.eternal-september.org>,
Keith Thompson <Keith.S.Thompson+u@gmail.com> wrote:

bart <bc@freeuk.com> writes:
[...]

Yeah, the C is so much clearer. Of course, you would all lie through
your teeth anyway before you'd admit mine might be simpler.

[...]

You preemptively accuse someone of being a liar, and then you wonder
why people are hostile to you.

Tone down the insults and hyperbole.

The Lord and Master has spoken.

All must comply with His dictates.

--
Just like Donald Trump today, Jesus Christ had a Messiah complex.

And, in fact, the similarities between the two figures are quite striking.
For example, both have a ragtag band of followers, whose faith cannot be shaken.

--- PyGate Linux v1.5.19
* Origin: Dragon's Lair, PyGate NNTP<>Fido Gate (3:633/10)

Lawrence D?Oliveiro pisze:

t to end each case-sequence in a switch statement with
a break-statement: put the break at the same indentation level as the case-clause as well as the switch-expression. That way, you can scan
your eye down a single line f

some time ago i was saying what the proper switch should like
(imo, but im not sure if my conclusions are anough to take is a s proven)

case {} case {} case {} otherwise {}

its indeed sorta needed becouse case in fact are ifs
(not if-elses) (so some in fact could write

if {} if {} if {} otherwise {}

its the same)

the problem is you got no group alse
and here this otherwise need to check all ifs
"or" them and use group else for them

this could be written in few ways, but my case case case otherwise names it could also do


if {} or if {} or if {} else {}

so either you need logic operators here or predefined constructs like otherwise (maybe both)

and that should be included not switch wchich is bad imo


other way is to define distionary more as data construct

dict {
'mental' {/* 1 */}
'reductionists' {/* 2 */}
'suck' {/* 3 */}
}

then you could use

dict('reductionists')

to yeld to /* 2 */

this second one parallels to switch keyword


so c switch mixes them both in bad way..they should be spitet and
upbuild as showed ;c

thats my conclusion as switch topic as far by now ;c













--- PyGate Linux v1.5.19
* Origin: Dragon's Lair, PyGate NNTP<>Fido Gate (3:633/10)

On 20/10/2026 22:07, bart wrote:

On 20/10/2026 16:02, David Brown wrote:

On 20/10/2026 16:11, bart wrote:

The other was C. There, several choices were made:

* To start with that Fortran style except that [] are used

* To decree that that 'A[20]' syntax is supposed to match indexing of
ÿÿ A as it might appear in an expression

* To introduce "*" as a prefix dereference operator in expressions ...

* ... which then means that a prefix "*" appears in the declaration too

* A further complication was to allow function pointers within that a
ÿÿ declaration list

I don't see a problem with that.ÿ If you need to declare a function
pointer, you need to declare it in a declaration list.

To me, the big disadvantage of C's declaration syntax is that it lets
you declare things of different (but related) types in the same
declaration.

Yes, but that doesn't bite so much because it is uncommon.

Unfortunately not - but it is uncommon to mix objects and function declarations, or objects of wildly different real types.

or, more common and therefore worse :

ÿÿÿÿÿint * a, b;

(See below.)

* Yet one more which came later was to add 'const', where placement now
ÿÿ gets confusing

Some people do find it hard to understand the difference between :

ÿÿÿÿÿconst int * p;
ÿÿÿÿÿint * const q;
ÿÿÿÿÿconst int * const r;

I note that this is despite the clear left-to-right nature of "const"
here.

I was going to say it was right-to-left, but it can be considered both
and thus not clear:

ÿÿÿ const int const * const p;
ÿÿÿÿÿ 1ÿÿÿÿÿÿÿÿ 2ÿÿÿÿÿÿ 3

const 1 applies to the basetype to its right.
const 2 applies to the basetype to its left.

These are redundant - they do the same thing. (I'd have preferred if
the ordering rules were strict - allowing only "const int" or "int
const" - but at least people are usually consistent in their style.)

(Both also can be in the middle with compound types like 'long long'!)

const 3 is tricky: I think it applies to the * to its left, since it
says that the pointer value itself is const. But 'p' has type 'pointer
to', so it could apply to that directly.

Yes - it is "p" that is const, not the "*".

What about this however:

ÿÿ int * const *ÿ p;

ÿÿÿÿÿÿ 1ÿÿ 2ÿÿ 3

I think here, const 2 applies to * 1, which is to it's left, and can't
apply to 'p' as that is the other side of the * 3.

*p is of type "int * const" - thus you can use "*p" to access a pointer-to-int, but you can't use *p to change that pointer-to-int.

Fortunately, such types are rare.

Fair to say that is a complete mess, and it is error prone.

No, it is not at all fair to say that. It is fair to say that a
different way of writing types might make it easier to understand - but
that's a /long/ way from saying it is "a complete mess". And you can't
call it "error prone" unless you know that people regularly use such declarations, and often have bugs in their code as a result of doing so incorrectly. I think that is an unrealistic claim.

I appreciate that it can be difficult to see exactly what that type
means, unless you use such a construct regularly - but there is no
benefit in wild exaggeration. And I don't think /any/ alternative
syntax would make it easy to understand what that type really is, what
it can do and what it cannot do, or why you might want it.

With a LTR syntax that a postfix deref would achieve, 'const' would
always be written immediately to the left of any * modifiers. (It is meaningless for arrays and functions.)

You can write this in C++ :

// This bit is only needed once
template <typename T> using ptr = T *;

// p is a pointer to a const pointer to an int
ptr<const ptr<int>> p;


That's LTR syntax. Sure, it also has < > parentheses, but that's a
minor point since the ordering of the components is what apparently
matters so much.


Or you can write :

typedef int * p_int;
const p_int * p;

Thus p is a pointer to a "const p_int", where a "p_int" is a pointer to
an int.

These are different ways to write the same type, including one that is
LTR, and the main hinder to understanding remains the same - what is the
type for?

It is never applied directly to a variable name.

For base types, it can be applied on the left, but C would still allow
it on the right or in the middle, or all three with duplicates.

What do you mean "base types" ? Do you mean that C lets you write

const long int a;
long const int a;
const int long a;
int const long a;
long int const a;
int long const a;

?

If that's your complaint, then I agree with that one - I would be
happier if C had allowed only "const long int;" here. But I think most programmers are consistent in the style they use (though some prefer
"east const").

That means there would be an ambiguity here where there is no identifier between 'int' and 'const':

ÿÿ (const int const *)

For such reasons I would restrict base type const to be only on the left.)

Complicated types are a minority.

I've showed even simple types or trying to use 'const' get becomes confusing.

No, you haven't.

You have shown that /you/ claim to be confused by types with "const".
Most C programmers, once they are used to the language, do not find it confusing in common and simple types.

You do not get to invent meaningless complicated types, claim that you
don't understand them, and use that as evidence that C's declaration
syntax is "a complete mess".

At best, all you can show is that for complex types, C's syntax can
require more thought to write or understand than some alternative
syntaxes might. But we've all known that for decades.

So, PARENTHESES HAVE BEEN ELIMINATED for purpose of disambiguating
array/pointer and pointer/array, both within expressions and within
type-declarations.

Agreed.

But does that make a significant difference?ÿ I don't think so.

It would make a HUGE difference:

Your points below are all true, but IMHO all very minor, and do not add
up to anything much. They might be enough to tip the balance when
developing a new language where you are trying to decide whether your dereference operator should be prefix or postfix, but they are not
enough to cause any concern in a language that has chosen prefix.

(1) It helps to fix that confusion above

Your invented confusion.

(2) You don't need parentheses so no need to remember if you want
ÿÿÿ (*A)[] or *A[]. Those will disappear from expressions too; less
ÿÿÿ clutter all round.

That doesn't matter in practice.

(3) It simplifies indexing of pointer-to-array from (*A)[i] to A*[i], so
ÿÿÿ that actual array pointers, which are more type-safe, could start to
ÿÿÿ appear more in C rather than the current T* idiom

I don't see that as significant.

I do agree that the decay of expressions using array types into pointer
types is a source of error in C code - though I do not think it is as
bad as you do. I would have been happier if arrays were value types and
the expressions did not decay to pointer expressions without manual intervention (like taking the address of the first element). In my C++
code, I make a lot of use of std::array<> types for that purpose - in my
C code, it is not uncommon for me to have arrays wrapped in a struct.

But I just don't see pointer-to-array expressions to be common enough
for the difference you describe to be important.

(4) For pointers to structs, these are the patterns:

ÿÿÿ prefix *ÿÿÿ With ->ÿÿÿ With postfix *

ÿÿÿ (*P).mÿÿÿÿÿ P->mÿÿÿÿÿÿ P*.m
ÿÿÿ (**P).mÿÿÿÿ (*P)->mÿÿÿ P**.m
ÿÿÿ (***P).mÿÿÿ (**P)->mÿÿ P***.m

Which column looks the tidiest?

Far and away the most common - by orders of magnitude - are pointers to structs. "p->m" looks fine to me, and I prefer it to "p*.m". A pointer
to a pointer to a struct is rare enough that it is a good thing for the
syntax to stand out - with a postfix dereference, I'd probably still use parentheses and write "(p*)->m".

(5) With prefix *, a pointer type looks like 'T*'; notice the * is on
ÿÿÿ the right, not left! With postfix *, it would all be consistent. You
ÿÿÿ also wouldn't have 'T*A'; that would be an error (T* only happens
ÿÿÿ when there is no name)

The C declaration syntax is "declaration follows use". If "*" were a
postfix operator, then the declaration of a pointer-to-int would become:

int p*;

while the type of p would be "int *". So you would still have an inconsistency there, unless you also changed the way C has its declarations.

(6) Your 'int * a, b' example would become:

ÿ int a *, b;

Much easier, even with that space, to see that '*' does not belong to
the base type but is a modifier for that variable.

It's still bad. I don't think finding a way to make it easier to write
bad code is a good idea.

It doesn't fix everything, so you'd still have this:

ÿÿ int p* = &a;
ÿÿÿÿÿÿ p* = a;

To fix this requires that all modifiers apply to the base type. But this would be a massive change. The above is merely what happens when *
becomes postfix.

So basically, the suggestion would change some very minor things -
mostly in subjective ways - and not actually do anything for aspects of
the language where there is more of a consensus that C is sub-optimal.
And for this, you would want a fundamental change to one of the most
used operators in all C code!

A mistake that could so easily have been avoid by choosing a
different precedence as shown above. Did none of the thousand people
working at Bell Labs (according to a comment in DC's follow-ip) spot
this and say anything?

I suspect the folks at Bell Labs were too busy writing real code to be
bothered by how confused you would be with artificially complex types.

So you agree the process was very different compared to that which lead
to Ada for example? Just a couple of guys left to do their own thing.

I don't see how you reach that conclusion from what I wrote.

It is, however, true that C was designed by a small number of people
working closely together, rather than a large committee-based design
process involving lots of people.

(Maybe they were respected enough that no one dared to offer any constructive criticism, or if they did then it was dismissed. As happens here.)

I have no insight into the culture at Bell Labs at the time, but that
sounds extraordinarily unlikely.

Feel free to offer some constructive criticism some time, and we will
see if it is dismissed. Note that "constructive criticism" involves
more than "It's C, and I hate everything about C because it is connected
to *nix, and I hate everything about *nix because it is connected to C".
And even if you occasionally have a valid criticism about C, it is not "constructive" criticism because we did not design the language, and we
do not dictate how it could be changed or how it is used.

(ACTUALLY IT IS NOT TOO LATE. A secondary postfix deref op could have
been added. This could have been done 50 years ago, with the original
eventually deprecated.

It /is/ too late - far, far too late.ÿ It would be a terrible idea to
add a new postfix dereference operator to give two different operators
with no benefit other than very occasionally reducing the need for
parentheses.

But a special operator P->m to do the same job as (*P).m was fine! The
new op would eliminate the need for ->.

The -> operator was added to C in 1972 ! It is not new - it has always
been part of the language beyond its early prototype versions.



--- PyGate Linux v1.5.19
* Origin: Dragon's Lair, PyGate NNTP<>Fido Gate (3:633/10)

On 21/10/2026 02:05, Keith Thompson wrote:

David Brown <david.brown@hesbynett.no> writes:
[...]

Without typedef's, that function signature would be something like :

signed char dns_gethostbyname(const char *hostname, struct ip_addr
*addr, void (*found)(const char *name, const struct ip_addr
*ipaddr, void *callback_arg), void *callback_arg);

I might write that as:

signed char dns_gethostbyname(
const char *hostname,
struct ip_addr *addr,
void (*found)(
const char *name,
const struct ip_addr *ipaddr,
void *callback_arg
),
void *callback_arg
);

so the indentation and structure reflects the semantics. I find
that much clearer than your version. (I'm not commenting on the
merits of typedefs.)

Certainly the indentation makes the unpleasant non-typedef'ed version
clearer. And /if/ I had to write that function signature without
typedefs, I would structure it like you had - but I can't think of any
reason I would ever have to do so.


--- PyGate Linux v1.5.19
* Origin: Dragon's Lair, PyGate NNTP<>Fido Gate (3:633/10)

On 21/10/2026 03:04, bart wrote:

On 20/10/2026 13:58, David Brown wrote:

On 20/10/2026 13:41, bart wrote:

But let us take a concrete example.ÿ These network functions are from
the LWIP network stack, which is designed to be used on small embedded
systems that may not have any kind of OS - so it uses call-backs for
asynchronous programming.

An example API function is this :

err_t dns_gethostbyname(const char *hostname, ip_addr_t *addr,
ÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿ dns_found_callback found, void *callback_arg)

The returned "err_t" can be "ERR_OK" (indicating the "hostname" is in
the DNS cache and *addr is set to the IP), "ERR_ARG" for argument
errors, or "ERR_INPROGRESS" to indicate that the stack is looking up
the DNS name, and will call the callback when there is a final result
or timeout.


Without typedef's, that function signature would be something like :

signed char dns_gethostbyname(const char *hostname, struct ip_addr
ÿÿÿÿÿ*addr, void (*found)(const char *name,ÿÿÿ const struct ip_addr
ÿÿÿÿÿ*ipaddr, void *callback_arg), void *callback_arg);


Do you expect anyone to believe you if you claim this is easier to
read than the real declaration using typedefs?ÿ I'll believe you if
you say you find the original hard to read - but not if you claim the
"untypedef'ed" version is clearer.

Neither are great. But let's first lay them out better:

ÿerr_t
ÿÿÿ dns_gethostbyname(
ÿÿÿÿÿ const char *hostname,
ÿÿÿÿÿ ip_addr_tÿ *addr,
ÿÿÿÿÿ dns_found_callback found,
ÿÿÿÿÿ voidÿÿÿÿÿÿ *callback_arg
ÿÿÿ );

OK. I'd not write it that way, and I don't think it is better, but
that's a subjective opinion.

(As a note on layout, the original code is not as line-length restricted
as a Usenet post, and the code has Doxygen comments. That means that
there is additional comment information in header, and that the user documentation, which is the normal way to get details of the API, is
generated html.)

Here, one problem is that there are 3 types that I don't know and would
have to look up.

Incorrect.

There are three types that are not standard C types, but if you are
using this function, you don't have to look them up. You generally
don't need to know what they are - indeed, knowing their details can
easily lead to writing poorer and less adaptable or portable code. Only information about the callback function type is of interest, and even
then it is only marginal - you look it up once when writing an
appropriate callback function, taking negligible effort compared to
writing the code itself. And because it is a named type, you know
immediately that your function is suitable for other use-cases of that specific named type, such as for related dns lookup APIs.

The long version at least has all the info in one place:

ÿsigned char
ÿÿÿ dns_gethostbyname(
ÿÿÿÿÿ const charÿÿÿÿ *hostname,
ÿÿÿÿÿ struct ip_addr *addr,
ÿÿÿÿÿ void (*found)(const char *name, const struct ip_addr *ipaddr,
void *callback_arg),
ÿÿÿÿÿ voidÿÿÿÿÿÿÿÿÿÿ *callback_arg
ÿÿÿ );

That signed char return is unusual; why not 'int'? (How would you even
print an 'err_t' value anyway)?

It seems that yet again, you need an explanation of fundamental points
of software development. Today's lesson is on "abstraction".

It does not matter what type "err_t" is, underneath. What matters is
what you can /do/ with it. It is a type that is returned by this
function (and many others), and which can be compared to ERR_OK, ERR_INPROGRESS, and ERR_ARG. That's all you need to know to use it here.

Maybe on some targets (of this portable library), err_t is "signed
char". Maybe on others it is "int32_t". Maybe in a newer version of
the library, it will be an enum.

It is also nice to know that it can be used in a switch, and cast to an
int for printf.

The documentation for the type can give more or less detail about it.
But it is /not/ the same as a "signed char". That is an implementation
detail which you should not rely on, and it is better - clearer, safer,
more portable, more maintainable - if you do not know what it is. (I
didn't know, until looking it up for these posts.) You use the correct
type, as documented.


Or look at the "ip_addr_t" type. It happens, at the moment, to be a
struct. But it might have been a union. The size and contents of the
struct depend on details of how the library is built - whether it has
support for ipv4, ipv6, or both. Maybe a future version will also
support ipv8, or ipv5 (I've heard some people are trying to make an IP protocol that covers more than IPv4, but without most of the
complicating additional features of IPv6). It is an abstract type - you
use it without knowing the details.

That 'ip_addr_t' turns out to be a struct. For those I would use
typedefs anyway; I rarely use struct tags and you have to invent an identifier in either case.

Then we come to the function pointer, which is a quite a chunky one, but let's work with it. Here, I would question whether you really need those types in there, and especially those names.

Presumably you have a regular function of your own with the same
signature? You anyway never directly 'call' this parameter with
arguments; you just pass it the address of your handler.

Yes, that is how callbacks work.

Or do you use that typedef as documentation?

You can certainly do that if you want, in a declaration of the function
- but it would be unusual to do so in the definition. The typedef is
used primarily when passing the function pointer around, or storing it
(in a local variable, in a struct, or whatever).

Where does the info come from anyway; does the library export a suitable typedef? In that case you might as well use it. But if not, info must
come from elsewhere.

Of course it "exports" the typedef - it is in one of the library's headers.

Anyway with some tweaks in place, using the struct typedef and using an inline function pointer type, it would look like this:

ÿsigned char
ÿÿÿ dns_gethostbyname(
ÿÿÿÿÿ const char *hostname,
ÿÿÿÿÿ IP_addrÿÿÿ *addr,
ÿÿÿÿÿ voidÿÿÿÿÿ (*found)(char*, IP_addr*, void *),
ÿÿÿÿÿ voidÿÿÿÿÿÿ *arg
ÿÿ );

In this form, it is not wildly different from your short version.

Not wildly different, just worse by counter-productively removing the abstractions and appropriate type names, and uselessly cluttering the declaration with unnecessary detail.

So I would look at other ways of tidying up before resorting to
extraneous typedefs.

But here, there may well be an extra reason to use a callback typedef; I don't have the full details.

--- PyGate Linux v1.5.19
* Origin: Dragon's Lair, PyGate NNTP<>Fido Gate (3:633/10)

In article <11ba78m$3peq3$3@dont-email.me>,
David Brown <david.brown@hesbynett.no> wrote:

On 21/10/2026 03:04, bart wrote:

[snip]
Anyway with some tweaks in place, using the struct typedef and using an
inline function pointer type, it would look like this:

ÿsigned char
ÿÿÿ dns_gethostbyname(
ÿÿÿÿÿ const char *hostname,
ÿÿÿÿÿ IP_addrÿÿÿ *addr,
ÿÿÿÿÿ voidÿÿÿÿÿ (*found)(char*, IP_addr*, void *),
ÿÿÿÿÿ voidÿÿÿÿÿÿ *arg
ÿÿ );

In this form, it is not wildly different from your short version.

Not wildly different, just worse by counter-productively removing the >abstractions and appropriate type names, and uselessly cluttering the >declaration with unnecessary detail.

...and also removing the `const` qualifiers on the first two
pointer arguments to `found`.

- Dan C.


--- PyGate Linux v1.5.19
* Origin: Dragon's Lair, PyGate NNTP<>Fido Gate (3:633/10)

On 21/10/2026 10:20, David Brown wrote:

On 20/10/2026 22:07, bart wrote:

On 20/10/2026 16:02, David Brown wrote:

On 20/10/2026 16:11, bart wrote:

* A further complication was to allow function pointers within that a
ÿÿ declaration list

To me, the big disadvantage of C's declaration syntax is that it lets
you declare things of different (but related) types in the same
declaration.

Yes, but that doesn't bite so much because it is uncommon.

Unfortunately not - but it is uncommon to mix objects and function declarations, or objects of wildly different real types.

That's what I meant.

ÿÿÿÿ const int const * const p;
ÿÿÿÿÿÿ 1ÿÿÿÿÿÿÿÿ 2ÿÿÿÿÿÿ 3

const 1 applies to the basetype to its right.
const 2 applies to the basetype to its left.

These are redundant - they do the same thing.ÿ (I'd have preferred if
the ordering rules were strict - allowing only "const int" or "int
const" - but at least people are usually consistent in their style.)

(Both also can be in the middle with compound types like 'long long'!)

const 3 is tricky: I think it applies to the * to its left, since it
says that the pointer value itself is const. But 'p' has type 'pointer
to', so it could apply to that directly.

Yes - it is "p" that is const,ÿ not the "*".

I would disagree. This type can also be written as:

(const int const * const)

There is no 'p' to apply to. The type describes a pointer to an integer.
The first two consts say, redundantly, that the integer value is const.

The third must then apply to the pointer.

What about this however:

ÿÿÿ int * const *ÿ p;

ÿÿÿÿÿÿÿ 1ÿÿ 2ÿÿ 3

I think here, const 2 applies to * 1, which is to it's left, and can't
apply to 'p' as that is the other side of the * 3.

*p is of type "int * const" - thus you can use "*p" to access a pointer- to-int, but you can't use *p to change that pointer-to-int.

But what exactly does this 'const' apply to?

I'm suggesting any 'const' applies either to the base type (the one on
the left) or to a particular '*'.

In that case the latter 'const's must apply right-to-left to the
preceding '*'.

Fair to say that is a complete mess, and it is error prone.

No, it is not at all fair to say that.ÿ It is fair to say that a
different way of writing types might make it easier to understand - but that's a /long/ way from saying it is "a complete mess".ÿ And you can't
call it "error prone" unless you know that people regularly use such declarations, and often have bugs in their code as a result of doing so incorrectly.ÿ I think that is an unrealistic claim.

If there's any confusion about which const applies to which type
element, then mistakes can be made.

You can write this in C++ :

ÿÿÿÿ// This bit is only needed once
ÿÿÿÿtemplate <typename T> using ptr = T *;

ÿÿÿÿ// p is a pointer to a const pointer to an int
ÿÿÿÿptr<const ptr<int>> p;

That's LTR syntax.ÿ Sure, it also has < > parentheses, but that's a
minor point since the ordering of the components is what apparently
matters so much.

That it is LTR is now irrelevant because I find that incomprehensible
anyway. You've turned a linear chain a nested structure ... oh never
mind, I don't even want to go there with C++.

Or you can write :

ÿÿÿÿtypedef int * p_int;
ÿÿÿÿconst p_int * p;

Thus p is a pointer to a "const p_int", where a "p_int" is a pointer to
an int.

So, a common pattern with you is to use workarounds so that you
effectively emulate LTR type patterns. Because they are easier to work
with and understand.

So you do appreciate how they facilitate things, even though they
introduce an extra level of indirection and also disseminate the type information across the program.

But you want to underplay how useful it would be to have natural LTR
type declarations within a syntax.

These are different ways to write the same type, including one that is
LTR, and the main hinder to understanding remains the same - what is the type for?

If you create a type alias voluntarily (I don't mean structs where
either a tag or a typedef needs to be created) then yes the name should
impart something useful.

But in my view this is often taken too far. Sometimes you have structs
where every member has a different user-type. When you look further, you
find they are all ints. That is just obfuscation.

(I would accept enumeration types if the compiler can employ that info
to improve type safety, but that seems to be limited.)

I've showed even simple types or trying to use 'const' get becomes
confusing.

No, you haven't.

OK. That is not surprising.

It would make a HUGE difference:

Your points below are all true, but IMHO all very minor, and do not add
up to anything much.

It would eliminate half the issues with C's type syntax. Probably CDECL wouldn't need to exist. Lots of () disappear. It would make
pointers-to-arrays more viable.

But that's nothing in your view. OK again.

Your invented confusion.

That doesn't matter in practice.

I don't see that as significant.

I do agree that the decay of expressions using array types into pointer types is a source of error in C code - though I do not think it is as
bad as you do.

I didn't say anything about, and that wouldn't be affected.

But I just don't see pointer-to-array expressions to be common enough
for the difference you describe to be important.

If you're passing arrays to a function by-reference then the natural way
is to a have a pointer to the array. C can do that, but nobody ever does
so, probably because indexing is then so ugly.

With my idea, (*A)[i] turns into A*[i], a bit less ugly.

(In my language, it was A^[i]. However, some years ago I relaxed the
rules to allow such in-between derefs to be dropped - the compiler will reinsert them as needed.

So indexing looks like A[i], and there is the extra type safety of
working with actual arrays, not pointers to things that may or may not
be arrays.

But then I also have pass-by-reference which achieves the same thing.)

(4) For pointers to structs, these are the patterns:

ÿÿÿÿ prefix *ÿÿÿ With ->ÿÿÿ With postfix *

ÿÿÿÿ (*P).mÿÿÿÿÿ P->mÿÿÿÿÿÿ P*.m
ÿÿÿÿ (**P).mÿÿÿÿ (*P)->mÿÿÿ P**.m
ÿÿÿÿ (***P).mÿÿÿ (**P)->mÿÿ P***.m

Which column looks the tidiest?

Far and away the most common - by orders of magnitude - are pointers to structs.ÿ "p->m" looks fine to me, and I prefer it to "p*.m".

But where's the consistency? Sometimes "." is used for member selection,
and sometimes "->". And with two pointer levels, you need both!

(Again in my language, all those * (or ^) in the right column can be
dropped. Some loss of transparency, but much, much cleaner code.

But TBF, this could also be done in C without needing postfix *.)

(5) With prefix *, a pointer type looks like 'T*'; notice the * is on
ÿÿÿÿ the right, not left! With postfix *, it would all be consistent. You
ÿÿÿÿ also wouldn't have 'T*A'; that would be an error (T* only happens
ÿÿÿÿ when there is no name)

The C declaration syntax is "declaration follows use".ÿ If "*" were a postfix operator, then the declaration of a pointer-to-int would become:

ÿÿÿÿint p*;

while the type of p would be "int *".ÿ So you would still have an inconsistency there, unless you also changed the way C has its
declarations.

The point is that currently you have 'int*' for the type, '*p' to
declare p, and '*p' in expressions. The '*' switches sides for the bare
type!

(6) Your 'int * a, b' example would become:

ÿÿ int a *, b;

Much easier, even with that space, to see that '*' does not belong to
the base type but is a modifier for that variable.

It's still bad.ÿ I don't think finding a way to make it easier to write
bad code is a good idea.

It wouldn't stay bad for long! Because if the intention was to declare
two pointers, then it's easier to see that this is wrong.

So basically, the suggestion would change some very minor things -
mostly in subjective ways - and not actually do anything for aspects of
the language where there is more of a consensus that C is sub-optimal.
And for this, you would want a fundamental change to one of the most
used operators in all C code!

Obviously you can't change prefix * now. A postfix /alternative/, in
addition to prefix *, could have been introduced decades ago. So by the
time /you/ encountered C, you might have been using the latter.


--- PyGate Linux v1.5.19
* Origin: Dragon's Lair, PyGate NNTP<>Fido Gate (3:633/10)

On 21/10/2026 12:21, David Brown wrote:

On 21/10/2026 03:04, bart wrote:

Where does the info come from anyway; does the library export a
suitable typedef? In that case you might as well use it. But if not,
info must come from elsewhere.

Of course it "exports" the typedef - it is in one of the library's headers.

You could have said that in the first place. So it's not really a choice
then is it?

Then it makes sense to use what they have provided.



--- PyGate Linux v1.5.19
* Origin: Dragon's Lair, PyGate NNTP<>Fido Gate (3:633/10)

On 20/10/2026 21:24, Dan Cross wrote:

In article <11b7k22$2v8e5$1@dont-email.me>, bart <bc@freeuk.com> wrote:

On 20/10/2026 09:01, David Brown wrote:

On 19/10/2026 23:28, bart wrote:

(Funny that when I suggest that nested loop breaks are uncommon,
everyone says I'm wrong! Some even write 200-line made-up examples to
prove their point.)

I don't remember "everyone" saying you were wrong to say that nested
loop breaks are uncommon - in fact, I don't remember /anyone/ saying
that was wrong.

(There was a LOT of antipathy towards my idea to fix the common case of
'loop-break' clashing with 'switch-break', BECAUSE it did not fix the
problem of nested loop-break, which is uncommon, even though that wasn't
the aim.)

Those are two different things. No one disagrees with you that
"nested break from a switch inside of a loop" is relatively more
common than other variants.

Quibble - that is not established to my satisfaction. I am not
convinced that wanting a nested break for "switch inside loop" is more
common than wanting it for "loop inside loop". So I neither agree nor disagree with that claim. I don't, however, think it matters much -
both are situations that turn up sometimes in code, and definitive
answers are neither possible nor useful.

Using that as an excuse not to provide a more general mechanism
because you already have a proposal for the specific case is
what I and others took you to task for. I find this ironic,
since you rail against things in C that you do not like, citing
the most ridiculous examples you can think of that do not show
up in actual programs, yet for something where it is pointed out
to you that your solution does not generalize, you claim that it
does not need to because ... the general case rarely shows up in
a real program.

There is no reason to abstract away that function pointer type.

You probably do so in C /because/ the type involves * () and [] but
have somehow persuaded yourself that it just better that way.

Do you hear that whooshing noise?ÿ It is the sound of the point flying
far above your head.

Here is an example of some sensible function typedefs, all from third-
party code (so not my "peculiar" style)

typedef void (*TimerCallbackFunction_t)( TimerHandle_t xTimer );

TimerHandle_t xTimerCreate(ÿ const char * const pcTimerName,
ÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿ TickType_t xTimerPeriodInTicks,
ÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿ UBaseType_t uxAutoReload,
ÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿ void * pvTimerID,
ÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿ TimerCallbackFunction_t pxCallbackFunction );

typedef void (*lwip_thread_fn)(void *arg);
typedef void (*tcpip_init_done_fn)(void *arg);
typedef void (*tcpip_callback_fn)(void *ctx);
typedef void (* sys_timeout_handler)(void *arg);
typedef void (*dns_found_callback)(const char *name,
ÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿ const ip_addr_t *ipaddr, void *callback_arg);

This is the kind of C I find hard to read. There are lots of typedefs
but few uses of those typedefs that I can see, so I don't know how much
difference they make.

You again missed the entire point. You may not see many uses
of them, but as David says, the `typedef`s give you
domain-specific *names* understandable to the programmer: a
programmer can see the `sys_timeout_handler` type instantly know
that this has a different function than the,
`tcpip_callback_fn`, despite the having the same type.

Exactly.

The other point is that the ridiculous examples you make up to
illustrate your distaste for C declaration syntax basically do
not appear in real programs.

[snip]
I've left in the regular parameter names, even though C doesn't need
them, but they are quite heavy - you don't really need those
Hungarian-style prefixes.)

Well, I guess this buys you one thing: the parameter name for the last
parameter is to the right of its type, rather than be inside it. But a C
expert should not be fazed by that.

Here is the same function as I might write it in an alternative syntax.

I've kept the same names, but changed case-style and removed prefixes
and suffixes. I've capitalised user-type names:

func TimerCreate( # (retain case if FFI import)
ichar timername,
Ticktype timerperiodinticks,
Ubasetype autoreload,
ref void timerid,
ref proc(Timerhandle) callbackfn)

In this form, it's hard to see what benefit a typedef would give for
that last parameter; it is simple enough.

What is your point? Do you have one? If you don't want to use
C, don't use C.

There are plenty of languages that can do this kind of thing
that are not C and have syntax and semantics closer to what you
seem to want. Here's an example in Rust:

pub trait TimerHandle { ... }

fn CreateTimer<T>(
timer_name: &str,
period: std::time::Duration,
auto_reload: bool,
timer_id: T,
handler: fn(&dyn TimerHandle),
) -> Result<Timer<T>, TimerError>

I didn't know what an `UBaseType_t` is, and while "autoreload"
sounded pretty intuitive, I wasn't sure about the semantics, so
I looked it up (the example comes from `FreeRTOS`). In this
context, it is a boolean saying whether the timer should repeat
with the given periodicity, or whether it is a one-shot.

FreeRTOS is written in C90 - a mistake, IMHO - and thus does not use
bool. Instead, it uses constants pdTRUE and pdFALSE of type
UBaseType_t. UBaseType_t is a type that is dependent on the target -
usually it is either 16-bit or 32-bit. But of course it doesn't matter
what the underlying types are - you use the typedef names, and the
documented constants.

The timer_id is opaque to the timer, and it looks like it's used
to facilitating the handler accessing timer-specific data. In
C, passing it as a `void *` is used as a way to get a poor-man's
overloading. But Rust has generics, I just made it generic over
some type T.

FreeRTOS uses "void *" to mean "pointer to internal structure that you shouldn't be messing with". It uses this far too often, and is, IMHO, a
poor design choice. (I also dislike the silly Hungarian naming.) I
would much preferred if there had been :

struct Internal_Timer_Struct;
typedef struct Internal_Timer_Struct * timer_id_t;

and then the parameter "timer_id_t timer_id". So in a re-write, it
would not be a generic. (You might choose to use a generic for the
handler function type, so that handler callbacks could have parameters
of other types, but not for the timer id.)

I am using these declarations from FreeRTOS (and LWIP) to demonstrate
the use of function typedefs in massively popular codebases, not to
claim FreeRTOS is a paradigm of C code design!

If I were writing this from scratch in Rust, a language that has
generics, closures, and so sum types, I'd do the whole thing
differently; see the end for an example.

But I digress. The point here is, Bart, that alternatives exist
if you don't like C. You don't have to keep posting, over and
over again, in comp.lang.c of all places, about how oh so
terribly awful C is. If you don't want to program in C, simply
don't program in C.

Ask yourself why the typedefs are used.ÿ Look at the /names/.ÿ Those
last four are all from the same network stack library, and are all
typedefs for "void (*)(void*)".

Until you mentioned it, I hadn't noticed. So typedef has done a good job
of hiding that useful fact! But looking more closely, it is the first
four of the last five.

Let's take one:

typedef void (*lwip_thread_fn)(void *arg);

That 'arg' is not much use for a start (other than being a hint that
this particular (...) is where the parameters go).

So, maybe this is used like this:

void F(lwip_thread_fn lwip_thread_callback);

I have no idea what you're trying to say here. The obvious (and
honestly, excusable) syntax error aside, what is F? It's a
function that, what, takes two function pointers?

The type defined by `lwip_thread_fn` is a pointer to a function
that takes a void pointer (`void *`) as its sole arugment, and
returns `void` (that is, has no meaningful return value).

Intuitively, the name implies that this is the function run as
some thread, so we'd pass it to a thread creation function. The
usual shape of those things is to give them a pointer to some
function to run in the new thread, and a pointer to some
arguments to be passed to that function.

Yes.

For example:

void
whatever(void *argp)
{
struct Args *args = argp;
while (keep_running()) {
// Do the thing the thread is supposed to do.
}
thread_exit(SUCCESS);
}

thread_t *
start_the_whatever_thread(void)
{
struct Args *args = malloc(sizeof(*args));
if (args == NULL) abort();
memset(args, 0, sizeof(*args));
args->whatever = something();
// etc...
thread_t *thr = thread_create(whatever, args);
if (thr == NULL) abort();
return thr;
}

Something could start this as:

thread_t *whatever_id = start_the_whatever_thread();

At some point later, if you want to wait for the thread to
exit, you'd run:

(void)thread_join(whatever_id);

Note this is decently complex behavior, but it's actually quite
intuitive from the name and the type.

You have got a very clear picture here, much of it from the names of the types. For a Rust programmer, you give a good impression of experience
with C :-)

The only mistake you made is that programmers working on systems using FreeRTOS and the like, have a fear and loathing of "malloc", have never
heard of "abort()", and do not join our threads because they all run
until the power is switched off.

Here you have two identifiers imparting the sort kind of information; a
tautology.

That's not what a tautology is.

If that function pointer pattern is common, or recurs in a suite of
functions, I might also have used a typedef, but with a common name.

Then you loose the domain specificity; you can't tell from the
name whether you need an LwIP thread, or a callback, or a
something run in a different thread, or just a plain 'ol
function you want to apply to run every now and again for a side
effect.

Precisely.

Then only one would be needed, say:

typedef void (*stack_callbackfn)(void);

I might have done the same in that alternate syntax as it would start to
get cluttery: 'ref proc(ref void)', but also in order to define that
common pattern in one place.

I dunno. Sounds like you have no idea what the code that David
posted is meant to do. But that's a "you" problem.

Note that 'pcl' in my example /is/ a typedef; here it makes sense as
it is used in 100s of places. This function pointer occurs in only one >>>> place.

I'm sorry, I had mistaken you for a programmer who wanted to write good, >>> clear programs.ÿ Naming things is not a shortcut to save keypresses.

Isn't that one of the main uses of typedefs? So as to give a handy,
'euphonious' one-token alias to an elaborate typedef.

It also allows you to change the type in one place without having to
update hundreds of instances.

It also allows the type to be opaque.

The point is that the name you chose is meaningless to anyone
other than you. What's a PCL? Phase Control Line? Printer
Command Language? Photon Compressor Loop?

Saving keypresses is bonus benefit, but if it is shorter, then it can
also help readability as other critical elements are not overshadowed.

So I'm not sure what objection you have to this particular use of it.

Have you ever written a large program that was maintained by
anyone other than yourself?

Here is the one place I do remember using typedef for a function pointer
(from an old project, not in C):

type fnptr = ref proc

repeat
(fnptr(pcptr^))^()
until stopped

It's used as a cast, but reason I have it is because with simple cast
syntax, which is 'T(X)', the meaning without it would be ambiguous (a
grammar issue that I might fix one day).

Rather than fallback to standard cast syntax (which is 'cast(X, T)'),
this was tidier.

I can only guess at what this may mean. Hazarding a guess,
`pcptr` is a "pointer to a program counter", which is a
reference type to some type that represents some executable
memory location in the program. You then have a loop that runs
until "stopped" is true where you indirect the program counter
pointer, cast it to a pointer to a function, and then invoke
the function, right? One presumes you have the, "PC Pointer"
because it changes over time, otherwise, you'd just give
whatever it points to a name and call it.

More generally, I fail to see what this is trying to
demonstrate. If it's to show some sort of imagined superiority
over C, I don't see it; that's sort of thing is easy enough to
write:

typedef void (*fnptr)(void);

// Assume uintptr_t *pcptr is declared somewhere.
do {
((fnptr)*pcptr)();
} while (!stopped);

E.g.,

```
term% cat b.c
#include <stdbool.h>
#include <stddef.h>
#include <stdint.h>
#include <stdio.h>

static void first(void);

typedef void (*fnptr)(void);
bool stopped = false;
uintptr_t pc = (uintptr_t)first;
uintptr_t *pcptr = &pc;

void
done(void)
{
printf("done\n");
stopped = true;
}

void
second(void)
{
printf("second\n");
*pcptr = (uintptr_t)done;
}

void
first(void)
{
printf("first\n");
*pcptr = (uintptr_t)second;
}

void
run(void)
{
do {
((fnptr)*pcptr)();
} while (!stopped);
}

int
main(void)
{
run();
return 0;
}
term% gcc-16 -std=c11 -pedantic -o b b.c
term% ./b
first
second
done
term%
```

Or just have :

fnptr pc = first;
fnptr *pcptr = &pc;

I don't see a need for "uintptr_t", except so that you have to have
casts like Bart had.

BTW what name would be given to such a function pointer type?

I have no idea what your code is supposed to do,

It's a table of function pointers! All sharing the same signature.

That's pretty generic. Is it really that hard to guess? You don't need
to know what they do, other than at some point they will be called as
handlertable[i](arg).

That part is fine.

What's utterly mystifying is what you are trying to show, if
anything, by posting it. Is this supposed to prove some kind of
point? Your code is not _a priori_ easier to understand than
the equivalent C code; if anything, it is harder to understand
because of your poorly chosen names.

- Dan C.

Rust implementation of Timers, mentioned above<--

As mentioned above, if I were providing the FreeRTOS timers API
in an alternative language, I'd write it differently from the
start. In particular, I'd use an enumeration to describe the
behavior with respect to repeating, and I'd use a closure to
obviate the need for the opaque id. Something that isn't easy
to express in the original API is a type of repeating timer that
waits for the initial period, and then repeats with some
different period.

Something like this:

```rust
pub mod timer {
use std::sync::atomic::{AtomicBool, Ordering};
use std::time::Duration;

/// Errors that may occur when working with timers.
#[derive(Clone, Copy, Debug)]
pub enum Error {
Running,
CantStop,
WontStop,
}

/// Describes the kind of a timer, as defined by its
/// periodicity.
///
/// A timer can either be a `OneShot` timer, which fires
/// once, after its timeout expires, or it may be a Repeating
/// timer, which will automatically reset after its handler
/// is run and continue firing at the rate defined by the
/// initial timeout, or it can be a periodic timer, that
/// will fire the first time at the initial timeout, and
/// then repeatedly a potentially different timeout. This
/// use case can be simulated by a OneShot timer that
/// creates a repeating Timer, but
///
/// Once started, Repeating and Periodic timers continue
/// firing until explicitly stopped.
#[derive(Clone, Copy, Debug)]
pub enum Kind {
OneShot,
Repeating,
Periodic(Duration),
}

/// A named timer, that is handled by the given callback.
pub struct Timer<'a, F> {
pub name: &'a str,
pub kind: Kind,
pub timeout: Duration,
callback: F,
running: AtomicBool,
// Whatever other innards...
// ...
}

/// A read-only "view" into the timer.
pub trait TimerView {
fn name(&self) -> &str;
fn kind(&self) -> Kind;
fn timeout(&self) -> Duration;
}

impl<'a, F: Fn(&dyn TimerView)> Timer<'a, F> {
/// Creates a new named timer of the given kind with an
/// initial timeout. When the timeout expires, it will
/// automatically invoke the given handler.
pub fn new(
name: &'a str,
timeout: Duration,
kind: Kind,
callback: F,
) -> Timer<'a, F> {
let running = AtomicBool::new(false);
Self {
name,
kind,
callback,
timeout,
running,
}
}

/// Starts the timer.
pub fn start(&self) -> Result<(), Error> {
if self.running.swap(true, Ordering::AcqRel) {
return Err(Error::Running);
}
self.arm(self.timeout)?;
Ok(())
}

/// Stops the timer.
///
/// Note that this inherently races with the timer firing,
/// and a timer event that occurs while we are disabling
/// the timer may still invoke `fired` after this returns.
///
/// Callers are advised to determine definitively that
/// there are no events pending for this timer before
/// destroying the `Timer` object.
pub fn stop(&self) -> Result<(), Error> {
let was_running = self.running.swap(false, Ordering::AcqRel);
if !was_running {
return Err(Error::WontStop);
}
self.disarm();
Ok(())
}

// Automatically called when the timeout fires.
//
// # Safety
//
// Nothing may be mutably borrowing a reference to the
// Timer object when this is called.
pub(super) unsafe fn fired(&self) -> Result<(), Error> {
if !self.running.load(Ordering::Acquire) {
return Ok(());
}
(self.callback)(self);
match self.kind {
Kind::OneShot => Ok(()),
Kind::Repeating => self.arm(self.timeout),
Kind::Periodic(period) => self.arm(period),
}
}

// Arranges for `self.fired(self)` to be called when
// the given timeout expires.
fn arm(&self, timeout: Duration) -> Result<(), Error> {
// Does whatever one does here to actually arm the
// timer (e.g., calls a HAL to actually program a
// physical timer to interrupt after the amount of
// time specified by `Duration`, for example).
// ...
Ok(())
}

// Disables an armed timer, so that it does not fire
// after this returns.
fn disarm(&self) -> Result<(), Error> {
// whatever one does here to disarm an active timer
// ...
Ok(())
}
}

impl<F> TimerView for Timer<'_, F> {
fn name(&self) -> &str { self.name }
fn kind(&self) -> Kind { self.kind }
fn timeout(&self) -> Duration { self.timeout }
}
}
```

One might use this with something like,

```
let value = 42;
let cb = move |timer: &dyn timer::TimerView| {
println!(
"Timer '{}' fired; value is {} and duration was {} ms",
timer.name(),
value,
timer.timeout().as_millis()
);
};
let timeout = std::time::Duration::from_millis(100);
let timer = timer::Timer::new("timer", timeout, timer::Kind::OneShot, &cb);
timer.start().expect("Timer started");
//... at some point the timer fires and prints,
// 'Timer 'timer1' fired; value is 42 and duration was 100 ms'
}
```

--- PyGate Linux v1.5.19
* Origin: Dragon's Lair, PyGate NNTP<>Fido Gate (3:633/10)

On 21/10/2026 13:33, bart wrote:

On 21/10/2026 12:21, David Brown wrote:

On 21/10/2026 03:04, bart wrote:

Where does the info come from anyway; does the library export a
suitable typedef? In that case you might as well use it. But if not,
info must come from elsewhere.

Of course it "exports" the typedef - it is in one of the library's
headers.

You could have said that in the first place. So it's not really a choice then is it?

What do you mean?

There is an API in "dns.h" that uses typedefs such as "ip_addr_t" and "dns_found_callback". /Obviously/ those typedefs are also included in
the header (or other headers included by "dns.h"). This is not
something that I should have had to point out.

Then it makes sense to use what they have provided.

It always makes sense to use the types provided.


--- PyGate Linux v1.5.19
* Origin: Dragon's Lair, PyGate NNTP<>Fido Gate (3:633/10)

On 21/10/2026 00:43, bart wrote:

On 20/10/2026 22:44, Dan Cross wrote:

In article <11b8j17$3btus$1@dont-email.me>, bartÿ <bc@freeuk.com> wrote:

On 20/10/2026 20:24, Dan Cross wrote:

In article <11b7k22$2v8e5$1@dont-email.me>, bartÿ <bc@freeuk.com>
wrote:

The point is that the name you chose is meaningless to anyone
other than you.ÿ What's a PCL?ÿ Phase Control Line?ÿ Printer
Command Language?ÿ Photon Compressor Loop?

Within the context of that application then it would be clear. You're
just being overly hostile.

Not really.ÿ You are, I presume, posting that code to try and
make some kind of point about how "readable" it is.ÿ But it's
not readable unless you already know what it does.

What it does not relevant. This is simply defining an array of T. But because T happens to be a function pointer, DB insists that an alias
must be created, and a new name invented.

I did not "insist" or say that an alias "must" be created. I said
that's normally what you should do in real code, to make it clear,
readable and maintainable.

Note that I wrote (in regard to the "pcl" stuff) :

"""
I have no idea what your code is supposed to do, so I have no idea what
names would be good. Presumably you /do/ know what it is for - such as
what "pcl" means - so /you/ pick good names. Maybe "host_handler_fn" ?
"""

If "pcl" makes sense in the context of your code, that's fine - use it
in your names.


But don't use generic names where specific names impart useful
information. Don't re-use generic names because of a coincidence in the underlying implementation - use names that make sense where they are used.

Why? Probably because in C, the syntax for function pointers gets hairy.

No, this is all because I (and Dan) know how to write good code in a
clear (to appropriate readers) and maintainable manner. The syntax is irrelevant. We appreciate that you find C's declaration syntax
confusing and difficult - I think that after the first two or three
hundred repetitions, it finally sank in. But please stop projecting
your weaknesses and prejudices onto other people. I do not name
function pointer types because of C's syntax - I name them because the
code is better in many ways when the types are named. I would do the
same in Pascal, Rust, Ada, or any other language, regardless of the syntax.

On the other hand, the code David posted _is_ readable, because
it uses the language to encode domain-specific information into
type names.

Maybe we should create aliases for function signatures more often then,
then we can encode that extra info.

So that instead of, for example:

ÿÿÿ void SomeFunc(int x, int y) {printf("%d %d\n", x, y);}

you do:

ÿÿÿ typedef void Take2Ints(int x, int y);

ÿÿÿ Take2Ints SomeFunc {printf("%d %d\n", x, y);}

Maybe we should not. That is not helpful to code clarity. It is a
pointless generic name (showing that you /still/ do not understand the fundamental matter of giving useful and informative names), and instead
of /giving/ useful additional information, it /hides/ details at the
point in the code where they are vital.

Now, if you had a concept of "Coordinate handler" that was expected to
receive an x, y pair and do something with them, then it is possible
that you would have a header file "coordinate_handlers.h" with :

typedef void Coordinate_Handler_Func(int x, int y);

and some related function declarations :

Coordinate_Handler_Func dummy_handler;
Coordinate_Handler_Func simple_printer;
Coordinate_Handler_Func fly_to_new_coordinates;

You are putting the emphasis here on what sort of usage you expect for
these functions, with the assumption that code using them knows how to
call them. This could be handy if you have another module that needs to
build an array or other data structure with these functions - it does
not care about the implementation details, and uses the function type
(or a pointer to the function type) without looking at its contents:

#include "coordinate_handlers.h"

size_t build_coordinate_handler_array(
Coordinate_Handler_Func * hs, size_t max_handlers)
{
assert(max_handlers >= 3);
hs[0] = &dummy_handler;
hs[1] = &simple_printer;
hs[2] = &fly_to_new_coordinates;

return 3;
}

A caller function might have :

#include "coordinate_handlers.h"

void call_handler(size_t handler_no, int x, int y) {
assert(handler_no < no_of_handlers);

Coordinate_Handler_Func h * handlers[handler_no];
h(x, y);
}


Handler implementations would be written normally :

#include "coordinate_handlers.h"

void simple_printer(int x, int y) {
printf("%d %d\n, x, y);
}


Then later when you decide to go to 3 dimensions, you need to change
code that calls these handlers, and you need to change the handler implementations (and you'll get compile-time errors until you do), but
generic "in the middle" code like "build_coordinate_handler_array" is unchanged.

But if the code also happened to need lots of functions for drawing
titles at x, y coordinates, it would have :

typedef void Title_Drawer_Func(int x, int y);

You would /not/ re-use the same typedef, just because the implementation
is the same, when the /purpose/ is different.

If you have a suite of functions sharing the signature, then it might be
a good idea. But funnily enough, you never see this being done.

Given that it is not remotely close to valid C, I don't think it is particularly surprising.

(I don't know if this is legal C; but it works fine with my compiler:

Your compiler is not a C compiler - it's a compiler for an undefined and undocumented superset of an undefined and undocumented subset of an undocumented version of C. If that's all you need, there's nothing
wrong with that - but what works or does not work with your compiler is
no indication of what is or is not "legal" C.

ÿ c:\m>type fred.c
ÿ #include <stdio.h>

ÿ typedef void Take2Ints(int x, int y);

ÿ Take2Ints SomeFunc{printf("%d %d\n", x, y);}

ÿ int main(void) { SomeFunc(10, 20); }

ÿ c:\m>bcc -r -q fred
ÿ 10 20

)

Yeah, you really just don't get it.

One of us doesn't get it.

Exactly. I'm fairly sure you are alone here.



--- PyGate Linux v1.5.19
* Origin: Dragon's Lair, PyGate NNTP<>Fido Gate (3:633/10)

In article <11baah2$3te3v$1@dont-email.me>,
David Brown <david.brown@hesbynett.no> wrote:

On 20/10/2026 21:24, Dan Cross wrote:

In article <11b7k22$2v8e5$1@dont-email.me>, bart <bc@freeuk.com> wrote:

[snip]
(There was a LOT of antipathy towards my idea to fix the common case of
'loop-break' clashing with 'switch-break', BECAUSE it did not fix the
problem of nested loop-break, which is uncommon, even though that wasn't >>> the aim.)

Those are two different things. No one disagrees with you that
"nested break from a switch inside of a loop" is relatively more
common than other variants.

Quibble - that is not established to my satisfaction. I am not
convinced that wanting a nested break for "switch inside loop" is more >common than wanting it for "loop inside loop". So I neither agree nor >disagree with that claim. I don't, however, think it matters much -
both are situations that turn up sometimes in code, and definitive
answers are neither possible nor useful.

Ok, that's fair; I shouldn't say "no one disagrees".

[snip]
There are plenty of languages that can do this kind of thing
that are not C and have syntax and semantics closer to what you
seem to want. Here's an example in Rust:

pub trait TimerHandle { ... }

fn CreateTimer<T>(
timer_name: &str,
period: std::time::Duration,
auto_reload: bool,
timer_id: T,
handler: fn(&dyn TimerHandle),
) -> Result<Timer<T>, TimerError>

I didn't know what an `UBaseType_t` is, and while "autoreload"
sounded pretty intuitive, I wasn't sure about the semantics, so
I looked it up (the example comes from `FreeRTOS`). In this
context, it is a boolean saying whether the timer should repeat
with the given periodicity, or whether it is a one-shot.

FreeRTOS is written in C90 - a mistake, IMHO - and thus does not use
bool. Instead, it uses constants pdTRUE and pdFALSE of type
UBaseType_t. UBaseType_t is a type that is dependent on the target - >usually it is either 16-bit or 32-bit. But of course it doesn't matter
what the underlying types are - you use the typedef names, and the >documented constants.

Thanks for the context. Your point that the underlying type
doesn't matter is salient: it's opaque to the programmer, but
99% of the time the programmer doesn't need to worry about the
details.

The timer_id is opaque to the timer, and it looks like it's used
to facilitating the handler accessing timer-specific data. In
C, passing it as a `void *` is used as a way to get a poor-man's
overloading. But Rust has generics, I just made it generic over
some type T.

FreeRTOS uses "void *" to mean "pointer to internal structure that you >shouldn't be messing with". It uses this far too often, and is, IMHO, a >poor design choice. (I also dislike the silly Hungarian naming.) I
would much preferred if there had been :

struct Internal_Timer_Struct;
typedef struct Internal_Timer_Struct * timer_id_t;

and then the parameter "timer_id_t timer_id". So in a re-write, it
would not be a generic. (You might choose to use a generic for the
handler function type, so that handler callbacks could have parameters
of other types, but not for the timer id.)

I am using these declarations from FreeRTOS (and LWIP) to demonstrate
the use of function typedefs in massively popular codebases, not to
claim FreeRTOS is a paradigm of C code design!

Oh interesting; in this case, I had assumed it was treated as
a callback-specific type so one could plumb extra context into
the handler; the documentation I saw suggested it could be used
by the handler to disambiguate several timers reusing the same
handler function.

For example:

[snip]

Note this is decently complex behavior, but it's actually quite
intuitive from the name and the type.

You have got a very clear picture here, much of it from the names of the >types. For a Rust programmer, you give a good impression of experience
with C :-)

I've been known to dabble.

The only mistake you made is that programmers working on systems using >FreeRTOS and the like, have a fear and loathing of "malloc", have never >heard of "abort()", and do not join our threads because they all run
until the power is switched off.

Ha, fair; that was just a made-up example, based on other thread
libraries I have used (in C). I didn't mean for it to be
interpreted strictly in the context of FreeRTOS! :-D

[snip]

Or just have :

fnptr pc = first;
fnptr *pcptr = &pc;

I don't see a need for "uintptr_t", except so that you have to have
casts like Bart had.

Yes. But I wanted to remain faithful to his original, to show
that one could write a more-or-less exact transliteration in C
that was extremely similar to his chosen syntax.

[Snip a bunch of Rust code; the point of which being that
bart need not complain about lack of an alternative to C]

- Dan C.


--- PyGate Linux v1.5.19
* Origin: Dragon's Lair, PyGate NNTP<>Fido Gate (3:633/10)

On 21/10/2026 03:23, Keith Thompson wrote:

David Brown <david.brown@hesbynett.no> writes:

On 19/10/2026 23:27, Janis Papanagnou wrote:

[...]

ÿ * a bÿÿÿÿ PN (Polish Notation)

There is no term "Polish Notation" - except as occasionally used to
mean /postfix/ as a short form of "Reverse Polish Notation". RPN was
invented, or at least popularised, by the Polish logician Jan
?ukasiewicz (I admit to looking that up on Wikipedia!). There is no
"PN" opposite.

Yes, there most certainly is, and "* a b" is a good example of it.

https://en.wikipedia.org/wiki/Polish_notation

Jan ?ukasiewicz invented what we now call Polish notation in 1924.
`+ 3 4` is an example (which yields 7). Lisp syntax is more or
less Polish notation with added parentheses. (I'm sure the phrase
"more or less" is doing a lot of work.)

Reverse Polish Notation, RPN, is very well known because it's
used by some calculators, particularly those made by HP. It's a
postfix notation. An example of RPN is `3 4 +` (which also yields 7).

I've never seen the term "Polish Notation", without "Reverse", used
to refer to postfix notation. PN is prefix; RPN is postfix.

I have - it was used as a "short" version of "Reverse Polish Notation".

I have not, that I recall, seen the term "Polish Notation" used to refer
to prefix notation until Janis' post.

But I accept that this is purely based on my experience of when /I/ have
heard (or not heard) the term. I stand by my assertion that "prefix"
would have been better in the context, but I was wrong about "Polish
Notation" not being an established term in its own right.

I see that Janis already pointed out your error. I'm disappointed
that your followup did not acknowledge it. (I'm not commenting on the
rest of what Janis wrote.)

I had not wanted to dwell on it. (I had started a longer reply to
Janis, but scrapped it.) I had simply intended to recommend terms that
had no chance of being misinterpreted, given that some of Janis' terms
had been.

But yes, I should have acknowledged that mistake on my part.

Thus I have learned a new term from Janis, and perhaps he has learned a
little of the another meaning of "monadic" from my post.


--- PyGate Linux v1.5.19
* Origin: Dragon's Lair, PyGate NNTP<>Fido Gate (3:633/10)

On 21/10/2026 13:29, bart wrote:

On 21/10/2026 10:20, David Brown wrote:

On 20/10/2026 22:07, bart wrote:

On 20/10/2026 16:02, David Brown wrote:

On 20/10/2026 16:11, bart wrote:

* A further complication was to allow function pointers within that a >>>>> ÿÿ declaration list

To me, the big disadvantage of C's declaration syntax is that it
lets you declare things of different (but related) types in the same
declaration.

Yes, but that doesn't bite so much because it is uncommon.

Unfortunately not - but it is uncommon to mix objects and function
declarations, or objects of wildly different real types.

That's what I meant.

Ok. It's nice to agree sometimes!

ÿÿÿÿ const int const * const p;
ÿÿÿÿÿÿ 1ÿÿÿÿÿÿÿÿ 2ÿÿÿÿÿÿ 3

const 1 applies to the basetype to its right.
const 2 applies to the basetype to its left.

These are redundant - they do the same thing.ÿ (I'd have preferred if
the ordering rules were strict - allowing only "const int" or "int
const" - but at least people are usually consistent in their style.)

(Both also can be in the middle with compound types like 'long long'!)

const 3 is tricky: I think it applies to the * to its left, since it
says that the pointer value itself is const. But 'p' has type
'pointer to', so it could apply to that directly.

Yes - it is "p" that is const,ÿ not the "*".

I would disagree. This type can also be written as:

ÿ(const int const * const)

There is no 'p' to apply to. The type describes a pointer to an integer.
The first two consts say, redundantly, that the integer value is const.

The third must then apply to the pointer.

Yes. But "the pointer" is the thing you are declaring.

I don't think it is worth belabouring this.

What about this however:

ÿÿÿ int * const *ÿ p;

ÿÿÿÿÿÿÿ 1ÿÿ 2ÿÿ 3

I think here, const 2 applies to * 1, which is to it's left, and
can't apply to 'p' as that is the other side of the * 3.

*p is of type "int * const" - thus you can use "*p" to access a
pointer- to-int, but you can't use *p to change that pointer-to-int.

But what exactly does this 'const' apply to?

The type of "*p" - the thing that "p" points to.

I'm suggesting any 'const' applies either to the base type (the one on
the left) or to a particular '*'.

In that case the latter 'const's must apply right-to-left to the
preceding '*'.

You can view it that way.

There is a style known as "east const" that aims to put "const" on the
right where possible (thus "int const", rather than "const int"), so
that it always applies to the thing immediately to its left. I have
never liked the style, but it is arguably more consistent.

Fair to say that is a complete mess, and it is error prone.

No, it is not at all fair to say that.ÿ It is fair to say that a
different way of writing types might make it easier to understand -
but that's a /long/ way from saying it is "a complete mess".ÿ And you
can't call it "error prone" unless you know that people regularly use
such declarations, and often have bugs in their code as a result of
doing so incorrectly.ÿ I think that is an unrealistic claim.

If there's any confusion about which const applies to which type
element, then mistakes can be made.

Mistakes can always be made. And mistakes can always be found, and
fixed. The questions are, are mistakes made often, are they made more
often than they would be with a different syntax, are the mistakes left undiscovered, and are they consequential? I don't think so - so I don't
see the syntax as "error prone".

Again, I do not think the C declaration syntax is the nicest or clearest
to be found, compared to some languages - but I do not think it is
nearly as bad in practice as some people make out.

You can write this in C++ :

ÿÿÿÿÿ// This bit is only needed once
ÿÿÿÿÿtemplate <typename T> using ptr = T *;

ÿÿÿÿÿ// p is a pointer to a const pointer to an int
ÿÿÿÿÿptr<const ptr<int>> p;


That's LTR syntax.ÿ Sure, it also has < > parentheses, but that's a
minor point since the ordering of the components is what apparently
matters so much.

That it is LTR is now irrelevant because I find that incomprehensible anyway. You've turned a linear chain a nested structure ... oh never
mind, I don't even want to go there with C++.

Your LTR form /is/ a nested structure - it's just that with this C++
format (which I have never seen anyone use in practice), the nesting is explicit.

Or you can write :

ÿÿÿÿÿtypedef int * p_int;
ÿÿÿÿÿconst p_int * p;

Thus p is a pointer to a "const p_int", where a "p_int" is a pointer
to an int.

So, a common pattern with you is to use workarounds so that you
effectively emulate LTR type patterns. Because they are easier to work
with and understand.

I'm offering you an alternative, because /you/ find the normal C syntax confusing. /I/ would not write that, because I don't find the C syntax
here confusing or difficult to read. And mostly I would not write "int
* const * p" because I have no idea when such a type might be useful.
(If I knew, then maybe I would give it a specific name.)

So you do appreciate how they facilitate things, even though they
introduce an extra level of indirection and also disseminate the type information across the program.

I appreciate that you are easily confused and have trouble with C
syntax. I recommend you do one of two things - stop worrying about
imaginary types with no meaning, or learn to use typedef so that they
are not so scary for you.

But you want to underplay how useful it would be to have natural LTR
type declarations within a syntax.

I don't see LTR syntax as making a /significant/ or fundamental
difference. There will be a narrow range of complex types where the C
syntax is getting hard to follow, but an LTR syntax is easier, but
beyond that LTR is equally impenetrable. The issue for complex types is
not the syntax, it is the complexity of the type - and you handle that
by breaking things down into manageable sections.

Let us put some numbers into this. (To be clear - these numbers are
pulled out of the air, and "real" values will depend on the reader, the context, the details of the real code, real alternative syntax, etc.)
Let us say that C syntax is comprehensible with up to 4 parts - where a
"part" is a "const", a "*", "[n]" - in addition to the base type. With
an LTR syntax, let us say it is comprehensible up to 5 parts. Then
there is no doubt - the LTR syntax /is/ clearer. But does it actually
matter, in practice? Most declarations require no more than 3 parts -
with the great majority clustered at 0 or 1 parts. Who cares if it is difficult to read a type declaration you almost never need? And then if
you have something really complicated - 6 parts or more - it is equally incomprehensible with LTR and C syntax, and should be handled by divide-and-conquer just like anything complicated in programming.

This is why I can agree that the C syntax is not optimal, that an LTR
syntax can be clearer, and yet it does not actually matter and the C
syntax works fine in practice.

These are different ways to write the same type, including one that is
LTR, and the main hinder to understanding remains the same - what is
the type for?

If you create a type alias voluntarily (I don't mean structs where
either a tag or a typedef needs to be created) then yes the name should impart something useful.

But in my view this is often taken too far. Sometimes you have structs
where every member has a different user-type. When you look further, you find they are all ints. That is just obfuscation.

Every good thing can be taken too far - but there are lots of good
reasons for having multiple typedefs that all coincidentally happen to
boil down to "int".

(I would accept enumeration types if the compiler can employ that info
to improve type safety, but that seems to be limited.)

I agree that C enumeration types are not as "strong" as I'd like.
Compiler static analysis can help in many ways, but it would be better
(for me) if they were strongly typed and scoped.

I've showed even simple types or trying to use 'const' get becomes
confusing.

No, you haven't.

OK. That is not surprising.

It would make a HUGE difference:

Your points below are all true, but IMHO all very minor, and do not
add up to anything much.

It would eliminate half the issues with C's type syntax. Probably CDECL wouldn't need to exist. Lots of () disappear. It would make pointers-to- arrays more viable.

But that's nothing in your view. OK again.

CDECL has never needed to exist. So few () are needed in declarations
that it doesn't matter if they are there or not. Pointers to arrays
work fine if you want to use them, but they are not often used in C - primarily because of the array-to-pointer decay in expressions, not
because of the declaration syntax or the prefix dereferencing operator.

Your invented confusion.

That doesn't matter in practice.

I don't see that as significant.

I do agree that the decay of expressions using array types into
pointer types is a source of error in C code - though I do not think
it is as bad as you do.

I didn't say anything about, and that wouldn't be affected.

Ok.

But I just don't see pointer-to-array expressions to be common enough
for the difference you describe to be important.

If you're passing arrays to a function by-reference then the natural way
is to a have a pointer to the array. C can do that, but nobody ever does
so, probably because indexing is then so ugly.

With my idea, (*A)[i] turns into A*[i], a bit less ugly.

Predictions are of course speculative, but I could not see that making noticeable difference. C programmers rarely use pointers to arrays
because they rarely give advantages over pointers to the first element
of an array, the decay in expressions means it is easy to make mistakes,
and you often need to make a pointer to the first element anyway.

If array expressions did not decay to pointer expressions, and array parameters were passed as values, it would be a very different matter.

(4) For pointers to structs, these are the patterns:

ÿÿÿÿ prefix *ÿÿÿ With ->ÿÿÿ With postfix *

ÿÿÿÿ (*P).mÿÿÿÿÿ P->mÿÿÿÿÿÿ P*.m
ÿÿÿÿ (**P).mÿÿÿÿ (*P)->mÿÿÿ P**.m
ÿÿÿÿ (***P).mÿÿÿ (**P)->mÿÿ P***.m

Which column looks the tidiest?

Far and away the most common - by orders of magnitude - are pointers
to structs.ÿ "p->m" looks fine to me, and I prefer it to "p*.m".

But where's the consistency? Sometimes "." is used for member selection,
and sometimes "->". And with two pointer levels, you need both!

The consistency is that you almost always have a pointer to a struct, so
you can consistently use p->m. There is no need to change that for consistency with a much rarer usage. And of course "." is used for
member selection when you have a struct object, or when you have already dereferenced a pointer to a struct.

(6) Your 'int * a, b' example would become:

ÿÿ int a *, b;

Much easier, even with that space, to see that '*' does not belong to
the base type but is a modifier for that variable.

It's still bad.ÿ I don't think finding a way to make it easier to
write bad code is a good idea.

It wouldn't stay bad for long! Because if the intention was to declare
two pointers, then it's easier to see that this is wrong.

It is bad (according to my personal style preferences) if your
intentionally declare an int and a pointer to an int in the same line.
I am not talking about mistakes here - a mixup between an int and an
int* will almost certainly result in a compilation failure and the code
will quickly be fixed to give valid C code.

C lets you write "int *a, b;" - it is legal C. There are lots of things
you can write in C that I think are bad code, even though they may be intentional and work as intended. (And even though others will,
naturally, have different opinions.)

I would be against any change to C syntax that made it /easier/ for
people to write such declarations - whether intentional or by mistake.

So basically, the suggestion would change some very minor things -
mostly in subjective ways - and not actually do anything for aspects
of the language where there is more of a consensus that C is sub-
optimal. And for this, you would want a fundamental change to one of
the most used operators in all C code!

Obviously you can't change prefix * now. A postfix /alternative/, in addition to prefix *, could have been introduced decades ago. So by the
time /you/ encountered C, you might have been using the latter.

I first used C on a very small scale in the late 1980's, so that was
quite a few decades ago.

I expect that a postfix dereferencing operator would have worked fine
instead of a prefix one - it works fine in Pascal. I don't think it
would have been "better" in any significant way. Two separate
dereferencing operators with no difference except the prefix vs. postfix positioning would have been a very bad idea, no matter when it were
introduced - it would have been a totally unnecessary complication, just adding confusion and inconsistency.

But even if you were right here, it is no more realistic to go back 4
decades to add this new postfix dereferencing operator as it is to go
back 5 decades and pick that one in the first place.



--- PyGate Linux v1.5.19
* Origin: Dragon's Lair, PyGate NNTP<>Fido Gate (3:633/10)

On 21/10/2026 12:21, David Brown wrote:

On 21/10/2026 03:04, bart wrote:

Here, one problem is that there are 3 types that I don't know and
would have to look up.

Incorrect.

If I wanted to use function from a language that is not C and for which
nobody has yet created a set of bindings, then I would have to
investigate every single abstract type.

Even then, I might find that a year later, 'err_t' has been defined to
be something slightly different. Standard types are easier to deal with
and more likely to be stable.

That signed char return is unusual; why not 'int'? (How would you even
print an 'err_t' value anyway)?

It seems that yet again, you need an explanation of fundamental points
of software development.ÿ Today's lesson is on "abstraction".

OK. I've just looked at several graphics libraries. Those have chosen to
use predominantly standard C types for function return values. And
standard C types for numeric arguments.

Sometimes they might be prefixed, eg. GL_int, SDL_bool, probably as abstraction from the vagaries of standard C.

It seems a trend to invent pointless extra types for everything. In C
itself, there are about 35 denotations for integer types, and that's
before you get into clock_t, time_t, offset_t and everything else.

In general most boil down to one of i32 u32 i64 u64.

So you can go over the top with abstraction.

Maybe on some targets (of this portable library), err_t is "signed
char".

Why not define it on top of 'int'? Is it likely that large numbers of
error codes are going to be stored within structs and arrays so that the
size must be minimal?

It is also nice to know that it can be used in a switch, and cast to an
int for printf.

How would you know that? I thought it was abstract! Maybe err_t is a
small struct.

Or look at the "ip_addr_t" type.ÿ It happens, at the moment, to be a
struct.ÿ But it might have been a union.ÿ The size and contents of the struct depend on details of how the library is built - whether it has support for ipv4, ipv6, or both.ÿ Maybe a future version will also
support ipv8, or ipv5 (I've heard some people are trying to make an IP protocol that covers more than IPv4, but without most of the
complicating additional features of IPv6).ÿ It is an abstract type - you
use it without knowing the details.

I haven't said much about that. It is a struct so some username is
needed. I renamed it to IP_addr in my example.

But I'm not sure it needs the _t suffix. (Is it a thing now for every
typedef name to need _t?)

I notice however that the argument is a pointer: if ip_addr_t* values
are commonly passed around, I would put an abstraction around that.

(However that's partly because how my language works is different; to
access a member of the struct, I don't need to know if the type of X is
an actual struct or is a pointer to one; I write X.addr in both cases.)



--- PyGate Linux v1.5.19
* Origin: Dragon's Lair, PyGate NNTP<>Fido Gate (3:633/10)

fir wrote:

Lawrence D?Oliveiro pisze:

t to end each case-sequence in a switch statement with
a break-statement: put the break at the same indentation level as the
case-clause as well as the switch-expression. That way, you can scan
your eye down a single line f

some time ago i was saying what the proper switch should like
(imo, but im not sure if my conclusions are anough to take is a s proven)

case {} case {}ÿ case {} otherwise {}

its indeed sorta needed becouse case in fact are ifs
(not if-elses)ÿ (so some in fact could write

if {} if {} if {} otherwise {}

its the same)

ÿthe problem is youÿ got no group alse
and here this otherwise need to check all ifs
"or" them and use group else for them

this could be written in few ways, but my case case case otherwise names it could also do

if {} or if {} or if {} else {}

so either you need logic operators here or predefined constructs like otherwise (maybe both)

and that should be included not switch wchich is bad imo

other way is to define distionary more as data construct

dict {
'mental'ÿ {/* 1 */}
'reductionists' {/* 2 */}
'suck' {/* 3 */}
}

then you could use

dict('reductionists')

to yeld toÿ /* 2 */

this second one parallels to switch keyword

so c switch mixes them both in bad way..they should be spitet and
upbuild as showed ;c

thats my conclusion as switch topic as far by now ;c

Just start using the switch statement. It's useful in very very very
many cases. You'll get the hang of it right away. Next, it doesn't just
test variable type 'int', also notably 'char', among others.

--
Can you strip away so we may start again?
"There?s a switch and they don't
seem authentic or themselves. It
feels like I?m an unnecessary
body and it?s a waste of time to
even be there." -- Grim, playful Blaine.

--- PyGate Linux v1.5.19
* Origin: Dragon's Lair, PyGate NNTP<>Fido Gate (3:633/10)

On 21/10/2026 15:22, Dan Cross wrote:

In article <11baah2$3te3v$1@dont-email.me>,
David Brown <david.brown@hesbynett.no> wrote:

On 20/10/2026 21:24, Dan Cross wrote:

In article <11b7k22$2v8e5$1@dont-email.me>, bart <bc@freeuk.com> wrote: >>>> [snip]

(There was a LOT of antipathy towards my idea to fix the common case of >>>> 'loop-break' clashing with 'switch-break', BECAUSE it did not fix the
problem of nested loop-break, which is uncommon, even though that wasn't >>>> the aim.)

Those are two different things. No one disagrees with you that
"nested break from a switch inside of a loop" is relatively more
common than other variants.

Quibble - that is not established to my satisfaction. I am not
convinced that wanting a nested break for "switch inside loop" is more
common than wanting it for "loop inside loop". So I neither agree nor
disagree with that claim. I don't, however, think it matters much -
both are situations that turn up sometimes in code, and definitive
answers are neither possible nor useful.

Ok, that's fair; I shouldn't say "no one disagrees".

And I didn't say I /did/ disagree - merely that I don't feel I have the information to disagree or agree.

We all over-generalise, and that's always bad!

[snip]
There are plenty of languages that can do this kind of thing
that are not C and have syntax and semantics closer to what you
seem to want. Here's an example in Rust:

pub trait TimerHandle { ... }

fn CreateTimer<T>(
timer_name: &str,
period: std::time::Duration,
auto_reload: bool,
timer_id: T,
handler: fn(&dyn TimerHandle),
) -> Result<Timer<T>, TimerError>

I didn't know what an `UBaseType_t` is, and while "autoreload"
sounded pretty intuitive, I wasn't sure about the semantics, so
I looked it up (the example comes from `FreeRTOS`). In this
context, it is a boolean saying whether the timer should repeat
with the given periodicity, or whether it is a one-shot.

FreeRTOS is written in C90 - a mistake, IMHO - and thus does not use
bool. Instead, it uses constants pdTRUE and pdFALSE of type
UBaseType_t. UBaseType_t is a type that is dependent on the target -
usually it is either 16-bit or 32-bit. But of course it doesn't matter
what the underlying types are - you use the typedef names, and the
documented constants.

Thanks for the context. Your point that the underlying type
doesn't matter is salient: it's opaque to the programmer, but
99% of the time the programmer doesn't need to worry about the
details.

Yes.

The timer_id is opaque to the timer, and it looks like it's used
to facilitating the handler accessing timer-specific data. In
C, passing it as a `void *` is used as a way to get a poor-man's
overloading. But Rust has generics, I just made it generic over
some type T.

FreeRTOS uses "void *" to mean "pointer to internal structure that you
shouldn't be messing with". It uses this far too often, and is, IMHO, a
poor design choice. (I also dislike the silly Hungarian naming.) I
would much preferred if there had been :

struct Internal_Timer_Struct;
typedef struct Internal_Timer_Struct * timer_id_t;

and then the parameter "timer_id_t timer_id". So in a re-write, it
would not be a generic. (You might choose to use a generic for the
handler function type, so that handler callbacks could have parameters
of other types, but not for the timer id.)

I am using these declarations from FreeRTOS (and LWIP) to demonstrate
the use of function typedefs in massively popular codebases, not to
claim FreeRTOS is a paradigm of C code design!

Oh interesting; in this case, I had assumed it was treated as
a callback-specific type so one could plumb extra context into
the handler; the documentation I saw suggested it could be used
by the handler to disambiguate several timers reusing the same
handler function.

Actually, I have mixed these up, and you are correct - the void* id is user-assigned, and you use it as you wish. There are other places in
FreeRTOS where pointer types get "erased" and reduced to void*
unnecessarily, but this was not one of them. (In my poor defence, the FreeRTOS code I have doesn't use timers, and the bits it does use -
threads and queues, mainly - is abstracted to a C++ interface.)

For example:

[snip]

Note this is decently complex behavior, but it's actually quite
intuitive from the name and the type.

You have got a very clear picture here, much of it from the names of the
types. For a Rust programmer, you give a good impression of experience
with C :-)

I've been known to dabble.

The only mistake you made is that programmers working on systems using
FreeRTOS and the like, have a fear and loathing of "malloc", have never
heard of "abort()", and do not join our threads because they all run
until the power is switched off.

Ha, fair; that was just a made-up example, based on other thread
libraries I have used (in C). I didn't mean for it to be
interpreted strictly in the context of FreeRTOS! :-D

[snip]

Or just have :

fnptr pc = first;
fnptr *pcptr = &pc;

I don't see a need for "uintptr_t", except so that you have to have
casts like Bart had.

Yes. But I wanted to remain faithful to his original, to show
that one could write a more-or-less exact transliteration in C
that was extremely similar to his chosen syntax.

[Snip a bunch of Rust code; the point of which being that
bart need not complain about lack of an alternative to C]

It was interesting to see the Rust code, but it made one thing clear to
me - Rust should be used for writing Rust code, and not for writing C
code in Rust syntax.

--- PyGate Linux v1.5.19
* Origin: Dragon's Lair, PyGate NNTP<>Fido Gate (3:633/10)

On 21/10/2026 16:41, bart wrote:

On 21/10/2026 12:21, David Brown wrote:

On 21/10/2026 03:04, bart wrote:

Here, one problem is that there are 3 types that I don't know and
would have to look up.

Incorrect.

If I wanted to use function from a language that is not C and for which nobody has yet created a set of bindings, then I would have to
investigate every single abstract type.

So for a one-in-a-million use-cases, you would have to look up the type,
such as by holding your mouse over the type, or pressing the "navigate
to definition" shortcut in your IDE. I think it is better to optimise
for the 999,999 other cases.

Or you could use a real programming language, for which there is
probably SWIG support.

Even then, I might find that a year later, 'err_t' has been defined to
be something slightly different. Standard types are easier to deal with
and more likely to be stable.

Libraries change types for good reasons. Support for one person using
an obscure language who does not want to have to look up a typedef is
not going to influence that decision. The world does not revolve around
you and your unique needs and wants.



--- PyGate Linux v1.5.19
* Origin: Dragon's Lair, PyGate NNTP<>Fido Gate (3:633/10)

In article <11baiuc$11ac$1@dont-email.me>, bart <bc@freeuk.com> wrote:

On 21/10/2026 12:21, David Brown wrote:

On 21/10/2026 03:04, bart wrote:

Here, one problem is that there are 3 types that I don't know and
would have to look up.

Incorrect.

If I wanted to use function from a language that is not C and for which >nobody has yet created a set of bindings, then I would have to
investigate every single abstract type.

That is true of every programming language.

Even then, I might find that a year later, 'err_t' has been defined to
be something slightly different. Standard types are easier to deal with
and more likely to be stable.

That is also true of every programming language.

You can write some library in BartM or whatever language you
like, and someone might write a binding to call it from, say,
Pascal; and then a year down the road, you might change your
compiler (since I gather you don't bother with a well-defined
ABI, based on your not seeming to understand them) or change
the type of something in a record, and you don't tell the Pascal
person; now, they've got a program that will probably link
against your library, and may even work correctly _most of the
time_, but sometimes will just mysteriously crash.

Welcome to programming. It's Hard(TM).

Your answer to that appears to be to simply give up on
abstraction; others work around it by writing tools (cf, `swig`
or `bindgen` for Rust).

That signed char return is unusual; why not 'int'? (How would you even
print an 'err_t' value anyway)?

It seems that yet again, you need an explanation of fundamental points
of software development.ÿ Today's lesson is on "abstraction".

OK. I've just looked at several graphics libraries. Those have chosen to
use predominantly standard C types for function return values. And
standard C types for numeric arguments.

Sometimes they might be prefixed, eg. GL_int, SDL_bool, probably as >abstraction from the vagaries of standard C.

It seems a trend to invent pointless extra types for everything. In C >itself, there are about 35 denotations for integer types, and that's
before you get into clock_t, time_t, offset_t and everything else.

In general most boil down to one of i32 u32 i64 u64.

Judicious use of types can render entire categories of errors
unexpressible. Alexis King wrote a wonderful post about this,
expressed using Haskell, but the general principles apply more
broadly.

https://lexi-lambda.github.io/blog/2019/11/05/parse-don-t-validate/

So you can go over the top with abstraction.

Of course. Part of becoming a true software engineer is
learning to find balance between too much abstraction and too
little.

Maybe on some targets (of this portable library), err_t is "signed
char".

Why not define it on top of 'int'? Is it likely that large numbers of
error codes are going to be stored within structs and arrays so that the >size must be minimal?

Because maybe on some platforms it's more efficient to keep it
in a `signed char`. Who knows? The point is you almost never
need to care.

It is also nice to know that it can be used in a switch, and cast to an
int for printf.

How would you know that? I thought it was abstract! Maybe err_t is a
small struct.

Because the documentation about it tells you that you can: "The
type `err_t` is used to represent errors. It can be cast to
`int`." Really, this is table-stakes software development.

Or look at the "ip_addr_t" type.ÿ It happens, at the moment, to be a
struct.ÿ But it might have been a union.ÿ The size and contents of the
struct depend on details of how the library is built - whether it has
support for ipv4, ipv6, or both.ÿ Maybe a future version will also
support ipv8, or ipv5 (I've heard some people are trying to make an IP
protocol that covers more than IPv4, but without most of the
complicating additional features of IPv6).ÿ It is an abstract type - you
use it without knowing the details.

I haven't said much about that. It is a struct so some username is
needed. I renamed it to IP_addr in my example.

Huh? Username?

But I'm not sure it needs the _t suffix. (Is it a thing now for every >typedef name to need _t?)

I notice however that the argument is a pointer: if ip_addr_t* values
are commonly passed around, I would put an abstraction around that.

(However that's partly because how my language works is different; to
access a member of the struct, I don't need to know if the type of X is
an actual struct or is a pointer to one; I write X.addr in both cases.)

So does Rust. You're welcome.

- Dan C.


--- PyGate Linux v1.5.19
* Origin: Dragon's Lair, PyGate NNTP<>Fido Gate (3:633/10)

On 21/10/2026 16:37, Dan Cross wrote:

In article <11baiuc$11ac$1@dont-email.me>, bart <bc@freeuk.com> wrote:

On 21/10/2026 12:21, David Brown wrote:

On 21/10/2026 03:04, bart wrote:

Here, one problem is that there are 3 types that I don't know and
would have to look up.

Incorrect.

If I wanted to use function from a language that is not C and for which
nobody has yet created a set of bindings, then I would have to
investigate every single abstract type.

That is true of every programming language.

It's not clear what you mean by 'that'.

But typically APIs are primarily expressed as C headers. With mainstream languages, somebody else has usually already done that work.

Even then, I might find that a year later, 'err_t' has been defined to
be something slightly different. Standard types are easier to deal with
and more likely to be stable.

That is also true of every programming language.

Then it is also true that standard types will be more stable.

You can write some library in BartM or whatever language you
like, and someone might write a binding to call it from, say,
Pascal; and then a year down the road, you might change your
compiler (since I gather you don't bother with a well-defined
ABI, based on your not seeming to understand them

You still don't get what an ABI is.

Welcome to programming. It's Hard(TM).

Some things could be easier. Someone produces library (eg. DLL binary).

That library exports a set of function names, but not a set of language-neutral function signatures. (And it will not export types,
structs, enums etc needed to use the library.)

Why not do that? Just a DLL having the C header API embedded within it
would be a start! You don't need to source them separately, and they
will always match in version.

In general most boil down to one of i32 u32 i64 u64.

Judicious use of types can render entire categories of errors
unexpressible. Alexis King wrote a wonderful post about this,
expressed using Haskell, but the general principles apply more
broadly.

If you want to use lots of abstraction then use a language with strict
type systems that can back them up. Ada for example.

But it's not a language I'd want to use. You can go too far down that
path (look at the Frink programming language).

It is also nice to know that it can be used in a switch, and cast to an
int for printf.

How would you know that? I thought it was abstract! Maybe err_t is a
small struct.

Because the documentation about it tells you that you can: "The
type `err_t` is used to represent errors. It can be cast to
`int`." Really, this is table-stakes software development.

In this case it doesn't. It is an alias for 's8_t', which is itself an
alias for 'int8_t' (which itself is probably an alias for 'signed char'
within 'stdint.h'.

What it does say however is that, if you define a certain macro, you can
make err_t' any type you like. I don't know how that would work here; I
assume it still has to be a numeric type, but it is not stated.



--- PyGate Linux v1.5.19
* Origin: Dragon's Lair, PyGate NNTP<>Fido Gate (3:633/10)

bart <bc@freeuk.com> writes:

On 21/10/2026 16:37, Dan Cross wrote:

You can write some library in BartM or whatever language you
like, and someone might write a binding to call it from, say,
Pascal; and then a year down the road, you might change your
compiler (since I gather you don't bother with a well-defined
ABI, based on your not seeming to understand

You still don't get what an ABI is.

Please, enlighten us. Be specific. What exactly
does the term ABI mean to you?

--- PyGate Linux v1.5.19
* Origin: Dragon's Lair, PyGate NNTP<>Fido Gate (3:633/10)

On 21/10/2026 18:21, Scott Lurndal wrote:

bart <bc@freeuk.com> writes:

On 21/10/2026 16:37, Dan Cross wrote:

You can write some library in BartM or whatever language you
like, and someone might write a binding to call it from, say,
Pascal; and then a year down the road, you might change your
compiler (since I gather you don't bother with a well-defined
ABI, based on your not seeming to understand

You still don't get what an ABI is.

Please, enlighten us. Be specific. What exactly
does the term ABI mean to you?

It's what I have to deal with in a compiler back-end if I want to
support an FFI in a language.

It's not the same problem as using that FFI to write a set of bindings corresponding with a particular API.

The latter problem needs to be solved even if there was no back-end and
no ABI to deal with (eg. transpiling to another language, or lowering to
some VM).

I don't why I'm bothering, since somebody will find another stick to
beat me over the head with or to somehow try to catch me out, but here
is an example of a function inside MSVCRT.DLL..

In the C API (ie. stdio.h) it will be expressed like this:

int puts(const char*);

In my FFI and in my syntax, it is expressed like this:

func puts (ichar)i32

So, this is 'creating a binding'. This can be done manually for this
one-off example. It's not perfect: on my platform, the C parameter has
'ref i8' type, but mine is more like 'ref u8'.

At this point, the ABI doesn't come into it.

That becomes relevant within the backend for a particular target and
platform.

So for this call:

puts(s)

the ABI for x64 running Windows will tell me that 's' must be passed in
rcx, the stack needs a shadow space, it needs to be 16-byte aligned, and
the 32-bit result is placed in eax.

For ARM64 running Linux (SYS V), then 's' is passed in x0, and the
result placed in w0. The stack will always properly aligned.

The only overlap in API/ABI may be to do with details of how structs may
be laid out in memory. But generally, C APIs will just follow the C
rules; I don't consider it an ABI thing. It would be something to deal
with even if no ABI existed and no native code was generated.

For my purposes, ABI is about calling conventions. ABI references may
cover a lot more (eg. for SYS V which likes to make everything as
complicated as possible).

So, now tell me what I've got wrong.




--- PyGate Linux v1.5.19
* Origin: Dragon's Lair, PyGate NNTP<>Fido Gate (3:633/10)

In article <11baur1$63id$1@dont-email.me>, bart <bc@freeuk.com> wrote:

On 21/10/2026 18:21, Scott Lurndal wrote:

bart <bc@freeuk.com> writes:

On 21/10/2026 16:37, Dan Cross wrote:

You can write some library in BartM or whatever language you
like, and someone might write a binding to call it from, say,
Pascal; and then a year down the road, you might change your
compiler (since I gather you don't bother with a well-defined
ABI, based on your not seeming to understand

You still don't get what an ABI is.

Please, enlighten us. Be specific. What exactly
does the term ABI mean to you?

It's what I have to deal with in a compiler back-end if I want to
support an FFI in a language.

It's not the same problem as using that FFI to write a set of bindings >corresponding with a particular API.

The latter problem needs to be solved even if there was no back-end and
no ABI to deal with (eg. transpiling to another language, or lowering to >some VM).

I don't why I'm bothering, since somebody will find another stick to
beat me over the head with or to somehow try to catch me out, but here
is an example of a function inside MSVCRT.DLL..

In the C API (ie. stdio.h) it will be expressed like this:

int puts(const char*);

In my FFI and in my syntax, it is expressed like this:

func puts (ichar)i32

So, this is 'creating a binding'. This can be done manually for this
one-off example. It's not perfect: on my platform, the C parameter has
'ref i8' type, but mine is more like 'ref u8'.

At this point, the ABI doesn't come into it.

That becomes relevant within the backend for a particular target and >platform.

So for this call:

puts(s)

the ABI for x64 running Windows will tell me that 's' must be passed in
rcx, the stack needs a shadow space, it needs to be 16-byte aligned, and
the 32-bit result is placed in eax.

For ARM64 running Linux (SYS V), then 's' is passed in x0, and the
result placed in w0. The stack will always properly aligned.

The only overlap in API/ABI may be to do with details of how structs may
be laid out in memory. But generally, C APIs will just follow the C
rules; I don't consider it an ABI thing. It would be something to deal
with even if no ABI existed and no native code was generated.

For my purposes, ABI is about calling conventions. ABI references may
cover a lot more (eg. for SYS V which likes to make everything as >complicated as possible).

So, now tell me what I've got wrong.

Wow. You really, truly, have no idea how any of this works. I
don't even know where to begin. You just throw around words but
have no idea what they mean in context.

It's breathtaking, really.

- Dan C.

--- PyGate Linux v1.5.19
* Origin: Dragon's Lair, PyGate NNTP<>Fido Gate (3:633/10)

In article <11balos$1042$2@dont-email.me>,
David Brown <david.brown@hesbynett.no> wrote:

On 21/10/2026 15:22, Dan Cross wrote:
[snip]
Actually, I have mixed these up, and you are correct - the void* id is >user-assigned, and you use it as you wish. There are other places in >FreeRTOS where pointer types get "erased" and reduced to void* >unnecessarily, but this was not one of them. (In my poor defence, the >FreeRTOS code I have doesn't use timers, and the bits it does use -
threads and queues, mainly - is abstracted to a C++ interface.)

No problem!

It was interesting to see the Rust code, but it made one thing clear to
me - Rust should be used for writing Rust code, and not for writing C
code in Rust syntax.

Yes. When we started working with Rust, most of us had a lot of
experience in C, C++, etc, and we brought a lot of inherited bad
habits to our Rust code. At one point, a colleague quipped that
we were writing, "crust: C in Rust syntax!" We all thought that
was a great play on words, and adopted it in self-deprecating
terms. Some people get pretty insulted by it, but it was never
intended that way.

- Dan C.


--- PyGate Linux v1.5.19
* Origin: Dragon's Lair, PyGate NNTP<>Fido Gate (3:633/10)

In article <11baot1$3j98$1@dont-email.me>, bart <bc@freeuk.com> wrote:

[snip]
You still don't get what an ABI is.

This is the only interesting thing in your post, and only
because it offers a key insight into your screeds: you use terms
in a way that matches your own sense of what they mean,
regardless of how they are used in the wider context. This is a
good example: later, you said that ABIs are _only_ about calling
conventions. For you, I'm sure that is true; for others who
work in the field and use the consensus definitions, it is
uninformed nonsense. No wonder you feel so attacked; what you
believe you are saying is competely divorced from the way people
read it.

- Dan C.


--- PyGate Linux v1.5.19
* Origin: Dragon's Lair, PyGate NNTP<>Fido Gate (3:633/10)

bart <bc@freeuk.com> writes:

On 21/10/2026 18:21, Scott Lurndal wrote:

bart <bc@freeuk.com> writes:

On 21/10/2026 16:37, Dan Cross wrote:

You can write some library in BartM or whatever language you
like, and someone might write a binding to call it from, say,
Pascal; and then a year down the road, you might change your
compiler (since I gather you don't bother with a well-defined
ABI, based on your not seeming to understand

You still don't get what an ABI is.

Please, enlighten us. Be specific. What exactly
does the term ABI mean to you?

It's what I have to deal with in a compiler back-end if I want to
support an FFI in a language.

Ah, so you don't know what an ABI is.

An Application Binary Interface (ABI) is a
low-level contract in computer science that
defines how two compiled binary program modules
interact with each other at the machine-code level.

<snip discussions of the well known ABI requirements for
windows x86_64 and linux on ARM64>[*]

If you want your compiler to leverage existing libraries
and/or code written in another language, you need to follow
the platform ABI. It is that simple.

Whether you like it or not, is completely irrelevent.

[*] It is worth noting that the Windows x86 64-bit ABI
requirement for the caller to reserve space for the
callee to save registers (shadow store) is quite
unusual in modern ABIs.

The stack pointer alignment requirement should be obvious.

--- PyGate Linux v1.5.19
* Origin: Dragon's Lair, PyGate NNTP<>Fido Gate (3:633/10)

On 21/10/2026 19:38, Dan Cross wrote:

In article <11baur1$63id$1@dont-email.me>, bart <bc@freeuk.com> wrote:

So, now tell me what I've got wrong.

Wow. You really, truly, have no idea how any of this works. I
don't even know where to begin. You just throw around words but
have no idea what they mean in context.

It's breathtaking, really.

And Wow, your reply is exactly the kind I expected!

Of course, you're not going to tell me what API means versus ABI, and
you're not going to answer my question about what I've got wrong.

Because actually you don't know. This was apparent from things you've
said in the past.

I have actually wondered what you're doing here, and this appears to be
it: being hostile, patronising, condescending and constantly taking the contrary view no matter what.

In other words, being a troll.



--- PyGate Linux v1.5.19
* Origin: Dragon's Lair, PyGate NNTP<>Fido Gate (3:633/10)

On 21/10/2026 20:17, Scott Lurndal wrote:

bart <bc@freeuk.com> writes:

On 21/10/2026 18:21, Scott Lurndal wrote:

bart <bc@freeuk.com> writes:

On 21/10/2026 16:37, Dan Cross wrote:

You can write some library in BartM or whatever language you
like, and someone might write a binding to call it from, say,
Pascal; and then a year down the road, you might change your
compiler (since I gather you don't bother with a well-defined
ABI, based on your not seeming to understand

You still don't get what an ABI is.

Please, enlighten us. Be specific. What exactly
does the term ABI mean to you?

It's what I have to deal with in a compiler back-end if I want to
support an FFI in a language.

Ah, so you don't know what an ABI is.

An Application Binary Interface (ABI) is a
low-level contract in computer science that
defines how two compiled binary program modules
interact with each other at the machine-code level.

OK. And how is my statement wrong?

If you want your compiler to leverage existing libraries
and/or code written in another language, you need to follow
the platform ABI. It is that simple.

OK. And what have I said that contradicts that? I said it is something
taken care of in the back end of my compiler; and it is a solved problem.

It sends very much like both of you are confused about the difference
between API and ABI!

Whether you like it or not, is completely irrelevent.

Irrelevant to ... what? You're making about as much sense as the other chap.

I was describing the problems of interfacing to APIs (with a 'P') and
DC spouted some stuff about ABIs, which was not relevant to those problems.

So, are you agreeing with me here that API issues and ABI issues are
separate matters?

The stack pointer alignment requirement should be obvious.

Not really: the ABI has to explicitly state it.

In any case that is not relevant to the issues I was describing in
working with APIs.



--- PyGate Linux v1.5.19
* Origin: Dragon's Lair, PyGate NNTP<>Fido Gate (3:633/10)

On 10/21/2026 5:17 AM, David Brown wrote:
[...]

*_t intrudes into POSIX.

--- PyGate Linux v1.5.19
* Origin: Dragon's Lair, PyGate NNTP<>Fido Gate (3:633/10)

In article <11bb47i$889c$1@dont-email.me>, bart <bc@freeuk.com> wrote:

On 21/10/2026 19:38, Dan Cross wrote:

In article <11baur1$63id$1@dont-email.me>, bart <bc@freeuk.com> wrote:

So, now tell me what I've got wrong.

Wow. You really, truly, have no idea how any of this works. I
don't even know where to begin. You just throw around words but
have no idea what they mean in context.

It's breathtaking, really.

And Wow, your reply is exactly the kind I expected!

Of course, you're not going to tell me what API means versus ABI, and
you're not going to answer my question about what I've got wrong.

Honestly? No, I'm not. It's clear that if I tried, you would
either not understand, or deliberately ignore it so you could
blindly continue in your self-imposed ignorance.

Because actually you don't know.

Umm.....

This was apparent from things you've said in the past.

You know, it's one thing to be ignorant yourself. It's quite
another to project that onto others.

I have actually wondered what you're doing here, and this appears to be
it: being hostile, patronising, condescending and constantly taking the >contrary view no matter what.

In other words, being a troll.

It's apparent that you really, truly, do not understand why so
many others seem like they are "having a go" at you. I actually
feel kind of bad for you.

- Dan C.


--- PyGate Linux v1.5.19
* Origin: Dragon's Lair, PyGate NNTP<>Fido Gate (3:633/10)

On 21/10/2026 21:36, Dan Cross wrote:

In article <11bb47i$889c$1@dont-email.me>, bart <bc@freeuk.com> wrote:

On 21/10/2026 19:38, Dan Cross wrote:

In article <11baur1$63id$1@dont-email.me>, bart <bc@freeuk.com> wrote:

So, now tell me what I've got wrong.

Wow. You really, truly, have no idea how any of this works. I
don't even know where to begin. You just throw around words but
have no idea what they mean in context.

It's breathtaking, really.

And Wow, your reply is exactly the kind I expected!

Of course, you're not going to tell me what API means versus ABI, and
you're not going to answer my question about what I've got wrong.

Honestly? No, I'm not. It's clear that if I tried, you would
either not understand, or deliberately ignore it so you could
blindly continue in your self-imposed ignorance.

Because actually you don't know.

Umm.....

This was apparent from things you've said in the past.

You know, it's one thing to be ignorant yourself. It's quite
another to project that onto others.

I've seen zero evidence that you know anything about the matter. Just
bluster.

I have actually wondered what you're doing here, and this appears to be
it: being hostile, patronising, condescending and constantly taking the
contrary view no matter what.

In other words, being a troll.

It's apparent that you really, truly, do not understand why so
many others seem like they are "having a go" at you. I actually
feel kind of bad for you.

If you don't know this stuff, that would be perfectly fine, not everyone
is into compilers.

But refusing to admit that you mixed up API/ABI and instead gaslighting
others into thinking they're the ones in the wrong is unacceptable and childish.

I've looked at the 40 or so posts you've made in the last few days, half
of them were replies to me, all unpleasant exchanges.

This is just persecution, constantly attacking and belittling at the
personal level. Maybe you're some sick fuck and and you get a kick out
of it, then you should get help together with JP, that other wonderful
person.



--- PyGate Linux v1.5.19
* Origin: Dragon's Lair, PyGate NNTP<>Fido Gate (3:633/10)

In article <11bbd8k$bhfq$1@dont-email.me>, bart <bc@freeuk.com> wrote:

On 21/10/2026 21:36, Dan Cross wrote:

In article <11bb47i$889c$1@dont-email.me>, bart <bc@freeuk.com> wrote:

On 21/10/2026 19:38, Dan Cross wrote:

In article <11baur1$63id$1@dont-email.me>, bart <bc@freeuk.com> wrote: >>>

So, now tell me what I've got wrong.

Wow. You really, truly, have no idea how any of this works. I
don't even know where to begin. You just throw around words but
have no idea what they mean in context.

It's breathtaking, really.

And Wow, your reply is exactly the kind I expected!

Of course, you're not going to tell me what API means versus ABI, and
you're not going to answer my question about what I've got wrong.

Honestly? No, I'm not. It's clear that if I tried, you would
either not understand, or deliberately ignore it so you could
blindly continue in your self-imposed ignorance.

Because actually you don't know.

Umm.....

This was apparent from things you've said in the past.

You know, it's one thing to be ignorant yourself. It's quite
another to project that onto others.

I've seen zero evidence that you know anything about the matter. Just >bluster.

And sadly, I've seen plenty of evidence confirming that you know
nothing about it at all.

- Dan C.


--- PyGate Linux v1.5.19
* Origin: Dragon's Lair, PyGate NNTP<>Fido Gate (3:633/10)

On Wed, 21 Oct 2026 09:29:24 -0600, Blaine wrote:

Just start using the switch statement. It's useful in very very very
many cases.

Has a well-known pitfall, though.

How not to forget to end each case-sequence in a switch statement with
a break-statement: put the break at the same indentation level as the case-clause as well as the switch-expression. That way, you can scan
your eye down a single line for each switch-statement to be sure that
no breaks are missing. A reasonably-complex example, with a nested
switch for added interest:

real stack_calc
(
stackcalc_op op,
...
)
/* starting with an empty operand stack, carries out the specified
operations on the specified operands, at the end of which there
should be just a single value on the operand stack. This value is
popped and returned as the function result. */
{
real * opstack = NULL;
size_t
opstacklen = 0,
opstackalloc = 0;
real result;
va_list args;
va_start(args, op);
bool first = true;
bool done = false;
for (;;)
{
if (not first)
{
op = va_arg(args, stackcalc_op);
} /*if*/
first = false;
switch (op)
{
case STACKCALC_END:
done = true;
break;
case STACKCALC_PUSH:
{
if (opstacklen == opstackalloc)
{
opstackalloc += 16;
opstack = realloc(opstack, opstackalloc * sizeof(real));
bugcheck(opstack != NULL, "unable to expand operand stack beyond %d", opstacklen);
} /*if*/
opstack[opstacklen] = va_arg(args, real);
++opstacklen;
}
break;
case STACKCALC_ADD:
case STACKCALC_SUB:
case STACKCALC_MUL:
case STACKCALC_DIV:
bugcheck(opstacklen >= 2, "not enough operands for operator %d", op);
{
const real op2 = opstack[opstacklen - 1];
real op1 = opstack[opstacklen - 2];
switch (op)
{
case STACKCALC_ADD:
op1 += op2;
break;
case STACKCALC_SUB:
op1 -= op2;
break;
case STACKCALC_MUL:
op1 *= op2;
break;
case STACKCALC_DIV:
op1 /= op2;
break;
} /*switch*/
--opstacklen;
opstack[opstacklen - 1] = op1;
}
break;
default:
bugcheck(false, "invalid operator %d", op);
break;
} /*switch*/
if (done)
break;
} /*for*/
va_end(args);
bugcheck(opstacklen == 1, "expecting exactly one result left on stack");
result = opstack[0];
free(opstack);
return result;
} /*stack_calc*/

--- PyGate Linux v1.5.19
* Origin: Dragon's Lair, PyGate NNTP<>Fido Gate (3:633/10)

On 21/10/2026 22:02, Chris M. Thomasson wrote:

On 10/21/2026 5:17 AM, David Brown wrote:
[...]

*_t intrudes into POSIX.

I don't program for POSIX, so I don't care. The same applies to most
code that is used in connection with FreeRTOS, or LWIP. (Of course
there will be some overlap - bits of code that are intended to run on a microcontroller but tested with code running native on a PC.)

I don't know if the "_t" convention for type identifiers started with
POSIX, but it has certainly far outgrown POSIX. And I think the smart
folks behind POSIX know this, and will not assume that just because they
pick a new type name ending in _t, it will not conflict with some user
code. As C doesn't have namespaces, there is always a risk of
conflicting names - you just have to try to avoid clashes in things you
are likely to see.


--- PyGate Linux v1.5.19
* Origin: Dragon's Lair, PyGate NNTP<>Fido Gate (3:633/10)

Blaine pisze:

fir wrote:

Lawrence D?Oliveiro pisze:

t to end each case-sequence in a switch statement with
a break-statement: put the break at the same indentation level as the
case-clause as well as the switch-expression. That way, you can scan
your eye down a single line f

some time ago i was saying what the proper switch should like
(imo, but im not sure if my conclusions are anough to take is a s proven)

case {} case {}ÿ case {} otherwise {}

its indeed sorta needed becouse case in fact are ifs
(not if-elses)ÿ (so some in fact could write

if {} if {} if {} otherwise {}

its the same)

ÿÿthe problem is youÿ got no group alse
and here this otherwise need to check all ifs
"or" them and use group else for them

this could be written in few ways, but my case case case otherwise
names it
could also do


if {} or if {} or if {} else {}

so either you need logic operators here or predefined constructs like
otherwise (maybe both)

and that should be included not switch wchich is bad imo


other way is to define distionary more as data construct

dict {
'mental'ÿ {/* 1 */}
'reductionists' {/* 2 */}
'suck' {/* 3 */}
}

then you could use

dict('reductionists')

to yeld toÿ /* 2 */

this second one parallels to switch keyword


so c switch mixes them both in bad way..they should be spitet and
upbuild as showed ;c

thats my conclusion as switch topic as far by now ;c

Just start using the switch statement. It's useful in very very very
many cases. You'll get the hang of it right away. Next, it doesn't just
test variable type 'int', also notably 'char', among others.

how do you know i dont use it?


in fact i dont use it its not logical (as roven above) yet looks ugly

(im not using parts of c quite happily especily switch and macros

--- PyGate Linux v1.5.19
* Origin: Dragon's Lair, PyGate NNTP<>Fido Gate (3:633/10)

In article <11bcc4o$jt81$1@dont-email.me>,
David Brown <david.brown@hesbynett.no> wrote:

On 21/10/2026 22:02, Chris M. Thomasson wrote:

On 10/21/2026 5:17 AM, David Brown wrote:
[...]

*_t intrudes into POSIX.

I don't program for POSIX, so I don't care. The same applies to most
code that is used in connection with FreeRTOS, or LWIP. (Of course
there will be some overlap - bits of code that are intended to run on a >microcontroller but tested with code running native on a PC.)

I don't know if the "_t" convention for type identifiers started with
POSIX, but it has certainly far outgrown POSIX. And I think the smart
folks behind POSIX know this, and will not assume that just because they >pick a new type name ending in _t, it will not conflict with some user
code. As C doesn't have namespaces, there is always a risk of
conflicting names - you just have to try to avoid clashes in things you
are likely to see.

It definitely predates POSIX. `typdef` appears to have come
into the language with "Typesetter C", which first shipped in
7th Edition research Unix, and 7th Ed had types ending in `_t`;
so 1979 or thereabouts. For instance, `daddr_t`, `time_t`, and
`caddr_t` to represent disk block addresses, times, and generic
addresses, respectively. Curiously, `size_t` isn't there yet,
and appears to arrive in 3bsd (also 1979, but based on 32/V),
where it is sized (it's just a typedef for `int`). `size_t`
makes it back into Research Unix with the 8th Edition, based
on 4BSD; probably 4.1. It is signed in 8th Ed, and is a typedef
for `long`. My notes put it into AT&T Unix with System V
Release 3, where it is unsigned.

POSIX started in 1984, building on work done by /usr/group, and
the first issue of POSIX was released in 1988.

Anyway, the point is that the `_t` convention predates POSIX
(and ANSI C) by about a decade.

- Dan C.


--- PyGate Linux v1.5.19
* Origin: Dragon's Lair, PyGate NNTP<>Fido Gate (3:633/10)

bart pisze:

On 21/10/2026 21:36, Dan Cross wrote:

In article <11bb47i$889c$1@dont-email.me>, bartÿ <bc@freeuk.com> wrote:

On 21/10/2026 19:38, Dan Cross wrote:

In article <11baur1$63id$1@dont-email.me>, bartÿ <bc@freeuk.com> wrote: >>>

So, now tell me what I've got wrong.

Wow.ÿ You really, truly, have no idea how any of this works.ÿ I
don't even know where to begin.ÿ You just throw around words but
have no idea what they mean in context.

It's breathtaking, really.

And Wow, your reply is exactly the kind I expected!

Of course, you're not going to tell me what API means versus ABI, and
you're not going to answer my question about what I've got wrong.

Honestly?ÿ No, I'm not.ÿ It's clear that if I tried, you would
either not understand, or deliberately ignore it so you could
blindly continue in your self-imposed ignorance.

Because actually you don't know.

Umm.....

This was apparent from things you've said in the past.

You know, it's one thing to be ignorant yourself.ÿ It's quite
another to project that onto others.

I've seen zero evidence that you know anything about the matter. Just bluster.

I have actually wondered what you're doing here, and this appears to be
it: being hostile, patronising, condescending and constantly taking the
contrary view no matter what.

In other words, being a troll.

It's apparent that you really, truly, do not understand why so
many others seem like they are "having a go" at you.ÿ I actually
feel kind of bad for you.

If you don't know this stuff, that would be perfectly fine, not everyone
is into compilers.

But refusing to admit that you mixed up API/ABI and instead gaslighting others into thinking they're the ones in the wrong is unacceptable and childish.

I've looked at the 40 or so posts you've made in the last few days, half
of them were replies to me, all unpleasant exchanges.

This is just persecution, constantly attacking and belittling at the personal level. Maybe you're some sick fuck and and you get a kick out
of it, then you should get help together with JP, that other wonderful person.

i dont know as to dan cross (only read some parts of side discusions
here) but for sure some people here are somewhat trollish - note keith thompson and his sidekicks ;c

but overally clc is quite decent and even this trolls are standable
(mostly)..

maybe its another advantage of writig with mistipes trolls not go into
you way coz they dont understood what you write ;c

clc is decent place coz honestly wide world has overally much worse
level than here imo..especially if some opens co called 'media'..thats terrible thing

--- PyGate Linux v1.5.19
* Origin: Dragon's Lair, PyGate NNTP<>Fido Gate (3:633/10)

On 2026-10-22, David Brown <david.brown@hesbynett.no> wrote:

On 21/10/2026 22:02, Chris M. Thomasson wrote:

On 10/21/2026 5:17 AM, David Brown wrote:
[...]

*_t intrudes into POSIX.

I don't program for POSIX, so I don't care. The same applies to most
code that is used in connection with FreeRTOS, or LWIP. (Of course
there will be some overlap - bits of code that are intended to run on a microcontroller but tested with code running native on a PC.)

I don't know if the "_t" convention for type identifiers started with
POSIX, but it has certainly far outgrown POSIX. And I think the smart
folks behind POSIX know this, and will not assume that just because they pick a new type name ending in _t, it will not conflict with some user
code. As C doesn't have namespaces, there is always a risk of
conflicting names - you just have to try to avoid clashes in things you
are likely to see.

These namespace declarations are really just a "heads up". POSIX
isn't saying, don't have an identifier ending in _t in a namespace
shared by typedefs. Rather, it is saying that new typedefs appearing
in POSIX will be in that namespace.

Consider this argument: whenever POSIX or ISO C introduces a new
public identifier, it's necessarily going to start with "a", or else if
not, then with "b", or else with "c", ... or else with "z"
or perhaps the underscore.

That doesn't mean you stop using identifiers in programming.

"nullptr" is now a keyword, previously a valid identifier not in
any proclaimed reserved namespace. Progrems which used it have
to be changed to work with the newer language.

Avoiding proclaimed namespaces will not protect you from clashes;
only from clashes that would occur in those namespaces.

Some spaces like _t are too attractive to avoid, because they are tied
to an important, popular convention that everyone understands,
and the benefits outweigh the unrealized risk of a future clash.

--
TXR Programming Language: http://nongnu.org/txr
Cygnal: Cygwin Native Application Library: http://kylheku.com/cygnal
Mastodon: @Kazinator@mstdn.ca

--- PyGate Linux v1.5.19
* Origin: Dragon's Lair, PyGate NNTP<>Fido Gate (3:633/10)

On 2026-10-22, Dan Cross <cross@spitfire.i.gajendra.net> wrote:

Anyway, the point is that the `_t` convention predates POSIX
(and ANSI C) by about a decade.

Speaking of caddr_t, that one was spread outside of Unix. I remember
caddr_t cropping up when I was working with Microsoft C on DOS in 1990. ANSI/ISO C and its void * were still new, and caddr_t was one of the conventions for a pointer-to-anything.

--
TXR Programming Language: http://nongnu.org/txr
Cygnal: Cygwin Native Application Library: http://kylheku.com/cygnal
Mastodon: @Kazinator@mstdn.ca

--- PyGate Linux v1.5.19
* Origin: Dragon's Lair, PyGate NNTP<>Fido Gate (3:633/10)

On 22/10/2026 18:54, Kaz Kylheku wrote:

On 2026-10-22, David Brown <david.brown@hesbynett.no> wrote:

On 21/10/2026 22:02, Chris M. Thomasson wrote:

On 10/21/2026 5:17 AM, David Brown wrote:
[...]

*_t intrudes into POSIX.

I don't program for POSIX, so I don't care. The same applies to most
code that is used in connection with FreeRTOS, or LWIP. (Of course
there will be some overlap - bits of code that are intended to run on a
microcontroller but tested with code running native on a PC.)

I don't know if the "_t" convention for type identifiers started with
POSIX, but it has certainly far outgrown POSIX. And I think the smart
folks behind POSIX know this, and will not assume that just because they
pick a new type name ending in _t, it will not conflict with some user
code. As C doesn't have namespaces, there is always a risk of
conflicting names - you just have to try to avoid clashes in things you
are likely to see.

These namespace declarations are really just a "heads up". POSIX
isn't saying, don't have an identifier ending in _t in a namespace
shared by typedefs. Rather, it is saying that new typedefs appearing
in POSIX will be in that namespace.

Consider this argument: whenever POSIX or ISO C introduces a new
public identifier, it's necessarily going to start with "a", or else if
not, then with "b", or else with "c", ... or else with "z"
or perhaps the underscore.

That doesn't mean you stop using identifiers in programming.

"nullptr" is now a keyword, previously a valid identifier not in
any proclaimed reserved namespace. Progrems which used it have
to be changed to work with the newer language.

Avoiding proclaimed namespaces will not protect you from clashes;
only from clashes that would occur in those namespaces.

Some spaces like _t are too attractive to avoid, because they are tied
to an important, popular convention that everyone understands,
and the benefits outweigh the unrealized risk of a future clash.

I agree entirely.


--- PyGate Linux v1.5.19
* Origin: Dragon's Lair, PyGate NNTP<>Fido Gate (3:633/10)

On 10/22/2026 9:54 AM, Kaz Kylheku wrote:

On 2026-10-22, David Brown <david.brown@hesbynett.no> wrote:

On 21/10/2026 22:02, Chris M. Thomasson wrote:

On 10/21/2026 5:17 AM, David Brown wrote:
[...]

*_t intrudes into POSIX.

I don't program for POSIX, so I don't care. The same applies to most
code that is used in connection with FreeRTOS, or LWIP. (Of course
there will be some overlap - bits of code that are intended to run on a
microcontroller but tested with code running native on a PC.)

I don't know if the "_t" convention for type identifiers started with
POSIX, but it has certainly far outgrown POSIX. And I think the smart
folks behind POSIX know this, and will not assume that just because they
pick a new type name ending in _t, it will not conflict with some user
code. As C doesn't have namespaces, there is always a risk of
conflicting names - you just have to try to avoid clashes in things you
are likely to see.

These namespace declarations are really just a "heads up". POSIX
isn't saying, don't have an identifier ending in _t in a namespace
shared by typedefs. Rather, it is saying that new typedefs appearing
in POSIX will be in that namespace.

Consider this argument: whenever POSIX or ISO C introduces a new
public identifier, it's necessarily going to start with "a", or else if
not, then with "b", or else with "c", ... or else with "z"
or perhaps the underscore.

That doesn't mean you stop using identifiers in programming.

"nullptr" is now a keyword, previously a valid identifier not in
any proclaimed reserved namespace. Progrems which used it have
to be changed to work with the newer language.

Avoiding proclaimed namespaces will not protect you from clashes;
only from clashes that would occur in those namespaces.

Some spaces like _t are too attractive to avoid, because they are tied
to an important, popular convention that everyone understands,
and the benefits outweigh the unrealized risk of a future clash.

Touche. How about _this vs this_. I just use self and be done with it.

--- PyGate Linux v1.5.19
* Origin: Dragon's Lair, PyGate NNTP<>Fido Gate (3:633/10)

Kaz Kylheku <046-301-5902@kylheku.com> writes:
[...]

These namespace declarations are really just a "heads up". POSIX
isn't saying, don't have an identifier ending in _t in a namespace
shared by typedefs. Rather, it is saying that new typedefs appearing
in POSIX will be in that namespace.

[...]

No, it says that all conforming applications are required to avoid
symbols ending in "_t".

https://pubs.opengroup.org/onlinepubs/9799919799/xrat/V4_xsh_chap01.html B.2.11.1 Defined Types

The requirement that additional types defined in this section
end in "_t" was prompted by the problem of name space pollution.
It is difficult to define a type (where that type is not one
defined by POSIX.1-2024) in one header file and use it in another
without adding symbols to the name space of the program. To
allow implementors to provide their own types, all conforming
applications are required to avoid symbols ending in "_t",
which permits the implementor to provide additional types.
Because a major use of types is in the definition of structure
members, which can (and in many cases must) be added to the
structures defined in POSIX.1-2024, the need for additional
types is compelling.

Of course you don't have to avoid defining symbols ending with "_t"
if you don't want to, but if you do so you don't have a "conforming application" as far as POSIX is concerned.

It is, of course, an imperfect solution.

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

--- PyGate Linux v1.5.19
* Origin: Dragon's Lair, PyGate NNTP<>Fido Gate (3:633/10)

Keith Thompson wrote:

Kaz Kylheku <046-301-5902@kylheku.com> writes:
[...]

These namespace declarations are really just a "heads up". POSIX
isn't saying, don't have an identifier ending in _t in a namespace
shared by typedefs. Rather, it is saying that new typedefs appearing
in POSIX will be in that namespace.

[...]

No, it says that all conforming applications are required to avoid
symbols ending in "_t".

https://pubs.opengroup.org/onlinepubs/9799919799/xrat/V4_xsh_chap01.html B.2.11.1 Defined Types

The requirement that additional types defined in this section
end in "_t" was prompted by the problem of name space pollution.
It is difficult to define a type (where that type is not one
defined by POSIX.1-2024) in one header file and use it in another
without adding symbols to the name space of the program. To
allow implementors to provide their own types, all conforming
applications are required to avoid symbols ending in "_t",
which permits the implementor to provide additional types.
Because a major use of types is in the definition of structure
members, which can (and in many cases must) be added to the
structures defined in POSIX.1-2024, the need for additional
types is compelling.

Of course you don't have to avoid defining symbols ending with "_t"
if you don't want to, but if you do so you don't have a "conforming application" as far as POSIX is concerned.

It is, of course, an imperfect solution.

Aside from having to type 'break' for each 'case', do you have a
legitimate case?

--
Can you strip away so we may start again?
"There?s a switch and they don't
seem authentic or themselves. It
feels like I?m an unnecessary
body and it?s a waste of time to
even be there." -- Grim, playful Blaine.

--- PyGate Linux v1.5.19
* Origin: Dragon's Lair, PyGate NNTP<>Fido Gate (3:633/10)

On 2026-10-22, Keith Thompson <Keith.S.Thompson+u@gmail.com> wrote:

Kaz Kylheku <046-301-5902@kylheku.com> writes:
[...]

These namespace declarations are really just a "heads up". POSIX
isn't saying, don't have an identifier ending in _t in a namespace
shared by typedefs. Rather, it is saying that new typedefs appearing
in POSIX will be in that namespace.

[...]

No, it says that all conforming applications are required to avoid
symbols ending in "_t".

That concept is needed in order to make it the application's fault
when it suddenly fails to build because it's using foo_t, and
POSIX decides to introduced that into <sys/types.h>.

If you use _t, a clash may happen, and if it does, then since POSIX told-you-so, it must be your program that is nonconforming, and not the
POSIX has a defect or the implementation is nonconforming.

Of course you don't have to avoid defining symbols ending with "_t"
if you don't want to, but if you do so you don't have a "conforming application" as far as POSIX is concerned.

This is okay if you have a grip on the nonconformances in the
application. You know where they are and have a way to be informed when
they turn into real problems and a plan for that situation.

Remember, a program that uses nullptr as a variable name was once
conforming. Through no change in the program whatsoever, it became nonconforming. Playing the conformance game in this area is largely
a fool's errand.

--
TXR Programming Language: http://nongnu.org/txr
Cygnal: Cygwin Native Application Library: http://kylheku.com/cygnal
Mastodon: @Kazinator@mstdn.ca

--- PyGate Linux v1.5.19
* Origin: Dragon's Lair, PyGate NNTP<>Fido Gate (3:633/10)

On 22/10/2026 21:46, Chris M. Thomasson wrote:

On 10/22/2026 9:54 AM, Kaz Kylheku wrote:

On 2026-10-22, David Brown <david.brown@hesbynett.no> wrote:

On 21/10/2026 22:02, Chris M. Thomasson wrote:

On 10/21/2026 5:17 AM, David Brown wrote:
[...]

*_t intrudes into POSIX.

I don't program for POSIX, so I don't care.ÿ The same applies to most
code that is used in connection with FreeRTOS, or LWIP.ÿ (Of course
there will be some overlap - bits of code that are intended to run on a
microcontroller but tested with code running native on a PC.)

Avoiding proclaimed namespaces will not protect you from clashes;
only from clashes that would occur in those namespaces.

Some spaces like _t are too attractive to avoid, because they are tied
to an important, popular convention that everyone understands,
and the benefits outweigh the unrealized risk of a future clash.

Touche. How about _this vs this_. I just use self and be done with it.

Imagine, just for a moment, that the rest of us are not privy to the
jumble of thoughts and ideas that jump around in your head. I don't
have the context of what you are thinking about. So I have no idea what
you mean by this.

Instead of posting random out-of-context snippets of thought, either
write posts that say what you are talking about, or don't bother. (And
do /not/ imagine that posting reams of unconnected code is a useful alternative.)

If you are trying to say something about avoiding C++ keywords when
picking identifiers in C coding, say that. If you are trying to say
something about naming conventions for C++ class members, feel free to
talk about that too - in comp.lang.c++. If you are trying to say
something else, say it. Or drop it, if you prefer.


--- PyGate Linux v1.5.19
* Origin: Dragon's Lair, PyGate NNTP<>Fido Gate (3:633/10)

Kaz Kylheku <046-301-5902@kylheku.com> writes:

On 2026-10-22, Keith Thompson <Keith.S.Thompson+u@gmail.com> wrote:

Kaz Kylheku <046-301-5902@kylheku.com> writes:
[...]

These namespace declarations are really just a "heads up". POSIX
isn't saying, don't have an identifier ending in _t in a namespace
shared by typedefs. Rather, it is saying that new typedefs appearing
in POSIX will be in that namespace.

[...]

No, it says that all conforming applications are required to avoid
symbols ending in "_t".

That concept is needed in order to make it the application's fault
when it suddenly fails to build because it's using foo_t, and
POSIX decides to introduced that into <sys/types.h>.

If you use _t, a clash may happen, and if it does, then since POSIX told-you-so, it must be your program that is nonconforming, and not the
POSIX has a defect or the implementation is nonconforming.

Of course you don't have to avoid defining symbols ending with "_t"
if you don't want to, but if you do so you don't have a "conforming
application" as far as POSIX is concerned.

This is okay if you have a grip on the nonconformances in the
application. You know where they are and have a way to be informed when
they turn into real problems and a plan for that situation.

Remember, a program that uses nullptr as a variable name was once
conforming. Through no change in the program whatsoever, it became nonconforming. Playing the conformance game in this area is largely
a fool's errand.

Yes, I understand all that. I was commenting on what POSIX actually
says.

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

--- PyGate Linux v1.5.19
* Origin: Dragon's Lair, PyGate NNTP<>Fido Gate (3:633/10)

On 10/23/2026 12:37 AM, David Brown wrote:

On 22/10/2026 21:46, Chris M. Thomasson wrote:

On 10/22/2026 9:54 AM, Kaz Kylheku wrote:

On 2026-10-22, David Brown <david.brown@hesbynett.no> wrote:

On 21/10/2026 22:02, Chris M. Thomasson wrote:

On 10/21/2026 5:17 AM, David Brown wrote:
[...]

*_t intrudes into POSIX.

I don't program for POSIX, so I don't care.ÿ The same applies to most
code that is used in connection with FreeRTOS, or LWIP.ÿ (Of course
there will be some overlap - bits of code that are intended to run on a >>>> microcontroller but tested with code running native on a PC.)

Avoiding proclaimed namespaces will not protect you from clashes;
only from clashes that would occur in those namespaces.

Some spaces like _t are too attractive to avoid, because they are tied
to an important, popular convention that everyone understands,
and the benefits outweigh the unrealized risk of a future clash.

Touche. How about _this vs this_. I just use self and be done with it.

Imagine, just for a moment, that the rest of us are not privy to the
jumble of thoughts and ideas that jump around in your head.ÿ I don't
have the context of what you are thinking about.ÿ So I have no idea what
you mean by this.

Instead of posting random out-of-context snippets of thought, either
write posts that say what you are talking about, or don't bother.ÿ (And
do /not/ imagine that posting reams of unconnected code is a useful alternative.)

If you are trying to say something about avoiding C++ keywords when
picking identifiers in C coding, say that.ÿ If you are trying to say something about naming conventions for C++ class members, feel free to
talk about that too - in comp.lang.c++.ÿ If you are trying to say
something else, say it.ÿ Or drop it, if you prefer.

Or, Well,

_this

vs

this_

Are they both legal?

I like self.

void foo(struct foo* const self);

vs

void foo(struct foo* const _this);
void foo(struct foo* const this);
void foo(struct foo* const this_);

? For some reason I do not want to use this in C.



--- PyGate Linux v1.5.19
* Origin: Dragon's Lair, PyGate NNTP<>Fido Gate (3:633/10)

On Fri, 23 Oct 2026 14:21:15 -0700, Chris M. Thomasson wrote:

I like self.

void foo(struct foo* const self);

The trouble with a fixed name is, how do you refer to the instance of
an outer class?

--- PyGate Linux v1.5.19
* Origin: Dragon's Lair, PyGate NNTP<>Fido Gate (3:633/10)

On 10/23/2026 3:40 PM, Lawrence D?Oliveiro wrote:

On Fri, 23 Oct 2026 14:21:15 -0700, Chris M. Thomasson wrote:

I like self.

void foo(struct foo* const self);

The trouble with a fixed name is, how do you refer to the instance of
an outer class?

Well, self can be internal to the API logic. See, user code does not
need to care how self is organized. It just needs to allocate n bytes
aligned on a boundary and call into the API to init it. calling a
deinit, or destroy whatever after its done. So the caller manages the
main memory. After its done it can make the memory go out of scope or deallocate it, free or whatever.

So, internal to the lib, self->foo is there.

--- PyGate Linux v1.5.19
* Origin: Dragon's Lair, PyGate NNTP<>Fido Gate (3:633/10)

On 23/10/2026 23:21, Chris M. Thomasson wrote:

On 10/23/2026 12:37 AM, David Brown wrote:

On 22/10/2026 21:46, Chris M. Thomasson wrote:

On 10/22/2026 9:54 AM, Kaz Kylheku wrote:

On 2026-10-22, David Brown <david.brown@hesbynett.no> wrote:

On 21/10/2026 22:02, Chris M. Thomasson wrote:

On 10/21/2026 5:17 AM, David Brown wrote:
[...]

*_t intrudes into POSIX.

I don't program for POSIX, so I don't care.ÿ The same applies to most >>>>> code that is used in connection with FreeRTOS, or LWIP.ÿ (Of course
there will be some overlap - bits of code that are intended to run
on a
microcontroller but tested with code running native on a PC.)

Avoiding proclaimed namespaces will not protect you from clashes;
only from clashes that would occur in those namespaces.

Some spaces like _t are too attractive to avoid, because they are tied >>>> to an important, popular convention that everyone understands,
and the benefits outweigh the unrealized risk of a future clash.

Touche. How about _this vs this_. I just use self and be done with it.

Imagine, just for a moment, that the rest of us are not privy to the
jumble of thoughts and ideas that jump around in your head.ÿ I don't
have the context of what you are thinking about.ÿ So I have no idea
what you mean by this.

Instead of posting random out-of-context snippets of thought, either
write posts that say what you are talking about, or don't bother.
(And do /not/ imagine that posting reams of unconnected code is a
useful alternative.)

If you are trying to say something about avoiding C++ keywords when
picking identifiers in C coding, say that.ÿ If you are trying to say
something about naming conventions for C++ class members, feel free to
talk about that too - in comp.lang.c++.ÿ If you are trying to say
something else, say it.ÿ Or drop it, if you prefer.

Or, Well,

_this

vs

this_

Are they both legal?

What do you mean, "legal" ? Identifiers in C can start with any letter (including most Unicode "letters") or underscore, or any other implementation-defined characters. Subsequent characters can be any of
these or a normal digit from the basic source character set.

The only identifiers you may not use are ones that match keywords.

There are various patterns that are "reserved", depending on header
usage, but using them is still "legal". The main ones to avoid are identifiers starting with two underscores, or one underscore and a
capital letter.

I like self.

void foo(struct foo* const self);

vs

void foo(struct foo* const _this);
void foo(struct foo* const this);
void foo(struct foo* const this_);

? For some reason I do not want to use this in C.

Use whichever you like. I would personally avoid using an identifier in
C that matches a keyword (or "contextual keyword") in C++, to make it
easier to re-use the same code in C++. But you don't have to do the same.


--- PyGate Linux v1.5.19
* Origin: Dragon's Lair, PyGate NNTP<>Fido Gate (3:633/10)

On Fri, 23 Oct 2026 18:33:56 -0700, Chris M. Thomasson wrote:

On 10/23/2026 3:40 PM, Lawrence D?Oliveiro wrote:

The trouble with a fixed name is, how do you refer to the instance
of an outer class?

Well, self can be internal to the API logic.

If ?self? refers to the current instance of the innermost class, how
do you refer to an instance of an outer class?

--- PyGate Linux v1.5.19
* Origin: Dragon's Lair, PyGate NNTP<>Fido Gate (3:633/10)

On 2026-10-25 00:26, Lawrence D?Oliveiro wrote:

On Fri, 23 Oct 2026 18:33:56 -0700, Chris M. Thomasson wrote:

On 10/23/2026 3:40 PM, Lawrence D?Oliveiro wrote:

The trouble with a fixed name is, how do you refer to the instance
of an outer class?

Well, self can be internal to the API logic.

If ?self? refers to the current instance of the innermost class, how
do you refer to an instance of an outer class?

I'm a bit confused about the intention of this sub-thread in CLC.

Since you have already been (at least implicitly) referring to
other languages (by mention of 'self' and 'this') I'd answer the
question that (in principal) a language could qualify the access;
for example, Simula has "THIS DerivedClass" or "THIS BaseClass",
or whatever class in the actual class-path is visible. We could
also access attributes that need an access qualification by the
'QUA' keyword to disambiguate names common in base and derived
classes.

Still curious about the "plan" (for "C") behind, why asking this.

Janis


--- PyGate Linux v1.5.19
* Origin: Dragon's Lair, PyGate NNTP<>Fido Gate (3:633/10)

Lawrence D?Oliveiro <ldo@nz.invalid> writes:

On Fri, 23 Oct 2026 18:33:56 -0700, Chris M. Thomasson wrote:

On 10/23/2026 3:40 PM, Lawrence D?Oliveiro wrote:

The trouble with a fixed name is, how do you refer to the instance
of an outer class?

Well, self can be internal to the API logic.

If ?self? refers to the current instance of the innermost class, how
do you refer to an instance of an outer class?

What's a "class"?

There are ways to implement or simulate classes and inheritance in C.
Without knowing how that's being done, it's not very meaningful to ask
how to refer to an instance of an outer class.

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

--- PyGate Linux v1.5.19
* Origin: Dragon's Lair, PyGate NNTP<>Fido Gate (3:633/10)