Re: Move tst-signal-numbers to Python

[Joseph Myers <joseph at codesourcery dot com>]

On Mon, 10 Dec 2018, Florian Weimer wrote:

> > I don't want to require separate Python code for each such test.
> 
> Why not?

Because most of the Python and Makefile code is essentially boilerplate 
that does not need repeating many times and does not need to vary between 
tests of different macros and headers.  The key information, the headers 
to include and the constants to compare (and the kernel version, where one 
is needed), is essentially data.  (But having a few such tests first 
should help make clear exactly what is or is not common between different 
such tests.)

> I still think the comment you included in your patch, listing the signal
> names explicitly, is a strong hint that regular expressions are not the
> right interface here.

This is an attempt to move towards interfaces that will cover a range of 
such tests.  An explicit list of names does not seem the right interface 
for excluding all MAP_HUGE_[0-9].* names.

> The other issue to consider is that the current approach only works if
> GCC can interpret the macro constant as a long int.  (I think the cast

Anything that is an integer constant, of any type, could be handled by 
making the code compute a few separate expressions (e.g. low 32 bits, high 
32 bits, sign) for each expression, rather than just casting the given 
expression to long int.

-- 
Joseph S. Myers
joseph@codesourcery.com