Am 2013-08-16 08:36, schrieb Lex Trotman:

In general I don't see any point in keeping compatibility with a standard as old as C89, what target (that we support) still needs that?

IIRC this was due to on Solaris system and others C99 was not fully supported. Honestly I have no clue what's the current status at this as with upgrading Gtk-dependency in past we might have lost the C89-compat. already.

Cheers, Frank

Am 2013-08-16 10:21, schrieb Matthew Brush:

On 13-08-16 01:18 AM, Frank Lanitz wrote:

...

Am 2013-08-16 08:36, schrieb Lex Trotman:

...

In general I don't see any point in keeping compatibility with a standard as old as C89, what target (that we support) still needs that?

IIRC this was due to on Solaris system and others C99 was not fully supported. Honestly I have no clue what's the current status at this as with upgrading Gtk-dependency in past we might have lost the C89-compat. already.

AFAIK we and GTK+ still conform to strict C89 including recent GTK+3 updates, but I think C99 support in GCC (our main targeted compiler) is quite robust for a long time on all targets where Geany is used (presumably).

There were some real old plattforms to keep on supporting running a gcc 2.9x ... IIRC Solaris 9.

We have to check the *x-world beside of Linux I think here.

Cheers, Frank

On 16/08/2013 07:36, Lex Trotman wrote:

The more we can allow modern(ish :) programming styles using a well known standard the simpler it is to produce correct code (eg inlines not macros, who will remember that EMPTY may compute its arguments multiple times).

That's why it's in capitals, so it's clear it's a macro. An inline would be better, good idea. Though for FALLBACK we don't know the return type.

At the moment C11 is too new (not enough complete support) but C99 is fine.

Unless we follow the example of gcc itself and upgrade to C++ :)

Not sure that's a good idea for Geany now, although I'm glad that gcc did it. They use a restricted subset IIRC. I miss templates and RAII in C though.

...

** - restricted pointers

C90 allows __restrict.

...

** - variable-length arrays

Not sure that's much better than g_alloca.

...

** - flexible array members

http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.dui0472c/BABECHJ...

Looks interesting, not sure we'll use it though. There's some other C99 info on that site in the sidebar.

...

** - // comments

yes please

...

** - mixed declarations and code

nice

...

** - inline functions

C90 allows __inline (GLib also has a macro for it).

...

** - the snprintf family of functions

g_snprintf?

...

• Allowed to use // style comments
• Allowed to declare loop counter-style variable inside the for loop.

amen

...

• Use standard C instead of G*-portability wrappers in various place

(bool, fixed-width ints, etc.).

I might use bool because it's shorter than gboolean, but I'm not sure about the others.

</tuppenceworth>

Am 16.08.2013 13:38, schrieb Nick Treleaven:

On 16/08/2013 07:36, Lex Trotman wrote:

...

...

** - restricted pointers

C90 allows __restrict.

...

...

** - inline functions

C90 allows __inline (GLib also has a macro for it).

Are you sure about this one? Perhaps you confuse it with a compiler extension. E.g GCC supports inline for C89 as a GNU extension (with slightly different semantics than the C99 version) but I'm pretty sure ANSI C does not support it.

Same for your __restrict point.

Best regards.

…and now the detailed rant, not in the other mail to stay constructive :)

<rant>

Le 16/08/2013 08:07, Matthew Brush a écrit :

Hi,

Up till now we've tried to stay compatible with ANSI C89 because of GTK+-stack doing so (unless I missed the real reason?).

No idea. BTW, note that even latest GCC don't fully support C99 http://gcc.gnu.org/c99status.html

I propose we update to allowing C99 for the following reasons:

I don't.

• restricted character set support in <iso646.h> (originally specifed in

AMD1)

WTF.

• wide-character library support in <wchar.h> and <wctype.h> (originally

specifed in AMD1)

only Windows actually uses this, and G* uses char* holding UTF-8 bytes, no point for us.

• restricted pointers

which are a trick to help the compiler, and that we probably wouldn't use anyway.

• variable-length arrays

That's partially useful, yet not terribly missing for me.

• fexible array members

Err. IIRC most compilers don't like that, and that's the single most prominent reason why they don't claim to support C99 (may be wrong, I can't trust my memory :-').

Ah, and BTW we don't want to use that anyway :)

• complex (and imaginary) support in <complex.h>
• type-generic math macros in <tgmath.h>
• the long long int type and library functions

Very useful for a test editor :)

• increased translation limits

Cool.

• remove implicit int

Just don't use it.

• the vscanf family of functions

We don't need those I'd say, and G* propose them anyway.

• reliable integer division

What does this mean?

• universal character names
• extended identifers

?

• binary foating-point literals and printf/scanf conversion specifers

Fun.

• compound literals

That's real fun, I must admit.

• designated initializers

