Is it safe to use __SECRET_INTERNALS_DO_NOT_USE_OR_YOU_WILL_BE_FIRED ?

[jinpa]

@PleegWat said in Is it safe to use __SECRET_INTERNALS_DO_NOT_USE_OR_YOU_WILL_BE_FIRED ?:

@jinpa said in Is it safe to use __SECRET_INTERNALS_DO_NOT_USE_OR_YOU_WILL_BE_FIRED ?:

I agree with the way they taught it to us. First you do machine language in binary, then in hexadecimals, then assembly, then C, then C++, then Java.

Some people may disagree with some steps in that progression.

Each step is a "higher" level. But if you're a master in one step, you may not like the idea that the "higher" levels make it easier. E.g., if you're an assembly programmer, you may think that C lets in too many people.

Real Programmers Don't Use FORTRAN.

Please elaborate.

[Mason_Wheeler]

@ixvedeusi said in Is it safe to use __SECRET_INTERNALS_DO_NOT_USE_OR_YOU_WILL_BE_FIRED ?:

@Steve_The_Cynic said in Is it safe to use __SECRET_INTERNALS_DO_NOT_USE_OR_YOU_WILL_BE_FIRED ?:

It merely requires programmers to know what they are doing.

... but doesn't tell them when they don't.

This is why I don't like C. It fails incredibly hard at usability rule #1: errare humanum est.

If a person makes a mistake once using a tool, you can blame it on them and say they just need to know how to use it right. If virtually everyone continues making the same mistake, even after knowing it's a mistake, the problem is not with the users, it's with the design of the tool.

[jinpa]

@Mason_Wheeler said in Is it safe to use __SECRET_INTERNALS_DO_NOT_USE_OR_YOU_WILL_BE_FIRED ?:

This is why I don't like C. It fails incredibly hard at usability rule #1: errare humanum est.

If a person makes a mistake once using a tool, you can blame it on them and say they just need to know how to use it right. If virtually everyone continues making the same mistake, even after knowing it's a mistake, the problem is not with the users, it's with the design of the tool.

If you're writing close-to-the-metal code, C is still a good tool for that, or so I hear. There are few programmers still writing new code in C except where it's required.

[Bulb]

@jinpa said in Is it safe to use __SECRET_INTERNALS_DO_NOT_USE_OR_YOU_WILL_BE_FIRED ?:

@Mason_Wheeler said in Is it safe to use __SECRET_INTERNALS_DO_NOT_USE_OR_YOU_WILL_BE_FIRED ?:

This is why I don't like C. It fails incredibly hard at usability rule #1: errare humanum est.

If a person makes a mistake once using a tool, you can blame it on them and say they just need to know how to use it right. If virtually everyone continues making the same mistake, even after knowing it's a mistake, the problem is not with the users, it's with the design of the tool.

If you're writing close-to-the-metal code, C is still a good tool for that, or so I hear.

Until recently there was no alternative to C (or C++, but the added complexity does not eliminate the errors anyway, so some do not want) for basically anything that needs to manipulate memory somewhat directly, which is surprisingly many things including the runtimes to all the higher level languages.

Now there is Rust for that, and it is slowly making its way into the market, but the lower layers have long development cycles, so it can't be expected to go that fast.

There are few programmers still writing new code in C except where it's required.

Well, there is quite a few who do it for histerical raisins—where going on in C is easier than porting the huge existing codebase that mostly works by now.

[topspin]

@Bulb said in Is it safe to use __SECRET_INTERNALS_DO_NOT_USE_OR_YOU_WILL_BE_FIRED ?:

Until recently there was no alternative to C (or C++, but the added complexity does not eliminate the errors anyway, so some do not want) for basically anything that needs to manipulate memory somewhat directly, which is surprisingly many things including the runtimes to all the higher level languages.

It's also a hard problem, because you either have safety or direct hardware access.

Even for C, some people treat it just as a high-level assembler and do "clever" things because they think they know what they're doing, it works in assembly but actually violates what you can do in the C abstract machine. And then the compiler will break your assumptions.

[Mason_Wheeler]

@topspin And therein lies the problem. If the "clever things" violate the C abstract machine spec, why is the compiler not erroring out on them?

[topspin]

@Mason_Wheeler said in Is it safe to use __SECRET_INTERNALS_DO_NOT_USE_OR_YOU_WILL_BE_FIRED ?:

