https://bugs.freedesktop.org/show_bug.cgi?id=49602
Stephan Bergmann <sberg...@redhat.com> changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|UNCONFIRMED |NEW
Whiteboard|Need_Advice |
Summary|Remove deprecated |Remove deprecated OSL
|include/osl/profile.hxx |Profile functionality
Ever confirmed|0 |1
--- Comment #2 from Stephan Bergmann <sberg...@redhat.com> ---
(In reply to comment #0)
> Seems the only user of it is sal/rtl/source/bootstrap.cxx
>
> it could easily be replaced with something like:
>
> oslProfile profile = osl_openProfile(strProfileName.pData, Options);
> if( ! profile )
> throw std::exception();
>
> sal_Char aBuf[1024];
> rtl::OString ret= osl_readProfileString( profile, rSection.getStr(),
> rEntry.getStr(), aBuf, sizeof( aBuf ), rDefault.getStr() ) ? rtl::OString(
> aBuf ) : rtl::OString();
>
> osl_closeProfile(profile);
>
> return ret;
Given the comment preceding the (only) use of osl::Profile in
sal/rtl/bootstrap.cxx,
// Going through osl::Profile, this code erroneously
// does not recursively expand macros in the resulting
// replacement text (and if it did, it would fail to
// detect cycles that pass through here):
it does not make much sense to merely unwrap that code from using the C++
osl/profile.hxx wrapper to using the underlying C osl/profile.h functionality.
Also note that this is part of the stable URE interface, so cannot be modified
arbitrarily (but can arguably be removed in an incompatible release, as it is
deprecated for a long time and should effectively be unused by client code).
So, a useful approach could be:
* Adapt sal/rtl/bootstrap.cxx to no longer use the OSL Profile functionality,
and in doing so fix the bug described in the comment above.
* In a commit with "[API CHANGE]" in the commit message, remove the
include/osl/profile.hxx wrapper.
* In the same or a subsequent "[API CHANGE]" commit, also remove
include/sal/profile.h and replace the implementation with stubs in
sal/osl/all/compat.cxx (which are necessary as the corresponding symbols could
not be removed from sal/util/sal.map without changing the sal SONAME, which we
do not want to do).
* Document the incompatible changes in the "API Changes" section of the
relevant <https://wiki.documentfoundation.org/ReleaseNotes>.
--
You are receiving this mail because:
You are the assignee for the bug.
_______________________________________________
Libreoffice-bugs mailing list
Libreoffice-bugs@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice-bugs
