[ccan] ccan and C standards newer than gnu89
Hugh Blemings
hugh at blemings.org
Fri Aug 21 07:13:47 AEST 2015
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 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").
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 :)
Cheers,
Hugh
More information about the ccan
mailing list