On 5/30/19 8:28 AM, Martin Sebor wrote:
> On 5/30/19 3:12 AM, Fredrik Hederstierna wrote:
>> 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 */
>> }
>
> Agreed. This (or a subset of the problem) is being tracked in
> PR 69433.
>
>>
>> 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?
>
> To me it seems close enough to -Wreturn-local-addr to be implemented
> in the same place, in gimple-ssa-isolate-paths.c. It's worth noting
> that besides warning, the pass also clears the returning address and
> isolates the path that returns the null in the CFG.
>
> As it happens, I recently submitted a modest enhancement to
> -Wreturn-local-addr to detect returning the addresses of VLAs and
> pointers obtained from alloca (PR 71924 and PR 90549). I'm working
> on extending the implementation to returning freed pointers (under
> a separate warning option).
>
> Besides the problems you mention, there is also a related request
> to diagnose dereferencing pointers to compound literals whose
> lifetime has ended (PR 89990), or more generally, those to any
> such local object.
>
> In the enhancement I submitted I chose not to use the alias oracle
> mainly because I didn't want to change the existing design. I'm
> not familiar enough with to tell with confidence if it can be used
> to obtain the same results. I.e., identify each instance of
> a local variable that a pointer may point to, rather than just
> answering the broad question: does this pointer point to any
> local variables? If it can, using it as Jeff suggests in his
> comments, would make sense. I don't think moving it out of
> gimple-ssa-isolate-paths.c is necessary (or even a good idea).
Note that you may also be able to use the alias oracle to detect
escaping locals. That's likely to have a higher false positive rate,
but may still be useful for detecting this kind of stuff.
jeff
