Hi,
At the very least, the portion that adds in \n to is necessary to
fix a bug in Internet Explorer experienced by PEAR documentation users.
The source code examples in the manual at pear.php.net are highlighted
with highlight_string(), and the lack of \n causes the rendered page
examples (
On Wed, 29 Oct 2003, Christian Schneider wrote:
> Gareth Ardron wrote:
> > $var = "foo=1&bar=2";
>
> To clarify:
> You should use $var = "foo=1&bar=2"; and then $var for header() but
> htmlspecialchar($var) for your href:
> - HTTP-Headers must not be html-encoded.
> - HTML-Attributes on the other
Gareth Ardron wrote:
$var = "foo=1&bar=2";
To clarify:
You should use $var = "foo=1&bar=2"; and then $var for header() but
htmlspecialchar($var) for your href:
- HTTP-Headers must not be html-encoded.
- HTML-Attributes on the other hand have to be html-encoded.
Even though most browsers work with
Zitat von Tal Peer <[EMAIL PROTECTED]>:
> On Tue, 28 Oct 2003, Gareth Ardron wrote:
>
> > I can't figure out if this is desired or not, if it's not, I'll happily
> > draft up a patch to alter the behaviour - I just want to make sure
> > before I do.
>
> Why should header() start parsing its argume
On Tue, 28 Oct 2003, Gareth Ardron wrote:
> I can't figure out if this is desired or not, if it's not, I'll happily
> draft up a patch to alter the behaviour - I just want to make sure
> before I do.
Why should header() start parsing its argument? its only job is to add its
argument to the HTTP h
On Tue, 2003-10-28 at 15:10, [EMAIL PROTECTED] wrote:
> In your diff, you have this line: + zend_printf(" %s\";>\n", last_color);
>
> There's a semicolon (;) in the tag (marked in red, if
> available). If that was meant to be part of the style attribute (like
> style=\"color: %s;\">), then it is
Derick Rethans wrote:
Can you please not send uuencoded stuff but just attach the files as
plain text?
Sorry Derick, I didn't mean to. :-(
The patch is attached as plain text now.
Cristiano Duarte
? php-src/ZendEngine1
Index: php-src/Zend/zend_alloc.c
==
Apologies if this is the wrong list.
I've just been running into some wierd issues regarding the header()
function, which I'm not 100% sure if it's desired behaviour or not.
Basically, we have a few variables such as:
$var = "foo=1&bar=2";
Now this variable gets used in 2 cases. The first is as
> Can you please not send uuencoded stuff but just attach the files as
> plain text?
Sorry Derick, I didn't mean to.
The patch is now included as plain text.
Cristiano Duarte
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
> Can you please not send uuencoded stuff but just attach the files as
> plain text?
Sorry Derick, I didn't mean to.
The patch is now included as plain text.
Cristiano Duarte
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
In your diff, you have this line: + zend_printf("\n", last_color);
There's a semicolon (;) in the tag (marked in red, if available). If
that was meant to be part of the style attribute (like style=\"color: %s;\">),
then it is in the wrong place. And also, if that is the place it's supposed to
Attached is a patch to change the behavior of source highlighting
functions to use instead of .
This patch also introduces \n and \t when the parser encounters one
(this change is mainly for readability).
The reasoning is: the tag is depreciated[1], and \n and \t should
be preserved, and not ju
If you're interrested in writing the patch yourself (and this sounds like a
rather minor one), your best bet is to just write it and submit it for
review (Note: It wouldn't make it into PHP4 as that branch is frozen and
accepting bugfixes only, no new features, but PHP5 has room).
If you don't fee
Hi, all
I want to propose to add an additional parameter to ocisavelob() && $lob->save();,
which will allow to tell how much of LOB to read from Oracle.
As I understand, this will not break BC, if this parameter will be optional and
ocisavelob() will continue to read all LOB's content by default
On Mon, 27 Oct 2003, Cristiano Duarte wrote:
> Oops, I figure out that the patch was incorrect, since the function call
> should be "zend_hash_destroy" instead of "zend_hash_clean". Sorry. :-p
> New patch included.
> Now the memory leaks are gone forever !
Can you please not send uuencoded stuff
15 matches
Mail list logo
