[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: two semantics of fclose()
From: |
Bruno Haible |
Subject: |
Re: two semantics of fclose() |
Date: |
Fri, 6 May 2011 00:44:14 +0200 |
User-agent: |
KMail/1.9.9 |
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+.
Bruno
--
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, 2011/05/05
- Re: gl_MODULE_INDICATOR, Eric Blake, 2011/05/05
- Re: two semantics of fclose(),
Bruno Haible <=
- 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