Not logged in
Log in now
Create an account
Subscribe to LWN
LWN.net Weekly Edition for December 5, 2013
Deadline scheduling: coming soon?
LWN.net Weekly Edition for November 27, 2013
ACPI for ARM?
LWN.net Weekly Edition for November 21, 2013
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 (✭ supporter ✭, #5246)
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.
Posted Jun 8, 2011 11:06 UTC (Wed) by etienne (subscriber, #25256)
Posted Jun 8, 2011 11:14 UTC (Wed) by cesarb (subscriber, #6266)
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?
Posted Jun 8, 2011 13:03 UTC (Wed) by tialaramex (subscriber, #21167)
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.
Posted Jun 9, 2011 15:34 UTC (Thu) by jwakely (subscriber, #60262)
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.
Posted Jun 10, 2011 3:40 UTC (Fri) by jzbiciak (✭ supporter ✭, #5246)
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 §18.104.22.168:
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.
Posted Jun 8, 2011 15:15 UTC (Wed) by etienne (subscriber, #25256)
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.
Copyright © 2013, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds