include/saldirectory handle a number of pieces of functionality, described here.
main()entry point into LibreOffice is located in
main.h, and is designed as a bunch of macros. As LibreOffice is a cross-platform application that runs on both Unix-based and Windows operaing systems, it must have a flexible way of starting up the program. It does this by using the C preprocessor.
SAL_MAIN_IMPLboth define the
main()function of LibreOffice. The difference, as the name suggests, is that one takes arguments from the command line, and the other does not. We shall focus on
SAL_MAIN_WITH_ARGS_IMPLas they are both exactly the same except for one function call. The macro is defined as:
SAL_MAIN_IMPLis exactly the same, only it calls on
sal_main_with_args(). These macros do the following:
sal_detail_initialize(). This init function ensures that OS X closes all its file descriptors because non-sandboxed versions of LibreOffice can restart themselves (normally when updating extensions), but not close all their descriptors. It initializes the global timer, and on systems that have syslog sets this up for logging. It then prepares the command line arguments.
sal_main_with_args()which runs the main LibreOffice program logic
sal_main_with_args()ends, it calls on
WinMain()is defined on Windows systems, and expands to nothing on non-Windows systems.
WinMain()on Windows systems is the default entry-point of the Windows C Runtime Library (Windows CRT) - LibreOffice does all the heavy lifting in
sal_main(), which you define using the
SAL_MAIN_IMPLmacros like this:
include/sal/types.hheader contains a number of macros, typedefs and namespace aliases that allow LibreOffice to be cross-platform - and even build under different compilers. The compilers supported are:
sal_Boolis deprecated in favour of
bool, however it is still used in the UNO API so cannot be completely removed. All code other than the API should use bool
intis 4 bytes wide, but on 64-bit architectures a
longis 4 bytes wide (a
longis also called a
long intis 8 bytes wide, but as a
long intis 4 bytes wide on a 64-bit architecture, a
long longis needed for 8 byte wide longs
wchar_tis a typedef to
unsigned int, however MinGW has a native
wchar_twhich is the reason for this
SAL_MAX_[U]INT*<bit-width>*. The macros assume that the
sal_Int\*types use two's complement to represent the numbers.
alloca()function allocates (as its name suggests) temporary memory in the calling functions stack frame. As it is in the stack frame and not in the heap, it automatically gets freed when the function returns. However, it is a "dangerous" function in that if you allocate too much to the stack you can actually run out of stack space and your program will crash.
alloca()function, however, resides in a variety of locations on different operating systems - on Linux and Solaris, the function is stored in
alloca.h; in OS X, BSD and iOS systems it is in
sys/types.hand on Windows it is in
malloc.h. Due to this quirk, LibreOffice defines its own
alloca()is considered dangerous because it returns a pointer to the beginning of the space that it allocates when it is called. If you pass this
void*pointer to the calling function you may cause a stack overflow - in which case the behaviour is undefined. On Linux, there is also no indication if the stack frame cannot be extended.
private/tbsdy/workbench. To get them, do the following:
git checkout private/tbsdy/workbench
coredirectory, you can run each of the programs via