Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:26638
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: error (pb1.pair.com: domain php.net from 140.211.166.39 cause and error)
DomainKey-Status: good
DomainKey-Signature: q=dns; a=rsa-sha1; c=nofws;
	s=mx; d=php.net;
	h=From:Subject:To:Date;
	b=sXY/fOk0kG7+19YHxG3bWLoaOEMKPPVkhvD4lOoX7+PuK2XXeFNraGj93QfS8PG2
	j8vNBJpjzAyGgCGQ+8gYuxMgNxZIq9D1ROumW/z48mE8uJvBjKsFnb5qt0/sn+V7
Message-ID: <455BEDA4.4090608@php.net>
Date: Wed, 15 Nov 2006 20:48:36 -0800
User-Agent: Thunderbird 1.5.0.8 (Macintosh/20061025)
MIME-Version: 1.0
To:  zeev@zend.com,  stas@zend.com
CC:  internals@lists.php.net
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Subject: Re: [PHP-DEV] fgets()/fgetss() BC break in HEAD
From: pollita@php.net (Sara Golemon)

Zeev-

> My IQ is higher than 12, and I don't see how defensive coding could have 
> defended against this BC break.  This code is missing error checking, 
> but that could be quite reasonable (e.g. if you check ahead of time that 
> the file is big enough to match the format you're expecting - so it's 
> not perfect, but it's quite reasonable).  But even if it did have error 
> checking, it would look something like this:
> 
You're ignoring the fact that fgets() is the wrong tool for this job. 
This is something for fread().  "I want to read precisely X bytes.  I 
know! I'll use a function which halts at a newline character."  This 
isn't accidental reasoning of someone who "doesn't have the time to read 
every page of the manual",  This is taking antibiotics for a flu.

> So, after the BC break, it'd barf.  There's really no way to protect 
> against this BC break, and it's pretty clear this behavior is being 
> relied upon.
> 
By one project. Which is very clearly using fgets() to do what fgetc() 
should be doing.

>>> Or change the docs and the variable name to something other than
>>> maxchars is a perfect solution. :-)
>> Yes, and that's what I said both in this thread and on IRC before the 
>> thread started.
> 
> That's fine by me, but I think it's a different issue.  The BC break 
> should be reverted irregardless...
> 
Just to be clear, noone's arguing against reversion.  I accepted before 
this thread ever started that while the current logic is broken, there's 
no driving force to fix it.


Stas-

   Please don't misquote me.  While I admit my crack about the stupidity 
of anyone relying on this behavior was uncalled for, your fictionalized 
summary was just that.  Fiction.  Get your facts straight.

-Sara