On 05/05/2011 04:44 PM, Bruno Haible wrote: > Hi Eric, > >>> 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 > > OK, that's how it's documented now, now that the dependency from fflush to > fclose is dropped. > >> 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. > > Yes, this would be very reasonable. Few users would want only the > halfway fixed fclose(). > > Can we relax the license of 'fflush' and its dependency 'fpurge' from LGPLv3+ > to LGPLv2+? > > lib/fflush.c - needs the permission of you, me, and Jim. > lib/fpurge.c - needs the permission of you and me. > > I agree to relax these two modules to LGPLv2+.
As do I. In fact, given the earlier question about libposix (should it be LGPLv2+ or LGPLv3+), we may be repeating our line of questioning. -- Eric Blake [email protected] +1-801-349-2682 Libvirt virtualization library http://libvirt.org
signature.asc
Description: OpenPGP digital signature
