Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:55005
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.160.170 as permitted sender)
MIME-Version: 1.0
In-Reply-To: <4E5AB903.9090602@mohiva.com>
References: <4E5A42B8.20600@mohiva.com>
	<op.v0xjnzo1idpuyk@damnation>
	<4E5AB903.9090602@mohiva.com>
Date: Mon, 29 Aug 2011 09:11:26 +0200
Message-ID: <CADNQb0UYne-foTVphni0OX=2wZn8Gg-o9tW6pd90uOc695gO5w@mail.gmail.com>
To: Christian Kaps <christian.kaps@mohiva.com>
Cc: PHPMailingList <internals@lists.php.net>
Content-Type: text/plain; charset=UTF-8
Subject: Re: [PHP-DEV] Problems with the stream API
From: hannes.magnusson@gmail.com (Hannes Magnusson)

On Sun, Aug 28, 2011 at 23:54, Christian Kaps <christian.kaps@mohiva.com> wrote:
> Hi Gustavo,
>
> thanks for your detailed explanation.
>
> Nevertheless it might be useful to document these inconsistent(from the
> userland point of view) behavior. Please see my comments inline.
>
> Am 28.08.2011 17:22, schrieb Gustavo Lopes:
>> On Sun, 28 Aug 2011 14:29:28 +0100, Christian Kaps
>> <christian.kaps@mohiva.com> wrote:
>>
>>> I have some problems with the stream API. The methods stream_tell and
>>> stream_seek works not as expected in some cases.
>>>
>>> Before reading the next lines, please look at the short
>>> gist(https://gist.github.com/1176641).
>>>
>>> First example:
>>>
>>> $fp = fopen('mfx://test1', 'w');
>>> fwrite($fp, '12345678');
>>> fseek($fp, -1, SEEK_CUR);
>>> fclose($fp);
>>> // stream_seek: $offset = 7
>>>
>>> If you call fseek with the arguments (-1, SEEK_CUR) then the $offset
>>> parameter in the method stream_seek is 7. It seems that the internal API
>>> takes the written bytes returned by fwrite and then it subtracts the
>>> argument (-1) from it before passing it to stream_seek. For the
>>> constants SEEK_SET and SEEK_END, the passed value is the same as defined
>>> for the fseek call.
>>
>> SEEK_CUR seeks are internally converted to SEEK_SET seeks. It's been
>> this way since at least 2002:
>>
>> http://svn.php.net/viewvc/php/php-src/trunk/main/streams.c?annotate=96547&pathrev=96547#l582
>>
>>
>> The first thing you should know is that PHP keeps track internally of
>> the position of the stream. That's why PHP knows how to convert SEEK_CUR
>> -1 to SEEK_SET 7.
>>
>> The seek type conversion is an arguable decision, but changing this has
>> some risks. Consider that some some streams might not respond to
>> SEEK_CUR seeks or that they do so defectively. The only advantages I see
>> is that it could mitigate the problems of an inaccurate internal
>> position (though this happens mostly with internal code that casts the
>> stream into e.g. a FILE* and then manipulates the pointer); it would
>> also save stream implementations that only support SEEK_CUR from having
>> to reconvert the SEEK_SET to SEEK_CUR.
>>
>
> This behavior should be documented. The possible values for the "whence"
> parameter of the "stream_seek" method should only be SEEK_SET and
> SEEK_END. And there should be a hint that the SEEK_CUR seeks are
> internally converted to SEEK_SET seeks.

Indeed, it should be documented. Please file a doc bug report for it
(and the others) :)

-Hannes