zombe on 24/12/2014 at 14:24
Totally unrelated, but i need to vent a bit:
Had a nice (
http://s30.postimg.org/4flimc5pd/bsodding_day.png) bsodding day so far.
FFS, wtf does LONG even mean!? How bsodding long is LONG? Longer than mine? I doubt it! Arrrrrgggghhh!
Anyway, take care when using
weapons casts of mass destruction. And yes, that irpBitMap is missing an ampersand. Windows type "system" is quite inconsistent, i need to use the same variable as: LONG, ULONG and DWORD ... where LONG does not even make any bloody sense for BTS imo. I really really hate all the silly typenames - ie. ALL of them. Especially fun when half of the exact matches, for the target platform, can not be silently "converted"!
Whatever, still totally my fault.
Yakoob on 26/12/2014 at 00:34
Aah, the days of win32 programming. Yea all the SDK/APis use their own data types that are usually aliases of regular types. It's actually not a terrible idea when you consider cross-platform compatibility. I used to work on an inhouse engine once that did the same thing as well, since some data types were defined/handled slightly differently on Xbox vs Playstation for instance.
zombe on 27/12/2014 at 15:36
Quote Posted by Al_B
I'm surprised your cast didn't give a compiler warning.
I would be really surprised when any compiler ever would give a warning there.
A compiler should never give a warning that the user can not get rid of (disabling the warning itself does not count) - especially when the default setting for kernel mode driver compilation is "treat all warnings as errors". If, say, i legitimately wanted to use a 32 bit value as a pointer (to whatever, say LONG) - then how could i get rid of the warning?
Windows type system is quite "special" on top of C inheritance - it uses, partially, Systems Hungarian (which IMNSHO is profoundly retarded and inexcusable). But to be fair, most of the mess is because of C:
* long, short, etc and their intentionally ambiguous definitions (ADOPTING thous, the way they did, IS Microsoft's fault though)
* example "short int" -> unknown bit encoding, range at least -32767..32767 (not -32768 as is true for x86 as it uses two's complement)
* no boolean data type
At some point you need to have a specific encoding (dealing with external storage etc) -> absolutely have to redefine some other types for it to do it portably (i use __intXX [ex: int32u -> unsigned __int32] in VS, as thous are exactly defined and happen to match exactly most of the prevalent hardware).
In addition to that, it is often important to adhere to your platform specifically -> byte, word, dword, qword from the assembler world (thous types make some historical sense, but should be used only when needed in higher level languages).
Add all that together and you have one big blissful mess.
... umm ... i'm blabbering.
Al_B on 27/12/2014 at 20:01
Quote Posted by zombe
I would be really surprised when any compiler ever would give a warning there.
I thought from your puzzlement about the size of "LONG" that you were compiling 64 bit code. If you were then you would get a warning on that line depending on the data type of m_irpBitMap. If m_irpBitMap is defined as a LONG then it would be narrower than a LONG * under Microsoft's definition of the datatypes and gives a compiler warning - at least in Visual Studio. I've done a quick test and it appears that 32 bit platforms don't give you the same warning under equivalent conditions.
Quote Posted by zombe
At some point you need to have a specific encoding (dealing with external storage etc) -> absolutely have to redefine some other types for it to do it portably (i use __intXX [ex: int32u -> unsigned __int32] in VS, as thous are exactly defined and happen to match exactly most of the prevalent hardware).
Why not use C99's stdint.h? It's portable and does the same thing - e.g. uint32_t, int16_t, uint64_t, etc.
zombe on 28/12/2014 at 11:45
Quote Posted by Al_B
I thought from your puzzlement about the size of "LONG" that you were compiling 64 bit code. If you were then you would get a warning on that line depending on the data type of m_irpBitMap. If m_irpBitMap is defined as a LONG then it would be narrower than a LONG * under Microsoft's definition of the datatypes and gives a compiler warning - at least in Visual Studio. I've done a quick test and it appears that 32 bit platforms don't give you the same warning under equivalent conditions.
64bit code does not have RAX and friends ;). I knew how LONG was defined, i was just annoyed by the multitude of similar types used inconsistently and having stupid type names (LONG!? btw. "long", while i would never use it, is fine in my book, but LONG? ... sure Microsoft did not want to hang themselves by where-ever C standard chose to go [understandable at the time] and hence needed their version of exactly what "long" meant [ie. fairly unspecific], but nowadays it is just sooooo annoying).
I am intrigued, i can not see any scenario (32 or 64 bit target) where that code could sensibly give a warning with any compiler. Can you give a code example of what you meant?
Quote Posted by Al_B
Why not use C99's stdint.h? It's portable and does the same thing - e.g. uint32_t, int16_t, uint64_t, etc.
O_o, C99 had thous? I was fairly sure fixed integer types were added by C++11 (iirc, with an unspecified/implementation upper limit for some reason). In any case, back in the day i choose my types i found __intXX to do the job - also, i find "_t" suffixes revolting (well, any type that has "_" in it), but that is just me perhaps. Yeah, thous types are fine too.
Al_B on 28/12/2014 at 12:41
Quote Posted by zombe
I am intrigued, i can not see any scenario (32 or 64 bit target) where that code could sensibly give a warning with any compiler. Can you give a code example of what you meant?
Sure - (
http://msdn.microsoft.com/en-us/library/h97f4b9y.aspx) Warning C4312 can be raised by casting from a value to a pointer. There are a couple of examples there but it can happen with unsigned values as well as signed ones.
zombe on 29/12/2014 at 13:30
Ah, the 32-64 migration option. Since the warning comes only when specifically asked for then it is fine. It was deprecated with 2010 version and is in unsupported state since 2013 version (which i currently use). I have never used the option myself as it has no use (have never needed to convert broken 32 bit code to 64 bit) - just creates a bunch of invalid warnings (ie. the option is for migration and not normal every day use).
Al_B on 29/12/2014 at 15:04
It's certainly active on Visual Studio 2013 (which I also use) when all warnings are enabled. gcc also gives the equivalent warning by default "warning: cast to pointer from integer of different size" if the size of your variable and the pointer are different even with the explicit cast.
zombe on 30/12/2014 at 22:32
Interesting. What i see:
* VS2013 express edition (Win7 native or normal target [driver or v120 toolset]).
* I cannot find the option anywhere in property pages.
* No warning is given with warning level 4 (max).
* Several pages of utter-garbage-level (padding to struct added / inline used / etc) warnings are given with "enable all warnings" - the 32bit->pointer conversion is not among them.
Odd.