@topspin And therein lies the problem. If the "clever things" violate the C abstract machine spec, why is the compiler not erroring out on them?

Because they're hard to distinguish from all the "clever" legal things.

Rust goes out of its way to improve on this situation, but its a quite complex compiler and the things it does just weren't possible back in the day. I guess it's no silver bullet, but a major step forward.

[cvi]

@Mason_Wheeler There's also the issue of breaking existing code. The C (and C++) committees and compiler vendors have been extremely reluctant to break existing code. There's a very long ongoing discussion around that topic.

The other way is to legalize some of the illegal "clever things". But even that is hard.

[Steve_The_Cynic]

@jinpa said in Is it safe to use __SECRET_INTERNALS_DO_NOT_USE_OR_YOU_WILL_BE_FIRED ?:

@Steve_The_Cynic said in Is it safe to use __SECRET_INTERNALS_DO_NOT_USE_OR_YOU_WILL_BE_FIRED ?:

@ixvedeusi As @Arantor says, mostly the programmers that know what they are doing don't need to be told.

The thing that worries me the most about modern "stuff"(1) is that it's a thinly-veiled, or more often just blatant, attempt at deskilling my chosen profession. I have the mad skillz, as it were, and the continual "learn to code" bulldinkey just ... annoys me.

Enough that my preferred way to express myself is no longer through the medium of code. No. I prefer to express myself by travelling to my local tattoo parlour and spending substantial sums on "ink". Like my little snake. Um. This little snake: https://i.imgur.com/obLJwp4.jpg

EDIT: footnote:
(1) A coded politeness.

A huge snake and a mask. It doesn't get any better than that.

Yeah, well the Covid rules weren't yet sufficiently relaxed that I could go there without one. I'm no refusenik on the question of covid masks, but I'm not a fan of them either.

[jinpa]

@Steve_The_Cynic said in Is it safe to use __SECRET_INTERNALS_DO_NOT_USE_OR_YOU_WILL_BE_FIRED ?:

@jinpa said in Is it safe to use __SECRET_INTERNALS_DO_NOT_USE_OR_YOU_WILL_BE_FIRED ?:

A huge snake and a mask. It doesn't get any better than that.

Yeah, well the Covid rules weren't yet sufficiently relaxed that I could go there without one. I'm no refusenik on the question of covid masks, but I'm not a fan of them either.

I get the situation, but it's still funny. Tattoos used to mean you were a tough guy. And your tattoo is definitely within that spirit. It's hard to think of a good analogy, even. But this is one I could use as an analogy in the future. "It's like a Hell's Angel getting a two-foot snake tattoo wearing a Wuhan virus mask!" This will be even funnier in the future when there's no one still defending everything that was done wrong. :)

On an aside, I looked up refusenik and it is the opposite of what I thought. Refuseniks did not refuse, they were refused (permission to emigrate from the USSR.)

[Steve_The_Cynic]

@cvi I can think of one fairly subtle and rarely problematic one from the transition to C++11:

   auto i = 1.4;

Before C++11, this is allowed only inside a function, and defined a variable i of type int and initialised it to be 1.

From C++11, this is allowed in other contexts than just inside a function, and defines a variable i of type double and initialises it to be 1.4.

[Steve_The_Cynic]

@jinpa said in Is it safe to use __SECRET_INTERNALS_DO_NOT_USE_OR_YOU_WILL_BE_FIRED ?:

@Steve_The_Cynic said in Is it safe to use __SECRET_INTERNALS_DO_NOT_USE_OR_YOU_WILL_BE_FIRED ?:

@jinpa said in Is it safe to use __SECRET_INTERNALS_DO_NOT_USE_OR_YOU_WILL_BE_FIRED ?:

A huge snake and a mask. It doesn't get any better than that.

Yeah, well the Covid rules weren't yet sufficiently relaxed that I could go there without one. I'm no refusenik on the question of covid masks, but I'm not a fan of them either.

I get the situation, but it's still funny. Tattoos used to mean you were a tough guy. And your tattoo is definitely within that spirit. It's hard to think of a good analogy, even. But this is one I could use as an analogy in the future. "It's like a Hell's Angel with a two-foot snake tattoo wearing a Wuhan virus mask!" This will be even funnier in the future when there's no one still defending everything that was done wrong. :)

For sure, even if the question of what was done wrong would get more different answers than people answering.

