On 05/05/2011 08:28 AM, Bruno Haible wrote: > Hi Eric, > >> 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 > situation via > #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 > configure.ac. > > 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.
1. fclose alone - guarantee that fdopen(sockfd) can be fclose'd 2. fclose + fflush - guarantee that fclose(stdin) properly positions the file on seekable input libvirt is in camp 1 - it can't import fflush (since that is GPL) but must import fclose (since it uses socket fds on mingw). > 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, > you write > > #if GNULIB_TEST_FCLOSE_STRICT > > (using the usual GNULIB_TEST_* macro). > > Would that solve your use-case? I suppose it might. But if we just relicense fflush to be LGPLv2+, then fclose can depend on fflush to begin with, and always solve both problems at once, at which point I don't see the need for an fflush-strict. -- Eric Blake [email protected] +1-801-349-2682 Libvirt virtualization library http://libvirt.org
signature.asc
Description: OpenPGP digital signature
