[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Static code analyzer Clang reports possible bug in getopt.c while de
From: |
Eric Blake |
Subject: |
Re: Static code analyzer Clang reports possible bug in getopt.c while developing gnu-pdf |
Date: |
Wed, 22 Jun 2011 10:30:59 -0600 |
User-agent: |
Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.17) Gecko/20110428 Fedora/3.1.10-1.fc14 Lightning/1.0b3pre Mnenhy/0.8.3 Thunderbird/3.1.10 |
On 06/22/2011 10:07 AM, Gustavo Martin Domato wrote:
> Hi:
>
> I copy something I wrote on gnu-pdf development mailing list. Static
> code analyzer Clang detected a possible bug at line 852. The file
> they're using is a copy of the source. To see the report go to
> http://www.gnupdf.org/prmgt/clang/report-kFVhsy.html#EndPath
>
>
> "> lib/getopt.c line 852 - This one is disturbing to me. It shouldn't be
>> possible because of the function's preconditions (longopt must be an
>> array with a null name at the end), but in the code it appears to be
>> that longopt can effectively be null (tested at line 476) and
> p=longopt
>> is actually derreferenced in the loop control statement at line 852...
> I
>> trust the gnulib better that me, but..."
Thanks for the report. I believe you (well, clang) found an actual
glibc bug! Of course, no one in their right mind ever calls
getopt(argc, argv, "W;"), do they?
I'm in the process of seeing if I can quickly turn this into an actual
crashing program, at which point I will spawn a glibc bug as well as fix
the problem in gnulib.
--
Eric Blake address@hidden +1-801-349-2682
Libvirt virtualization library http://libvirt.org
signature.asc
Description: OpenPGP digital signature