|
float mpu6886::inv_sqrt(float x) {
float halfx = 0.5f * x;
float y = x;
#pragma GCC diagnostic ignored "-Wuninitialized"
#pragma GCC diagnostic ignored "-Wstrict-aliasing"
long i = *(long *)&y;
i = 0x5f3759df - (i >> 1);
y = *(float *)&i;
#pragma GCC diagnostic warning "-Wuninitialized"
#pragma GCC diagnostic warning "-Wstrict-aliasing"
y = y * (1.5f - (halfx * y * y));
return y;
}
Tell me how y is uninitialized? This isn't the first time I've encountered this.
Check out my IoT graphics library here:
https://honeythecodewitch.com/gfx
And my IoT UI/User Experience library here:
https://honeythecodewitch.com/uix
|
|
|
|
|
Ah, the fast inverse square root. Mind boggling code, I have not spent the time trying to work out how it works.
Without the code they commented then y would very likely have a terrible guesstimate and the function would be inaccurate, so y has not been 'initialised' with a good first guess. Weak definition of initialised, but some grain of logic there.
|
|
|
|
|
but i explicitly assign y to x.
Check out my IoT graphics library here:
https://honeythecodewitch.com/gfx
And my IoT UI/User Experience library here:
https://honeythecodewitch.com/uix
|
|
|
|
|
Ah, sorry, I completely misread your original post.
I would guess the error/warning is because you can not guarantee the sizes of long and float will be the same between C++ implementations. Just a stab in the dark though, and it seems like a strange error for that.
|
|
|
|
|
I would guess std::bit_cast in the line long i= ... should help.
|
|
|
|
|
no std available here
Check out my IoT graphics library here:
https://honeythecodewitch.com/gfx
And my IoT UI/User Experience library here:
https://honeythecodewitch.com/uix
|
|
|
|
|
If you split assignment via a long i; and float y, halfx; does it still happen?
|
|
|
|
|
That is weird. But better than what clang does at any optimization level above -O0, as per Compiler Explorer for X86-64:
inv_sqrt: # @inv_sqrt
ret
Um, what?
"A little song, a little dance, a little seltzer down your pants"
Chuckles the clown
|
|
|
|
|
Visual C++ does not complain about anything with that code. I think this qualifies as a bug.
"They have a consciousness, they have a life, they have a soul! Damn you! Let the rabbits wear glasses! Save our brothers! Can I get an amen?"
|
|
|
|
|
It very well could be. I've encountered this error in error before, I think?
I'm just really hesitant to file a bug against a compiler because I feel like they know a hell of a lot more about C and C++ than I do.
Check out my IoT graphics library here:
https://honeythecodewitch.com/gfx
And my IoT UI/User Experience library here:
https://honeythecodewitch.com/uix
|
|
|
|
|
What machine are you targeting, and what are the sizes of float and long* ?: If you compile this as 32 bit with gcc, you do not get any warnings.
Theory: you're compiling in 64 bit mode sizeof(float) = 4 and sizeof(long*) = 8. So what the compiler is trying to tell you is that long i = *(long*)&y the conversion of the float to a pointer, half the bytes are uninitialized. My theory anyway.
"A little song, a little dance, a little seltzer down your pants"
Chuckles the clown
|
|
|
|
|
it's 32-bit GCC
My processor can handle 64-bit numbers, but not as a native word.
Edit: I'm not sure long isn't 64 bit on this platform, but I've always used long long for that.
My CPU will not handle 128-bit words under any circumstances.
Check out my IoT graphics library here:
https://honeythecodewitch.com/gfx
And my IoT UI/User Experience library here:
https://honeythecodewitch.com/uix
|
|
|
|
|
The issue would arise if the size of a float is less than the size of a pointer. Maybe just ask the compiler to what sizeof(float) and sizeof(void*) return?
"A little song, a little dance, a little seltzer down your pants"
Chuckles the clown
|
|
|
|
|
Thanks. I'll look into it as time and motivation allows.
Edit: Turns out i had a project open so it was easy enough to check
sizeof(float): 4
sizeof(long*): 4
I checked sizeof long* just to be certain
Check out my IoT graphics library here:
https://honeythecodewitch.com/gfx
And my IoT UI/User Experience library here:
https://honeythecodewitch.com/uix
|
|
|
|
|
Well, not that then Seemed like a good answer at the time. Maybe it's just the type punning that's baffling the compiler?
"A little song, a little dance, a little seltzer down your pants"
Chuckles the clown
|
|
|
|
|
That's my theory, but I'm uncomfortable with it if nothing else because
a) I hate assuming compiler bugs. So often it's some effing intricacy of the C or C++ language that is at play, rather than the compiler in error.
b) You'd think it would have been found and fixed. Like I said, this isn't the first time I've run into it. The last time was a lot more innocuous - no type aliasing or fudging like that. it was an enum struct type declared as a local variable and initialized at declaration time.
I'd dig up the old example if i could, but I ended up working around it in order to get the warnings out of my code without using compiler specific pragmas.
Check out my IoT graphics library here:
https://honeythecodewitch.com/gfx
And my IoT UI/User Experience library here:
https://honeythecodewitch.com/uix
|
|
|
|
|
Reviewing a CSV file today (which already has inconsistent quotes and such), I noticed it has a few characters (e.g. non-breaking space) encoded as UTF-8 -- fine, no big deal. But they still look odd after decoding... ah, they're encoded as UTF-8 twice... double-UTF-8.
So now I have to write a recursive UTF-8 decoder... Why doesn't .net simply do that to begin with?
It'll be breakfast at Milliways again.
|
|
|
|
|
I got a phishing email the other day.
Embedded HTML to imitate a Micro$oft login form (posting credentials to evil.org of course).
Inline base-64 encoded, easy peasy.
%-encoded inside that. One and a half times....
The outer decode works, but still got %'s in there.
Decode again and *barf*, it's broken (but only in some places).
Wasn't game to see what a browser would make of it.
Given browsers' general tolerance of coding errors, I suspect it might just have worked.
Software rusts. Simon Stephenson, ca 1994. So does this signature. me, 2012
|
|
|
|
|
.NET doesn't do that to begin with because it wouldn't make any sense.
The problem is your CSV has bad encoding.
What you wrote is a workaround for a poorly encoded file.
That's not .NET's business, and frankly, if it did that, it would be a Bad Thing(TM)
Check out my IoT graphics library here:
https://honeythecodewitch.com/gfx
And my IoT UI/User Experience library here:
https://honeythecodewitch.com/uix
|
|
|
|
|
Oh, I know. Yet why not have an option? As when getting a directory listing, you can specify TopDirectoryOnly or AllDirectories. Not that they would have expected this to be needed twenty years ago.
What I have so far will deal with double-encoding, but I can imagine the rabbit hole going deeper. All the way to the turtles I'm sure.
Anyway, it's a good exercise.
|
|
|
|
|
Because in the decades that UTF-8 is available you're the second person to need the feature.
Check out my IoT graphics library here:
https://honeythecodewitch.com/gfx
And my IoT UI/User Experience library here:
https://honeythecodewitch.com/uix
|
|
|
|
|
Adding, there's another issue.
What if your intent was to embed control characters into UTF-8?
.NET cannot do this for you without breaking the UTF-8 spec.
Check out my IoT graphics library here:
https://honeythecodewitch.com/gfx
And my IoT UI/User Experience library here:
https://honeythecodewitch.com/uix
|
|
|
|
|
My career seems to be entirely described by the following:
"Use a simple technology to do a thing that 80% of Devs take for granted and who also tell you it works, but discovering that the thing doesn't actually work the way they say it works."
Here's the latest. I will try to keep it short (because I'm going to write an article on it, but I can't wait to share this one because it is so weird (from multiple angles)).
1) JavaScript FormData Posted To Backend Is All Strings
Mabye a lot of you know this, but all of the values in the following (real) example end up being strings when they get to the backend.
var formData = new FormData();
formData.append("uuid",currentUuid);
var entryId = 9;
var jentry = {
Id:entryId,
Title: titleText,
Note: noteText,
Created: createdDate,
Updated: null
};
for (var key in jentry) {
formData.append(key, jentry[key]);
} Odd, But Acceptable
Ok, so the point of that is that all of the values in the jentry object are converted to string values. That means Updated = "null" (string) and the Id = "9".
This is odd, to me, but acceptable.
If you refute this, please provide citations. I've searched far & wide and asked Copilot -- all says they are strings when they hit the backend.
Now It Gets Real Weird
My WebAPI method which gets called by the JS Fetch with the previously shown FormData looks like:
public ActionResult Save([FromForm] String uuid,[FromForm] JournalEntry jentry)
AutoBinding In .NET Core Works With JS Fetch
1. The JS Fetch works.
2. The C# JournalEntry is created from the data posted via the FormData variables.
3. I can examine the data in the C# JournalEntry object and (almost) everything looks fine.
Autobinding Ignores The Id Value!
However, at some point I needed the Id value which was being passed in.
But I noticed that the Id value in the C# object was always ZERO Id = 0.
FormData Value Is Non-Zero, But Autobound Object Is 0
But, keep in mind that the FormData object shown above is passing in a non-zero value for Id (9 in the example.
What!?!
Why Is This Happening?
The only thing I could guess is that since the Id value (from the FormData) was being passed as a String that the autobinding just ignores the value and sets it to 0.
Here's How My C# Object (Used for Autobinding) Is Defined
public class JournalEntry{
public Int64 Id{get;set;}
public String? Title{get;set;}
public String Note{get;set;}
public String Created{get;set;}
public String? Updated{get;set;}
}
Yes, the point is that the Id is an Int64 (not a string).
This Part Should Alarm You!!! This Should Be The Bug
So, somehow the autobinder is able to bind the JournalEntry to the FormData object but it just ignores the Id value and sets it to 0!!!!
Why?? !! Please someone explain it to me.
A "Workaround" Test
I altered my JournalEntry class so the Id is a String
public class JournalEntry{
public String Id{get;set;}
and posted the data again.
Autobinder Works! What?!
After that change, the autobinder sets the Id value properly (non-zero value that is read from FormData).
Not What I Expected
This is not what I expected. JSON data is _supposed_ to get autobound to the C# object, right?
Just Binds the Parts It Wants To Bind?
It's weird because it doesn't fail to bind it just skips parts of the object that it wants to skip.
I could accept it if it failed to bind because it was the wrong type.
Article Is Coming Later Today
This was long but I will be writing it up in an article with associated examples and an example project you'll be able to download and try for yourself.
modified yesterday.
|
|
|
|
|
Automatism is often also random.
Either you declare what absolutely has to be bound or you have to live with chance.
|
|
|
|
|
0x01AA wrote: Automatism is often also random.
That's quite true.
We often interact with behavior that is basically _undefined_.
Undefined behavior could result in anything.
So, I guess software development is just a form of "trial and error". Just see what you get.
This is why it is illegal in many areas to call it software engineering.
|
|
|
|