Re: CVS commit: src/sys/fs/tmpfs
On Sat, May 14, 2011 at 2:37 AM, Mindaugas Rasiukevicius wrote: > Matt Thomas wrote: >> >> On May 7, 2011, at 5:03 PM, Christos Zoulas wrote: >> >> > Module Name: src >> > Committed By: christos >> > Date: Sun May 8 00:03:35 UTC 2011 >> > >> > Modified Files: >> > src/sys/fs/tmpfs: tmpfs_vnops.c >> > >> > Log Message: >> > no c99 please. >> >> The kernel explicitly allows C99 and actually C99 is encouraged. >> So that should reverted :) > > Generally - C99 is encouraged. However, I disagree that variables > should be declared in the middle of context (for a minimum scope), > unless there is a *clear* benefit. Otherwise, it makes code harder > to read, especially if code fragment is long and/or complex. I disagree. If variables are declared in the middle of context, those variables have narrower contexts. Narrowing context is always a win IMO. I'd like to hear the benefit not doing this (== the old convention). > > Benefits could be, e.g. use of const or limitation of the variable > scope for performance sensitive code, also avoiding of #ifdefs, etc. > > In this case, I used for (int i = 0; ...) because the loop was in > the beginning of context and #ifdef DEBUG-only. > > -- > Mindaugas >
Re: CVS commit: src/sys/fs/tmpfs
On Fri, May 13, 2011 at 06:37:53PM +0100, Mindaugas Rasiukevicius wrote: > Generally - C99 is encouraged. However, I disagree that variables > should be declared in the middle of context (for a minimum scope), > unless there is a *clear* benefit. Otherwise, it makes code harder > to read, especially if code fragment is long and/or complex. The "i" in "for (int i=0; i
Re: CVS commit: src/sys/fs/tmpfs
Matt Thomas wrote: > > On May 7, 2011, at 5:03 PM, Christos Zoulas wrote: > > > Module Name:src > > Committed By: christos > > Date: Sun May 8 00:03:35 UTC 2011 > > > > Modified Files: > > src/sys/fs/tmpfs: tmpfs_vnops.c > > > > Log Message: > > no c99 please. > > The kernel explicitly allows C99 and actually C99 is encouraged. > So that should reverted :) Generally - C99 is encouraged. However, I disagree that variables should be declared in the middle of context (for a minimum scope), unless there is a *clear* benefit. Otherwise, it makes code harder to read, especially if code fragment is long and/or complex. Benefits could be, e.g. use of const or limitation of the variable scope for performance sensitive code, also avoiding of #ifdefs, etc. In this case, I used for (int i = 0; ...) because the loop was in the beginning of context and #ifdef DEBUG-only. -- Mindaugas
Re: CVS commit: src/gnu/dist/gcc4/gcc
On Sat, 7 May 2011, Christos Zoulas wrote: > Add a no_stack_protector function attribute to localize the effect > of disabling stack protection on a function-by-function level, as > opposed to per source file. how should we enable use of this, is the patch below ok or should it have additional restrictions? (kernel scope only? __SSP__/__SSP_ALL__?) also, anybody with FSF privileges prepared to push the gcc addition upstream? iain Index: cdefs.h === RCS file: /cvsroot/src/sys/sys/cdefs.h,v retrieving revision 1.84 diff -u -p -r1.84 cdefs.h --- cdefs.h 19 Feb 2011 02:21:21 - 1.84 +++ cdefs.h 13 May 2011 07:56:42 - @@ -266,6 +266,12 @@ #define__BEGIN_DECLS __BEGIN_PUBLIC_DECLS #define__END_DECLS __END_PUBLIC_DECLS +#if __GNUC_PREREQ__(4, 1) +#define__nossp __attribute__((__no_stack_protector__)) +#else +#define__nossp /* nothing */ +#endif + /* * Non-static C99 inline functions are optional bodies. They don't * create global symbols if not used, but can be replaced if desirable.
