On Mon, Mar 14, 2016 at 8:39 AM, Tom Hacohen <t...@osg.samsung.com> wrote:
> On 14/03/16 11:23, Jean-Philippe André wrote:
>> Hi,
[snip]
>> No objections but I'm not 100% sure what is the plan?
>> Is it to have two versions of eo_add depending on #ifdef GCC, like below?
>> - if not GCC, use a TLS stack and a macro eo_self returning the top value
>> - if GCC, use GCC construct ({ Eo *eo_self = internal_add(); ... ; eo_self;
>> })
>>
>> If that's the plan, then I'm happy with it.
>> eo_self or eo_this or whatever short and meaningful enough are fine :)
>>
>
> This is exactly the plan.
I liked the idea before realizing we'd still needed the GCC extension.
I'm against if it uses TLS for non-GCC-extension-compatible compilers.
We're going to have a piece of code that nobody uses, nobody tests, to
say we're portable, when it will actually bit rot and break when
somebody actually tries to use it. They will think this is a bad piece
of code (or maybe even too slow to use) and will just abandon before
even bug report it.
And it will not be valuable enough to test (possibly raising our test
infra 30%) for something that nobody uses now or will in the
foreseable future.
Or we require GCC-extension, or we just use the uglier version IMO.
[snip]
> --
> Tom.
Regards,
--
Felipe Magno de Almeida
------------------------------------------------------------------------------
Transform Data into Opportunity.
Accelerate data analysis in your applications with
Intel Data Analytics Acceleration Library.
Click to learn more.
http://pubads.g.doubleclick.net/gampad/clk?id=278785231&iu=/4140
_______________________________________________
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
