I can't find that Burton wrote an autobiography, though there seem to be several well-regarded biographies - have you a link to such a thing?

It's my belief all that could exist is heavily bowdlerised because his wife was a proselytizing christian and burnt his diaries having declared he made a deathbed act of contrition recognising god. I don't think Burton's friends believed it for a moment, apparently she did a trick like cutting a vein to show blood still flowed, claimed she heard him speak and some friendly prelate agreed to the shenanigans in a higher cause. (Burton's abjuration of faith was obviously "political", for the religous fervour of the day)

It beggars belief a man who was into data collecting about prostitution and homosexuality, and who helped publish extensive pornographic works to a cogniscenti married a prude, and came to jesus at the last. But the thing is, he DID marry a prude. And he DID publish works which at the time were beyond the pale, and he DID explore the darker corners of british army life in the middle east and India. The only conjecture here is the deathbed confession of faith.

He wrote memoirs, for sure. "Personal Narrative of a Pilgrimage to Al-Medinah and Meccah" I mean, thats not objective writing by title-intent, is it.

No, I think I'm mistaken (and confusing it a little bit with the autobiography of Aleister Crowley, who was also something of an explorer and which I read around the same time - it is also interesting and untrustworthy but not as good overall IMO). I don't recall if it was the Farwell, Hastings, or Rice, unfortunately.

you can access it using extern from anywhere:

    // a.c
    int f( int x ) {
        return x + 1;
    }

    // b.c
    extern int f(int x );

    int main() {
        int y = f(41);
    }

but if f() had been defined as static, you couldn't do this.

"private function" doesn't mean "you can't know about this", it means "you shouldn't rely on this as a stable interface to my code".

Just because you can use the information you have to call a given function, doesn't mean you aren't violating an interface.

my point was that f() had been defined static then you can't access it from outside the translation unit it is defined in - in other words, it is "private". i'm afraid i'm unclear what your point is.

`static inline` is definitely not private. See https://github.com/axboe/liburing/blob/master/src/include/li... , for a practical example.

It's going to become private, but its part of your side of the interface, not of the other side. The ABI boundary is between that `static inline` function and the library, not between that function and your code.

Both points are related and matter.

For most purposes, not being able to access something, and being able to access something not officially in an interface, where doing so introduces an unpredictable breaking dependency, the practical result is the same: You can't (actually/sensibly) do it.

Then why not define "something" as static, which makes the compiler and linker guarantee that you can't do it?

What if I want to internally access it from multiple compilation units, but not necessarily encourage downstream users from using it? This is really common.

I don't see what you're getting at with respect to writing bindings.

The whole point of using "static" in that way is to prevent people from using it outside of the file.

If you need to call a static function (inline or otherwise) from outside of the compilation unit to use the API, then it's a bug in the API, not a problem with static.

I agree with you about pre-processor macros, though.

Here is a use case. I have a function that takes variable parameters, so there is no formal type control:

    int Foo(int a, ...);

But in fact the types are restricted depending on a call type, set by 'a'. So I could add a wrapper for a specific variant:

    static inline FooVar1(char b, long c)
    {
        return Foo(FOO_VAR_1, b, c);
    }

All the wrapper does is adds a bit of type control during compilation, otherwise it must be just a function call to 'Foo'. It is like a supermacro. It does make sense to put that into 'static inline' in a header.

Then what the FFI needs to target is `int Foo(int a, ...);`. FooVar1 is just a convenience method for the C language binding.

That is not an option - it may be layers on layers of them and force you to recreate half the library and force you to have to redo subsequent version updates in your code. Then a shim is the preferred solution. But anything that requires a C compiler for FFI is something that won't make anyone happy. Hence my claim that it really is something that needs fixing on the language or linker level.

But FooVar1 isn't part of the library, that's the point. Sure, the library developer could choose to make it a part, but he explicitly choose to not make it a part of the library. Hence, it is also nothing that needs fixing, because it is already possible to make the interface boundary somewhere else, people just choose to do it this way. As far as the language and the linker is concerned FooVar1 is part of your code, not part of the library.

If the language provides nice features to libraries for C language users by sabotaging the library for use outside the language, then this is absolutely a problem on the language side.

The library interface says to do X call `Foo(FOO_VAR_1, b, c)`. That is what you need to somehow call from another language using FFI. In addition it also has an example wrapper for convenience. You can choose to also include that example as part of your implementation in another language, but you don't need to. I fail to see how that is sabotaging.

It also does not have to do anything with the language, because it IS possible to have FooVar1 as part of the interface. The library developer just didn't want that, likely because they do not want tons of slightly different functions in the interface that they would need to maintain, when they already exposed that functionality.

EDIT:

Concerning your earlier complaint, that you would need to

> have to redo subsequent version updates in your code.

