On Wed, 27 Nov 2002, Derick Rethans wrote:
On Wed, 27 Nov 2002, Sara Pollita Golemon wrote:
User complains that maximum length of a line used by fscanf is too short
(he has lines 1600 chars). Looking at file.h I agree (it's only 512).
The user requested two options:
1) Add an
On Sat, 30 Nov 2002, Stig S. Bakken wrote:
4) Make sure we can use fscanf on a dynamically sized buffer. This will
definitely the hardest solution, but also the most beautiful one.
[4] is definitely the best option. formatted_print.c already does
something similar.
Stig, it's already
On November 29, 2002 01:05 am, Sara Golemon wrote:
I disagree with this, the current behaviour is imho wrong.
mailto: is a url, rejecting the patch because it introduces a special
case, is not a good thing. parse_url() is for _all_ url's, not just
http:// url's, and besides, the current
It looks like php_url_parse can be modified to return user and host
for mailto schemes without making it a 'special case', but that would
also remove the current 'path' index which would break existing PHP
code ((bad)).
So we can (A) put in a special case, or (B) not modify the function at
On Fri, 29 Nov 2002, Sara Golemon wrote:
I'm not so much worried about the user in this case, a few explodes will
keep them happy. I'm more worried about the behavior of parse_url being
just plain lacking. mailto:[EMAIL PROTECTED]?subject=Bug+20308 should be
entitled to everybit as much
On November 29, 2002 12:41 pm, Sara Golemon wrote:
It looks like php_url_parse can be modified to return user and host
for mailto schemes without making it a 'special case', but that would
also remove the current 'path' index which would break existing PHP
code ((bad)).
So we can (A)
I'm not so much worried about the user in this case, a few explodes
will keep them happy. I'm more worried about the behavior of
parse_url being just plain lacking.
mailto:[EMAIL PROTECTED]?subject=Bug+20308 should be entitled to
everybit as much parsing as
http://joe:[EMAIL
I disagree with this, the current behaviour is imho wrong.
mailto: is a url, rejecting the patch because it introduces a special
case, is not a good thing. parse_url() is for _all_ url's, not just
http:// url's, and besides, the current syntax for mailto is
completely valid, and should be
On Wed, 27 Nov 2002, Sara Pollita Golemon wrote:
User complains that maximum length of a line used by fscanf is too short
(he has lines 1600 chars). Looking at file.h I agree (it's only 512).
The user requested two options:
1) Add an optional length field.
No way to do that without
User complains that maximum length of a line used by fscanf is too short
(he has lines 1600 chars). Looking at file.h I agree (it's only 512).
The user requested two options:
1) Add an optional length field.
No way to do that without breaking parameter list. :(
2) Increase to a
Derick Rethans [EMAIL PROTECTED] wrote:
On Wed, 27 Nov 2002, Sara Pollita Golemon wrote:
User complains that maximum length of a line used by fscanf is too short
(he has lines 1600 chars). Looking at file.h I agree (it's only 512).
The user requested two options:
1) Add an
I don't like us adding a new ini entry for this, I think we should try
another option:
4) Make sure we can use fscanf on a dynamically sized buffer. This will
definitely the hardest solution, but also the most beautiful one.
I like this fourth option, because the internal scanf
On Thu, 28 Nov 2002, Moriyoshi Koizumi wrote:
Derick Rethans [EMAIL PROTECTED] wrote:
I don't like us adding a new ini entry for this, I think we should try
another option:
4) Make sure we can use fscanf on a dynamically sized buffer. This will
definitely the hardest solution, but
err. it didn't need a reimplementation, i fixed it, it works fine in cvs.
Then,
?php
$buf = 123 456 \0 567
sscanf($buf, %d%d%s%d, $a, $b, $c, $d);
var_dump($a, $b, $c, $d);
?
How about this?
The result was the same as for fscanf.
Moriyoshi
-Sterling
Moriyoshi
Derick
err. it didn't need a reimplementation, i fixed it, it works fine in cvs.
Then,
?php
$buf = 123 456 \0 567
sscanf($buf, %d%d%s%d, $a, $b, $c, $d);
var_dump($a, $b, $c, $d);
?
How about this?
The result was the same as for fscanf.
Yes, but it didn't need a reimplementation
Sterling Hughes [EMAIL PROTECTED] wrote:
err. it didn't need a reimplementation, i fixed it, it works fine in cvs.
Then,
?php
$buf = 123 456 \0 567
sscanf($buf, %d%d%s%d, $a, $b, $c, $d);
var_dump($a, $b, $c, $d);
?
How about this?
The result was the same as
Derick Rethans [EMAIL PROTECTED] wrote:
I don't like us adding a new ini entry for this, I think we should
try another option:
4) Make sure we can use fscanf on a dynamically sized buffer. This
will definitely the hardest solution, but also the most beautiful
one.
I'll admit to not
Derick Rethans [EMAIL PROTECTED] wrote:
I don't like us adding a new ini entry for this, I think we should
try another option:
4) Make sure we can use fscanf on a dynamically sized buffer. This
will definitely the hardest solution, but also the most beautiful
one.
I'll
On Wed, 27 Nov 2002, Sara Pollita Golemon wrote:
Derick Rethans [EMAIL PROTECTED] wrote:
I don't like us adding a new ini entry for this, I think we should
try another option:
4) Make sure we can use fscanf on a dynamically sized buffer. This
will definitely the hardest
While waiting for opinions on Bug#20460 I went ahead and addressed #20308.
User complains that parse_url returns the full email address in 'path'
element. Makes reference to documents which claim it should return 'user'
and 'host' element.
To address this request and maintain backward
I am not so sure that adding special cases for things like mailto: and so on
is a good idea. The code works identically to how it worked in 4.2.3 and
prior.
Ilia
On November 27, 2002 04:19 pm, Sara Pollita Golemon wrote:
While waiting for opinions on Bug#20460 I went ahead and addressed
That was one of the comments I was looking for Is this really necessary?
After all the user can certainly use explode() to take it apart. I'm not
against giving him that answer, it was just a quick patch to write...
Is that a -1 then?
I am not so sure that adding special cases for things like
On November 27, 2002 04:45 pm, Sara Pollita Golemon wrote:
That was one of the comments I was looking for Is this really necessary?
After all the user can certainly use explode() to take it apart. I'm not
against giving him that answer, it was just a quick patch to write...
Is that a -1
On November 27, 2002 04:45 pm, Sara Pollita Golemon wrote:
That was one of the comments I was looking for Is this really necessary?
After all the user can certainly use explode() to take it apart. I'm not
against giving him that answer, it was just a quick patch to write...
Is that a
On November 27, 2002 04:32 pm, Sterling Hughes wrote:
On November 27, 2002 04:45 pm, Sara Pollita Golemon wrote:
That was one of the comments I was looking for Is this really
necessary? After all the user can certainly use explode() to take it
apart. I'm not against giving him that
Hello Ian,
On Wed, 1 May 2002, Ian Thurlbeck wrote:
Is this a bug or a feature?
Tested on Apache 1.3.22 + PHP 4.1.2 and
Apache 2.0.35 + PHP 4.2.0RC4
With php.ini setting some_var=On I get the following:
ini_get(some_var) returns 1
Fair enough.
If you set some_var=Off the
Hello,
On Fri, 25 Jan 2002, Robinson, Mike wrote:
Just a thought
Would it be possible to add a drop down for some pre-defined
comments, such as:
1. Fixed in CVS, thanks for your report.
2. Please provide a backtrace to this report. See ... for instructions...
3. Old version, please
Zeev Suraski wrote:
It's good that this question was asked, but really, be prepared to the fact
that 'no' can also be an answer.
Then let me rephrase the question: What is the recommended
way to signal error conditions from the inside of an object
constructor?
Kristian
--
Kristian Köhntopp,
At 15:49 22/5/2001, Kristian Köhntopp wrote:
Zeev Suraski wrote:
It's good that this question was asked, but really, be prepared to the fact
that 'no' can also be an answer.
Then let me rephrase the question: What is the recommended
way to signal error conditions from the inside of an object
Stig Sæther Bakken wrote:
I disagree with your conclusion here. If a side-effect is useful
enough and people want to use it, why not document it de-bastardize
it? The fact that other OO languages implement this should be a hint
that it shouldn't be impossible to do in a different OO model.
On Fri, 18 May 2001, Stig Bakken wrote:
Anyway, I'd like to see $this assignment in constructor:
1. dismissed as a bug
2. documented as a feature, or
+1 from me on this one.
-Andrei
Hacker: Any person who derives joy from
discovering ways to circumvent limitations.
--
PHP
At 16:08 18/5/2001, Andrei Zmievski wrote:
On Fri, 18 May 2001, Stig Bakken wrote:
Anyway, I'd like to see $this assignment in constructor:
1. dismissed as a bug
2. documented as a feature, or
+1 from me on this one.
+1 on what? :)
It's generally a side effect of the implementation, so
On Fri, 18 May 2001, Zeev Suraski wrote:
It's generally a side effect of the implementation, so I wouldn't be too
keen on documenting as a feature, but as an undefined behavior.
A very useful side effect, perhaps?
-Andrei
Computers are useless. They can only give you answers.
* Zeev Suraski [EMAIL PROTECTED]
|
| At 16:08 18/5/2001, Andrei Zmievski wrote:
| On Fri, 18 May 2001, Stig Bakken wrote:
| Anyway, I'd like to see $this assignment in constructor:
|
| 1. dismissed as a bug
| 2. documented as a feature, or
|
| +1 from me on this one.
|
| +1 on what? :)
Oyvind Moll wrote:
Could the current behaviour be hard to keep in the future, with the
$this assignment in constructor syntax?
Assignments to self (to $this) are a very useful features and
common in other OO languages as well. I'd vote for keeping the
feature, document it as such and making it
Kristian Köhntopp wrote:
Assignments to self (to $this) are a very useful features and
common in other OO languages as well. I'd vote for keeping the
feature, document it as such and making it legal.
+1
--
sebastian bergmann[EMAIL PROTECTED]
At 16:27 18/5/2001, Andrei Zmievski wrote:
On Fri, 18 May 2001, Zeev Suraski wrote:
It's generally a side effect of the implementation, so I wouldn't be too
keen on documenting as a feature, but as an undefined behavior.
A very useful side effect, perhaps?
Yes, but still, a side effect.
On Fri, 18 May 2001, Zeev Suraski wrote:
Yes, but still, a side effect. Could end up changing in the future, and we
don't want to have to limit ourselves to implementations that have this
side effect.
Well, if we define it as a feature, wouldn't you be able to support it
in the future
At 16:31 18/5/2001, Oyvind Moll wrote:
Could the current behaviour be hard to keep in the future, with the
$this assignment in constructor syntax?
Yes, it is.
Zeev
--
PHP Development Mailing List http://www.php.net/
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail:
Guys,
This isn't up for a vote... It's a side effect of implementation, and
other implementations may invalidate it. We can't document it as a
feature, because it may bite us big time in the future.
Zeev
At 19:21 18/5/2001, Sebastian Bergmann wrote:
Kristian Köhntopp wrote:
Assignments to
At 20:00 18/5/2001, Andrei Zmievski wrote:
On Fri, 18 May 2001, Zeev Suraski wrote:
Yes, but still, a side effect. Could end up changing in the future,
and we
don't want to have to limit ourselves to implementations that have this
side effect.
Well, if we define it as a feature,
Zeev Suraski wrote:
Guys,
This isn't up for a vote... It's a side effect of implementation, and
other implementations may invalidate it. We can't document it as a
feature, because it may bite us big time in the future.
Is it just me, or are you refering to very different people by
'we'
At 20:39 18/5/2001, Hartmut Holzgraefe wrote:
Zeev Suraski wrote:
Guys,
This isn't up for a vote... It's a side effect of implementation, and
other implementations may invalidate it. We can't document it as a
feature, because it may bite us big time in the future.
Is it just me, or
I disagree with your conclusion here. If a side-effect is useful
enough and people want to use it, why not document it de-bastardize
it? The fact that other OO languages implement this should be a hint
that it shouldn't be impossible to do in a different OO model.
Why care more about forward
Hi fabiankessler!
On Thu, 12 Apr 2001, [EMAIL PROTECTED] wrote:
From: [EMAIL PROTECTED]
Operating system: all
PHP version: 4.0.4
PHP Bug Type: Feature/Change Request
Bug description: feature request
$a = 'foo';
$b = 'bar';
$c = (true) ? $a : $b;
suggestions:
45 matches
Mail list logo