On an aside, I looked up refusenik and it is the opposite of what I thought. Refuseniks did not refuse, they were refused (permission to emigrate from the USSR.)

Huh. TIL. It's the opposite of what I thought, too. These days, everyone seems to use it to mean a refuseR rather than a refuseE.

[Bulb]

@jinpa said in Is it safe to use __SECRET_INTERNALS_DO_NOT_USE_OR_YOU_WILL_BE_FIRED ?:

On an aside, I looked up refusenik and it is the opposite of what I thought.

Originally yes, but it's now used in the sense you thought.

Over time, "refusenik" has entered colloquial English for a person who refuses to do something, especially by way of protest.
– https://en.wikipedia.org/wiki/Refusenik

[Mason_Wheeler]

@Steve_The_Cynic said in Is it safe to use __SECRET_INTERNALS_DO_NOT_USE_OR_YOU_WILL_BE_FIRED ?:

@cvi I can think of one fairly subtle and rarely problematic one from the transition to C++11:

   auto i = 1.4;

Before C++11, this is allowed only inside a function, and defined a variable i of type int and initialised it to be 1.

From C++11, this is allowed in other contexts than just inside a function, and defines a variable i of type double and initialises it to be 1.4.

[Bulb]

@Mason_Wheeler Well, yes. The keyword auto used to be a storage class specifier alongside register and static since the early days of C. But because it was the default, nobody sane ever typed it out, especially as relying on default int was no longer fashionable by the time C++ took off. This meant when the time came to create C++11, it was a reserved keyword that wasn't used, which is why it was chosen for this new functionality.

[Steve_The_Cynic]

@Bulb Indeed, although I did, around 2000, encounter a big body of C code (a third-party H.323 signalling stack that we were using) that used auto and register religiously, even though pretty much any C compiler of the time would ignore both of them (auto is the default, and the compilers are generally better at deciding what should be in a register than any programmer other than Mel).

[Bulb]

@Steve_The_Cynic But it was a C codebase, not a C++ one, wasn't it? In C the meaning didn't change.

Sounds like they had an architect or senior developer who learned C some time during the rule of king stick and stubbornly refused to update his “knowledge” of how to write efficient code. I've met a couple of such guys and they are pain in the butt.

