[Bf-committers] Sharp/Flat selections

Chris Want cwant at ualberta.ca
Wed Dec 28 22:48:19 CET 2005

Ken Hughes wrote:
> Tom M wrote:
>>> One thing I don't like about this code (and this certainly
>>> isn't the only place in the code this happens), is that
>>> it uses the fact that the (short int) edge flags eed->f1
>>> and eed->f2 are consecutive, and casts that storage to
>>> be a long int.
>> Is that safe for 64 bit systems too?  Also are compilers allowed to
>> reorder stuff in structs at high optimization levels?  Also would
>> making it a true long int and having the old f1 and f2 accessed via a
>> bitmask method work?
> It would be problematic on 64-bit machines anyway. Isn't a short int 
> should 16-bits but on 64-bit machines (except WinXP) a long would be 
> 64-bits?  Or is a long int the same as an int?

Hi Ken,

I think you're right, at least according to
the data models presented on this page:


What it boils down to is that I need at least
a 32 bit integer (it is unlikely we will see
meshes with more than 2 billion edges for some
time). I think Ton says he would like to adopt
the LP64 standard (with typedef's for windows),
so it seems that an 'int' would be a better choice there.
An int causes problems with the LP32 standard though,
so maybe an #ifdef is needed to do the right thing (long
for 32 bits, int for 64 bits). Best of all worlds though
would be to have a flag that is a long.

Btw, does anybody have any comments on the functionality
of the patch that aren't related to the abuse of flags?


More information about the Bf-committers mailing list