[libcxxabi] r228903 - unwind: move exported APIs out of header

Saleem Abdulrasool compnerd at compnerd.org
Thu Apr 23 18:48:31 PDT 2015


On Thu, Apr 23, 2015 at 5:23 PM, Logan Chien <tzuhsiang.chien at gmail.com>
wrote:

> Hi Saleem,
>
> Any updated comments on this?  Thanks.
>

Sorry, been busy with other things for a while.

I agree that we shouldn't extend the API/ABI without due consideration.  Im
merely requesting that we maintain parity with the existing APIs in the
other implementations.  The interfaces here need to be provided for such
compatibility.


> Logan
>
> On Tue, Mar 24, 2015 at 5:46 AM, Logan Chien <tzuhsiang.chien at gmail.com>
> wrote:
>
>> Hi Saleem,
>>
>> Sorry for the late reply.
>>
>> Although I am not strongly oppose to the idea to provide both inline and
>> extern version, I am concerned that exporting these symbols will further
>> fragmentize the ecosystem.  With these symbol exported, some application
>> will start to simply declaring their own prototype and referencing the
>> these functions directly instead of including <unwind.h>.  IMO, it should
>> be conservative to extend an ABI especially when the extension is neither
>> documented nor de facto in the ARM ecosystem.
>>
>> > On the other hand, when applications are using the interfaces,
>> expecting the unwind APIs, I think that they should continue to function.
>> Providing both the external as well as the inlined version should achieve
>> that.
>>
>> In fact, this is what I wish to avoid.  IMO, for the application
>> developers, they should simply include <unwind.h> if they need these
>> functions, instead of declaring their own function prototype.
>>
>> Sincerely,
>> Logan
>>
>
>


-- 
Saleem Abdulrasool
compnerd (at) compnerd (dot) org
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-commits/attachments/20150423/af94f558/attachment.html>


More information about the cfe-commits mailing list