The C-style definitions of SAL_CONST_CAST and SAL_STATIC_CAST

Michael Stahl mstahl at redhat.com
Tue Apr 3 09:48:34 PDT 2012


On 03/04/12 18:36, Lubos Lunak wrote:
> On Tuesday 03 of April 2012, Lubos Lunak wrote:
>> On Tuesday 03 of April 2012, Michael Meeks wrote:
>>> On Tue, 2012-04-03 at 17:52 +0200, Lubos Lunak wrote:
>>>> On Tuesday 03 of April 2012, Tor Lillqvist wrote:
>>>>> (SAL_REINTERPRET_CAST is not used anywhere, says opengrok, so that
>>>>> can be binned outright.)
>>>>
>>>>  Stuff from sal/ is public API, so you should not remove anything from
>>>> there or you might break backwards compatibility for somebody (the fix
>>>> is trivial here, but still).
>>>
>>> 	True, true - but pragmatically if you have an old extension, that you
>>> want to work on lots of older OpenOffice.org's / LibreOffices you'll
>>> want to build with an old SDK, since the new ones automagically require
>>> a newer LibreOffice.
>>
>>  Although this may seem like being overly pedantic, it's quite possible
>> that there is an extension that simply still uses the macro in the code
>> just as a relic of the past, even though otherwise it would have no problem
>> with recent SDK. And the cost in LO is leaving one simple macro in,
>> compared to a possibly massive search&replace.
> 
>  But the main thing I didn't say, it's easier to keep the mindset "SAL is 
> public API, so we don't break backwards compatibility there (unless possibly 
> really really necessary)", rather than "opengrok didn't find anything, I can 
> nuke it".

is there some macro that is defined by LO build system for which we can
assume that nobody outside of LO uses it?  we could wrap the deprecated
cruft in an #ifndef now, and remove it for LO4.



More information about the LibreOffice mailing list