[lkml]   [2004]   [Nov]   [22]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: sparse segfaults

On Mon, 22 Nov 2004, Jan Engelhardt wrote:
> >BAD gcc extensions:
> You don't have to use them...

We don't, generally. But they are bad even if you DON'T use them, because
they sometimes make obvious syntax errors etc much harder to debug.

For example, the "nested function" thing makes something as simple as a
missing end brace cause the error reporting to be totally off, when gcc
decides that "hey, that's ok, those other function declarations are just
nested functions in the middle of that other function". So you get
something like

file.c: lastline: parse error at end of input

even though the _real_ parse error could have been pinpointed exactly if
gcc did NOT do it's totally braindamaged nested functions. IOW, the
extension causes problems even when you don't use it.

Same goes for the "extended lvalues". They are not only insane, but they
mean that code like

(0,i) = 1;

actually compiles. Why is that a problem? Because some people (ie me) have
used constructs like this in macros to make sure that the macro is
"read-only", ie you have a situation where you don't want people to
mis-use the macro on some architecture. So having

int max_of_something;
#define MAX_SOMETHING (0,max_of_something)

is actually a nice way to make sure nobody does anything like


but the gcc extension means that this doesn't actually work.

(Yes, I've been bitten by this. And no, I don't see the _point_ of the
extension - does anybody actually admit to ever _using_ comma- expressions
for assignments?)

To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
More majordomo info at
Please read the FAQ at

 \ /
  Last update: 2009-11-18 23:46    [W:0.056 / U:6.236 seconds]
©2003-2018 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site