On 2020-03-26, Daniel Silverstone <dsilvers@netsurf-browser.org> wrote:
>> The plan 9 compilers are not gcc, and do not handle many
>> gcc extensions like expression templates. this change
>> replaces them with either plain macros, or with static
>> inline functions, which are already in use elsewhere in
>> the project.
>
> I've reviewed the patch and it's not fundamentally bad, though
> the inline function for lwc_string_ref() will end up exploding the
> size of code a lot on many of our platforms.
>
> Instead I'd prefer to rework this to have the same effect for
> you, but to remain slightly less impactful on our other platforms.
>
> Could you let me know of a preprocessor macro I can rely on for plan9?
> With that, I can then rework this into something I hope will work
> for you, but also be nicer for the rest of our targets.
Hi there,
I've been using a similar patch[0] for my netsurf builds because my C
compiler, cproc, also does not support GNU C statement-expressions. I
hope that we can solve this without a plan9-specific #ifdef so that
the issue can be fixed for other non-GNU C compilers.
I'm curious as to why the inline function is exploding the code size
on other platforms. Is the code not getting inlined? If that's the
case, another option might be to just use plain `inline` in the
headers, and then make a `extern inline` declaration in
libwapcaplet.c. This way, anything that includes libwapcaplet.h will
be able to inline calls to lwc_string_ref if the compiler wants, and
if it doesn't, it will just use the single definition in
libwapcaplet.a (avoiding separate definitions for each translation
unit). I can provide a patch using this approach if you want check if
it works for your other platforms.
If this is not an option, then I would suggest using `#ifdef __GNUC__`
to check for the availability of statement-expressions rather than
assuming only plan9 lacks them.
[0] https://github.com/michaelforney/libwapcaplet/commit/5c4d56ff64856fb5d39a91d15df417934981e4fe
No comments:
Post a Comment