stdcxx-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Martin Sebor <se...@roguewave.com>
Subject Re: design of regression tests
Date Sat, 15 Sep 2007 22:07:25 GMT
Travis Vitek wrote:
>  
[...]
> I'm onboard with reducing the scope of this test to just verify
> MB_LEN_MAX and creating a new test for verifying all of the required
> limits.

Okay, let's do that then.

> 
> That said, I'm actually hoping to get feedback an the guts of the test
> itself. It feels a bit fragile to me because it compiles a separate
> executable to emulate getconf [for the necessary constants only], and to
> do this I had to hardcode the compiler names and flags into the test.
> I'm just hoping that this isn't something that will cause a bunch of
> trouble in the future. If it looks fragile to you guys, then maybe it
> would be best to just pass for windows builds and invoke the system
> getconf as you suggested earlier on other platforms.

I agree that it looks fragile, although I admit I am intrigued
by the idea of programmatically invoking the compiler. I have
been contemplating an API that would let us do this in general
(i.e., build programs or even libraries, either using stdcxx
or the native C++ Standard Library, or even C programs) but so
far it's just an idea.

Despite the fragility, I do see the appeal of this approach:
unlike computing the constants directly in the test that I was
at first inclined to suggest, it guarantees to yield the exact
same values as the C library. (I assume that's why you chose
it?) I suggest we keep the test in Jira and revisit it, maybe
along withe the whole compiler API idea, when we have more
time after the release.

Some observations about the formatting code in the test:

First, there's a macro for the "template <>" syntax to deal with
outdated compiler: _RWSTD_SPECIALIZED_FUNCTION. We have been
talking about dropping support for these kinds of workarounds at
some point in the (near) future but we haven't actually done it
yet. So until we do, we should continue to use these macros (if
nothing else, it'll help us all appreciate the extent of these
workarounds and decide which one we want to get rid of and which
one we might want to keep).

Second, this kind of type-based formatting is unnecessary. It would
be sufficient to convert each constant to long and use %li or %lu
to format them all. The formatting code is also slightly buggy
because it doesn't account for integer promotion and sign extension.
At least one of the conversion specifications (%hc) is also not
defined.

Martin

Mime
View raw message