Thank you for your replies, for the future I will use bool when substituting BOOL outside of the UNO API.
With respect to ULONG, I, as Norbert correctly observed, used sal_uIntPtr because of the typedef in tools/solar.h, but what should I use instead? It seems there are the following possibilities: - unsigned long - sal_uInt32 (could be too short on 64-bit systems) - sal_uIntPtr (wrong) - C99 data types (but which of these, and as Norbert writes this would require a compat.h for Microsoft compilers, and I have no idea how to do this (and no Microsoft compiler to test it)) I would like to do similar removements of dependencies on tools/ in other files in sc/inc/ (and the related source files), so it would be nice to know. which data types I should use instead. Regards Sören 2011/1/4 Norbert Thiebaud <nthieb...@gmail.com>: > On Mon, Jan 3, 2011 at 10:36 PM, Kohei Yoshida <kyosh...@novell.com> wrote: >> On Mon, 2011-01-03 at 21:47 +0100, Soeren Moeller wrote: >>> Hi >>> >>> I have removed dependencies on tools/solar.h in some files in sc >>> (according to >>> http://wiki.documentfoundation.org/Easy_Hacks#write_tools.2F_pieces_out >>> ) please review and commit. >> >> Thanks, pushed! >> >> BTW, we generally prefer the standard bool over sal_Bool, so I replaced >> sal_Bool with bool in your patch. The only place we need to use >> sal_Bool is when dealing with the UNO API. Other than that, the >> standard boolean type is preferred. >> >> Also, it's a bit weird to use sal_uIntPtr which isn't used much in our >> code base. So I replaced that with sal_uInt32. > > Kohei, > > I have not read the related code, but in principle uintptr_t and > int32_t are not interchangeable. > int32_t is 32 bit long, uintptr_t is supposed to be the same size > than void* (that is 32 or 64 bits) > > in our sources, > ULONG is typedef'ed as sal_uIntPrt (in tools/solar.h) , which is wrong (*) > but that explain why Soeren used sal_uIntPtr. > > (*) it is wrong because there are multiple model of 64 bits support. > Notoriously, Microsoft, as usual, instead of fixing their 64 bits > support bugs, have, once again, turn their bugs into a standard and > use the so-called LLP64 model, in which sizeof(long) != sizeof(void*) > Note that ULONG is defined at multiple place, most of them as unsigned > long (which conflict with the main definition of ULONG = sal_uIntPtr). > Which raise the following question: has anyone successfully built > LibreOffice for Win64 ? > > > Note: > C99 has been a standard for quite a while now. why are we not using > the standardized type for these. that is: > int8_t uint8_t, int16_t, uint16_t, int32_t, uint32_t, int64_t, > uint64_t, intptr_t, uintptr_t,... > see http://en.wikipedia.org/wiki/Stdint.h > > Yes, I know, Microsoft still do not have a compiler compliant with the > C-standard published 10 years ago... but that can be worked around > with a compat.h header to hide Microsoft's screw-ups, without > 'uglyfying' the rest of the code. > >> >> Kohei >> >> -- >> Kohei Yoshida, LibreOffice hacker, Calc >> <kyosh...@novell.com> >> >> _______________________________________________ >> LibreOffice mailing list >> LibreOffice@lists.freedesktop.org >> http://lists.freedesktop.org/mailman/listinfo/libreoffice >> > _______________________________________________ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
