On Tue, Aug 02, 2011 at 09:56:46AM +0530, Marc-André Laverdière wrote:
I am inclined to think that we should follow suit and standardize on the
sal_* types, and not just on the boundaries. We are already in the
process of fixing our internals with vectors and different string APIs,
so that
2011/8/1 Marc-André Laverdière marc-an...@atc.tcs.com:
I remember that one rocket disintegrated because of an issue of types...
https://secure.wikimedia.org/wikipedia/en/wiki/Ariane_5_Flight_501
Thankfully, LO shouldn't be used in this way... but mismatching of types
(especially between
I remember that one rocket disintegrated because of an issue of types...
https://secure.wikimedia.org/wikipedia/en/wiki/Ariane_5_Flight_501
Thankfully, LO shouldn't be used in this way... but mismatching of types
(especially between modules) can be a source of a gazillion bugs and a
few security
On Tue, 2011-07-26 at 23:44 -0500, Norbert Thiebaud wrote:
the goal is also to get rid of BOOL, but again being careful with uno
interaction: if uno - sal_Bool otherwise bool
(this is particularly tricky when touching the prototype of a virtual
function... as all of the derived virtual of a
2011/7/26 Marc-André Laverdière marc-an...@atc.tcs.com:
This patch is bringing up a small question:
I thought we were trying to standardize the code to use sal_* types
everywhere...
Can anyone confirm/deny that?
No, not exactly.
it is actually the intention to use bool/true/false unless
2011/7/26 Marc-André Laverdière marc-an...@atc.tcs.com:
This patch is bringing up a small question:
I thought we were trying to standardize the code to use sal_* types
everywhere...
Can anyone confirm/deny that?
and also, more generally for local variable that have no impact
what-so-ever
