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