|
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.
Edit: Duh. I am not using the latest GCC. I didn't think about that. Could easily be a bug.
Check out my IoT graphics library here:
https://honeythecodewitch.com/gfx
And my IoT UI/User Experience library here:
https://honeythecodewitch.com/uix
modified 2 days ago.
|
|
|
|
|
I get the same warning with gcc-14.1.0, and with x86-64 gcc-trunk over at the compiler explorer, so it's not been fixed so far.
"A little song, a little dance, a little seltzer down your pants"
Chuckles the clown
|
|
|
|
|
I didn't think of trying godbolt. I'm really distracted rn on the phone w/ an old friend.
Check out my IoT graphics library here:
https://honeythecodewitch.com/gfx
And my IoT UI/User Experience library here:
https://honeythecodewitch.com/uix
|
|
|
|
|
As far as I am concerned, the fact that you have this line :
float y = x;
which is clearly initializing the variable qualifies it as a bug. I can not conceive a situation where that is not 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?"
|
|
|
|
|
Quote: I hate assuming compiler bugs
No, it is definitely not a compiler bug. It is a defined behaviour, there are lots of documents in www which explain the background.
|
|
|
|
|
0x01AA wrote: It is a defined behaviour
That's precisely what I was afraid of.
Check out my IoT graphics library here:
https://honeythecodewitch.com/gfx
And my IoT UI/User Experience library here:
https://honeythecodewitch.com/uix
|
|
|
|
|
In a message above, you mentioned, there is no std available. But maybe in your environement some kind of bit_cast is available?
If not, I think a similar behaviour (to inform the compiler [optimizer]) can be achived with reinterpret_cast , but at the moment I don't remember the document, from where I got this
Sorry, for my strange English ...
|
|
|
|
|
It's possible I could do it with reinterpret_cast? I dunno
Check out my IoT graphics library here:
https://honeythecodewitch.com/gfx
And my IoT UI/User Experience library here:
https://honeythecodewitch.com/uix
|
|
|
|
|
Try it I think it simply informs the compiler 'you are aware' about a maybe not safe conversion ...
|
|
|
|
|
|
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
|
|
|
|
|
Probably the first. The other guy on the team hadn't noticed the issue.
|
|
|
|
|
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
|
|
|
|