We used to use those for arrays, but I never saw much point in them. For structure though they are nice.

• // comments

Fun.

• extended integer types in <inttypes.h> and <stdint.h>

Cool.

• remove implicit function declaration

Just don't use that.

• preprocessor arithmetic done in intmax_t/uintmax_t

Cool.

• mixed declarations and code

NOOOOOOOOOOOOOOOOOOOOOOOO!

• integer constant type rules
• integer promotion rules

What did change?

• vararg macros

Those are fun, but still broken IIRC (e.g. usage has limitation, like requires some arg, I don't remember the details)

• additional math library functions in <math.h>
• foating-point environment access in <fenv.h>
• IEC 60559 (also known as IEC 559 or IEEE arithmetic) support

Fun.

• trailing comma allowed in enum declaration

Fun, would remove 1 character change in some commits, not that useful.

• %lf conversion specifer allowed in printf

Fun.

• inline functions

Those are nice, but I think G* provide them if available, and the compilers generally are clever enough to inline some anyway.

• the snprintf family of functions

g*

• boolean type in <stdbool.h>

what a new thing. gboolean is fine, isn't it?

• idempotent type qualifers

Err.

• empty macro arguments

Fun.

• new struct type compatibility rules (tag compatibility)

Cool, but we probably don't need it either.

• _Prama preprocessing operator

Isn't this _Pragma? Anyway, no.

• standard pragmas

Err

• __func__ predefned identifer

Cool, but G_STRFUNC is better because it uses better compilers extensions if available.

• VA_COPY macro

Yeah, that's practical in some cases, I must admit :)

• additional strftime conversion specifers

Cool.

• LIA compatibility annex

Cool.

• deprecate ungetc at the beginning of a binary file

Yeah, whatever

• remove deprecation of aliased array parameters

(Source: list is 2nd hand from http://www.open-std.org/JTC1/sc22/wg14/www/docs/n869/)

And that's just improvements since 1999 (way back when I was in high school), not to mention more recent changes in the latest C11 standard.

But I hope you don't suggest to use it :)

[...]

</rant>

On 13-08-16 05:29 AM, Colomban Wendling wrote:

Le 16/08/2013 08:07, Matthew Brush a écrit :

...

Hi,

[...]

• mixed declarations and code

NO.

...

[...]

• Coding in the new millennium style :)

No point in that, it's not like switching to a modern language, just a few small corner changes to improve the language.

...

• Microsoft Visual C++ compiler is not C99 conformant and plans not to

ever be AFAIK (of little consequence since we don't compile with MSVC).

That'd be a point against it, although MSVC always was crappy for C, no matter which C version :-'

...

• Allowed to use // style comments

Honestly, although they are a little practical to quickly comment a line without having to care if it's already a comment or something, I don't see much need for this, I'm just fine with /**/

...

• Allowed to declare loop counter-style variable inside the for loop.

Yeah, that's kinda fun.

...

• Use standard C instead of G*-portability wrappers in various place

(bool, fixed-width ints, etc.).

This is just sort of random, but I feel that some our code could be better if we depended less on G*-stack and more on (>10 year old) ISO standards.

One question: why? There are only very few things that we really do use from GLib that C99 has, and even if it does, what's the matter?

Rant against G* if you wish, no problem, but then just drop it altogether, "upgrading" to C99 won't change anything in this matter.

Not meant as a rant against G*, 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.

...

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.

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?

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

{ .Cheers = "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

On 13-08-16 04:38 AM, Nick Treleaven wrote:

On 16/08/2013 07:36, Lex Trotman wrote:

...

The more we can allow modern(ish :) programming styles using a well known standard the simpler it is to produce correct code (eg inlines not macros, who will remember that EMPTY may compute its arguments multiple times).

That's why it's in capitals, so it's clear it's a macro. An inline would be better, good idea. Though for FALLBACK we don't know the return type.

Templates! Oh wait, C, right :)

...

At the moment C11 is too new (not enough complete support) but C99 is fine.

Unless we follow the example of gcc itself and upgrade to C++ :)

Not sure that's a good idea for Geany now, although I'm glad that gcc did it. They use a restricted subset IIRC. I miss templates and RAII in C though.

+1. While I'm also not sure it's a good idea in Geany and certainly won't be pressing for it anytime soon, 90% of C++'s crumminess is due to backwards compatibility with C, so I think it should be (theoretically, not socially) possible to gradually transition from one to the other in a project like Geany without too much pain.

Fun (but useless) fact: over 50% of Geany's codebase is already C++[1]

</offtopic>

Cheers, Matthew Brush

[1] Based on count of *.cxx vs *.c files in codebase, and obviously including Scintilla, which isn't really part of our program, hence the "(but useless)".

Le 17/08/2013 06:20, Matthew Brush a écrit :

[...]

P.S. Just a nitpick, the current ANSI C standard is C11, not C99 or C89/90 (Of course, I'm just being sarcastically pedantic for fun and know exactly what you meant[1] :)

…and you failed at it, because the only ANSI C there is is ANSI X3.159-1989 (C89), all other ones are ISO standards ;)

Cheers, Colomban

Also, I doubt it's any kind of sensible either, because good C++ use is sufficiently different from C to require large rewrite. In this case, better rewrite everything and don't keep the clumsy code :)

