Lockdown mode allows one to optionally disable 2g, maybe it is also the default there. One can turn 2g back on in said mode if desired.

As to 3g, it is largely switched off here, and I understand most of the rest of the world is also disabling it.

However it does not remove images from messages, it just disables certain automatic helpers - e.g. link previews etc.

One can still send photos, etc without any issue.

This doesn’t mitigate the issue that a malicious base station poses by downgrading a phone.

It doesn’t matter what the network supports. It matters what the phone supports

An interesting theory, however I rather suspect it is basically because Limbo had a similar concept for pseudo-enums.

I allowed (e.g.) a syntax like:

    M0, M1, M2, M3, M4: con (1<<iota);

That was taken from one of the Limbo papers.

Actually lots is still on C89.

I'm trying to drag one program at $employer up to C99 (plus C11 _Generic), so I can then subsequently drag it to the bits of C23 which GCC 13 supports.

This all takes times, and having to convince colleagues during code reviews.

What C23 has done is authorise some of the extensions which GCC has had for some time as legitimate things (typeof, etc).

However the ability to adopt is also limited by what third party linters in use at $employer may also support.

Nah - more that a lot of commercial code is written in it; and it doesn't make sense to replace (or rewrite) it at this time.

For example, I'm maintaining some 20 year old C code, which the employer adopted around 10 years ago. It will likely stay in use at least until the current product is replaced, whenever that may be.

Let me rephrase that: I feel myself addressed by "some people will never move beyond C, no matter what" and I prefer C over C++, because it is a much simpler language. Each time I am leaving the cozy world of C and write C++ I am annoyed and miss things.

Well his "Normal Functions" (benchmarks/closures/source/normal_functions.cpp in his repo) looks quite similar to what I had with my GNU nested functions using a stand in "wide pointer", and hence no generated trampoline.

(https://news.ycombinator.com/item?id=46243298)

Which rather suggests to me that such a scheme, but generated by the compiler, should have a similar performance to said "Normal Functions" and hence similar to his preferred lambda form.

Since his benchmark environment is so unwieldy, I may have a go at extracting those two code sets to a standalone environment, and measure them so see...

So here are my preliminary benchmarks with my own implementation on an AMD EPYC 9334 32-Core processo. I need to double checks things - so take this with a grain of salt for now. Time is in seconds for 100000 iterations of manorboy(10). So far, the only implementation which clearly sucks is std::function<>. Even trampolines are suprisingly good (but I can imagine that they are much worse on other CPUs / architectures)

  xgcc (GCC) 16.0.0 20260103 (experimental)
  1.50 gcc -ftrampoline-impl=stack -Wl,-no-warn-execstack
  1.11 gcc -ftrampoline-impl=stack -Wl,-no-warn-execstack -DREFARG
  7.21 gcc -ftrampoline-impl=heap
  7.34 gcc -ftrampoline-impl=heap -DREFARG
  0.93 gcc -DWIDEPTR
  1.38 gcc -DWIDEPTR -DREFARG
  1.40 gcc -DDIRECT
  1.05 gcc -xc++ -std=c++26 -DFUNCREF -DDEDUCING
  19.68 gcc -xc++ -std=c++26 -DDEDUCING
  20.73 gcc -xc++ -std=c++26
  6.31 gcc -xc++ -std=c++26 -DDEDUCING -DREFARG
  6.31 gcc -xc++ -std=c++26 -DREFARG
  Debian clang version 16.0.6 (15~deb12u1)
  21.11 clang -xc++
  6.16 clang -xc++ -DREFARG
  1.66 clang -fblocks
  1.70 clang -fblocks -DREFARG

Here some more bechmarking: https://codeberg.org/uecker/nested-functions-benchmarking

Ah - thanks. I'll have a play with some of my systems, and see what it shows.

Remember that English also suffers from digraphs.

e.g. ch, th, sh, wr, oo; etc

See https://en.wikipedia.org/wiki/Digraph_(orthography)#English

That page lists 15 such over and above the doubled letters.

The Latin alphabet is also a poor match for English. We make do.

Yes.

All through middle and high school, so for 7 years from around 10 to 16. It did become one eventually in primary school, so probably the last 2 or 3 years there.

> In 1979 the “standard practice in C of passing a large struct to a function” wasn’t just not standard practice, it didn’t exist!

Yes it did exist. It just wasn't mentioned in the original K&R book.

See this page of a memo from November 78, passing and returning structs was supported. When I learn C on a Unix system, there was a copy of this memo in the printed papers section.

https://www.nokia.com/bell-labs/about/dennis-m-ritchie/cchan...

OK: "It didn't exist in the language as published and defined."

One quibble I have with the piece is the quotes.

        There is a bark of an Englifh tree, which I have found by experience to be a powerful aftringent, and very efficacious in curing aguifh [agues] and intermitting diforders.


        My curiofity prompted me to look into the difpenfatories and books of botany, and examine what they faid concerning it; but there it exifted only by name. I could not find, that it hath, or ever had, any place in pharmacy, or any fuch qualities, as I fufpected afcribed to it by the botanifts.

If (as it appears) the author was unable to type in a long-S, he could at least have used a normal one, making the text more readable.

i.e. Englifh => English; aftringent => astringent; aguifh => aguish; diforders => disorders; curiofity => curiosity; difpenfatories => dispensatories; faid => said; exifted => existed; fuch => such; fufpected afcribed => suspected ascribed; botanifts => botanists