From: Fredrik Hederstierna <fredrik.hederstierna@verisure.com>
To: "gcc@gcc.gnu.org" <gcc@gcc.gnu.org>
Subject: Question about GCC not warning for some noncompliant SEI CERT C code examples
Date: Thu, 30 May 2019 09:13:00 -0000 [thread overview]
Message-ID: <HE1PR1001MB1306C71F79B5D87ACD247F23EF180@HE1PR1001MB1306.EURPRD10.PROD.OUTLOOK.COM> (raw)
In-Reply-To: <DB6PR1001MB102963EA708E5211EEF4F451EF550@DB6PR1001MB1029.EURPRD10.PROD.OUTLOOK.COM>
Hi
When reading the SEI CERT C Coding Standard rules, looking at
"DCL30-C. Declare objects with appropriate storage durations"
it seem like GCC does not warn in compile-time for some noncompliant examples.
I know eg AddressSanitizer and several runtime running tools finds these bugs,
but it would be convenient of GCC could do some basic static analysis already in compile-time to avoid bad code generation.
Some static analysers finds these bugs, but not all, and GCC does not warn.
Example from DCL30-C, not warned by GCC:
/* NONCOMPLIANT EXAMPLE-1 */
#include <stdio.h>
const char *p;
void dont_do_this(void) {
const char c_str[] = "This will change";
p = c_str; /* Dangerous */
}
void innocuous(void) {
printf("%s\n", p);
}
int main(void) {
dont_do_this();
innocuous();
return 0;
}
/* NONCOMPLIANT EXAMPLE-2 */
void squirrel_away(char **ptr_param) {
char local[10];
/* Initialize array */
*ptr_param = local;
}
void rodent(void) {
char *ptr;
squirrel_away(&ptr);
/* ptr is live but invalid here */
}
Question, where in GCC is the most appropriate place to implements such a checker?
I know there are some warnings for return-local-addr, and null-pointer-dereference in some different parts, but this seems different?
Can it be found be points-to analysis, or where is it best to put this warning if being implemented?
Reference:
https://wiki.sei.cmu.edu/confluence/display/c/DCL30-C.+Declare+objects+with+appropriate+storage+durations
next prev parent reply other threads:[~2019-05-30 9:13 UTC|newest]
Thread overview: 19+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-07-24 8:48 Question about GCC benchmarks and uninitialized variables Fredrik Hederstierna
2018-07-24 9:04 ` Alexander Monakov
2018-07-24 12:17 ` David Brown
2019-05-30 9:13 ` Fredrik Hederstierna [this message]
2019-05-30 14:28 ` Question about GCC not warning for some noncompliant SEI CERT C code examples Martin Sebor
2019-05-30 14:48 ` Jeff Law
2019-06-01 23:35 ` ARM peephole2 from 2003 never merged, still valid Fredrik Hederstierna
2019-06-01 23:41 ` Fredrik Hederstierna
2019-06-02 12:28 ` Segher Boessenkool
2019-06-05 23:03 ` Jeff Law
2019-06-05 23:46 ` Segher Boessenkool
2019-06-06 9:13 ` Richard Earnshaw (lists)
2019-06-06 14:02 ` Segher Boessenkool
2019-06-06 14:55 ` Fredrik Hederstierna
2019-06-06 16:06 ` Richard Earnshaw (lists)
2019-06-06 16:49 ` Segher Boessenkool
2019-07-08 6:41 ` Fredrik Hederstierna
2019-07-09 19:13 ` Jeff Law
2019-06-14 20:30 ` Jeff Law
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=HE1PR1001MB1306C71F79B5D87ACD247F23EF180@HE1PR1001MB1306.EURPRD10.PROD.OUTLOOK.COM \
--to=fredrik.hederstierna@verisure.com \
--cc=gcc@gcc.gnu.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).