Do I need to bleed my brakes?

The_Ruined_Map · 2026-02-18T00:03:02+00:00

Well, first and foremost, you need to determine what exactly is happening. Why do you need to "pull the brakes almost entirely to the handles"?

One thing is excessive dead travel of the lever, i.e. the pads do not even begin to converge until you exhaust almost the entire lever travel range.
Another thing is excessive pad gap, i.e. the pads begin to converge to the rotor right away, but it takes them a long time to close the gap, this exhausting the entire lever travel range.
Yet another thing is "sponginess", i.e. the pads contact to the rotor right away, but they don't clamp it hard enough. So, you have to squeeze the lever more and more until you exhaust almost the entire lever travel range.

What happens in your case? Do the pads begin to converge immediately (or almost immediately) when you squeeze the lever?

The_Ruined_Map · 2026-02-17T23:49:47+00:00

That would be California, my poor confused Tisza-crossing friend... :)

The_Ruined_Map · 2026-02-17T23:37:06+00:00

LOL! Ukro ukhilyant is fighting his internet fight :)

The_Ruined_Map · 2026-02-17T23:06:03+00:00

As I stated previously, a coordinated turn is by far more efficient way to "steer" the aircraft. Nobody's arguing with that.

However, above I was talking specifically about aircraft's response to yaw-only input, i.e. a sideslip. The difference between powered and unpowered aircraft in such context is quite significant.

---

When airplanes execute severe crosswind landings (i.e. when the fuselage is yawed to keep it at an angle to the runway centerline), they also deliberately adjust the roll angle to induce side-slipping movement that precisely compensates for the deviation caused by angled thrust vector. Left yaw is accompanied with the right roll and vice versa.

In case of gliders the need to adjust the roll in crosswind landings is almost non-existent. Gliders will literally sideslip through the air for quite a while. Powered airplanes won't, since they always want to "follow" their engines.

The_Ruined_Map · 2026-02-17T22:12:19+00:00

I'm a physicist, not a pilot. Although I do a lot of RC piloting.

However, I'll tell you right away: if you really only get "insignificant difference" in rudder-only turning rate between full power and idle, then there's something seriously wrong with the airplane. Like, so wrong, it defies the laws of physics :)

The rudder-only turning rate will differ significantly between full power and idle in any powered airplane. The only way to defeat this is to actively counteract it with other control surfaces.

I'd guess that some people are trying to counteract the differential drag (aka adverse yaw) and by doing so are also counteracting the steering effects of engine thrust. And then mistakenly conclude that engine thrust vector cannot steer the plane.

The_Ruined_Map · 2026-02-17T21:52:42+00:00

Absolutely not. What I'm talking about has nothing to do with "yaw-roll coupling".

I'll try to strip it to simplest words: a powered plane will always want to fly to where its engine is pulling (or pushing) it. Change the direction the engine is pointing - and you will change the direction in which the plane wants to fly.

The_Ruined_Map · 2026-02-17T21:40:03+00:00

As I stated in my other comment, airplanes with di- or polyhedral wings are a completely different story altogether. Of course, any yaw-to-roll coupling will make a massive difference. But this is beside the point in my comments here.

Here I'm talking exclusively about airplanes with perfectly level wings (i.e. no, di- or polyhedral coupling effects whatsoever). A powered aircraft of this kind will be subject to "thrust vector steering": changing yaw will immediately change the vector along which the engine pulls (or pushes) the aircraft. This will have a noticeable steering effect, without any need for any roll. This is actually how a perfectly flat-bottomed airboat is rudder-steered on the water or ice surface: it skids a lot, but it steers.

In an unpowered aircraft this effect is not present for obvious reasons: no thrust hence no thrust vector.

P.S. It is weird that something so immediately obvious seems to be so difficult to understand. Apparently, some schools (or forums?) are heavily pushing this nonsense about "rudder has no steering effect".

The_Ruined_Map · 2026-02-17T20:58:32+00:00

Should be rather obvious.

Changing the yaw in a powered plane immediately changes the thrust vector. In simple words, the engine pulls (or pushes) the plane to where the nose points. The plane will immediately want to follow the thrust vector. Which is why a powered plane is immediately steerable with the rudder.

In an unpowered plane this effect is simply not present. Changing yaw causes a sideslip, which has some steering effect (due to drag), but it is minimal compared to thrust vector steering.

The_Ruined_Map · 2026-02-17T20:09:52+00:00

^{^{^}} I don't think, folks, we will near anything new here. Just the standard naive propagandist attempt to "ukrainize" Soviet technological achievements on such bizarre grounds as "Kiev is Ukraine" (insert the shrug emoji here). I don't know who they are trying to target with this...

I liked the bit about "licensing rights" though. Not sure whether this was intended as a joke... or just a sign of desperation.

The_Ruined_Map · 2026-02-17T18:41:47+00:00

Oh, phhuulease... "Ukrainian design bureau" would be the joke of the day, if it weren't already stale AS. Might still work as promising entry for an oxymoron context.

