Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:40307 Return-Path: Mailing-List: contact internals-help@lists.php.net; run by ezmlm Delivered-To: mailing list internals@lists.php.net Received: (qmail 41449 invoked from network); 7 Sep 2008 00:41:40 -0000 Received: from unknown (HELO lists.php.net) (127.0.0.1) by localhost with SMTP; 7 Sep 2008 00:41:40 -0000 Authentication-Results: pb1.pair.com header.from=scott@macvicar.net; sender-id=unknown Authentication-Results: pb1.pair.com smtp.mail=scott@macvicar.net; spf=permerror; sender-id=unknown Received-SPF: error (pb1.pair.com: domain macvicar.net from 193.227.246.108 cause and error) X-PHP-List-Original-Sender: scott@macvicar.net X-Host-Fingerprint: 193.227.246.108 ip246-108-v193.static.x-ip.net Received: from [193.227.246.108] ([193.227.246.108:41430] helo=lovelace.midden.org.uk) by pb1.pair.com (ecelerity 2.1.1.9-wez r(12769M)) with ESMTP id 72/C5-12247-34323C84 for ; Sat, 06 Sep 2008 20:41:40 -0400 Received: from macvicar.demon.co.uk ([80.177.111.173] helo=[192.168.1.104]) by lovelace.midden.org.uk with esmtpsa (TLS-1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.69) (envelope-from ) id 1Kc8LN-0004cr-N5; Sun, 07 Sep 2008 01:41:36 +0100 Cc: "PHP Internals" Message-ID: <6D0AFF01-4E44-426F-B129-F70304F79F64@macvicar.net> To: "Mangol Smith" In-Reply-To: Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v926) Date: Sun, 7 Sep 2008 01:41:27 +0100 References: X-Mailer: Apple Mail (2.926) X-Spam-Score: -4.1 X-Spam_Report: Spam detection software, running on the system "lovelace.midden.org.uk", has identified this incoming email as possible spam. The original message has been attached to this so you can view it (if it isn't spam) or label similar future email. If you have any questions, see the administrator of that system for details. Content preview: buff needs to be null terminated, you can use RETURN_STRINGL(buff, content_size, 1); if you know the length. Scott On 6 Sep 2008, at 23:19, Mangol Smith wrote: > Hello all, > > I got a strange problem. I opened a network stream with my web server > (localhost:80) and wrote a HTTP GET into stream and reading the HTTP > RESPONSE. > > buff = (char *)emalloc(content_size); > php_stream_read(http_stream, buff, content_size); > > where content_size is the Content-Length value in Response header. > Problem > is that when I return RETURN_STRING(buff,1); to userland. I'm > getting a > string with the content (response body) + some crap. > > length of string is more than content_size. > > for example: in a case content_size was 29; after php_stream_read() > line, > the strlen(buff) is returning 41. How is this possible? > > somewhere I read this > > php_stream_read() differs from other stream read functions in one > surprising > way. If the stream in use is not a plain files stream, only one call > to the > underlying stream implementation's read function will be made, even > if more > data was requested and more is actually available to return. This is a > compromise to let packet-based protocols such as UDP function cleanly > without blocking. > > I didn't clearly understand its meaning. Does it has anything to do > with my > results? Any help in understanding this behavious of > php_stream_read() ? > > > > -- > Mangol Smith [...] Content analysis details: (-4.1 points, 5.0 required) pts rule name description ---- ---------------------- -------------------------------------------------- -1.8 ALL_TRUSTED Passed through trusted hosts only via SMTP -2.6 BAYES_00 BODY: Bayesian spam probability is 0 to 1% [score: 0.0000] 0.3 AWL AWL: From: address is in the auto white-list Subject: Re: [PHP-DEV] Strange problem with php_stream_read() From: scott@macvicar.net (Scott MacVicar) buff needs to be null terminated, you can use RETURN_STRINGL(buff, content_size, 1); if you know the length. Scott On 6 Sep 2008, at 23:19, Mangol Smith wrote: > Hello all, > > I got a strange problem. I opened a network stream with my web server > (localhost:80) and wrote a HTTP GET into stream and reading the HTTP > RESPONSE. > > buff = (char *)emalloc(content_size); > php_stream_read(http_stream, buff, content_size); > > where content_size is the Content-Length value in Response header. > Problem > is that when I return RETURN_STRING(buff,1); to userland. I'm > getting a > string with the content (response body) + some crap. > > length of string is more than content_size. > > for example: in a case content_size was 29; after php_stream_read() > line, > the strlen(buff) is returning 41. How is this possible? > > somewhere I read this > > php_stream_read() differs from other stream read functions in one > surprising > way. If the stream in use is not a plain files stream, only one call > to the > underlying stream implementation's read function will be made, even > if more > data was requested and more is actually available to return. This is a > compromise to let packet-based protocols such as UDP function cleanly > without blocking. > > I didn't clearly understand its meaning. Does it has anything to do > with my > results? Any help in understanding this behavious of > php_stream_read() ? > > > > -- > Mangol Smith