Just a little bug (I think ?) report
In juce\modules\juce_events\native\juce_win32_HiddenMessageWindow.h, this line of code
creates a runtime error when compiled in 32 bit, about loosing digits.
It’s because on windows, LONG_PTR is defined as a __int3264 (http://msdn.microsoft.com/en-us/library/cc230349(v=prot.10).aspx)
and __int3264 is defined as 32 bit int when compiled in 32bit and 64 bit int when compiled in 64 bit.
This isn’t critical and it might have been fixed in later Juce releases. Unfortunately I can’t update to the latest tip right now, so, very sorry in advance if this problem has been already solved.
Huh? Surely instead of “runtime error” you mean “compile-time warning” ??
But even so, I don’t get a warning in VS2010, and the fact that I gave it a C-style cast should avoid any warnings anyway… (?)
Actually, thanks to the cast I don’t get a warning neither.
What I forgot to metion is that I have “Smaller Type Check” enabled which is runtime , debug mode, check under VS2010
The exact error message is :
“Run-Time Check Failure #1 - A cast to smaller data type has caused a loss of data. If this was intentional, you should mask the source of the cast with the appropriate bitmask. For example: char c = (i & 0xFF); Changing the code in this way will not affect the quality of the resulting optimized code.”
Oh, I see… I had no idea such a thing existed! Well, it’s a false alarm, but I guess I can tweak it to stop it going off…
Me neither. Sometimes it’s usefull to catch weird bugs…
Anyway, and just FYI, the same error goes off here :
[code] /** Writes a unicode character to this string, and advances this pointer to point to the next position. */
void write (const juce_wchar charToWrite) noexcept
const uint32 c = (uint32) charToWrite;
if (c >= 0x80)
int numExtraBytes = 1;
if (c >= 0x800)
if (c >= 0x10000)
*data++ = (CharType) ((uint32) (0xff << (7 - numExtraBytes)) | (c >> (numExtraBytes * 6)));
while (--numExtraBytes >= 0)
*data++ = (CharType) (0x80 | (0x3f & (c >> (numExtraBytes * 6))));
*data++ = (CharType) c;
}[/code] (juce_CharPointer _UTF8.h)
Oh, well if it’s going to go off every time a number gets cast to a smaller size, then sod it, I’m not changing all that perfectly good code to avoid their false alarms. I’m sure there are lots of other places where it’ll be triggered too.
As far as I know, that’s the only places but as I said, it’s not too important. I just wanted to mention it, mainly in case there’s a nasty side effect at some point. Anyway, this runtime check isn’t turned on by default anyway so you may as well leave it like this …
“Type overflow” is not supposed to be turned on project-wide, the feature is mainly there for FIPS compliance and the prevention of attacks through code using malformed inputs.
Expecting JUCE to work with it turned on is quite frankly, unreasonable.
[quote=“TheVinn”]“Type overflow” is not supposed to be turned on project-wide, the feature is mainly there for FIPS compliance and the prevention of attacks through code using malformed inputs.
Expecting JUCE to work with it turned on is quite frankly, unreasonable.[/quote]
Well, I use juce a lot, both for audio, graphics, etc … in my app and except the 2 errors above, there’s no other error !