[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