[Geany-Devel] Lets move to C99

[Colomban Wendling]

Le 17/08/2013 01:01, Matthew Brush a écrit :
> On 13-08-16 01:57 PM, Colomban Wendling wrote:
>> Le 16/08/2013 22:09, Matthew Brush a écrit :
>>> [...]
>>
>>>>> P.S. Sorry for the bikeshed bait.
>>>>
>>>> Yeah, and sorry to sound so annoying (especially in the other mail ;),
>>>> but I really see this as "let's upgrade for the sake of upgrading", and
>>>> I don't see the point.  And this annoys me when you try to justify
>>>> it by
>>>> ranting against G* -- not that I care about the rant, but because
>>>> it's a
>>>> false justification.
>>>>
>>>
>>> Although I often do rant against G*, I didn't do that here at all, I
>>> don't think. My point is why does everyone (core devs and especially
>>> other drive-by contributors) have to use rules from before you were born
>>> (or so), just for the sake of you being able to stick -pedantic -std=c89
>>> on your compiler command line? It seems so arbitrary.
>>
>> A: Why not?  Or, so we don't get mixed declaration and code, it just
>> doesn't build with -std=c89 :)
>>
> 
> While I agree mixing declaration and code is almost always a bad thing
> (generally means you should have another scope), I'm pretty sure it does
> have sometimes a usefulness. One fake example could be:
> 
>     int foo, bar;
>     GtkWidget *blah;
> 
>     ... 50 lines of code using foo, bar and blah ...
> 
>     bool result = something_at_end(blah);
>     if (result)
>     do_something_special();
>     return result;

This may be OK-ish, but IMO yet not a reason to allow it.

>> Although I'm not fan of the idea, I wouldn't bikeshed against it if
>> there was a reason *to* do so.  The only one I see in your mail is
>> "Allowed to declare loop counter-style variable inside the for loop",
>> and I don't find it worth even updating HACKING.
>>
> 
> Actually I provided a list of 44 new features, of which we all seem to
> agree (even you) that a subset of those are useful.

None that I find, as ironically said, worth updating HACKING :)

>>> Even if it was only for // comments, what's the argument for *NOT*
>>> starting to use a well-established ISO standard that's already one full
>>> iteration behind the current standard? Sure we might only use 4 or 5
>>> "new" language features in practice as opposed to the full list I
>>> pasted, but so what? Why not? What do we lose by doing this?
>>
>> What do we get?
>>
> 
> I'm pretty sure I already gave a list of things, including a number of
> those that we all seem to think are useful, but I'll filter out and
> repeat here:
> 
> 1. Variable length arrays

OK, this would probably be usable in some places -- we have a few alloca
around there.  But this has to be used with care not to blow up the stack.

> 2. Translation unit limits (IIUC - and not super compelling)
>     - Longer string literals (from 509 chars to 4095) after concat
>     - Number of external variables (think of those from sys hdrs)
>     - Number of nested includes (again gtk/sys hdrs)
>     - Number of enumerators in an enum (from 127 to 1023)

You'll be happy, we probably break these already and we don't even care :)

> 3. Remove implicit int (useful for when you made a typo, like forgetting
> return statement, although compiler usually warns anyway).

As you say, it warns, and you can even make it fail I guess.

> 8. Extended integer types (can use std names rather than g ones)

G ones are just fine

> 9. Remove implicit func. decls (compiler usually warns, but still)

same as 3

> 10. Mixed declaration and code (as example above it *might* be useful
> once in a while, but nothing says our style guide can't disallow it).

You know what I think about this :)

> 11. Vararg macros (IIRC the thing you mentioned can be avoided by
> combining the arguments - would need to confirm, I've only used the GCC
> extensions for this).

ok, maybe, I don't remember the details.  But would we really use those
anyway?  IIRC I *once* wanted to use them (not in Geany), and given up
because they couldn't work anyway.

> 12. Trailing comma in enums (no biggie but it's useful in case of
> modifying or re-arranging existing code)