Like in my previous job I became part of a thing you should never do (a full rewrite of a working software) that was started by such guy. He was strictly against using std::vector, probably because some time he wrote vector<vector<something>> and was surprised by the abysmal performance (this was fixed by C++11, but that project still didn't use C++11 when I left in 2016 due to supporting a legacy platform), but his own version of string used linear reallocation +32 bytes, which is much bigger sin and made it completely unusable for longer strings.

And his image processing that processed a 32×32 box for each pixel, but cleared the whole working buffer (sized as the image) after every pixel, well, that caused larger images to take hours to process. We cursed that for years until one day I pulled out the profiler, found that abomination, fixed it to only clear the used part of the buffer, speeding up the resource compilation by almost three orders of magnitude.

But that guy insisted we should do calculation in integers rather than floats because floats are much slower, a thing that was decidedly false for at least a decade (since most CPUs got FPUs) and never mattered in the grand scheme of things except maybe in the drawing code.

[Bulb]

@Steve_The_Cynic said in Is it safe to use __SECRET_INTERNALS_DO_NOT_USE_OR_YOU_WILL_BE_FIRED ?:

and the compilers are generally better at deciding what should be in a register than any programmer other than Mel

I remember back in university (around 20 years ago) a colleague who was contributing to gcc talked about how it does “register coloring” and that it is a fairly sophisticated heuristics for graph coloring (an NP-hard problem) on the dependency graph of the RTL to minimize the storage requirements of the of a basic block to make best use of the very limited register set—as x86 only has 4 general-purpose registers.

[Zerosquare]

@Bulb said in Is it safe to use __SECRET_INTERNALS_DO_NOT_USE_OR_YOU_WILL_BE_FIRED ?:

x86 only has 4 general-purpose registers.

: seven (eax, ebx, ecx, edx, esi, edi, ebp - even if the last one is generally used as a pointer to local storage on the stack, so it's more like six in practice).

[Bulb]

@Zerosquare Only the first four (eax to edx) are general purpose. The two index ones (esi and edi) can be abused for storing other things than offsets too, but IIRC not with all instructions that the first four can. And ebp is taken by the frame, so not available for anything else.

[Steve_The_Cynic]

@Bulb Ugh. Memory does not always serve me well. I was wrong - it was C++ (a foul hybrid of C++-pre98 and the mess that came before. It also had a jolly catch(...) at the base of its loops and stuff. That combined with VC++6's jolly thing of using SEH to handle C++ exceptions and meant that their stack was impossible to crash. Mind you, that was not because it wouldn't try to crash, but because when it segged or whatever, it would get caught by the catch(...) and the code would then stumble on, becoming progressively more and more broken as it shredded its internal state more and more.

[Steve_The_Cynic]

@Bulb said in Is it safe to use __SECRET_INTERNALS_DO_NOT_USE_OR_YOU_WILL_BE_FIRED ?:

@Zerosquare Only the first four (eax to edx) are general purpose. The two index ones (esi and edi) can be abused for storing other things than offsets too, but IIRC not with all instructions that the first four can. And ebp is taken by the frame, so not available for anything else.

In x86-32, you don't actually need ebp-relative addressing to use the variables on the stack, because x86-32 also has addressing modes relative to the stack pointer.

[Mason_Wheeler]

@Steve_The_Cynic Pokémon exception handling!

[dkf]

@Mason_Wheeler said in Is it safe to use __SECRET_INTERNALS_DO_NOT_USE_OR_YOU_WILL_BE_FIRED ?:

If the "clever things" violate the C abstract machine spec, why is the compiler not erroring out on them?

Why are you seeking to prevent people from doing things that are legal? There's whole sets of things that the C abstract machine doesn't allow that nonetheless work very well on actual concrete machines. In one specific case I'm thinking of, memory is conceptually an array of structs (with a compile-time dynamic number of elements), but is actually the concatenation of two arrays of structs, where the first array is the (larger) static part and the second array is the smaller dynamic part; this layout permits all the data to be moved into working memory using a single DMA, and for a single DMA to write back the modified parts (but just those, which is good because writes are slower). Supporting this requires going beyond the C abstract machine, but in ways that are extremely predictable on the target platform.

If we were to convert this to the Rust style, it would either involve multiple reads or a much larger write back, either of which would likely break the soft realtime performance requirements in some cases (there's not a lot of spare time as it is). The operations cannot be made type-safe anyway; the underlying matrix simply doesn't have the same number of elements per row unless you add a lot of padding (which runs you out of space elsewhere).

Another thing that we use in our code is TDMA access control to shared memory. By that, I mean that the thread in question has free access to its shared resource during a given fraction of its timeslice, and no access the rest of the time. That's pretty easy to show the correctness of, yet is entirely impossible to express the safety of in Rust. Rust's solution is to use locks, but we don't have those (or rather we do hardware locks but they're such a meagre resource that we treat them as OS-only; the rest of the hardware doesn't have a memory consistency model that supports a working model of locking).

The technical problem with Rust is that it bakes in assumptions that aren't always true, and it is very difficult to work around them. The sociological problem with Rust is that its advocates tend to treat its natural way of working as the only possible way to solve anything, and insist on trying to proselytise to people who have problems that don't and cannot fit nicely.

By comparison, C doesn't try to solve any of that. It's trying to solve how to make it possible to write mostly-portable low-level code without writing miserable amounts of assembly language.

[dkf]

@Bulb said in Is it safe to use __SECRET_INTERNALS_DO_NOT_USE_OR_YOU_WILL_BE_FIRED ?:

But that guy insisted we should do calculation in integers rather than floats because floats are much slower, a thing that was decidedly false for at least a decade (since most CPUs got FPUs) and never mattered in the grand scheme of things except maybe in the drawing code.

There are cases where that's correct even now. The result is fixed point math, and it's... a very mixed bag as to whether it is better or not. Essentially, you get to skip some of the processing that is necessary for floats and get more bits of mantissa (these are strongly linked!) but in return you have to make sure that you get your scaling exactly right or you are so fucked. Floating point is a lot more lenient, and tends to have better programmer tooling support.

[Bulb]

@dkf said in Is it safe to use __SECRET_INTERNALS_DO_NOT_USE_OR_YOU_WILL_BE_FIRED ?:

There's whole sets of things that the C abstract machine doesn't allow that nonetheless work very well on actual concrete machines.

Because the thing tends to break with newer versions of compiler optimizations, leaving everybody confounded.

The technical problem with Rust is that it bakes in assumptions that aren't always true, and it is very difficult to work around them.

That's what unsafe is for. After all, everything is ultimately implemented by an unsafe bit under the hood.

The sociological problem with Rust is that its advocates tend to treat its natural way of working as the only possible way to solve anything, and insist on trying to proselytise to people who have problems that don't and cannot fit nicely.

My understanding is that Rust embedded subcommunity advocates doing whatever it takes to be efficient in unsafe and then building an abstraction on top of it that enforces as much of the rules as possible, but never at the cost of giving up the efficiency.

So

memory is conceptually an array of structs (with a compile-time dynamic number of elements), but is actually the concatenation of two arrays of structs, where the first array is the (larger) static part and the second array is the smaller dynamic part; this layout permits all the data to be moved into working memory using a single DMA, and for a single DMA to write back the modified parts (but just those, which is good because writes are slower).

The “Rust way” would be to wrap the memory block in something that will do the DMA just as it should and hand-out the pointers to the content as needed, with checking of conflicts, possibly turned off in release mode if it can't be done purely compile time. But no sane rustacean would give up the DMA efficiency.

By that, I mean that the thread in question has free access to its shared resource during a given fraction of its timeslice, and no access the rest of the time. That's pretty easy to show the correctness of, yet is entirely impossible to express the safety of in Rust. Rust's solution is to use locks, but we don't have those

Rust solution isn't to use locks, it is to ensure that you only have a reference to the buffer for the duration of the slice. Something that would look similar to locks, but tailored to how your scheduler works. And punt to unsafe whenever building the abstraction does not look like worth it for the few call-sites if you are sure it's actually sound.

[dkf]

@Bulb Sounds like a lot of work with no real value to me at the end.

[topspin]

@dkf said in Is it safe to use __SECRET_INTERNALS_DO_NOT_USE_OR_YOU_WILL_BE_FIRED ?:

@Bulb Sounds like a lot of work with no real value to me at the end.

Isolating things that are not standard C but implementation defined to a small amount of code, so the rest can be statically checked to be sound?

[Zerosquare]

@Bulb said in Is it safe to use __SECRET_INTERNALS_DO_NOT_USE_OR_YOU_WILL_BE_FIRED ?:

Only the first four (eax to edx) are general purpose. The two index ones (esi and edi) can be abused for storing other things than offsets too, but IIRC not with all instructions that the first four can.

How to know if a register is a "general purpose register"?

I am trying to understand what criteria a register must have to be called a "general purpose register". I believe a general purpose register is a register that can be used for anything (for calcul...

With the introduction of the 32-bit architecture - IA-32 - the purpose of the integer registers generalized and (nearly) each register can be used for every purpose (hence general purpose).
...
With many new architectures new special purpose registers were added. A complete overview is given in the Intel Manual, Volume 1, Section 3.7.2.:
• 32-bit general-purpose registers (EAX, EBX, ECX, EDX, ESI, EDI, ESP, or EBP)

@Steve_The_Cynic said in Is it safe to use __SECRET_INTERNALS_DO_NOT_USE_OR_YOU_WILL_BE_FIRED ?:

In x86-32, you don't actually need ebp-relative addressing to use the variables on the stack, because x86-32 also has addressing modes relative to the stack pointer.

You don't have to, but most compilers use ebp that way:

What is between ESP and EBP?

Right, I'm sure this is implicitly answered many times, but I seem not to be able to quite get to it. If you have a (x86) stack trace (say, looking at it in WinDbg), and you look at the registers,...

[dkf]

@topspin said in Is it safe to use __SECRET_INTERNALS_DO_NOT_USE_OR_YOU_WILL_BE_FIRED ?:

@dkf said in Is it safe to use __SECRET_INTERNALS_DO_NOT_USE_OR_YOU_WILL_BE_FIRED ?:

@Bulb Sounds like a lot of work with no real value to me at the end.

Isolating things that are not standard C but implementation defined to a small amount of code, so the rest can be statically checked to be sound?

The code's running in an interrupt handler. There are additional complexities here. I've got code on a branch that repurposes the stack pointer register as a general register (this is ARM so the rules aren't the same) and knows it can do that because it knows that it's running as the highest priority standard interrupt. It uses that extra register to avoid needing to spill any of its local variables to the stack at all, which in turn accelerates the inner loop to the point where it operates in a significantly more efficient performance domain (there's a whole bunch of extra costly stuff that becomes unnecessary). As long as you want exactly what it does, it goes incredibly fast using virtually no resources (or correspondingly at huge scale). But that's in assembler and is something that no current team member (myself included!) is willing to touch. Instead, we use C and get things that aren't as efficient, but which still do very well within our time and various memory budgets (code size is limited, working memory size is limited, and the architecture doesn't let us trade those off against each other; there's also shared memory, which is comparatively huge, but which is also a lot slower if we don't use DMAs). That's where we're coming from as a team; if something gets too nasty, we'll code it in assembler, but we'd rather not because it's harder to maintain. (We do have some of that, but it is mostly in our custom OS, and even then it is only a few percent of the whole.)

We've looked at C++, and it could compile to the platform (provided we turn off many language features like exceptions and RTTI) but it has a nasty tendency to bloat up too large to fit in the code space. It's just too easy to hit that problem. (It's also too easy to end up with surprise floating point, which is a horrible problem on the current platform version. The easiest way to diagnose that is to grep the disassembled machine code to look for where the floating point support library is referenced.) All the principles of "zero cost" don't include that cost being zero in any way we actually care about. We prefer C; it springs fewer surprises on us (and it builds so much faster; that's also why we prefer to not develop on Windows). Rust's approach in all this feels far too close to C++, not in how the language works but rather in how it expects you to pay for things. As what we have already works, we don't see the value from investing in changing everything to a new toolchain. We also don't really care what some other compiler would choose to do; it works with the versions of the compilers we've validated for use in the application area.

[Benjamin Hall]

@dkf said in Is it safe to use __SECRET_INTERNALS_DO_NOT_USE_OR_YOU_WILL_BE_FIRED ?:

surprise floating point

Is that what kids are calling it these days?

Seriously, I'm glad I'm not in your shoes. Even if I have to deal with date math instead.

[Zerosquare]

@Benjamin-Hall said in Is it safe to use __SECRET_INTERNALS_DO_NOT_USE_OR_YOU_WILL_BE_FIRED ?:

I have to deal with date math

Is splitting the bill that hard?

[Applied Mediocrity]

@Zerosquare Surface area calculations to decide whether to get one 45 cm pizza or two 30 cm ones (there's a discount for 2). If I order two, the pretty cashier will think I'm ordering for two. If I order one, she'll think I'm a miserable chud. Which is, however, offset by less crust (it's a gamble, really) and only one pizza box surcharge...

[dkf]

@Benjamin-Hall said in Is it safe to use __SECRET_INTERNALS_DO_NOT_USE_OR_YOU_WILL_BE_FIRED ?:

Is that what kids are calling it these days?

That's one of these stupid things. The hardware doesn't have float support, so if you use them in the code, they get emulated in software. If this is what you're expecting, it's great; you get to use the algorithm you wrote as you wrote it. But if it isn't, you get something surprisingly expensive both in terms of execution time and code space (there isn't much spare in 32kB; it's not like we're somewhere where a few extra megabytes of library is no big deal). It's very easy to get it wrong; the compiler (usually a gcc variant) tries to hide this stuff, but there's a limit.

We've designed our math to work with fixed point. In fixed point, addition and subtraction have fewer surprises than with floats, but multiplication has more and division is "best avoided if unnecessary" (or converted into multiplication by a reciprocal; this is trivial for constants). Transcendental functions are supported; we have our own library for them (they take a lot of code space, but if you need them you need them). In the next version of the hardware, we'll have float (but not double; didn't fancy the cost of that IP option) and hardware accelerators for some transcendental functions (exp and log; our problem domain doesn't need the trig funcs). It should be so much nicer... once proper quantities of the chips are available and the first version of the OS is written. It's going to be great, except we still will have to be careful with printf-like functions because C says that float converts to double when passing those in and that'll cause a hardware exception. Yay.

[MrL]

@Applied-Mediocrity said in Is it safe to use __SECRET_INTERNALS_DO_NOT_USE_OR_YOU_WILL_BE_FIRED ?:

If I order two, the pretty cashier will think I'm ordering for two. If I order one, she'll think I'm a miserable chud.

Either ask her out or stop caring what she thinks. Just saying.

[Applied Mediocrity]

@MrL

[HardwareGeek]

@Applied-Mediocrity said in Is it safe to use __SECRET_INTERNALS_DO_NOT_USE_OR_YOU_WILL_BE_FIRED ?:

If I order two, the pretty cashier will think I'm ordering for two. If I order one, she'll think I'm a miserable chud.

Order a half-dozen, and she'll think you're a fun party guy and ask if she can come to the party, too?

[Gribnit]

@HardwareGeek said in Is it safe to use __SECRET_INTERNALS_DO_NOT_USE_OR_YOU_WILL_BE_FIRED ?:

@Applied-Mediocrity said in Is it safe to use __SECRET_INTERNALS_DO_NOT_USE_OR_YOU_WILL_BE_FIRED ?:

If I order two, the pretty cashier will think I'm ordering for two. If I order one, she'll think I'm a miserable chud.

Order a half-dozen, and she'll think you're a fun party guy and ask if she can come to the party, too?

Ancient 80's coming of age movie secret.

[Zerosquare]

The dreams thread is

[topspin]

@dkf said in Is it safe to use __SECRET_INTERNALS_DO_NOT_USE_OR_YOU_WILL_BE_FIRED ?:

The hardware doesn't have float support, so if you use them in the code, they get emulated in software.

Can't you tell the compiler to generate an error instead of emulating it (assuming you never want emulation in any case)?

[Benjamin Hall]

@topspin said in Is it safe to use __SECRET_INTERNALS_DO_NOT_USE_OR_YOU_WILL_BE_FIRED ?:

@dkf said in Is it safe to use __SECRET_INTERNALS_DO_NOT_USE_OR_YOU_WILL_BE_FIRED ?:

The hardware doesn't have float support, so if you use them in the code, they get emulated in software.

Can't you tell the compiler to generate an error instead of emulating it (assuming you never want emulation in any case)?

From the post you quoted:

If this is what you're expecting, it's great; you get to use the algorithm you wrote as you wrote it. But if it isn't, you get something surprisingly expensive both in terms of execution time and code space (there isn't much spare in 32kB; it's not like we're somewhere where a few extra megabytes of library is no big deal). It's very easy to get it wrong; the compiler (usually a gcc variant) tries to hide this stuff, but there's a limit.

[TwelveBaud]

@Benjamin-Hall So why not have a dummy FP library that explodes the linker if it's ever used, make it available to the linker by default, and substitute the real one only for modules that have been properly determined to need FP?

[Benjamin Hall]

@TwelveBaud said in Is it safe to use __SECRET_INTERNALS_DO_NOT_USE_OR_YOU_WILL_BE_FIRED ?:

@Benjamin-Hall So why not have a dummy FP library that explodes the linker if it's ever used, make it available to the linker by default, and substitute the real one only for modules that have been properly determined to need FP?

That might work. I was pointing out that, contra your parenthetical assumption, they do sometimes want emulation. So simply locking it out entirely would be a BAD THING.

[dkf]

@TwelveBaud said in Is it safe to use __SECRET_INTERNALS_DO_NOT_USE_OR_YOU_WILL_BE_FIRED ?:

@Benjamin-Hall So why not have a dummy FP library that explodes the linker if it's ever used, make it available to the linker by default, and substitute the real one only for modules that have been properly determined to need FP?

Two reasons:

1. That would require a custom build of that variant of gcc. (The FP-emulation library is part of the compiler stack itself.) That's a massive pain for users, especially on Windows; we have a mandatory requirement to support user custom code.
2. Sometimes our own code needs float anyway, because the math algorithm in the model in question is too ill-informed for the types of math that fixed point is good at. At that point, we have to suck it up and pay for it (deploying more cores to emulate the neurons and taking a lot more networking resources too; the consequences run deep).

It's easier to manually review from time to time than to sort out an automatic detection scheme. (You basically just scan the dump of the names of the symbols in the code and look for anything "weird". It only takes a few seconds with a little practice; the naming rules used are quite distinctive.)

[PleegWat]

@dkf said in Is it safe to use __SECRET_INTERNALS_DO_NOT_USE_OR_YOU_WILL_BE_FIRED ?:

(You basically just scan the dump of the names of the symbols in the code and look for anything "weird". It only takes a few seconds with a little practice; the naming rules used are quite distinctive.)

Sounds like something you could write a static analysis test for.

[Zerosquare]

:

[sarimarton]

@dcon It's super easy to sniff it out

import * as react from 'react'

const reactInternals = Object.entries(react).find(
  ([, val]) => val.ReactCurrentOwner
)[1]