Lessons learned from compiler error/warnings tests

Florian Weimer fweimer@redhat.com
Mon Sep 12 09:44:00 GMT 2016


On 09/09/2016 04:13 PM, David Malcolm wrote:
> On Fri, 2016-09-09 at 14:28 +0200, Florian Weimer wrote:
>> For compile-time fortify checks (such as the wrappers for type-safe
>> open/openat), we need to add tests in glibc which examine the
>> compiler
>> output for warnings and errors.
>>
>> I do not want to add Dejagnu as a dependency to the glibc test suite,
>> but I wonder if you could share any lessons learned from the testing
>> support facility in GCC.
>>
>> Would you suggest to mirror the GCC directives exactly?
>>
>> I probably have to implement the testing directive parser as a small
>> C
>> program.
>
> Is Python acceptable as a dependency for the test suite?

I doubt it.  We use Perl and awk so far.

> String parsing is likely to be saner in Python than in C, especially when the
> requirements grow over time.

For a lexer, I'm not sure if this is true.  The core loop will look 
almost identical (at least if you somehow fake enums in Python).

I looked at doing this in awk, but it gets fairly messy soon.

> (FWIW, I'd much prefer it if DejaGnu were implemented in Python rather
> than Tcl; writing and debugging .exp files below gcc/testsuite is one
> of my least favorite activities in gcc development; we have all kinds
> of nasty kludges involving global variables, peeking at names in the
> stack frames above us, and other fragile coding practices.  Some of
> this may be to do with Tcl, and some to do with legacy code, I guess).

I'm sure you can write in this style even Python. :)

Florian



More information about the Libc-alpha mailing list