Mailing-List: contact dev-help@openoffice.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@openoffice.apache.org
MIME-Version: 1.0
In-Reply-To: <56D95C86.5010602@acm.org>
References: <003c01d17323$b021a6a0$1064f3e0$@acm.org>
 <56D72FF5.9090307@acm.org>
 <00ab01d174bb$a5d0dc90$f17295b0$@acm.org>
 <005c01d17580$ecab0670$c6011350$@acm.org>
 <56D8BCC3.4070008@acm.org> <00d801d175b1$4fff2f00$effd8d00$@acm.org>
 <56D8E840.8050205@acm.org>
 <CAJm2B-k1K34tmkRdiO+ZNXTuMLVGwrgsmSTX7hqKOZT-t=dZiQ@mail.gmail.com>
 <56D95C86.5010602@acm.org>
From: Damjan Jovanovic <damjan@apache.org>
Date: Fri, 4 Mar 2016 14:40:58 +0200
Message-ID: 
 <CAJm2B-=yxqGbxpa-pWpC_Txsk0Pw=kxHzywhKXjorF3xfAqtaw@mail.gmail.com>
Subject: Re: Profile.c bugs (was RE: Some thoughts on the learning curve)
To: Apache OO <dev@openoffice.apache.org>
Content-Type: text/plain; charset=UTF-8

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