Ok, sounds like a plan :)

Cheers Lex

Cheers, Colomban _______________________________________________ Devel mailing list Devel@lists.geany.org https://lists.geany.org/cgi-bin/mailman/listinfo/devel

Le 17/08/2013 10:33, Lex Trotman a écrit :

Also, I doubt it's any kind of sensible either, because good C++ use is
sufficiently different from C to require large rewrite.  In this case,
better rewrite everything and don't keep the clumsy code :)

Ok, sounds like a plan :)

I'd be happy to use Geany 2.0, but I'm afraid I won't be able to help building it :) (although it'd be a good learning thing)

Cheers, Colomban

On 13-08-17 01:35 AM, Colomban Wendling wrote:

Le 17/08/2013 03:30, Matthew Brush a écrit :

...

On 13-08-16 01:28 AM, Frank Lanitz wrote:

...

[...]

There were some real old plattforms to keep on supporting running a gcc 2.9x ... IIRC Solaris 9.

We have to check the *x-world beside of Linux I think here.

Just stumbled upon this: https://github.com/libav/c99-to-c89/

[...]

You must absolutely die for some C99 features to come down to such a thing :) I mean, if we'd need this, do you really want to be able to declare counter inside loops so bad?

Nope, just pointing out a way for backwards antiquated platforms to still using our source code if we updated to C99.

Cheers, Matthew Brush

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

On 13-08-17 02:12 AM, Colomban Wendling wrote:

Le 16/08/2013 08:07, Matthew Brush a écrit :

...

Hi,

Up till now we've tried to stay compatible with ANSI C89 because of GTK+-stack doing so (unless I missed the real reason?).

I propose we update to allowing C99 for the following reasons:

[...]

Hum. Since apparently I'm the only one not to see the point, just do as you wish, I don't want to block development or make people angry just for this. It's just that I don't see what it would benefit us.

So feel free to update our coding rules if you feel like it, but I'd prefer not to see mixed declaration and code or C++-style comments :)

IIUC it's not an "all or nothing", so we could move towards C99 slowly by just accepting such new changes using it or whatever. (I don't think we need to use AC_PROG_C99 or whatever it's called). So just for your maintainer checks would have to use -pedantic -std=c99 as replacement.

Agree about mixed code and declarations. Disagree about // style comments but I think we shouldn't at least disallow in future code (at least "strictly")?

P.S. Patches coming for HACKING for review.

Thanks, Matthew Brush

On Sat, 17 Aug 2013 02:19:17 -0700 Matthew Brush mbrush@codebrainz.ca wrote:

...

...

Up till now we've tried to stay compatible with ANSI C89 because of GTK+-stack doing so (unless I missed the real reason?).

I propose we update to allowing C99 for the following reasons:

[...]

IMHO, Colomban summed up pretty well why there's no compelling reason to adopt C99. My 2 euro-cents:

1. Code with gboolean and bool, as well as g_ and non-g_ function versions, would be ugly. So, if we are to move, we'd better upgdate everything at once. Though it won't be very nice to have glib/gtk+ callbacks documented as "... gboolean something ...", but implemented with "bool".

2. If you think that everyone who completed university in the last 14 years uses C99, that's not quite the case. There were years of time lag before all compilers implemented it, and there would be an even larger lag until the programs started before the stable C99 implementation are re-written or obsoleted - if ever. The business is conservative, and does not like to spend money for nothing. On that note, let's cheer for all the programmers using MSVC, pretty much the standard C/C++ compiler for Windows: VS moved "closer" to C99! A month ago, that is. :)

On 17/08/2013 10:01, Matthew Brush wrote:

On 13-08-17 01:22 AM, Colomban Wendling wrote:

...

Le 17/08/2013 06:20, Matthew Brush a écrit :

...

[...]

P.S. Just a nitpick, the current ANSI C standard is C11, not C99 or C89/90 (Of course, I'm just being sarcastically pedantic for fun and know exactly what you meant[1] :)

…and you failed at it, because the only ANSI C there is is ANSI X3.159-1989 (C89), all other ones are ISO standards ;)

I just go from Wiki as usual: http://en.wikipedia.org/wiki/ANSI_C#C11

(Sounds like ANSI adopts all ISO standards for this)

OK, I'll use C90 instead of ANSI C in future then ;-)