On 2020-03-26, Daniel Silverstone <dsilv...@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
