Object-oriented design patterns in the kernel, part 2

Posted Jun 8, 2011 4:55 UTC (Wed) by jzbiciak (guest, #5246)
In reply to: Object-oriented design patterns in the kernel, part 2 by nix
Parent article: Object-oriented design patterns in the kernel, part 2

FWIW, this sort of hack is something Dennis Ritchie once referred to as "unwarranted chumminess with the implementation." I always found that phrase amusing. :-)

Object-oriented design patterns in the kernel, part 2

Posted Jun 8, 2011 9:48 UTC (Wed) by tialaramex (subscriber, #21167) [Link] (7 responses)

The outcome is also notable.

Everybody did this, the implementations all allowed it, but the standard said you couldn't rely upon it.

So they fixed the standard, introducing in C99 a way to explicitly ask for what everyone wanted here, and adding text insisting that implementations do what the developers expect in that case.

Not every case can or should be treated this way, but it's a useful option. When the conflict is between reality and the standard, consider altering the standard.

Object-oriented design patterns in the kernel, part 2

Posted Jun 8, 2011 10:07 UTC (Wed) by jzbiciak (guest, #5246) [Link]

Oh, I agree. C is quite a pragmatic language, drawing its pragmatism from many directions. The fact that its compiler directive for turning on/off various vendor-defined features is named #pragma I think says a lot.

C99 also cleared up the meaning of const as it qualified pointer arguments to functions, offering up the much better suited restrict qualifier in its place. That was a case where the cookie crumbled a bit differently, but still fit with the general pragmatism of the C working group and C language. I can't really complain.

Object-oriented design patterns in the kernel, part 2

Posted Jun 8, 2011 11:06 UTC (Wed) by etienne (guest, #25256) [Link] (5 responses)

C99 could have added a warning when a structure is created (and not a structure pointer allocated), so that this is catched:
$ cat tmp.c
struct str { unsigned len; char data[]; };
void fct1(struct str *ptr);
void fct2(struct str *initial) {
struct str copy = *initial;
fct1(&copy);
}
$ gcc -Wall -std=c99 -O2 -c tmp.c
$

Object-oriented design patterns in the kernel, part 2

Posted Jun 8, 2011 11:14 UTC (Wed) by cesarb (subscriber, #6266) [Link] (4 responses)

I think it is the compiler which adds warnings, not the standard. So, you could report this as a bug to the gcc developers and they could add a warning, even if the standard thinks this is valid.

That is, if the warning does not exist already. -Wall does not enable all warnings. Did you try -Wextra and check the manual for the warnings neither option enables?

Object-oriented design patterns in the kernel, part 2

Posted Jun 8, 2011 13:03 UTC (Wed) by tialaramex (subscriber, #21167) [Link] (2 responses)

The standard requires some diagnostics, GCC complies with the standard in this regard when in 'pedantic' mode (of course you must also tell GCC which standard you intended to comply with to get anything useful)

But yes, a useful compiler will definitely want to offer additional diagnostic information beyond that called out in the standard, and it may find that some diagnostics called for by the standard are just unhelpful, conflict with real world practice or obstruct a cool but non-standard feature they wish to offer, and so disable them at least by default.

The case outlined above doesn't strike me as worth being called out in the standard, but I can see that at least some similar cases could be usefully mentioned by the compiler, like unadorned occurrences of the assignment operator in a boolean context. You _might_ mean what you say, but you probably don't, and if you really do, you could say it more clearly for the benefit of some future maintenance programmer.

Object-oriented design patterns in the kernel, part 2

Posted Jun 9, 2011 15:34 UTC (Thu) by jwakely (subscriber, #60262) [Link] (1 responses)

The standard does *not* require any warnings. The diagnostics it requires are for violations of syntax rules or constraints, not for warning about questionable constructs.

The standard says something works or it doesn't, it never says "this is ok but the implementation should warn about it", so cesarb is quite right, C99 could not have added a warning, and requests for such a warning should go to compiler implementations not the standard.

Object-oriented design patterns in the kernel, part 2

Posted Jun 10, 2011 3:40 UTC (Fri) by jzbiciak (guest, #5246) [Link]

That's largely true. I did find at least one place (and there are likely others) where the standard suggests a warning. It doesn't mandate it though, in §6.4.4.2:

Recommended practice

The implementation should produce a diagnostic message if a hexadecimal constant cannot be represented exactly in its evaluation format; the implementation should then proceed with the translation of the program.

If "produc[ing] a diagnostic" and "proceed[ing] with the translation of the program" doesn't constitute a warning, I don't know what does.

Object-oriented design patterns in the kernel, part 2

Posted Jun 8, 2011 15:15 UTC (Wed) by etienne (guest, #25256) [Link]

For this GCC version:
$ gcc --version
gcc (Ubuntu 4.4.3-4ubuntu5) 4.4.3

I get no warnings:
$ gcc -Wall -Wextra -pedantic -Wvla -std=c99 -O2 -c tmp.c
$

But I never use this construct and I already have my own list of bugs for GCC in bugzillia.

Object-oriented design patterns in the kernel, part 2

Posted Jun 8, 2011 13:21 UTC (Wed) by nix (subscriber, #2304) [Link]

Oh no. What Ritchie described *was* unwarranted chumminess with the implementation, because you're declaring a short array then allocating more space and walking off the end of it. That *is* forbidden by the Standard. But allocating enough space for one structure appended to the end of another one, then doing pointer addition and a typecast? That's allowed: you're not accessing off the end of one object at all, you're accessing the object you cast to.