On Thu, Apr 23, 2015 at 5:23 PM, Logan Chien <[email protected]> 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 <[email protected]> > 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
_______________________________________________ cfe-commits mailing list [email protected] http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits
