This reverts commit 9ab99483808bad973363f1f27bb548c8628ace1d. Coverity warning
about mkstemp without umask appears to be bogus (cf.
<https://communities.coverity.com/message/6516> "Why are uses of mkstemp
'without securely setting umask first' being flagged?) and calling umask is not
MT-safe, see fdo#60338 "FILESAVE: Saved files have incorrect permissions on
linux."
Modules sal, salhelper, cppu, cppuhelper, codemaker (selectively) and odk
have kept them, in order not to break external API (the automatic using declaration
is LO-internal).
Change-Id: I588fc9e0c45b914f824f91c0376980621d730f09
SAL_UNUSED_PARAMETER (expanding to __attribute__ ((unused)) for GCC)
is used to annotate legitimately unused parameters, so that static
analysis tools can tell legitimately unused parameters from truly
unnecessary ones. To that end, some patches for external modules
are also added, that are only applied when compiling with GCC and
add necessary __attribute__ ((unused)) in headers.
It simplifies function table and unwinding info management, as those
are now static for the privateSnippetExecutor() function in
call.asm. Even if it is slightly ugly to have to poke in more
instructions in codeSnippet().
Out privateSnippetExecutor() is much simpler than the x64 Linux one,
thanks to the simpler calling convention.
Now the call through the trampoline into cpp_vtable_call() seems to
work, but I get a crash later. Glitches in parameter passing, no
doubt. Debugging needed in cpp_vtable_call() and cpp2uno_call().
The basic implementation is probably sane. But I wonder if I after all
should have done like in the x86-64 Linux implementation, with the
dynamically generated trampoline just jumping into fixed code shared
between all trampolines. Probably should redo it like that, yes.
Will it then cause a problem for OS unwinding if the caller of the
trampoline calls a short dynamically generated code snippet, which
then jumps into the fixed part, and only the fixed part has a
(assembler-generated) function table and unwind info? Probably not.
It is quite impossible that such a short dynamically generated snippet
with just a couple of instructions would cause an exception, and when
we have jumped into the fixed part, where the call to
cpp_vtable_call() is done, it doesn't matter any more that the caller
in fact didn't call what the function table claims is the entry
point. Or does it?
Doing it that way would mean no RtlAddFunctionTable() and
RtlDeleteFunctionTable() would be needed, and especially doing the
latter correctly is a bit hairy.
2009-01-13 12:54:38 +0100 cmc r266213 : #i97320# might as well be silent if we fallback
2009-01-07 11:17:16 +0100 cmc r265957 : #i97320# use a double-mmap of an anonymous file under linux to keep onside of selinux
