This is the mail archive of the libc-alpha@sourceware.org mailing list for the glibc project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Variable scope issue in confstr


On Sun, Mar 25, 2012 at 10:15 AM, Allan McRae <allan@archlinux.org> wrote:
> On 26/03/12 00:01, Carlos O'Donell wrote:
>> On Sat, Mar 24, 2012 at 11:00 PM, Allan McRae <allan@archlinux.org> wrote:
>>> In confstr (posix/confstr.c), the variable restenvs is defined within a
>>> swtich case block and then used outside the switch statement (via
>>> assignment to the variable string). ?Issues with this are exposed with
>>> gcc-4.7 and -O2.
>>>
>>>
>>> 2012-03-25 ?Allan McRae ?<allan@archlinux.org>
>>>
>>> ? ? ? ?* posix/confstr.c: fix variable scope issue.
>>
>> What testing did you do?
>
> I ran "make check" on i686-pc-linux-gnu and x86_64-unknown-linux-gnu and
> there were no regressions. ?I also made sure the patch worked by
> checking the file names in the getconf directory no longer had random
> characters in them (which is how I spotted the issue).

Excellent.

>> Can we add a regression test for this please?
>
> I have no idea how to add a regression test for this issue...

Is this "I have no idea because I've never done this in glibc..." or
"I have no idea because my reproducer is very complicated and I
haven't created a small regression test..."

If your problem is the former that's easier to solve, in general:

* Create a C file that can reproduce the problem.
* The C file should make use of glibc/test-skeleton.c, see other tests
for reference.
* Add the C file test to a subdirectory that relates to the
functionality it's testing and add it to the Makefile of that
particular subdirectory, adding it to the list of test files being
built and run for that subdirectory.
* Run make -k check to see that your tests gets built and run. Your
test should exit with a non-zero exit code in the event of a failure.

We need to keep building up our regression tests, not because it helps
keep out bugs (research shows that code review is better than reg.
tests), but because it makes us think about all the failure modes and
contributes a small percentage to making the software more robust and
bug free.

Cheers,
Carlos.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]