This is the mail archive of the
mailing list for the glibc project.
Re: Lessons learned from compiler error/warnings tests
- From: Florian Weimer <fweimer at redhat dot com>
- To: David Malcolm <dmalcolm at redhat dot com>, GCC <gcc at gcc dot gnu dot org>
- Cc: GNU C Library <libc-alpha at sourceware dot org>
- Date: Mon, 12 Sep 2016 11:44:23 +0200
- Subject: Re: Lessons learned from compiler error/warnings tests
- Authentication-results: sourceware.org; auth=none
- References: <firstname.lastname@example.org> <email@example.com>
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
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
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. :)