[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: two semantics of fclose()
From: |
Eric Blake |
Subject: |
Re: two semantics of fclose() |
Date: |
Thu, 05 May 2011 16:47:03 -0600 |
User-agent: |
Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.17) Gecko/20110428 Fedora/3.1.10-1.fc14 Lightning/1.0b3pre Mnenhy/0.8.3 Thunderbird/3.1.10 |
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 address@hidden +1-801-349-2682
Libvirt virtualization library http://libvirt.org
signature.asc
Description: OpenPGP digital signature
- 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, 2011/05/05
- Re: two semantics of fclose(),
Eric Blake <=
- 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