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:
- restricted character set support in <iso646.h> (originally specifed in AMD1) - wide-character library support in <wchar.h> and <wctype.h> (originally specifed in AMD1) - restricted pointers - variable-length arrays - fexible array members - complex (and imaginary) support in <complex.h> - type-generic math macros in <tgmath.h> - the long long int type and library functions - increased translation limits - remove implicit int - the vscanf family of functions - reliable integer division - universal character names - extended identifers - binary foating-point literals and printf/scanf conversion specifers - compound literals - designated initializers - // comments - extended integer types in <inttypes.h> and <stdint.h> - remove implicit function declaration - preprocessor arithmetic done in intmax_t/uintmax_t - mixed declarations and code - integer constant type rules - integer promotion rules - vararg macros - 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 - trailing comma allowed in enum declaration - %lf conversion specifer allowed in printf - inline functions - the snprintf family of functions - boolean type in <stdbool.h> - idempotent type qualifers - empty macro arguments - new struct type compatibility rules (tag compatibility) - _Prama preprocessing operator - standard pragmas - __func__ predefned identifer - VA_COPY macro - additional strftime conversion specifers - LIA compatibility annex - deprecate ungetc at the beginning of a binary file - 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.
I think for us the most likely consequences are:
- Coding in the new millennium style :) - 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). - Allowed to use // style comments - Allowed to declare loop counter-style variable inside the for loop. - 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.
P.S. Sorry for the bikeshed bait.
Cheers, Matthew Brush
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?
The items that are obviously likely to be useful to Geany I have marked in the list with **. Some of these may come with magic options to gcc, but that limits us to that compiler.
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).
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++ :)
On 16 August 2013 16:07, Matthew Brush mbrush@codebrainz.ca wrote:
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:
- restricted character set support in <iso646.h> (originally specifed in
AMD1)
- wide-character library support in <wchar.h> and <wctype.h> (originally
specifed in AMD1) ** - restricted pointers ** - variable-length arrays ** - flexible array members
- complex (and imaginary) support in <complex.h>
- type-generic math macros in <tgmath.h>
- the long long int type and library functions
- increased translation limits
- remove implicit int
** - the vscanf family of functions ** - reliable integer division
- universal character names
- extended identifers
- binary foating-point literals and printf/scanf conversion specifers
- compound literals
** - designated initializers ** - // comments ** - extended integer types in <inttypes.h> and <stdint.h> ** - remove implicit function declaration ** - preprocessor arithmetic done in intmax_t/uintmax_t ** - mixed declarations and code ** - integer constant type rules
- integer promotion rules
- vararg macros
- 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
- trailing comma allowed in enum declaration
- %lf conversion specifer allowed in printf
** - inline functions ** - the snprintf family of functions ** - boolean type in <stdbool.h>
- idempotent type qualifers
- empty macro arguments
** - new struct type compatibility rules (tag compatibility)
- _Prama preprocessing operator
- standard pragmas
- __func__ predefned identifer
- VA_COPY macro
- additional strftime conversion specifers
- LIA compatibility annex
- deprecate ungetc at the beginning of a binary file
- remove deprecation of aliased array parameters
(Source: list is 2nd hand from http://www.open-std.org/JTC1/** sc22/wg14/www/docs/n869/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.
I think for us the most likely consequences are:
- Coding in the new millennium style :)
- 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).
- Allowed to use // style comments
- Allowed to declare loop counter-style variable inside the for loop.
- 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.
P.S. Sorry for the bikeshed bait.
Red and purple.
Cheers Lex
Cheers, Matthew Brush ______________________________**_________________ Devel mailing list Devel@lists.geany.org https://lists.geany.org/cgi-**bin/mailman/listinfo/develhttps://lists.geany.org/cgi-bin/mailman/listinfo/devel
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
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).
Cheers, Matthew Brush
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 13-08-16 01:28 AM, Frank Lanitz wrote:
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.
IMO, if a platform can't support compiling C99 code using any type of pre-historic GCC that supports it, then its package maintainers deserve to (and likely do already) use cross-compilation and it's users won't care either way.
P.S. I'm not a package maintainer for pre-historic distro, so please flame me if I pissed you off.
Cheers, Matthew Brush
On 16/08/2013 10:25, Matthew Brush wrote:
On 13-08-16 01:28 AM, Frank Lanitz wrote:
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.
IMO, if a platform can't support compiling C99 code using any type of pre-historic GCC that supports it, then its package maintainers deserve to (and likely do already) use cross-compilation and it's users won't care either way.
P.S. I'm not a package maintainer for pre-historic distro, so please flame me if I pissed you off.
Perhaps we could try asking if they still need ANSI-C on geany-users and maybe on the website news too.
On 13-08-16 04:40 AM, Nick Treleaven wrote:
On 16/08/2013 10:25, Matthew Brush wrote:
On 13-08-16 01:28 AM, Frank Lanitz wrote:
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.
IMO, if a platform can't support compiling C99 code using any type of pre-historic GCC that supports it, then its package maintainers deserve to (and likely do already) use cross-compilation and it's users won't care either way.
P.S. I'm not a package maintainer for pre-historic distro, so please flame me if I pissed you off.
Perhaps we could try asking if they still need ANSI-C on geany-users and maybe on the website news too.
Good idea, if no one objects, I'll ask on the users list whether anyone actually compiles Geany on such platforms (although I guess it's only a small subset of the actual user base).
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] :)
Cheers, Matthew Brush
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
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)
Cheers, Matthew Brush
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 ;-)
On 13-08-16 01:28 AM, Frank Lanitz wrote:
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.
Just stumbled upon this: https://github.com/libav/c99-to-c89/
Used by FFMPEG/libav (at least it looks like it from Github repo). That might be an option for super old platforms to build C99 code, although it requires an additional step in the build process.
Note: I just happen to find this in a related web search and I've never tested it nor can I attest to whether it works or is hard to build or use or anything.
Cheers, Matthew Brush
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?
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
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.
On 16/08/2013 12:47, Thomas Martitz wrote:
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.
Hmm, maybe I was wrong.
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 04:19, Matthew Brush a écrit :
[...] 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.
I doubt it, C++ is sufficiently different from a C program not to be compilable by a C++ compiler in many cases -- even if it is just for some implicit casts C++ requires to be explicit (IIRC), and there are plenty. Or maybe it depends what "too much pain" means :)
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 :)
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:31 AM, Colomban Wendling wrote:
Le 17/08/2013 04:19, Matthew Brush a écrit :
[...] 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.
I doubt it, C++ is sufficiently different from a C program not to be compilable by a C++ compiler in many cases -- even if it is just for some implicit casts C++ requires to be explicit (IIRC), and there are plenty. Or maybe it depends what "too much pain" means :)
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 :)
I think it wouldn't be too bad. It only took ~1hr IIRC to make Geany headers compilable in C++, I expect not much more than 10x that for the C sources files. But anyway I don't care, I don't want to port it and I don't think anyone is crazy enough to truly propose it :)
Cheers, Matthew Brush
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.
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.
Now I can cheer, Colomban
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" };
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 :)
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.
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?
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.
{ .Cheers = "Matthew Brush" };
return "Cheers";
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
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:
- 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.
- 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 :)
- 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.
- Extended integer types (can use std names rather than g ones)
G ones are just fine
- Remove implicit func. decls (compiler usually warns, but still)
same as 3
- 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 :)
- 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.
- 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
- 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)
- snprintf (without using non-std g one)
g is fine
- 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.
- 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.
- 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
…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>
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 :)
Regards, 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 13-08-17 02:19 AM, Matthew Brush wrote:
On 13-08-17 02:12 AM, Colomban Wendling wrote:
Le 16/08/2013 08:07, Matthew Brush a écrit :
[bikeshed]
P.S. Patches coming for HACKING for review.
Here's a quick pass at HACKING, though maybe I miss some subtler points (I don't think though).
Cheers, 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 13-08-17 12:46 PM, Dimitar Zhekov wrote:
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:
I think I missed this summation, will re-read thread.
- 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".
It's a good point. My personal opinion is that we should use "bool" everywhere we mean boolean except at the API boundaries of G* where it expects an int (ie. gboolean), in which case we should either use gboolean or standard "int".
If we do this way, we get the type safety/checking of using _Bool (and true/false) instead of int (gboolean and 0/!0 macros) everywhere but we can still keep all our g_idle_add() and similar callbacks that are expecting ints (gbooleans), without casting the callback function pointers and losing type-checking on the other parameters/return type.
At least it's a thought. I'd be interested to see what everyone thinks of that.
- 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
The smiley face in the sentence you didn't quote but are responding to means I was joking/being sarcastic.
all the programmers using MSVC, pretty much the standard C/C++ compiler for Windows: VS moved "closer" to C99! A month ago, that is. :)
Neat! For anyone curious: http://blogs.msdn.com/b/vcblog/archive/2013/07/19/c99-library-support-in-vis...
Cheers, Matthew Brush