GCC defaults to gnu89 if no explicit standard was set by -std flag. I think there is no reason to stick to this old standard. It was discussed earlier off-list and if nobody has anything against it, please apply this patch to use gnu99 instead of 89 (for gcc).
The patch is attached.
Thanks Michal
On Tue, 2012-08-28 at 15:42 +0200, Michal Židek wrote:
GCC defaults to gnu89 if no explicit standard was set by -std flag. I think there is no reason to stick to this old standard. It was discussed earlier off-list and if nobody has anything against it, please apply this patch to use gnu99 instead of 89 (for gcc).
The patch is attached.
Ack to the patch, but would you mind identifying what features of gnu99 we want to take advantage of? Where's the value in this patch?
On 08/28/2012 04:32 PM, Stephen Gallagher wrote:
On Tue, 2012-08-28 at 15:42 +0200, Michal Židek wrote:
GCC defaults to gnu89 if no explicit standard was set by -std flag. I think there is no reason to stick to this old standard. It was discussed earlier off-list and if nobody has anything against it, please apply this patch to use gnu99 instead of 89 (for gcc).
The patch is attached.
Ack to the patch, but would you mind identifying what features of gnu99 we want to take advantage of? Where's the value in this patch?
sssd-devel mailing list sssd-devel@lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/sssd-devel
A feature I really miss is declaration of variables in for cycles. It is ugly to create variables with names like 'i', 'a' (or whatever) at function start if all you need is one or two for cycle 'iterators'.
But in general, I think the selection of standard should be explicit (I am really not sure if the default GCC standard is 'gnu89' or 'gnu89 + something'). And if we have to make it explicit, why bother with 89? With 99 we can count with these features:
http://gcc.gnu.org/c99status.html + gnu extensions.
It is not like we need them all, but there is also no reason to get rid off them.
Thanks Michal
On Tue, 2012-08-28 at 17:37 +0200, Michal Židek wrote:
On 08/28/2012 04:32 PM, Stephen Gallagher wrote:
On Tue, 2012-08-28 at 15:42 +0200, Michal Židek wrote:
GCC defaults to gnu89 if no explicit standard was set by -std flag. I think there is no reason to stick to this old standard. It was discussed earlier off-list and if nobody has anything against it, please apply this patch to use gnu99 instead of 89 (for gcc).
The patch is attached.
Ack to the patch, but would you mind identifying what features of gnu99 we want to take advantage of? Where's the value in this patch?
A feature I really miss is declaration of variables in for cycles. It is ugly to create variables with names like 'i', 'a' (or whatever) at function start if all you need is one or two for cycle 'iterators'.
I'd prefer to actually forbid this entirely in our style guidelines. Declaring variables in for-loops is a pretty good way to screw up scoping. I've seen MANY mistakes start this way.
But in general, I think the selection of standard should be explicit (I am really not sure if the default GCC standard is 'gnu89' or 'gnu89 + something'). And if we have to make it explicit, why bother with 89? With 99 we can count with these features:
http://gcc.gnu.org/c99status.html
- gnu extensions.
It is not like we need them all, but there is also no reason to get rid off them.
Sure, makes sense to pick a standard and stick with it.
On 08/28/2012 06:31 PM, Stephen Gallagher wrote:
On Tue, 2012-08-28 at 17:37 +0200, Michal Židek wrote:
On 08/28/2012 04:32 PM, Stephen Gallagher wrote:
On Tue, 2012-08-28 at 15:42 +0200, Michal Židek wrote:
GCC defaults to gnu89 if no explicit standard was set by -std flag. I think there is no reason to stick to this old standard. It was discussed earlier off-list and if nobody has anything against it, please apply this patch to use gnu99 instead of 89 (for gcc).
The patch is attached.
Ack to the patch, but would you mind identifying what features of gnu99 we want to take advantage of? Where's the value in this patch?
A feature I really miss is declaration of variables in for cycles. It is ugly to create variables with names like 'i', 'a' (or whatever) at function start if all you need is one or two for cycle 'iterators'.
I'd prefer to actually forbid this entirely in our style guidelines. Declaring variables in for-loops is a pretty good way to screw up scoping. I've seen MANY mistakes start this way.
It is actually one of my favorite features :-) . But I'll survive it if it's forbidden by guidelines. You are probably right, that it can be source of trouble.
But in general, I think the selection of standard should be explicit (I am really not sure if the default GCC standard is 'gnu89' or 'gnu89 + something'). And if we have to make it explicit, why bother with 89? With 99 we can count with these features:
http://gcc.gnu.org/c99status.html
- gnu extensions.
It is not like we need them all, but there is also no reason to get rid off them.
Sure, makes sense to pick a standard and stick with it.
That was the main reason for it.
Thanks Michal
On Tue, Aug 28, 2012 at 07:07:40PM +0200, Michal Židek wrote:
On 08/28/2012 06:31 PM, Stephen Gallagher wrote:
On Tue, 2012-08-28 at 17:37 +0200, Michal Židek wrote:
On 08/28/2012 04:32 PM, Stephen Gallagher wrote:
On Tue, 2012-08-28 at 15:42 +0200, Michal Židek wrote:
GCC defaults to gnu89 if no explicit standard was set by -std flag. I think there is no reason to stick to this old standard. It was discussed earlier off-list and if nobody has anything against it, please apply this patch to use gnu99 instead of 89 (for gcc).
The patch is attached.
Ack to the patch, but would you mind identifying what features of gnu99 we want to take advantage of? Where's the value in this patch?
A feature I really miss is declaration of variables in for cycles. It is ugly to create variables with names like 'i', 'a' (or whatever) at function start if all you need is one or two for cycle 'iterators'.
I'd prefer to actually forbid this entirely in our style guidelines. Declaring variables in for-loops is a pretty good way to screw up scoping. I've seen MANY mistakes start this way.
It is actually one of my favorite features :-) . But I'll survive it if it's forbidden by guidelines. You are probably right, that it can be source of trouble.
We already use variadic macros for instance, which is a GCC extension that became part of the C99 standard. I think the same goes for stdbool.h
One of the features I think we could use (with caution in order not to smash stack) is variable length arrays on the stack. One of the patches on review used code that looked somewhat like:
char *attributes[3] = { "foo", "bar", "baz" }; char *processed[3];
for (i=0; i < 3; i++) { processed[i] = find_and_process(input, attributes[i]); }
sure it could have been solved by #defining a constant (and to be pedantic looping extending somearray with NULL sentinel and changing the loop to go until it hits a sentinel), but in this case using a cost int would have been more elegant and would allow us to keep the variable length coupled within the function it is used at.
On Tue, Aug 28, 2012 at 10:32:53AM -0400, Stephen Gallagher wrote:
On Tue, 2012-08-28 at 15:42 +0200, Michal Židek wrote:
GCC defaults to gnu89 if no explicit standard was set by -std flag. I think there is no reason to stick to this old standard. It was discussed earlier off-list and if nobody has anything against it, please apply this patch to use gnu99 instead of 89 (for gcc).
The patch is attached.
Ack to the patch, but would you mind identifying what features of gnu99 we want to take advantage of? Where's the value in this patch?
Ack from me, too. Works on both Fedora and RHEL5.
On Mon, Sep 03, 2012 at 08:50:22PM +0200, Jakub Hrozek wrote:
On Tue, Aug 28, 2012 at 10:32:53AM -0400, Stephen Gallagher wrote:
On Tue, 2012-08-28 at 15:42 +0200, Michal Židek wrote:
GCC defaults to gnu89 if no explicit standard was set by -std flag. I think there is no reason to stick to this old standard. It was discussed earlier off-list and if nobody has anything against it, please apply this patch to use gnu99 instead of 89 (for gcc).
The patch is attached.
Ack to the patch, but would you mind identifying what features of gnu99 we want to take advantage of? Where's the value in this patch?
Ack from me, too. Works on both Fedora and RHEL5.
Pushed to master.
sssd-devel@lists.fedorahosted.org
-
Jakub Hrozek -
Michal Židek -
Stephen Gallagher