https://bugzilla.mozilla.org/show_bug.cgi?id=265084
I have checked in initial support for turning nscoord from 'PRInt32' to 'float'. When nscoord is 'float', we do not allow it to ever have a fraction; it's still always an integral number of fractional units. But being a float still has advantages: NS_MAXSIZE can be IEEE positive infinity, which has the arithmetic properties we want (e.g., +Inf + X = +Inf for finite X); but more importantly, we can handle extremely large offsets without overflowing and wrapping around to a negative number. This should make layout much more robust to corrupt or malicious content specifying absurd sizes or positions. The performance implications are currently unknown; they could be good (because layout will start using processor registers and functional units that are currently idle) or they could be bad (because code size will probably increase and floating point code may not be as efficient as integer code for the processor and/or compiler). The selection of PRInt32 or float is governed by a preprocessor macro in nscoord.h.
Currently there are lots of places where we assume nscoord is PRInt32 and use nscoords where we just want integers or vice versa. These will need to be cleaned up before we can build with the switch on. My plan is to use nscoords for all application units (twips) values, and for those values only. In particular, variables which hold pixel offsets must be PRInt32 (or possibly float in rare cases where we care about fractional pixels). I have defined nsIntRect, nsIntSize, nsIntMargin and nsIntPoint types for working in pixel space. When the float switch is off, they're just aliases for nsRect, nsSize, nsMargin and nsPoint. Even if we never turn on the float switch for production builds, I believe that these changes will make the code clearer.
The next step is to go through the entire codebase and locate the places that must be converted from nscoord to PRInt32 (or vice versa) and convert them. This can be done piecemeal I will be submitting patches for this soon.
Rob _______________________________________________ mozilla-layout mailing list [EMAIL PROTECTED] http://mail.mozilla.org/listinfo/mozilla-layout