This one is indeed nice, yet nothing fancy

> 13. Inline functions guaranteed to hint the compiler (and without ugly g
> names)

AFAIK GLib simply defines "inline" if it's missing so it's just
available already (but may have no effect if the compiler don't support
them either by standard or with an extension GLib knows about)

> 14. snprintf (without using non-std g one)

g is fine

> 15. bool (without using non-std g named one - shorter and more readable,
> and can use "true" and "false" instead of non-std TRUE and FALSE macros,
> which is same as most other C-ish langs)

Almost all C code I ever saw, using or not GLib, *always* used uppercase
TRUE and FALSE, so it looks like it's normal for C programmers.

> 16. Empty macro arguments (might be useful for avoiding to break code by
> changing a function out for a function-like macro without arguments).

Huh?  "empty macro arguments" only means you can write FOO(,,42), not
that you can pass 2 args to a macro expecting 3.

> 17. VA_COPY (sometimes useful when passing around va_lists)

MIO would love this, but that's all -- copying VA isn't a common thing.

> So there's 17 reasons to allow using C99 (not including mentioned loop
> counter thingie), of which I'm sure you'll agree at least a handful
> could be well used in Geany.

Handful of hardly 1,5 :)

> And yeah G* provides wrappers for some of
> them, but why would we want to use non-standard G* wrappers rather than
> standard C unless we had to?

Why wouldn't we?  It's just a library in both cases, and the function
names are almost the same, and they work just the same.  IMO, this isn't
an argument in either direction, it's just a no-op.

> Think of new contributors who haven't used C since college (which likely
> could've been C99 at that point :), when they want to make changes to
> Geany they not only have to learn all of the G*-isms and follow our own
> style rules, but also code to a > 20 year old obsolete (twice over)
> language standard.

If they don't know C very well, they won't know what's in which standard
anyway, so switching standard won't change anything, but maybe make
random code "valid".  And "G-isms" is, again, a no-op: the only thing
that is any kind of hard to learn is the whole *useful* library, like
data types and utilities, not the C99 compatibility layer.  Maybe we
could use STL :)

>>> BTW, what originally inspired me to send this message was that many many
>>> PRs have this comment attached to them: "no //-style comment, we use
>>> C89" (paraphrasing). IMO that's a crap reason for blocking a
>>> contribution or making someone (who used a perfectly standard C feature)
>>> add another commit, squash it into the previous ones and open a new pull
>>> request (or however it gets dealt with).
>>
>> We cant change them ourselves, indeed.  But even if we started to use
>> C99 (why?), I'd still would like to keep our style -- which does include
>> "no C++-style comments" :)  Why?  Because I like it, because it'd be
>> consistent with the rest of the sources, and because it doesn't hurt.
>> Yesterday I said "no blank line at start of block": this has nothing to
>> do with the language, it's just useless and ugly.
>>
> 
> I'm not advocating for throwing away our style guide at all, just that
> we should allow some C99 and update our guide accordingly. And FWIW,
> they aren't "C++-style comments", they're "standard C comments" since
> over 10 years,

Yet everybody calls them "C++-style", IIUC because C++ introduced them,
and C99 (or 94?) took them from here.

> and you're the only person I've heard say they don't
> like/use em :)

As said earlier, I use and like them for debugging and temporary stuff,
but yes, I hate comments spanning multiple lines and using single-line
comments markers.  And don't use those even in languages where nobody
cares the standard like PHP or so.

> And one last note is that we have a giant glob of C++ in our source tree
> that is moving towards C++11[1] (which not surprisingly uses //
> comments),

Those are C++ comments and it's C++, there must be something here ;)

> and I'm pretty ruins any chance of compiling Geany on a
> pocket calculator that only supports ancient C89 compilers :)

This is an argument not to forcefully stick to an old standard, not to
switch to a newer one :)  Who can the most can the less :)

Cheers,
Colomban