Re: [Libreoffice] Small Question About sal_* Types

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 issues. I guess that is the reason why POSIX and Windows
APIs have created all sorts of types like HANDLE and size_t :)

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 change could be done gradually as we go along.

Just my 2 paisa ;)

Marc-André Laverdière
Software Security Scientist
Innovation Labs, Tata Consultancy Services
Hyderabad, India

On 07/27/2011 10:25 AM, Norbert Thiebaud wrote:
> 2011/7/26 Marc-André Laverdière <marc-andre@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 with UNO interface it is ok to use standard type like
> size_t
>
> I _personnaly_ (as-in that is not necessarily a consensus view) think
> that sal_* type should be reserved exclusively for UNO interface. and
> for stuff that need 'cross-platform' serialization in general. that
> would have the merit of drawing attention to these border-zone.
> But of course that benefit would require a complete an systematic
> review of sal_* usage... which is not practical... so the compromise
> is use sal_* for sure in UNO case and serialisation case, but other
> than that, let dev be and use sane standard type if they want to.
>
>
> Norbert
> _______________________________________________
> LibreOffice mailing list
> LibreOffice@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/libreoffice