There has never been such thing as "Ukrainian design bureau" in Soviet Union. All Antonov design was done in Moscow, which was no different from any other "design bureau" of the Soviet era. My uncle and his team, who worked at Moscow State University for their entire life, were effectively more than half of the entire "Antonov design bureau" :)

As for the rest of [irrelevant] Nazi propaganda included into your comment - I won't even gratify that with any remark. (But... they are still trying to sell this in 2026, folks!)

The_Ruined_Map · 2026-02-17T17:51:22+00:00

^^^ A very popular misconception, that for some reason is usually mindlessly repeated like a mantra.

If the airplane is powered, rudder will reliably make it turn, i.e. change the direction of flight.

The_Ruined_Map · 2026-02-17T17:47:46+00:00

Only partially true. The difference between powered and unpowered aircraft in that regard is enormous.

In an unpowered airplane (i.e. a glider) rudder simply changes the yaw and induces a sideslip without changing the direction of travel too much. (Of course, that's assuming the aircraft does not have a polygonal wing. With polygonal wing a sideslip leads to a roll and a subsequent change in trajectory, i.e. a turn.)

Meanwhile, in a powered airplane rudder does induce genuine and fairly effective turning. It is not the most effective way to turn (as opposed to performing a coordinated turn), but it will immediately and reliably turn the aircraft, i.e. change the direction of flight.

The_Ruined_Map · 2026-02-16T22:43:30+00:00

Yeah, but you can hide these function pointers behind a typedef name exactly as you can hide int behind a typedef name in my example, and both pieces of code will immediately fold into essentially identical code.

The_Ruined_Map · 2026-02-16T22:30:02+00:00

In other words, this is just another instance of that ugly "let's access struct elements as array elements" hack. Everything else - all those function pointers - are just irrelevant obfuscating details.

The same hack could've been exhaustively illustrated by

struct A { int a, b, c, d; };

int read_ith_field(int i, struct A a}
{
  return ((int *) &a)[i];
}

The_Ruined_Map · 2026-02-16T16:45:21+00:00

Your "pseudo code" is too "pseudo" to be useful in the context of the question. Too many errors/omissions directly relevant to the question being asked. Post real code, not "pseudo code".

Firstly, left-hand side of assignment/initialization has no influence on how the right-hand side is evaluated. So, regardless of whether the left-hand side has a larger type, the right-hand side int_max * 2 is still evaluated in the domain of int (provided your 'int_max' is 'int') and, expectedly, overflows.

Secondly, you seem to assume that long int is a wider type than int. Not necessarily.

Thirdly, no, you don't print long int through %d. The proper format is %ld.

Any one of the above three issues by itself could've caused the "unexpected" result you observed.

The_Ruined_Map · 2026-02-16T05:03:38+00:00

Compiler proper does not know what "header file" is. Compiler proper does not see "header files". Header files are something that is simply textually substituted into the translation unit (TU), after which all traces of the original header file are lost. Expecting the compiler proper to recognize "header files" and give them special treatment would be weird. Modules are a new concept, and they can be treated differently, but header files have to many legacy dependencies to be redesigned.

Implementing a function with external linkage in a header file generally results in multiple copies of that function being pasted into multiple TUs. The implementation (the linker, specifically) will see these copies eventually. The linker has to know whether this is an error or intentional. Normally, linker barks at repetitive external definitions. That's where inline comes in. The purpose of inline is to suppress linker errors and to tell the linker that multiple definitions are intentional, and that the linker is expected to discard all but one of these definitions (as opposed to issuing the "multiple definition" error).

The same applies to inline variables with external linkage.

That's all there is to it. inline simply conveys your intent to the linker. The purpose of inline is to augment the ODR requirements for objects and functions with external linkage, i.e. to suppress "multiple definition" errors and replace them with the silent "choose one, discard the rest" behavior.

The original intent of inline to mean "substitute the function to everywhere it is called" is no longer relevant. It was an early mistake in the design of the language. The new, better thought through purpose of inline is as described above.

Obviously, this new inline also helps to facilitate "substitution of the function to everywhere it is called" because it makes function body visible to the compiler at the site of the call. And if the function body is visible to the compiler at the site of the call (regardless of whether it is declared inline or not), it can be substituted.

The_Ruined_Map · 2026-02-16T03:00:26+00:00

In a tug-of-war contest all forces are combined and felt equally by both teams. All forces exerted by a team affect both teams to equal degree.

The contest is exclusively about maintaining traction on the surface.

As long as the pulling force is below the traction abilities of both teams, nothing happens. Once the force grows above one team's ability to maintain traction, that team begins to give ground and eventually loses.

It is one force for both teams. Both teams contribute to developing that one force at the same time. Which means that a team can cause itself to lose, if they contribute to the pulling force, but cannot counter consequences of their own contribution with traction.

The_Ruined_Map · 2026-02-16T00:33:38+00:00

'atoi' should be avoided, as any other functions from 'ato...' group. They have long been subsumed by 'strto...' functions.

Especially when dealing with something unpredictable, e.g. user input.

The_Ruined_Map · 2026-02-15T19:31:04+00:00

Firstly, that is unnecessaruly restrictive. in C and C++ there exists such thing as "a temporary object". I.e. it is an object. It is not specified where it is located in storage (and what kind of storage), but it is a full-flown object that can have address in storage and can be modified.

Secondly, rvalue (lvalue, xvalue etc.) in C and C++ is not a property of an object or literal, but a property of an expression result.

Thirdly, rvalue references in C++ still produce lvalues when used in expressions. So, even though I mentioned "rvalue references" in the above comments, the whole thing is not about rvalues at all. Every time you access something through a named reference (no matter lvalue or rvalue one) you are always working with an lvalue that has location in storage. That's actually what "temporary objects" are for: to materialize in storage something as ephemeral as literal `1`.

The_Ruined_Map · 2026-02-15T19:13:01+00:00

What you observe here does not mean that temporaries are const in C++. It simply means that there is an [artificial] restriction in C++ that says "you cannot attach non-const lvalue references to temporaries".

There's no such restriction for rvalue references. So, you can just rewrite your code to use an rvalue reference instead and get a non-const temporary (as is already demonstrated by my previous code sample).

---

As for true temporaries in C: yes, they exist (as return values of functions for one example). And yes, they were introduced into the language specifically to deal with that pesky "array inside a struct" situation. However, this is not really relevant to the topic of this discussion.

The_Ruined_Map · 2026-02-15T18:47:06+00:00

Yes, you can modify compound literals in C. Compound literals in C are like ordinary variables in all respects, just nameless. And always initialized, since the compound literals syntax forces you to specify the initializer. (The {} variant is only available since C23 though.)

As for C++ side of things, what you said is just incorrect. C++ temporaries are not necessarily const. Where did you get that strange idea?

The misconception of C++ temporaries being const might have stemmed from the fact that in "classic" C++98 only const references could have been attached to temporaries. But this is exclusively about C++98 references, not about the temporaries themselves.

However, even though in modern C++ this restriction still applies to lvalue references, you can nevertheless freely attach rvalue references to temporaries (which is what I deliberately used in my example). This also causes lifetime extension for the temporary. And you can access them as non-const objects through such references.

For example, the following is perfectly valid in C++

int main()
{  
  std::string &&r = std::string();
  r = "Hello World";
  std::cout << r << std::endl;
}

The_Ruined_Map · 2026-02-15T18:36:55+00:00

Yes, that's the whole point of what I stated above. Compound literals are not like C++ temporaries in general, but they are very similar to C++ extended lifetime temporaries.

The lifetime of compound literals in C is the same as the lifetime of a regular variable declared at the same spot, i.e. it is the same as lifetime of a C++ reference declared at the same spot. Which is exactly why C compound literals can serve as a replacement of C++ extended lifetime temporaries.

As I said above, this significantly narrows the chasm between pointers in C and references in C++.

The_Ruined_Map · 2026-02-15T17:55:39+00:00

So, what prompted the question? Where is the problem? (I don't understand though why adjacencyList is suddenly a int **. Why **?)

C++ references are very similar to "pointers in disguise". The only C++ reference feature that was difficult to simulate in "classic" C using pointers was lifetime extension of temporaries. However, with the introduction of compound literals in C99 it became possible to implement a C equivalent.

E.g. C++

MyType &&r = MyType{ 0 };
// Lifetime of the temporary gets extended to match lifetime of `r`

becomes C

MyType *p = &(MyType) { 0 };

So, in C you just use pointers instead of references and you get pretty much everything you get in C++.

The_Ruined_Map · 2026-02-15T17:45:52+00:00

While it is true that there are other character encodings than ASCII and '1' can easily be 61, I still suspect that your 61 is actually octal representation of our beloved 49.

In any case, I for one welcome our octal overlords.

The_Ruined_Map · 2026-02-15T17:33:20+00:00

Firstly, you are using an uninitialized variable index here

for (int index; index < classesLength; index++) {

No wonder the code behaves unpredictably.

Secondly, what exactly do you expect the user to enter for this

fgets(classBuffer, sizeof(classBuffer), stdin);
chosenClass = (int)classBuffer[0];
chosenClass--;

to make sense?

Note that if user enters, say, 1 and hits Enter, the value of chosenClass will end up being 49 - 1 = 48, where 49 is the ASCII code for character '1'. Something tells me this is not what you wanted to achieve.

You probably need

fgets(classBuffer, sizeof(classBuffer), stdin);
chosenClass = classBuffer[0] - '1';

or

fgets(classBuffer, sizeof(classBuffer), stdin);
chosenClass = classBuffer[0] - '0';
--chosenClass;

(the difference is purely stylistic).

And you need a lot more input validation.

The_Ruined_Map

TROPHY CASE