openoffice-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Damjan Jovanovic <dam...@apache.org>
Subject Re: Profile.c bugs (was RE: Some thoughts on the learning curve)
Date Fri, 04 Mar 2016 12:40:58 GMT
On Fri, Mar 4, 2016 at 11:59 AM, Patricia Shanahan <pats@acm.org> wrote:
> On 3/4/2016 12:54 AM, Damjan Jovanovic wrote:
>>
>> ELF binaries (Linux, *BSD) fundamentally use one of the worst ideas of
>> all time: symbols are process scoped (unlike on Windows and MacOS
>> where they're library scoped), meaning that symbols with the same name
>> can clash even if in different libraries loaded through arbitrary
>> layers of indirection. For example, compiling AOO with GCC on recent
>> FreeBSD easily crashes AOO because both GCC's and Clang's C++ runtime
>> libraries are loaded, their symbols clash with each other, and their
>> ABIs are not fully compatible -> memory corruption -> undebuggable
>> crash. Symbol map files are supposed to work around the problem
>> because the UDK_3_0_0 becomes part of the symbol name and makes it
>> more globally unique.
>>
>> I don't know if UDK_3_0_0 is correct since we are on AOO version 4 now
>> (or do we version UDK differently?).
>
>
> Embedding version numbers in source code should be done very sparingly,
> because it grows old fast.
>
>>
>> Also UNO is all good in theory, but in practice plugins can always use
>> run-time dynamic linking to load any library and call any exported
>> function (which the profile functions are) - even when running in a
>> separate process, or written a different language (eg. JNA/BridJ for
>> Java). Whether they actually do this in practice is the more important
>> question.
>
>
> I have a possibly pathetic hope that the 14 year deprecation of the
> functions may have discouraged their direct use in plugins.
>
>

main/sal/rtl/source/bootstrap.cxx uses osl::Profile().readString() in
1 place. osl::Profile found in main/sal/inc/osl/profile.hxx is a thin
C++ wrapper around the C API. That seems to be the extent of the usage
of the profile API in SVN trunk. I can't remember where else I found
them, but on https://wiki.openoffice.org/wiki/Documentation/DevGuide/WritingUNO/Manual_Component_Installation
there is a brief mention of these ini/rc files that I suspect are
parsed by the profile API. Examples are in the program/ directory of
the AOO installation (there is quite a few, all ending in ".ini" on
Windows and "rc" elsewhere, eg. uno.ini/unorc).

As for locking, all platforms can and do lock the file against access
from other processes (LockFileEx on Windows, fcntl+F_SETLKW on *nix)
though on *nix it is only *advisory* locking. The pthread API would
only be useful to ensure thread safety within the process. I presume
"bootstrapping" only happens once per process, so it can't really be
multi threaded anyway?

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@openoffice.apache.org
For additional commands, e-mail: dev-help@openoffice.apache.org


Mime
View raw message