Re: [Lcms-user] OSX Warnings

[Noel C. <NCa...@Pr...>]

>Have test compiles also been done for 64-bit Windows builds?

Yes, that's what I have been doing.

Not to worry, the 64 bit Visual Studio compiler for Windows lets you
know if you have coded implicit conversions that could lose data.  I'll
confirm what Marti has said - the Little CMS library compiles clean
w/regard to 32 vs. 64 bit variables (not to mention runs properly) on
x64 Windows.

>> http://my.cdash.org/buildSummary.php?buildid=1262991

>For 64-bit Windows builds, 'unsigned long' is only a 32-bit type but
'size_t' is a 64-bit type.  It seems likely that
>there are many more problems when computing size_t values given
apparent assumptions that 'unsigned long' will be >large enough.
Integer overflow may occur.
>There will also be more prominence of sign-extension problems, which
can create security risks.

Note that the warnings Aaron showed are specifically about sign
conversion, not about data size, because it is possible data could be
lost (e.g., negative numbers turned into positive numbers) no matter
what size the variables are.

It is always possible to implicitly promote a smaller unsigned integer
into a larger one, thus you would not see a warning if a 32 bit unsigned
int value were provided in the 3rd argument of a memmove call.

Although IMHO it's often better form to use size_t when you are
expressing the size of something in code, even if you know it will
always fit in a smaller unsigned int or unsigned long variable.

That being said, I have seen both better and worse generated code by
using a 64 bit size_t data type for e.g., an index variable.  If there
are sufficient registers for the compiler to optimize the coded routine
well, the generated code is usually better, since the machine
instructions needed to convert 32 bit values to 64 bit values are
eliminated.  But it isn't always the case, especially if there's
register starvation (e.g., a function is a bit more complex than what
"fits" well with the processor architecture).  In those cases, when data
has to be pushed onto / popped off of the stack, the additional overhead
of moving 64 bits to/from RAM where 32 would suffice (because the number
is small, something like 0x0000000000000004) can actually slow things
down.

-Noel