[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Thu, 5 May 2011 16:28:31 +0200
> I have a condition (namely, test-fclose), where I only want to test
> a particular behavior of fclose if I know that fflush was replaced at
> the same level as fclose. That is, if fclose is in lib, but fflush is
> only in tests, then the test is likely to fail and so I want to compile
> it out.
It seems an odd wish, and it seems odd to want to test for such a
#if GNULIB_FFLUSH == GNULIB_FCLOSE
Rather, we should try to make things work also in situations where
people have invoked gnulib-tool several times within the same
What is the semantic of fclose() that you want to test?
Basically, you have two possible behaviours of fclose(), one is probably
stricter POSIX compliant than the other. How can a user request the
stricter one? By requiring 'fclose' and 'fflush' together? Why not
introduce 'fclose-strict' (or 'fclose-posix' or whatever is appropriate)?
This module would depend on 'fclose' and 'fflush'. Then, in the tests,
(using the usual GNULIB_TEST_* macro).
Would that solve your use-case?
In memoriam Peter van Pels <http://en.wikipedia.org/wiki/Peter_van_Pels>
- gl_MODULE_INDICATOR, Eric Blake, 2011/05/04
- [PATCH 1/2] tests: allow tests to learn where a module is present, Eric Blake, 2011/05/04
- Re: gl_MODULE_INDICATOR,
Bruno Haible <=
- Re: gl_MODULE_INDICATOR, Eric Blake, 2011/05/05
- Re: two semantics of fclose(), Bruno Haible, 2011/05/05
- Re: two semantics of fclose(), Eric Blake, 2011/05/05
- Re: two semantics of fclose(), Jim Meyering, 2011/05/06
- Re: two semantics of fclose(), Bruno Haible, 2011/05/06
- [PATCH] fclose: guarantee behavior on seekable stdin, Eric Blake, 2011/05/06
- Re: [PATCH] fclose: guarantee behavior on seekable stdin, Bruno Haible, 2011/05/06
- Re: [PATCH] fclose: guarantee behavior on seekable stdin, Bruno Haible, 2011/05/07