[Bug c/31893] New: Please provide an "inout" attribute for function parameters.
Here is what I mean. When you write code like:
int foo(void) {
static bar_t bar;
call_some_function(&bar);
return 0;
}
gcc assumes that call_some_function will initialize bar properly. Though,
sometimes call_some_function is a function that will modify 'bar' but also need
it to be properly initialized. In that case, the parameter is inout. (I must
say I'm unsure what gcc thinks if call_some_function prototype is: void
call_some_function(const bar_t *); maybe it suffers from the same problem).
That'd be great to have an __attribute__((inout(1,2,3...))) to say that the
1st, 2nd, 3rd, ... variables of the function need their argument to be
initialized. That would make gcc issue warning about variables beeing used
uninitialized properly.
Maybe "inout" is a very lousy name, and I don't care much about it. My point
is, I'd really like to be able to express in the function prototypes that a
structure needs to be initialized before that function can be called. WIth this
attribute, the call_some_function prototype would be:
int call_some_function(bar_t *) __attribute__((inout(1)));
--
Summary: Please provide an "inout" attribute for function
parameters.
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: enhancement
Priority: P3
Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: madcoder at debian dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31893
[Bug c/31893] Please provide an "inout" attribute for function parameters.
--- Comment #1 from madcoder at debian dot org 2007-05-10 11:12 ---
It seems that even if the argument is declared const foo_t * gcc assumes the
function will initialize the data, which is rather ... erm... strange. Here is
the testcase:
==
struct foo { int toto; };
void do_bar(const struct foo *);
int main(void) {
struct foo foo;
do_bar(&foo);
return 0;
}
==
gcc -Wall -Wextra -O2 -Wuninitialized -c -o foo.o foo.c
gives no warning while I'd expect to have one as do_bar takes a const foo_t *
hence should not initialize it.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31893
[Bug c/31893] Please provide an "inout" attribute for function parameters.
--- Comment #3 from madcoder at debian dot org 2007-05-11 09:32 --- Subject: Re: Please provide an "inout" attribute for function parameters. On Thu, May 10, 2007 at 10:00:51PM -, pinskia at gcc dot gnu dot org wrote: > --- Comment #2 from pinskia at gcc dot gnu dot org 2007-05-10 23:00 > --- > What are you doing, writting Fortran code in C? :) (really I am serious about > this one too) > > > It seems that even if the argument is declared const foo_t * gcc assumes the > > function will initialize the data, which is rather ... erm... strange. > > Why do you think it is strange? you can remove the const part in do_bar > anyways. I know you *can* but it's very bad practice, and when you're a warning freak like I am, I won't mark a variable "const" if the function will eventually change it. Anyways, that does not changes my request, that is to mark the fact that the data must be pre-initialized before use to make -Wuninitialized even more useful :) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31893
[Bug c/49143] New: make -Wsuggest-attribute less verbose
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49143
Summary: make -Wsuggest-attribute less verbose
Product: gcc
Version: 4.6.0
Status: UNCONFIRMED
Severity: enhancement
Priority: P3
Component: c
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: madco...@debian.org
In many code bases, -Wsuggest-attribute={const|pure} is really verbose (unlike
missing printf/sccanf format attributes or noreturn attributes, which are
rarer).
Though it's not particularly useful to mark functions as pure/const when those
are known inside the compilation unit or are inline. It'd be great to be able
to restrict the -Wsuggest-attribute to functions whose storage isn't static
because those are the functions for those it's useful (because it's likely that
the prototype lives in some header to be used by external programs).
[Bug middle-end/49143] make -Wsuggest-attribute less verbose
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49143 Pierre Habouzit changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID --- Comment #2 from Pierre Habouzit 2011-05-25 06:03:31 UTC --- looks like with the last gcc-4.6 it's already what happens, sorry for the noise!
[Bug c/30043] New: __attribute__((nonull(...))) and silent optimizations
when a coder writes (erroneously) such a code:
char *m_strrtrim(char *s) __attribute__((nonull(1));
char *m_strrtrim(char *s)
{
int len = s ? strlen(s) : 0;
while (len > 1 && isspace((unsigned char)s[len - 1]))
len--;
return s + len;
}
Then gcc uses the __attribute__((nonnull(1)) — which again is a
programming mistake — to optimize the check of s beeing NULL or not. That
is very correct from a compiling point of view, but it generated segfaults in
my code, that I had a very hard time to find, because of it beeing in the
header file rather than in the implementation where I looked for it (as the
backtrace pointed me in that function).
I suppose that gcc do the optimization because it knows that 's' is non NULL,
though it should make a distinction between s beeing non NULL because it knows
so (e.g. because s is a local buffer) or because it comes from a programmer
assertion.
When it's the latter, it should warn about any trivial test, like it does when
you test if an unsigned int is greater or equal to 0 for example. What I mean
is that:
__attribute__((nonull(1))) void foo(char *s) {
if (!s) {
if (!s) {
// do sth;
}
}
}
here, the first test on s SHOULD NOT be optimized silently, because at this
point s is marked as beeing NONNNUL thanks to a /programmer/ assertion, not
constant folding. I don't know for the second though, maybe it's worth to warn,
maybe not.
--
Summary: __attribute__((nonull(...))) and silent optimizations
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: enhancement
Priority: P3
Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: madcoder at debian dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30043
[Bug c/30043] __attribute__((nonull(...))) and silent optimizations
--- Comment #2 from madcoder at debian dot org 2006-12-01 22:45 ---
Please, I'm not telling the behaviour is crazy, it's indeed correct.
I'm just asking for a smallish warning that I may be shooting myself in the
foot when I do sth like my 'foo' function from the bug report.
When you do :
size_t i;
// ...
if (i >= 0) { ...
if (i < 0) { ...
gcc issues a warning to tell me that I'm doing a test that will always be true
(or always be false). I'd just like to have the same when I've specified that a
parameter is nonnull and that I nontheless tries to see if it's NULL or not.
You're not answering to what I ask, I've read the documentation, and I've
already acknowledged that gcc optimizations in presence of the nonnull
attribute are legitimate.
--
madcoder at debian dot org changed:
What|Removed |Added
Status|RESOLVED|UNCONFIRMED
Resolution|INVALID |
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30043
