[Bug c/47701] New: separate warning to detect c99 enum constraint violation
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47701
Summary: separate warning to detect c99 enum constraint
violation
Product: gcc
Version: 4.4.5
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: er...@gcc.gnu.org
C99 6.7.2.2 states:
The expression that defines the value of an enumeration constant shall be an
integer constant expression that has a value representable as an int.
Obviously, gcc has an extension that any integral value can be used, and
-pedantic can detect that this extension was utilized:
$ cat foo.c
enum { a = 0x10001LL };
int main(void) { return a; }
$ gcc -Wall -Wextra -std=c99 -fdiagnostics-show-option foo.c -o foo
$ gcc -Wall -Wextra -std=c99 -pedantic -fdiagnostics-show-option foo.c -o foo
foo.c:1: warning: ISO C restricts enumerator values to range of ‘int’
[-pedantic]
$ ./foo; echo $?
1
However, -pedantic is a rather heavy hammer; I would love to have a dedicated
-W option, independent of -pedantic, for detecting just the issue of using an
integer constant outside the range of int, to be sure that I don't fall foul of
something like failure to compiler, or worse behavior like silent enum
truncation, on other compilers that don't implement the same extension as gcc.
[Bug middle-end/17308] nonnull attribute not as useful as it could
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17308 Eric Blake changed: What|Removed |Added CC||ericb at gcc dot gnu.org --- Comment #6 from Eric Blake 2011-02-11 16:58:01 UTC --- It's been several years, and this attribute is still missing functionality about warning for deduced NULL values. Can this be looked at?
[Bug c/47702] New: feature request: sentinel_value
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47702
Summary: feature request: sentinel_value
Product: gcc
Version: 4.4.5
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: er...@gcc.gnu.org
__attribute__((sentinel)) is great for detecting a trailing NULL argument. But
what about code that wants to detect some other trailing sentinel argument?
For example:
#include
enum flags {
FLAG_A,
FLAG_B,
FLAG_C,
FLAG_LAST
};
void setFlags(int *result, ...)
{
va_list list;
int flag;
va_start(list, result);
while ((flag = va_arg(list, int)) != FLAG_LAST)
*result |= 1 << flag;
va_end(list);
}
int main (void)
{
int flags;
setFlags(flags, FLAG_A, FLAG_C, FLAG_LAST);
return flags;
}
I'd love to be able to mark that all callers of setFlags must provide a
trailing argument of FLAG_LAST as their sentinel value.
Would it be possible to introduce:
__attribute__((sentinel_value(value, [position])))
and make the current sentinel([position]) be strictly equivalent to
sentinel_value(NULL, [position]).
[Bug c/53182] GNU C: attributes without underscores should be discouraged / no longer be documented e.g. as examples
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53182 Eric Blake changed: What|Removed |Added CC||ericb at gcc dot gnu.org --- Comment #2 from Eric Blake 2012-05-02 13:27:28 UTC --- It would also help to add an attribute named __attribute__((_Noreturn)) (and therefore also adding __attribute__((___Noreturn__)), of course), for this particular instance of vs. existing code.
[Bug middle-end/17308] nonnull attribute not as useful as it could
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17308
--- Comment #8 from Eric Blake 2012-04-25 19:31:59
UTC ---
I hit this again today, and I'm still upset that gcc is doing such a poor job
with (not) using this attribute as a way to improve code quality via decent
warnings.
Basically, libvirt had an issue where we accidentally misused the nonnull
attribute marker; we had added the marker in a header file, then later changed
the C file to work with a NULL argument but without updating the header file to
match: https://bugzilla.redhat.com/show_bug.cgi?id=815270
The calling code managed to pass in a NULL pointer to a parameter based on the
semantics we saw in the .c file, but the NULL check in our function in question
was "helpfully" elided by gcc since the attribute was still present, all
without ever warning us that we were losing the NULL check. As a result, the
code misbehaved when it dereferenced NULL. If gcc is smart enough to elide
code based on the attribute, it should be smart enough to issue a warning that
we have dead code, and the only reason the code is assumed to be dead is
because of a suspicious attribute. Had we had the warning, we would have known
to either remove our dead NULL check, or to fix the header to no longer have
the (now-inappropriate) attribute.
In other words, with a header like:
void foo(void *bar) __attribute__((nonnull(1)));
and a C file like:
void foo(void *bar) { if (!bar) abort(); }
Even if you decide that you are unable to warn about a call to foo(var) because
the only way to analyze that var might be NULL is in the middle end but the
warning is only emitted by the front end, AT LEAST you could have warned that
the 'if (!bar)' conditional is assumed to be dead code based on the attribute
placed on var.
[Bug c/45780] Warning for arithmetic operations involving C99 _Bool variable
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45780
Eric Blake changed:
What|Removed |Added
CC||ericb at gcc dot gnu.org
--- Comment #1 from Eric Blake 2010-11-03 20:05:00
UTC ---
Don't forget a warning on implicit conversions from int to bool, such as:
bool f(int i) { return i; }
although it might make sense to avoid warnings on provably 0/1 int conversion
to bool, as in:
bool f(int i) { i = !!i; return i; }