, such a change would be ABI-incompatible anyway and demand a change in the major version number of the library. Neither your FFI, nor any program even when written in C, is going to work anymore. The latter, would just randomly crash, not sure about the former.

Note, that you also see here, where the real interface is. A change to Foo itself, would break programs written in C as well as your FFI, while a change to FooVar1 wouldn't matter at all. Both C programs and your FFI will continue to run just fine without any changes.

> likely because they do not want tons of slightly different functions

No. They do it because it avoids the overhead of dynamic dispatch. Nothing else.

So when I've seen these in reality in real library interfaces they have not been 'example wrappers'. They are real intended usage of the API, and in some cases the lib authors recognize that it is a problem and even provide ways to build it without the issues - either by compile time flag or always outputting two variants of the .so. The former moves the question to the distro - should they provide the version optimized for C or the one optimized for other languages? In the case of the latter it obviously creates a situation where the vast majority of both .so-s are duplicated.

As an example of the compile flag, there is libpipewire. As an example of providing two versions of the .so, there is liburing.

So no, this is clearly something the language ecosystem lacks a good answer to. There is currently no way to make everyone happy.

> such a change would be ABI-incompatible anyway

True, but the C based ones can at least simply rebuild and the problem would go away.

Modern libraries consistently use `static inline`, to avoid the overhead of dynamic dispatch. Just take a look at liburing, and the client libraries for pipewire and wayland. All of them have `static inline` all over the place, for methods that are definitely intended to be called.

i think you replied to the wrong comment

Be like the Romans - make them all straight lines :-)

Of course the Romans didn't give a shit who's property rights they might be violating. I live in Lincolnshire UK, where Roman roads are still used. The last one that got changed was years ago when they had to put a kink in Ermine Street (now the A15) at RAF Scampton when they extended the runway to accommodate Vulcan bombers.

The romans did care about property lines! Romes’ second aqueduct was held up when land owner Crassus refused to give up private land for its construction. Check out the article for a fascinating read: https://en.wikipedia.org/wiki/Roman_aqueduct

What an ugly attitude for the landowner to have held. There should be a word for that.

In my area, streets are often church tower to church tower. From the middle ages. You can nowadays drive these streets and the middle line indicators align perfectly with the church tower showing up. I think the church /church based government share that property right understanding of the Romans :)

naming is hard.

my advice to junior programmers after i see them agonising over a name - "just call it x or foo for now, you are going to change it later anyway"

“It might be hard, but don’t let that stop you from making it worse” :)

Speaking as someone with over 40 years paid programming experience, I've never understood this "flow" thing. I typically do about half an hours typing, get up and walk around, mooch over to colleague and yack bit, or go to the coffee machine, or just think a bit and then go back to the keyboard.

Never used headphones - if the environment is too loud, make it quieter. I once moved into a new office area that had a dot-matrix printer that "logged", in the worst sense of the word (how could you find any access on such a giant printout), every door open/close in the block. It was beyond annoying (ever heard a DM printer? only thing worse is a daisy wheel) so I simply unplugged it, took out the ink ribbon and twisted off the print head. It was never replaced, because as is very often the case nobody ever used the "reports" it produced.

Half an hour of typing would be above average attention span for the youth these days. That's pretty much how Pomodoro Timers start out for people who can't focus at all.

>if the environment is too loud, make it quieter.

we shifted to open office setups over the decades. There may not even be anyway to make things "quieter" externally.

But why does it "feel good", if in fact it does?

I tried writing a small utility library using Windows Copilot, just for some experience with the tach (OK, not the highest tech, but I am 73 this year) and found it mildly impressive, but quite slow compared to what I would have done myself to get some quality out of it. It didn't make me feel good, particularly.

Isn't this like turboprops (already very efficient) with bigger propellors? I couldn't tell from the article, but quite possibly missed something.

This website has some nice explanations and GIFs: https://s2.smu.edu/propulsion/Pages/variations.htm

So the "open rotor" engine is actually a propfan engine?

Essentially yes, different engine companies have used different nomenclature over time. It seems that the "open rotor" terminology is being used to emphasize the improvements which have been made to blade design, noise, and general efficiency.

The inner nerd in me is so satisfied. Thanks for the link.

That website it gold!

I think it is the stators fixed to the engine nacelle, judging by the article image.

People posting Excel formulae?

I think I remember hacking some of the copy-protection out of a version of Tetris using the Borland debugger. I definitely patched mouse support into a Chris Crawford "Battle of the Bulge" game using it (for my rather tricky platform). That was a good debugger, and probably the last one I have used much - prefer logging/printing for stuff I write myself.

I remember my Dragon 32 (6809, Color Computer clone) had a dongle you plugged into the joystick port to protect a really crap game - Jumping Knights? I never tried to defeat it.

That's an episode from "Thunderbirds".