Herbert Duerr wrote: > With their int equivalents. E.g. > svx/inc/svx/svdpage.hxx: sal_uInt16 GetPageNum() const; > could be replaced by > svx/inc/svx/svdpage.hxx: int GetPageNum() const; > > And there are a gazillion other methods that can be found using grep > "sal_.*Int16" */inc/ > Of course all these are no high priority else they would have been > updated long ago... > Hi Herbert,
your suggestion shows the fundamental flaw I've pointed out earlier - that too much of the code makes implicit assumptions about the available int ranges. Just grep for 0xFFFF, 0xFFFE etc. and weep. Add to that performance implications - the Calc guys can likely tell the story much better than me, how 'simple' increases in row/column sizes affect overall speed. > When I look through other high profile multi-platform sources such > as gcc, the linux-kernel, etc. they have no problems to use native > types for everything except for interfaces defined by their ABI or > the API of the underlying platforms. > The kernel code presumably gets enough coverage with different int sizes over the range of supported platforms, that such bad code gets weeded out; besides I'm rather certain the kernel code is overall much more defensive than OOo's. gcc is a different league, compiler are usually no target for exploits. Ultimately, most of OOo's internal state stems from external input, and since there's no designed firewalling e.g. around the binary filters, I guess we're better safe than sorry, and not permit this extra dose of platform dependency, for no apparent benefit. Cheers, -- Thorsten
pgp3ZSDvoix3d.pgp
Description: PGP signature
