[ccan] ccan and C standards newer than gnu89

[Cody P Schafer]

On Thu, Aug 20, 2015 at 5:13 PM, Hugh Blemings <hugh at blemings.org> wrote:
> Hiya,
>
> On 21/08/2015 6:57, David Gibson wrote:
>>
>> On Wed, Aug 19, 2015 at 11:54:43PM -0700, Hugh Blemings wrote:
>>>
>>> Hiya,
>>>
>>>> On 19 Aug 2015, at 23:04, Rusty Russell <rusty at rustcorp.com.au> wrote:
>>>>
>>>> Cody P Schafer <dev at codyps.com> writes:
>>>>>
>>>>> I while back, I submitted a module that depended on some c99 behavior
>>>>> (inline & extern inline) that isn't quite avalaible in gnu89, and as a
>>>>> result was rejected at the time.
>>>>>
>>>>> Now that gcc has switched it's default to gnu11 (which includes the
>>>>> behavior of inline & extern inline I needed), I'm wondering if modules
>>>>> that need non-gnu89 features might be submittable.
>>>>
>>>>
>>>> Hmm, maybe it is time?  It's best if it doesn't completely break older
>>>> compilers though...
>>>

I'd like to note that a few modules already depend on c99 features
(notably, bool) that happen to work in gnu89 mode.

It seems unlikely that a compiler that supports c99 _Bool wouldn't
support c99 extern inline vs inline (given apropriate compiler options
are passed)

I suppose we could add a way to mark certain modules as depending on
certain c standard revisons (and could detect this via the standard
__STDC_VERSION__ define).

>>>
>>> I apologise for framing this as a generality but I wonder if it's
>>> feasible to make this build time configurable so you can get some
>>> ccan goodness even with an older compiler, just not the newer
>>> modules ? Seek to confine the reliance on new functions as much as
>>> possible without hamstringing the whole endeavour perhaps.
>>
>>
>> The difficulty isn't new functions - they're easily filled in for old
>> compilers / libraries.  The problem is new syntax, and - worst of all
>> - changed semantics for existing syntax (like the meaning of "static
>> inline" and "extern inline").
>

Just for clarity, the issue I had was the meaning of "extern inline"
vs "inline": gnu89 and c99 have swapped meanings for those. There is
no issue with "static inline".

>
> Ah, ok, I understand.
>
>> It *can* generally be made built time configurable, but it usually
>> requires ugly macros scattered in an unpleasantly large number of
>> locations.
>
>
> That sounds unpleasant.  Perhaps we publicise a version or tag of ccan that
> is "old compiler compliant" and people just pull that older version.  If
> it's missing functionality they require from later ccan versions, their
> backport patches are welcome :)
>

When I first tried to get the module in question merged (which needed
c99-inline), after the initial rejection I looked at adding a
configurator test for the style of inline supported. Unfortunately, I
couldn't find a way to check the style of inline without needing to
build more than 1 source file (and then link them together), which
would have required more restructuring to configurator than I was
willing to do.