[Geany-Devel] Lets move to C99

[Matthew Brush]

On 13-08-16 01:57 PM, Colomban Wendling wrote:
> Le 16/08/2013 22:09, Matthew Brush a écrit :
>> [...]
>>
>> Not meant as a rant against G*,
>
> Sorry then, I read the final sentences as such, sorry.
>
>> when it was started (~1998 IIRC), there
>> was a reason for wrapping all the (then) non-standard stuff for
>> portability. But now, it just makes it harder for people to contribute
>> code since many are used to using standard C (or more likely C++) and
>> have to double check everything to make sure that nothing post 1989 was
>> used unless it has a g in front of it.
>
> You're dreaming, I 99.99999% sure *nobody* does it, and if we don't have
> to change much is only because there aren't much use of the things C99
> adds.  And at worse it's only adding "g_" in front, it doesn't really
> mangle the name.
>
>>>> 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;

> 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.

>> 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
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)
3. Remove implicit int (useful for when you made a typo, like forgetting 
return statement, although compiler usually warns anyway).
4. Reliable integer division (always rounds in same direction)
5. Compound literals
6. Designated initializers
7. // comments
8. Extended integer types (can use std names rather than g ones)
9. Remove implicit func. decls (compiler usually warns, but still)
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).
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).
12. Trailing comma in enums (no biggie but it's useful in case of 
modifying or re-arranging existing code)
13. Inline functions guaranteed to hint the compiler (and without ugly g 
names)
14. snprintf (without using non-std g one)
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)
16. Empty macro arguments (might be useful for avoiding to break code by 
changing a function out for a function-like macro without arguments).
17. VA_COPY (sometimes useful when passing around va_lists)

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. 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?

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.

>> 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, and you're the only person I've heard say they don't 
like/use em :)

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), and I'm pretty ruins any chance of compiling Geany on a 
pocket calculator that only supports ancient C89 compilers :)

Let's party like it's 1999!

Cheers,
Matthew Brush

[1] https://groups.google.com/forum/#!topic/scintilla-interest/j5xKrl9cU2g