[PHP] A really wacky design decision
Daevid Vincent is surprised that:
$num = 123;
$num = $num++;
print $num; //this prints 123 and not 124 ?!!
To me this is relatively logical. As I understand it, the post-increment
operator says "do
something with the variable, and then increment it. The trouble in this case is
that we
are doing something irrational; we are copying the number back to itself, and
to me it is
reasonably logical (or at least no less illogical than the alternative) to
assume that if
we copy it to itself, then increment the original version, the copy will not be
incremented.
However there is one feature of PHP which, to my mind, is really bad design.
How many of
you can see anything wrong with the following procedure to search a list of
names for a
particular name?
$i = 0; $j = count ($names); while ($i < $j)
{ if ($names[$i] == $target) { break; }
++$i;
}
As long as the names are conventional names, this procedure is probably safe to
use.
However if you allow the names to be general alphanumeric strings, it is not
reliable. One
of my programs recently broke down in one particular case, and when I
eventually isolated
the bug I discovered that it was matching '2260' to '226E1'. (The logic of this
is: 226E1
= 226*10^1 = 2260).
I agree that I was well aware of this trap, and that I should not have used a
simple
comparison, but it seems to me to be a bizarre design decision to assume that
anything
which can be converted to an integer, using any of the available notations, is
in fact an
integer, rather than making the default to simply treat it as a string. It is
also a trap
that it is very easy to fall into if you start off thinking about simple names,
and then
extend (or borrow) the procedure to use more general strings.
And can anyone tell me whether, in the above case, it is sufficient to write
simply:
if ((string) $names[$i] == $target),
or should I write:
if ((string) $names[$i] == (string) $target)?
(I decided to play safe and use strcmp ().)
--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
[PHP] Header problem
Hi PHP people
I have a really strange and annoying problem. I've got a site, where
members can download music. User clicks index.php (in index.php
there's an iframe, that opens another file), if certain check are okay
then a popup window opens download.php, where a mp3 file is fetched
from the server and renamed in the header, then pushed to the enduser,
this works fine. But now I want to create zipfiles too but when a user
downloads a zipfile it's like the whole site is freezed until download
has completed. My guess is that this is some sort of header problem
(see headers below), due to three headers at the same time, cause the
class works as expected in the test page i've created. Inputs to
correct headers would be appriciated very much :-)
Mp3 headers:
$new_filename = "attachment; filename=\"{$artist} - {$title}.mp3\"";
header('Content-Description: File Transfer');
header("Content-Type: application/octet-stream");
header("Content-Length: $size");
header("Content-Disposition: $new_filename");
header("Content-Transfer-Encoding: binary");
readfile($source_file);
Zip headers:
$zip = new zipfile();
$zip->add_dir(".");
$new_filename= "{$artist} - {$title}.mp3";
if(mysql_num_rows($result)) {
$zip->add_file($file, $new_filename);
}
header("Pragma: public");
header("Expires: 0");
header("Cache-Control: must-revalidate, post-check=0, pre-check=0");
header("Cache-Control: private",false);
header("Content-type: application/zip");
#header("Content-Type: application/octet-stream");
header("Content-disposition: attachment; filename=\"zipTest.zip\"");
header('Content-Transfer-Encoding: binary');
ob_end_clean();
echo $zip->file();
Code example: http://lps.netlinq.dk/test010/test_zip.class.php
Headers (fetched with firefox add-on: live http headers)
This is headers from the site, where the problem occurs:
1. click on the link to a title (Maxwell in this case)
--
http://lps.netlinq.dk/?action=download&track_id=357
GET /?action=download&track_id=357 HTTP/1.1
Host: lps.netlinq.dk
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.1.2) Gecko/
20090803 Ubuntu/9.04 (jaunty) Shiretoko/3.5.2
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/
*;q=0.8
Accept-Language: en-us,en;q=0.5
Accept-Encoding: gzip,deflate
Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7
Keep-Alive: 300
Connection: keep-alive
Referer: http://lps.netlinq.dk/?action=download&track_id=350
Cookie: login_email=kim%40emax.dk;
PHPSESSID=fbb5d6adec802766cf6f638c99ab4f1d
HTTP/1.x 200 OK
Date: Fri, 02 Oct 2009 15:15:21 GMT
Server: Apache/2.2.8 (Ubuntu) PHP/5.2.4-2ubuntu5.6 with Suhosin-Patch
mod_ruby/1.2.6 Ruby/1.8.6(2007-09-24) mod_ssl/2.2.8 OpenSSL/0.9.8g
X-Powered-By: PHP/5.2.4-2ubuntu5.6
Expires: Thu, 19 Nov 1981 08:52:00 GMT
Cache-Control: no-store, no-cache, must-revalidate, post-check=0, pre-
check=0
Pragma: no-cache
Vary: Accept-Encoding
Content-Encoding: gzip
Content-Length: 4250
Keep-Alive: timeout=15, max=100
Connection: Keep-Alive
Content-Type: text/html
2. I click on "download zip" (this is a link to index.php)
if conditions are met, then a popup with download.php is activated and
here a zip header is made
--
http://lps.netlinq.dk/index.php
POST /index.php HTTP/1.1
Host: lps.netlinq.dk
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.1.2) Gecko/
20090803 Ubuntu/9.04 (jaunty) Shiretoko/3.5.2
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/
*;q=0.8
Accept-Language: en-us,en;q=0.5
Accept-Encoding: gzip,deflate
Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7
Keep-Alive: 300
Connection: keep-alive
Referer: http://lps.netlinq.dk/?action=download&track_id=357
Cookie: login_email=kim%40emax.dk;
PHPSESSID=fbb5d6adec802766cf6f638c99ab4f1d
Content-Type: application/x-www-form-urlencoded
Content-Length: 131
action=ask_questions&download_zipfile=1&version_id
%5B1065%5D=1&version_id%5B1066%5D=1&version_id%5B1067%5D=1&version_id
%5B1068%5D=1
HTTP/1.x 200 OK
Date: Fri, 02 Oct 2009 15:15:29 GMT
Server: Apache/2.2.8 (Ubuntu) PHP/5.2.4-2ubuntu5.6 with Suhosin-Patch
mod_ruby/1.2.6 Ruby/1.8.6(2007-09-24) mod_ssl/2.2.8 OpenSSL/0.9.8g
X-Powered-By: PHP/5.2.4-2ubuntu5.6
Expires: Thu, 19 Nov 1981 08:52:00 GMT
Cache-Control: no-store, no-cache, must-revalidate, post-check=0, pre-
check=0
Pragma: no-cache
Vary: Accept-Encoding
Content-Encoding: gzip
Content-Length: 3216
Keep-Alive: timeout=15, max=99
Connection: Keep-Alive
Content-Type: text/html
--
http://lps.netlinq.dk/download.php?track_id=357&member_id=1&string=41e0cd250ca3a40598e2019fd4c813cc&kbit=320&zipfile=1
GET /download.php?
track_id=357&member_id=1&string=41e0cd250ca3a40598e2019fd4c813cc&kbit=320&zipfile=1
HTTP/1.1
Host: lps.netlinq.dk
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.1.2) Gecko/
20090803 Ubuntu/9.04 (jaunty) Shiretoko/3.5.2
Accept: text/html,appl
RE: [PHP] A really wacky design decision
And then you discover ===
$i = 0; $j = count ($names); while ($i < $j)
{ if ($names[$i] === $target) { break; }
++$i;
}
... regards
> To: php-general@lists.php.net
> From: clanc...@cybec.com.au
> Date: Sat, 3 Oct 2009 21:21:00 +1000
> Subject: [PHP] A really wacky design decision
>
> Daevid Vincent is surprised that:
>
> $num = 123;
> $num = $num++;
> print $num; //this prints 123 and not 124 ?!!
>
> To me this is relatively logical. As I understand it, the post-increment
> operator says "do
> something with the variable, and then increment it. The trouble in this case
> is that we
> are doing something irrational; we are copying the number back to itself, and
> to me it is
> reasonably logical (or at least no less illogical than the alternative) to
> assume that if
> we copy it to itself, then increment the original version, the copy will not
> be
> incremented.
>
> However there is one feature of PHP which, to my mind, is really bad design.
> How many of
> you can see anything wrong with the following procedure to search a list of
> names for a
> particular name?
>
> $i = 0; $j = count ($names); while ($i < $j)
> { if ($names[$i] == $target) { break; }
> ++$i;
> }
>
> As long as the names are conventional names, this procedure is probably safe
> to use.
> However if you allow the names to be general alphanumeric strings, it is not
> reliable. One
> of my programs recently broke down in one particular case, and when I
> eventually isolated
> the bug I discovered that it was matching '2260' to '226E1'. (The logic of
> this is: 226E1
> = 226*10^1 = 2260).
>
> I agree that I was well aware of this trap, and that I should not have used a
> simple
> comparison, but it seems to me to be a bizarre design decision to assume that
> anything
> which can be converted to an integer, using any of the available notations,
> is in fact an
> integer, rather than making the default to simply treat it as a string. It is
> also a trap
> that it is very easy to fall into if you start off thinking about simple
> names, and then
> extend (or borrow) the procedure to use more general strings.
>
> And can anyone tell me whether, in the above case, it is sufficient to write
> simply:
> if ((string) $names[$i] == $target),
>
> or should I write:
> if ((string) $names[$i] == (string) $target)?
>
> (I decided to play safe and use strcmp ().)
>
>
> --
> PHP General Mailing List (http://www.php.net/)
> To unsubscribe, visit: http://www.php.net/unsub.php
>
_
Windows Live: Keep your friends up to date with what you do online.
http://www.microsoft.com/middleeast/windows/windowslive/see-it-in-action/social-network-basics.aspx?ocid=PID23461::T:WLMTAGL:ON:WL:en-xm:SI_SB_1:092010
RE: [PHP] Header problem
Do you want users download the file or the zip?
do you send other headers before the download?
It's
quite a common error to set a default header in PHP at the beginning of
whatever application, while header should be used as last exit point
and never in the middle, or at the beginning, of a response.
Moreover,
if you use readfile and then zip what do you expect, multiple downloads
in one? This is not how HTTP work ... so please show more php, or
explain better what you would like to do.
Regards
> Date: Sat, 3 Oct 2009 13:30:38 +0200
> From: php@emax.dk
> To: php-general@lists.php.net
> Subject: [PHP] Header problem
>
> Hi PHP people
>
> I have a really strange and annoying problem. I've got a site, where
> members can download music. User clicks index.php (in index.php
> there's an iframe, that opens another file), if certain check are okay
> then a popup window opens download.php, where a mp3 file is fetched
> from the server and renamed in the header, then pushed to the enduser,
> this works fine. But now I want to create zipfiles too but when a user
> downloads a zipfile it's like the whole site is freezed until download
> has completed. My guess is that this is some sort of header problem
> (see headers below), due to three headers at the same time, cause the
> class works as expected in the test page i've created. Inputs to
> correct headers would be appriciated very much :-)
>
> Mp3 headers:
> $new_filename = "attachment; filename=\"{$artist} - {$title}.mp3\"";
> header('Content-Description: File Transfer');
> header("Content-Type: application/octet-stream");
> header("Content-Length: $size");
> header("Content-Disposition: $new_filename");
> header("Content-Transfer-Encoding: binary");
> readfile($source_file);
>
> Zip headers:
> $zip = new zipfile();
> $zip->add_dir(".");
> $new_filename= "{$artist} - {$title}.mp3";
> if(mysql_num_rows($result)) {
> $zip->add_file($file, $new_filename);
> }
> header("Pragma: public");
> header("Expires: 0");
> header("Cache-Control: must-revalidate, post-check=0, pre-check=0");
> header("Cache-Control: private",false);
> header("Content-type: application/zip");
> #header("Content-Type: application/octet-stream");
> header("Content-disposition: attachment; filename=\"zipTest.zip\"");
> header('Content-Transfer-Encoding: binary');
> ob_end_clean();
> echo $zip->file();
>
> Code example: http://lps.netlinq.dk/test010/test_zip.class.php
>
> Headers (fetched with firefox add-on: live http headers)
>
> This is headers from the site, where the problem occurs:
>
> 1. click on the link to a title (Maxwell in this case)
> --
> http://lps.netlinq.dk/?action=download&track_id=357
>
> GET /?action=download&track_id=357 HTTP/1.1
> Host: lps.netlinq.dk
> User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.1.2) Gecko/
> 20090803 Ubuntu/9.04 (jaunty) Shiretoko/3.5.2
> Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/
> *;q=0.8
> Accept-Language: en-us,en;q=0.5
> Accept-Encoding: gzip,deflate
> Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7
> Keep-Alive: 300
> Connection: keep-alive
> Referer: http://lps.netlinq.dk/?action=download&track_id=350
> Cookie: login_email=kim%40emax.dk;
> PHPSESSID=fbb5d6adec802766cf6f638c99ab4f1d
>
> HTTP/1.x 200 OK
> Date: Fri, 02 Oct 2009 15:15:21 GMT
> Server: Apache/2.2.8 (Ubuntu) PHP/5.2.4-2ubuntu5.6 with Suhosin-Patch
> mod_ruby/1.2.6 Ruby/1.8.6(2007-09-24) mod_ssl/2.2.8 OpenSSL/0.9.8g
> X-Powered-By: PHP/5.2.4-2ubuntu5.6
> Expires: Thu, 19 Nov 1981 08:52:00 GMT
> Cache-Control: no-store, no-cache, must-revalidate, post-check=0, pre-
> check=0
> Pragma: no-cache
> Vary: Accept-Encoding
> Content-Encoding: gzip
> Content-Length: 4250
> Keep-Alive: timeout=15, max=100
> Connection: Keep-Alive
> Content-Type: text/html
>
> 2. I click on "download zip" (this is a link to index.php)
> if conditions are met, then a popup with download.php is activated and
> here a zip header is made
>
> --
> http://lps.netlinq.dk/index.php
>
> POST /index.php HTTP/1.1
> Host: lps.netlinq.dk
> User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.1.2) Gecko/
> 20090803 Ubuntu/9.04 (jaunty) Shiretoko/3.5.2
> Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/
> *;q=0.8
> Accept-Language: en-us,en;q=0.5
> Accept-Encoding: gzip,deflate
> Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7
> Keep-Alive: 300
> Connection: keep-alive
> Referer: http://lps.netlinq.dk/?action=download&track_id=357
> Cookie: login_email=kim%40emax.dk;
> PHPSESSID=fbb5d6adec802766cf6f638c99ab4f1d
> Content-Type: application/x-www-form-urlencoded
> Content-Length: 131
> action=ask_questions&download_zipfile=1&version_id
> %5B1065%5D=1&version_id%5B1066%5D=1&version_id%5B1067%5D=1&version_id
> %5B1068%5D=1
>
> HTTP/1.x 200 OK
> Date: Fri, 02 Oct 2009 15:15:29 GMT
> Server: Apache/2.2.8
[PHP] Problem with Filesystem Functions
I hope this isn't too basic of a question . . . I'm having a problem with the Filesystem Functions, I think. Specifically, I'm recursing through a directory, and have this code: $size = filesize($file); $type = filetype($file); $date = filemtime($file); I'm getting these warnings: Warning: filesize() [function.filesize]: stat failed for AudioJungle.jpg in C:\wamp\www\file_explorer\index.php on line 33 Warning: filetype() [function.filetype]: Lstat failed for AudioJungle.jpg in C:\wamp\www\file_explorer\index.php on line 34 Warning: filemtime() [function.filemtime]: stat failed for AudioJungle.jpg in C:\wamp\www\file_explorer\index.php on line 35 These warning display for every file in the directory; however . and .. have no trouble. I've googled around and searched for probably 45min without coming up with a solution. Any help would be appreciated! TIA! -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Problem with Filesystem Functions
On Sat, 2009-10-03 at 09:07 -0400, Andrew Burgess wrote: > I hope this isn't too basic of a question . . . > > I'm having a problem with the Filesystem Functions, I think. > Specifically, I'm recursing through a directory, and have this code: > > $size = filesize($file); > $type = filetype($file); > $date = filemtime($file); > > I'm getting these warnings: > > Warning: filesize() [function.filesize]: stat failed for > AudioJungle.jpg in C:\wamp\www\file_explorer\index.php on line 33 > Warning: filetype() [function.filetype]: Lstat failed for > AudioJungle.jpg in C:\wamp\www\file_explorer\index.php on line 34 > Warning: filemtime() [function.filemtime]: stat failed for > AudioJungle.jpg in C:\wamp\www\file_explorer\index.php on line 35 > > These warning display for every file in the directory; however . and > .. have no trouble. I've googled around and searched for probably > 45min without coming up with a solution. Any help would be > appreciated! > > TIA! > Two things spring to mind. Firstly, what size are your files? I had problems reading info on files over 3GB on a 32-bit PHP install, as there's a problem with the number storage that leaves all the values read as 0. Second thing, are the values you're passing to these functions what you think they are? While the directory browsing functions might be functioning from a relative pointer, the calls to filesize() etc might need values relative to the PHP script itself, or failing that, absolute path values. Thanks, Ash http://www.ashleysheridan.co.uk
[PHP] Re: A really wacky design decision
u increment after! asigning, so far so good, but for math reasons the
interpreter has to keep in mind the 123 you want to assign before increment
to the same var.
this is absolutely correct what php does here.
$num = ++$num; would print 124
the same like
$num++;
on the other hand this is just bullshit I would release any programmer using
that type of code.
ralph_def...@yahoo.de
wrote in message
news:8fudc5tc6qvfj4n297kvjlqd3s7sjdk...@4ax.com...
> Daevid Vincent is surprised that:
>
> $num = 123;
> $num = $num++;
> print $num; //this prints 123 and not 124 ?!!
>
> To me this is relatively logical. As I understand it, the post-increment
operator says "do
> something with the variable, and then increment it. The trouble in this
case is that we
> are doing something irrational; we are copying the number back to itself,
and to me it is
> reasonably logical (or at least no less illogical than the alternative) to
assume that if
> we copy it to itself, then increment the original version, the copy will
not be
> incremented.
>
> However there is one feature of PHP which, to my mind, is really bad
design. How many of
> you can see anything wrong with the following procedure to search a list
of names for a
> particular name?
>
> $i = 0; $j = count ($names); while ($i < $j)
> { if ($names[$i] == $target) { break; }
> ++$i;
> }
>
> As long as the names are conventional names, this procedure is probably
safe to use.
> However if you allow the names to be general alphanumeric strings, it is
not reliable. One
> of my programs recently broke down in one particular case, and when I
eventually isolated
> the bug I discovered that it was matching '2260' to '226E1'. (The logic of
this is: 226E1
> = 226*10^1 = 2260).
>
> I agree that I was well aware of this trap, and that I should not have
used a simple
> comparison, but it seems to me to be a bizarre design decision to assume
that anything
> which can be converted to an integer, using any of the available
notations, is in fact an
> integer, rather than making the default to simply treat it as a string. It
is also a trap
> that it is very easy to fall into if you start off thinking about simple
names, and then
> extend (or borrow) the procedure to use more general strings.
>
> And can anyone tell me whether, in the above case, it is sufficient to
write simply:
> if ((string) $names[$i] == $target),
>
> or should I write:
> if ((string) $names[$i] == (string) $target)?
>
> (I decided to play safe and use strcmp ().)
>
--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Self-Process php forms or not?
On 10/2/09 10:24 AM, "tedd" wrote: > At 1:55 PM +0530 10/2/09, kranthi wrote: >> and yes i forgot to mention... i avoid hidden form elements because >> they can be modified very easily and hence pose a security threat. > > That depends upon how sloppy you are in coding. > > NONE of my hidden variables pose any security problems whatsoever. ...because one always assumes that data supplied in an http request is tainted. hence arguments about which exploit is more likely is rather pointless. a hidden input is really no different from any other form field. kranthi's argument would be consistent if he felt that all form inputs should be avoided because they are so easily modified as to pose a security threat. -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Re: A really wacky design decision
On Sat, 2009-10-03 at 15:33 +0200, Ralph Deffke wrote:
> u increment after! asigning, so far so good, but for math reasons the
> interpreter has to keep in mind the 123 you want to assign before increment
> to the same var.
>
> this is absolutely correct what php does here.
>
> $num = ++$num; would print 124
> the same like
> $num++;
>
> on the other hand this is just bullshit I would release any programmer using
> that type of code.
>
> ralph_def...@yahoo.de
>
> wrote in message
> news:8fudc5tc6qvfj4n297kvjlqd3s7sjdk...@4ax.com...
> > Daevid Vincent is surprised that:
> >
> > $num = 123;
> > $num = $num++;
> > print $num; //this prints 123 and not 124 ?!!
> >
> > To me this is relatively logical. As I understand it, the post-increment
> operator says "do
> > something with the variable, and then increment it. The trouble in this
> case is that we
> > are doing something irrational; we are copying the number back to itself,
> and to me it is
> > reasonably logical (or at least no less illogical than the alternative) to
> assume that if
> > we copy it to itself, then increment the original version, the copy will
> not be
> > incremented.
> >
> > However there is one feature of PHP which, to my mind, is really bad
> design. How many of
> > you can see anything wrong with the following procedure to search a list
> of names for a
> > particular name?
> >
> > $i = 0; $j = count ($names); while ($i < $j)
> > { if ($names[$i] == $target) { break; }
> > ++$i;
> > }
> >
> > As long as the names are conventional names, this procedure is probably
> safe to use.
> > However if you allow the names to be general alphanumeric strings, it is
> not reliable. One
> > of my programs recently broke down in one particular case, and when I
> eventually isolated
> > the bug I discovered that it was matching '2260' to '226E1'. (The logic of
> this is: 226E1
> > = 226*10^1 = 2260).
> >
> > I agree that I was well aware of this trap, and that I should not have
> used a simple
> > comparison, but it seems to me to be a bizarre design decision to assume
> that anything
> > which can be converted to an integer, using any of the available
> notations, is in fact an
> > integer, rather than making the default to simply treat it as a string. It
> is also a trap
> > that it is very easy to fall into if you start off thinking about simple
> names, and then
> > extend (or borrow) the procedure to use more general strings.
> >
> > And can anyone tell me whether, in the above case, it is sufficient to
> write simply:
> > if ((string) $names[$i] == $target),
> >
> > or should I write:
> > if ((string) $names[$i] == (string) $target)?
> >
> > (I decided to play safe and use strcmp ().)
> >
>
>
>
You'd release a programmer for using the incremental operators for self
assignation?
Thanks,
Ash
http://www.ashleysheridan.co.uk
--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Re: A really wacky design decision
yes for using
$num = $num++;
yes !!
"Ashley Sheridan" wrote in message
news:1254577641.2385.7.ca...@localhost...
> On Sat, 2009-10-03 at 15:33 +0200, Ralph Deffke wrote:
> > u increment after! asigning, so far so good, but for math reasons the
> > interpreter has to keep in mind the 123 you want to assign before
increment
> > to the same var.
> >
> > this is absolutely correct what php does here.
> >
> > $num = ++$num; would print 124
> > the same like
> > $num++;
> >
> > on the other hand this is just bullshit I would release any programmer
using
> > that type of code.
> >
> > ralph_def...@yahoo.de
> >
> > wrote in message
> > news:8fudc5tc6qvfj4n297kvjlqd3s7sjdk...@4ax.com...
> > > Daevid Vincent is surprised that:
> > >
> > > $num = 123;
> > > $num = $num++;
> > > print $num; //this prints 123 and not 124 ?!!
> > >
> > > To me this is relatively logical. As I understand it, the
post-increment
> > operator says "do
> > > something with the variable, and then increment it. The trouble in
this
> > case is that we
> > > are doing something irrational; we are copying the number back to
itself,
> > and to me it is
> > > reasonably logical (or at least no less illogical than the
alternative) to
> > assume that if
> > > we copy it to itself, then increment the original version, the copy
will
> > not be
> > > incremented.
> > >
> > > However there is one feature of PHP which, to my mind, is really bad
> > design. How many of
> > > you can see anything wrong with the following procedure to search a
list
> > of names for a
> > > particular name?
> > >
> > > $i = 0; $j = count ($names); while ($i < $j)
> > > { if ($names[$i] == $target) { break; }
> > > ++$i;
> > > }
> > >
> > > As long as the names are conventional names, this procedure is
probably
> > safe to use.
> > > However if you allow the names to be general alphanumeric strings, it
is
> > not reliable. One
> > > of my programs recently broke down in one particular case, and when I
> > eventually isolated
> > > the bug I discovered that it was matching '2260' to '226E1'. (The
logic of
> > this is: 226E1
> > > = 226*10^1 = 2260).
> > >
> > > I agree that I was well aware of this trap, and that I should not have
> > used a simple
> > > comparison, but it seems to me to be a bizarre design decision to
assume
> > that anything
> > > which can be converted to an integer, using any of the available
> > notations, is in fact an
> > > integer, rather than making the default to simply treat it as a
string. It
> > is also a trap
> > > that it is very easy to fall into if you start off thinking about
simple
> > names, and then
> > > extend (or borrow) the procedure to use more general strings.
> > >
> > > And can anyone tell me whether, in the above case, it is sufficient to
> > write simply:
> > > if ((string) $names[$i] == $target),
> > >
> > > or should I write:
> > > if ((string) $names[$i] == (string) $target)?
> > >
> > > (I decided to play safe and use strcmp ().)
> > >
> >
> >
> >
> You'd release a programmer for using the incremental operators for self
> assignation?
>
> Thanks,
> Ash
> http://www.ashleysheridan.co.uk
>
>
>
--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Re: A really wacky design decision
On Sat, 2009-10-03 at 15:46 +0200, Ralph Deffke wrote:
> yes for using
> $num = $num++;
> yes !!
>
> "Ashley Sheridan" wrote in message
> news:1254577641.2385.7.ca...@localhost...
> > On Sat, 2009-10-03 at 15:33 +0200, Ralph Deffke wrote:
> > > u increment after! asigning, so far so good, but for math reasons the
> > > interpreter has to keep in mind the 123 you want to assign before
> increment
> > > to the same var.
> > >
> > > this is absolutely correct what php does here.
> > >
> > > $num = ++$num; would print 124
> > > the same like
> > > $num++;
> > >
> > > on the other hand this is just bullshit I would release any programmer
> using
> > > that type of code.
> > >
> > > ralph_def...@yahoo.de
> > >
> > > wrote in message
> > > news:8fudc5tc6qvfj4n297kvjlqd3s7sjdk...@4ax.com...
> > > > Daevid Vincent is surprised that:
> > > >
> > > > $num = 123;
> > > > $num = $num++;
> > > > print $num; //this prints 123 and not 124 ?!!
> > > >
> > > > To me this is relatively logical. As I understand it, the
> post-increment
> > > operator says "do
> > > > something with the variable, and then increment it. The trouble in
> this
> > > case is that we
> > > > are doing something irrational; we are copying the number back to
> itself,
> > > and to me it is
> > > > reasonably logical (or at least no less illogical than the
> alternative) to
> > > assume that if
> > > > we copy it to itself, then increment the original version, the copy
> will
> > > not be
> > > > incremented.
> > > >
> > > > However there is one feature of PHP which, to my mind, is really bad
> > > design. How many of
> > > > you can see anything wrong with the following procedure to search a
> list
> > > of names for a
> > > > particular name?
> > > >
> > > > $i = 0; $j = count ($names); while ($i < $j)
> > > > { if ($names[$i] == $target) { break; }
> > > > ++$i;
> > > > }
> > > >
> > > > As long as the names are conventional names, this procedure is
> probably
> > > safe to use.
> > > > However if you allow the names to be general alphanumeric strings, it
> is
> > > not reliable. One
> > > > of my programs recently broke down in one particular case, and when I
> > > eventually isolated
> > > > the bug I discovered that it was matching '2260' to '226E1'. (The
> logic of
> > > this is: 226E1
> > > > = 226*10^1 = 2260).
> > > >
> > > > I agree that I was well aware of this trap, and that I should not have
> > > used a simple
> > > > comparison, but it seems to me to be a bizarre design decision to
> assume
> > > that anything
> > > > which can be converted to an integer, using any of the available
> > > notations, is in fact an
> > > > integer, rather than making the default to simply treat it as a
> string. It
> > > is also a trap
> > > > that it is very easy to fall into if you start off thinking about
> simple
> > > names, and then
> > > > extend (or borrow) the procedure to use more general strings.
> > > >
> > > > And can anyone tell me whether, in the above case, it is sufficient to
> > > write simply:
> > > > if ((string) $names[$i] == $target),
> > > >
> > > > or should I write:
> > > > if ((string) $names[$i] == (string) $target)?
> > > >
> > > > (I decided to play safe and use strcmp ().)
> > > >
> > >
> > >
> > >
> > You'd release a programmer for using the incremental operators for self
> > assignation?
> >
> > Thanks,
> > Ash
> > http://www.ashleysheridan.co.uk
> >
> >
> >
>
>
>
To be honest, of all the programming sins, this is not one to fire
someone for. Have a look at the daily wtf and you'll see what i mean!
Thanks,
Ash
http://www.ashleysheridan.co.uk
Re: [PHP] Re: A really wacky design decision
this is a clear sign that somebody is on a sin TRAIL, I would not even spend
the time on what sin collections this guy got
"Ashley Sheridan" wrote in message
news:1254577986.2385.8.ca...@localhost...
> On Sat, 2009-10-03 at 15:46 +0200, Ralph Deffke wrote:
>
> > yes for using
> > $num = $num++;
> > yes !!
> >
> > "Ashley Sheridan" wrote in message
> > news:1254577641.2385.7.ca...@localhost...
> > > On Sat, 2009-10-03 at 15:33 +0200, Ralph Deffke wrote:
> > > > u increment after! asigning, so far so good, but for math reasons
the
> > > > interpreter has to keep in mind the 123 you want to assign before
> > increment
> > > > to the same var.
> > > >
> > > > this is absolutely correct what php does here.
> > > >
> > > > $num = ++$num; would print 124
> > > > the same like
> > > > $num++;
> > > >
> > > > on the other hand this is just bullshit I would release any
programmer
> > using
> > > > that type of code.
> > > >
> > > > ralph_def...@yahoo.de
> > > >
> > > > wrote in message
> > > > news:8fudc5tc6qvfj4n297kvjlqd3s7sjdk...@4ax.com...
> > > > > Daevid Vincent is surprised that:
> > > > >
> > > > > $num = 123;
> > > > > $num = $num++;
> > > > > print $num; //this prints 123 and not 124 ?!!
> > > > >
> > > > > To me this is relatively logical. As I understand it, the
> > post-increment
> > > > operator says "do
> > > > > something with the variable, and then increment it. The trouble in
> > this
> > > > case is that we
> > > > > are doing something irrational; we are copying the number back to
> > itself,
> > > > and to me it is
> > > > > reasonably logical (or at least no less illogical than the
> > alternative) to
> > > > assume that if
> > > > > we copy it to itself, then increment the original version, the
copy
> > will
> > > > not be
> > > > > incremented.
> > > > >
> > > > > However there is one feature of PHP which, to my mind, is really
bad
> > > > design. How many of
> > > > > you can see anything wrong with the following procedure to search
a
> > list
> > > > of names for a
> > > > > particular name?
> > > > >
> > > > > $i = 0; $j = count ($names); while ($i < $j)
> > > > > { if ($names[$i] == $target) { break; }
> > > > > ++$i;
> > > > > }
> > > > >
> > > > > As long as the names are conventional names, this procedure is
> > probably
> > > > safe to use.
> > > > > However if you allow the names to be general alphanumeric strings,
it
> > is
> > > > not reliable. One
> > > > > of my programs recently broke down in one particular case, and
when I
> > > > eventually isolated
> > > > > the bug I discovered that it was matching '2260' to '226E1'. (The
> > logic of
> > > > this is: 226E1
> > > > > = 226*10^1 = 2260).
> > > > >
> > > > > I agree that I was well aware of this trap, and that I should not
have
> > > > used a simple
> > > > > comparison, but it seems to me to be a bizarre design decision to
> > assume
> > > > that anything
> > > > > which can be converted to an integer, using any of the available
> > > > notations, is in fact an
> > > > > integer, rather than making the default to simply treat it as a
> > string. It
> > > > is also a trap
> > > > > that it is very easy to fall into if you start off thinking about
> > simple
> > > > names, and then
> > > > > extend (or borrow) the procedure to use more general strings.
> > > > >
> > > > > And can anyone tell me whether, in the above case, it is
sufficient to
> > > > write simply:
> > > > > if ((string) $names[$i] == $target),
> > > > >
> > > > > or should I write:
> > > > > if ((string) $names[$i] == (string) $target)?
> > > > >
> > > > > (I decided to play safe and use strcmp ().)
> > > > >
> > > >
> > > >
> > > >
> > > You'd release a programmer for using the incremental operators for
self
> > > assignation?
> > >
> > > Thanks,
> > > Ash
> > > http://www.ashleysheridan.co.uk
> > >
> > >
> > >
> >
> >
> >
>
> To be honest, of all the programming sins, this is not one to fire
> someone for. Have a look at the daily wtf and you'll see what i mean!
>
> Thanks,
> Ash
> http://www.ashleysheridan.co.uk
>
>
>
--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Whacky increment/assignment logic with $foo++ vs ++$foo
Ben,
might be intersting to consider that in ur c axample u r working with a pure
memory position, while php works with references. thry it with pointers it
I'm pretty shure u get the same result as in PHP.
I'm not shure, because I don't work in perl, but doesn't per work on
references as well ?
ralph_def...@yahoo.de
"Ben Dunlap" wrote in message
news:7997e80e0910021458h20ebd75dtfc51f9264f351...@mail.gmail.com...
> mind-blowing. What the heck /is/ supposed to happen when you do this:
>
> $a = 2;
> $a = $a++;
> echo $a;
>
> Seems like any way you slice it the output should be 3. I guess what's
... and, in fact, that /is/ how C behaves. The following code:
int a = 2;
a = a++;
printf("a = [%d]\n", a);
Will output "a = [3]". At least on Ubuntu 9 using gcc 4.3.3.
So I retract my initial terse reply and apologize for misunderstanding
your question.
Ben
--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP] Self-Process php forms or not?
At 7:11 PM +0100 10/2/09, MEM wrote: I don't want to take another path. The hidden fields seems the way to go. However, you gave me the example above, and I'm not understanding how can I pass from your example: A multi-step form. To what I was looking form: 1 step form with a success page that shows no form elements. Sorry if I've not understand. I was having no intention of doing so. Regards, Márcio Márcio: At some point here, you must take keyboard in hand and program this yourself. If you took my code and ran it, then you would understand. Here's a working example: http://www.webbytedd.com/aa/step-form/ This only one of many ways to solve your problem, but it does solve it. Cheers, tedd PS: Please reply to the list and not me privately, unless you are hiring me (learned that from Stut) -- --- http://sperling.com http://ancientstones.com http://earthstones.com -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Self-Process php forms or not?
At 9:42 AM -0400 10/3/09, Tom Worster wrote: On 10/2/09 10:24 AM, "tedd" wrote: At 1:55 PM +0530 10/2/09, kranthi wrote: and yes i forgot to mention... i avoid hidden form elements because they can be modified very easily and hence pose a security threat. That depends upon how sloppy you are in coding. NONE of my hidden variables pose any security problems whatsoever. ...because one always assumes that data supplied in an http request is tainted. hence arguments about which exploit is more likely is rather pointless. a hidden input is really no different from any other form field. kranthi's argument would be consistent if he felt that all form inputs should be avoided because they are so easily modified as to pose a security threat. Exactly. All data gathered via forms, hidden or not, must be sanitized. Cheers, tedd -- --- http://sperling.com http://ancientstones.com http://earthstones.com -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Header problem
Thats a lot of headers to read.. At a first glance I can see that you did not specify a content-length header. this is a must and must be equal to the size of the file in bytes -- Kranthi. -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] A really wacky design decision
At 9:21 PM +1000 10/3/09, clanc...@cybec.com.au wrote: Daevid Vincent is surprised that: $num = 123; $num = $num++; print $num; //this prints 123 and not 124 ?!! I can understand why someone might think this is not correct, but they need to understand what is happening and why the above second assignment statement is in bad form (IMO). The first statement assigns 123 to $num. Everyone is OK with that. The next statement assigns 123 to $num, but then tries to increment $num, but doesn't because the assignment overrides the ++ operator -- this is bad form (IMO). Now, if you change the syntax to this: $num = 123; $num = ++num; print $num;//this prints 124 The first statement assigns 123 to $num. The next statement adds 1 to $num and then assigns 124 to $num, but it's still not the best form because you can do the same thing with: ++$num; OR $num++; It's usually easier to understand if one doesn't compound statements with ++ operator. Cheers, tedd -- --- http://sperling.com http://ancientstones.com http://earthstones.com -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Whacky increment/assignment logic with $foo++ vs ++$foo
At 2:01 PM -0700 10/2/09, Daevid Vincent wrote: Why would you EVER want $num = $num++; to give you back the value you already had? Even if we did $foo = $bar++; I would still logically (and common sensely) expect $foo to be the increment of $bar! You are right -- one should never structure a statement like that. Cheers, tedd -- --- http://sperling.com http://ancientstones.com http://earthstones.com -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Whacky increment/assignment logic with $foo++ vs ++$foo
At 5:12 PM -0400 10/2/09, Robert Cummings wrote: Daevid Vincent wrote: So then I read the manual because I think I'm loosing my mind and perhaps it's backwards day and nobody told me: http://us3.php.net/manual/en/language.operators.increment.php I'm baffled as to the reasoning behind: "$a++ :: Post-increment :: Returns $a, then increments $a by one." Why would you EVER want $num = $num++; to give you back the value you already had? Even if we did $foo = $bar++; I would still logically (and common sensely) expect $foo to be the increment of $bar! It also seems counter-intuitive, as I was always lead to believe everything is processed on the right of an equals sign and then assigned back to the left side of the equals sign. In this case, it does a mixture of both. Can someone PLEASE explain why the developers of PHP chose this seemingly whacky logic? This logic is almost universal in modern programming languages. Some people do the following: ' .''.($index++).'' .''.$item.'' .''; } ?> Some people consider it weird to start at 0 for the above index, because the index is only used when it is 1 or more. But the equivalent of the above is the following: ' .''.(++$index).'' .''.$item.'' .''; } ?> Cheers, Rob. -- Rob: Your examples are fine -- no problems whatsoever. I do the same thing myself. The problem I see here is with the original statement of: $num = $$num++; That's just bad form -- it doesn't do anything except inject confusion. Cheers, tedd -- --- http://sperling.com http://ancientstones.com http://earthstones.com -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP] Whacky increment/assignment logic with $foo++ vs ++$foo
At 2:28 PM -0700 10/2/09, Daevid Vincent wrote: My problem isn't with $foo++ vs ++$foo per say. I use pre/post all the time. My issue is that I see no reason to do the ASSIGNMENT FIRST and THEN INCREMENT. I see your point exactly. The problem is with the statement of: $num = $num++; That statement is just bad form. The increment is never realized. Cheers, tedd -- --- http://sperling.com http://ancientstones.com http://earthstones.com -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Whacky increment/assignment logic with $foo++ vs ++$foo
At 2:53 PM -0700 10/2/09, Ben Dunlap wrote: $a = 2; $a = $a++; echo $a; Honestly I think the only reason anyone would write an expression like that is either to fake out the compiler or because they don't properly understand the use of a unary operator. Or rather, of the increment/decrement operators, because no other unary operator actually changes the thing it operates on (AFAIK), which makes ++ and -- doubly weird. Ben Honestly, I think that the only reason why one would write that is that they don't know any better. Why do this: $a = $a++; when $a++; will do what is intended? Cheers, tedd -- --- http://sperling.com http://ancientstones.com http://earthstones.com -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Whacky increment/assignment logic with $foo++ vs ++$foo
At 5:42 PM -0400 10/2/09, Daniel Brown wrote: > If you were to use $num++, it would echo out the current number, THEN increment the value. In this example, it increments the value, THEN echoes it out. The placement of the signs (plus or minus) is the giveaway: if it's before the variable, it's modified before being processed. If it's after, then it's evaluated immediately after the variable is processed. That's absolutely true. The problem here is in the statement of: $num = $num++; Cheers, tedd -- --- http://sperling.com http://ancientstones.com http://earthstones.com -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Problem with Filesystem Functions
On Sat, Oct 3, 2009 at 9:29 AM, Ashley Sheridan wrote: > > On Sat, 2009-10-03 at 09:07 -0400, Andrew Burgess wrote: > > I hope this isn't too basic of a question . . . > > I'm having a problem with the Filesystem Functions, I think. > Specifically, I'm recursing through a directory, and have this code: > > $size = filesize($file); > $type = filetype($file); > $date = filemtime($file); > > I'm getting these warnings: > > Warning: filesize() [function.filesize]: stat failed for > AudioJungle.jpg in C:\wamp\www\file_explorer\index.php on line 33 > Warning: filetype() [function.filetype]: Lstat failed for > AudioJungle.jpg in C:\wamp\www\file_explorer\index.php on line 34 > Warning: filemtime() [function.filemtime]: stat failed for > AudioJungle.jpg in C:\wamp\www\file_explorer\index.php on line 35 > > These warning display for every file in the directory; however . and > .. have no trouble. I've googled around and searched for probably > 45min without coming up with a solution. Any help would be > appreciated! > > TIA! > > > Two things spring to mind. Firstly, what size are your files? I had problems > reading info on files over 3GB on a 32-bit PHP install, as there's a problem > with the number storage that leaves all the values read as 0. > > Second thing, are the values you're passing to these functions what you think > they are? While the directory browsing functions might be functioning from a > relative pointer, the calls to filesize() etc might need values relative to > the PHP script itself, or failing that, absolute path values. > > Thanks, > Ash > http://www.ashleysheridan.co.uk > > Thanks, Ashley! Turns out, the relative paths were wrong; changing $file to $dir . '/' . $file worked fine. Andrew -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Self-Process php forms or not?
On 10/2/09 10:06 AM, "MEM" wrote: > I'm now understanding that even if the form is submitted to self, we can > still use a redirect to a "success_message_page.php". However, we must do > this redirect, AFTER the form has submitted to himself. It's the only thing > that we have to pay attention here, correct? > > Since we are not dealing with a confirmation page, or a multi-step form, the > hidden field isn't necessary. > > It's this correct assumptions? the server script that runs in response to an http request for uri X can determine if "conditions of success" are met only after the server receives the request for X. so, if i understand your question, yes. i think your terminology is confusing you, e.g.: "AFTER the form has submitted to himself". a form doesn't submit to itself. a form and a script that processes it are SEPARATE THINGS. it's better to think in terms of a user agent and a server communicating with http requests and responses. the UA sends http requests for uris X, Y, Z, etc. (with or without accompanying form data). the forms are part of html pages the server sends to the UA in http responses. a user drives the UA. PHP scripts are involved in the server's generation of responses. (a diagram might help.) now to your queston: if a UA has an html page that it got in a response for uri X; and if the page has a form; and if the form has no action attribute (or action=X); and if the user submits the form; then the UA will send the server an http request for X. next the server receives the request for X and the server runs a certain script, the php script you are coding. now i'm assuming these are your requirements: if that script determines failure, the user says at X and is asked to resubmit the form. if the script determines success, the user will wind up at a new uri: Y. further, you want to send the user over to Y by sending her UA an http response with Location=Y redirection. in these terms, the answer to your question should be pretty clear. your script has to receive and process requests for X before it can decide if it's going to respond to the UA with a Location=Y redirection or an html page with a form and an error message. -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Whacky increment/assignment logic with $foo++ vs ++$foo
On Sat, Oct 3, 2009 at 10:49, tedd wrote: > > That's absolutely true. > > The problem here is in the statement of: > > $num = $num++; Yeah, I understood Daevid's email a bit better *after* I sent mine. Then I was hoping no one noticed. -- daniel.br...@parasane.net || danbr...@php.net http://www.parasane.net/ || http://www.pilotpig.net/ Check out our great hosting and dedicated server deals at http://twitter.com/pilotpig -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Re: A really wacky design decision
On 10/3/09 9:53 AM, "Ralph Deffke" wrote: > this is a clear sign that somebody is on a sin TRAIL, I would not even spend > the time on what sin collections this guy got i see it more as ignorance than sin. to misunderstand the difference between $n++ and ++$n is a beginner error. as k&r made very clear with their sequences of lessons in the original book, without actually saying so, becoming "an experienced programming" is like becoming a zen master. it is a progression to sophistication, the exemplars of which can be found here: http://www1.us.ioccc.org/years-spoiler.html i particularly recommend herrmann2 from 2001. masterful and dumbfounding. read the .hint file. -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] A really wacky design decision
On 10/3/09 7:21 AM, "clanc...@cybec.com.au" wrote:
> However there is one feature of PHP which, to my mind, is really bad design.
> How many of
> you can see anything wrong with the following procedure to search a list of
> names for a
> particular name?
>
> $i = 0; $j = count ($names); while ($i < $j)
> { if ($names[$i] == $target) { break; }
> ++$i;
> }
>
> As long as the names are conventional names, this procedure is probably safe
> to use.
> However if you allow the names to be general alphanumeric strings, it is not
> reliable. One
> of my programs recently broke down in one particular case, and when I
> eventually isolated
> the bug I discovered that it was matching '2260' to '226E1'. (The logic of
> this is: 226E1
> = 226*10^1 = 2260).
>
> I agree that I was well aware of this trap, and that I should not have used a
> simple
> comparison, but it seems to me to be a bizarre design decision to assume that
> anything
> which can be converted to an integer, using any of the available notations, is
> in fact an
> integer, rather than making the default to simply treat it as a string.
this is odd.
i might think it ok for (2260 == '226E1') to be true since php would be
doing type juggling in a logical left-to-right manner: we start with an
integer 2260, next is the juggling comparison operator, then a string, so it
might reasonably try to convert the string to an integer and then compare.
but with ('2260' == '226E1'), where both lhs and rhs are already of the same
time, it seems elliptical, to say the least, that php should search the
types to which it can convert the strings looking for one in which they are
equal.
--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] A really wacky design decision
On Sat, 2009-10-03 at 11:57 -0400, Tom Worster wrote:
> On 10/3/09 7:21 AM, "clanc...@cybec.com.au" wrote:
>
> > However there is one feature of PHP which, to my mind, is really bad design.
> > How many of
> > you can see anything wrong with the following procedure to search a list of
> > names for a
> > particular name?
> >
> > $i = 0; $j = count ($names); while ($i < $j)
> > { if ($names[$i] == $target) { break; }
> > ++$i;
> > }
> >
> > As long as the names are conventional names, this procedure is probably safe
> > to use.
> > However if you allow the names to be general alphanumeric strings, it is not
> > reliable. One
> > of my programs recently broke down in one particular case, and when I
> > eventually isolated
> > the bug I discovered that it was matching '2260' to '226E1'. (The logic of
> > this is: 226E1
> > = 226*10^1 = 2260).
> >
> > I agree that I was well aware of this trap, and that I should not have used
> > a
> > simple
> > comparison, but it seems to me to be a bizarre design decision to assume
> > that
> > anything
> > which can be converted to an integer, using any of the available notations,
> > is
> > in fact an
> > integer, rather than making the default to simply treat it as a string.
>
> this is odd.
>
> i might think it ok for (2260 == '226E1') to be true since php would be
> doing type juggling in a logical left-to-right manner: we start with an
> integer 2260, next is the juggling comparison operator, then a string, so it
> might reasonably try to convert the string to an integer and then compare.
>
> but with ('2260' == '226E1'), where both lhs and rhs are already of the same
> time, it seems elliptical, to say the least, that php should search the
> types to which it can convert the strings looking for one in which they are
> equal.
>
>
>
I don't know what you mean by elliptical, but I'd expect and certainly
hope that PHP wouldn't try to convert both strings to something which
would mean they had the same value. Also, afaik, if the variables types
are exactly the same, PHP won't try to convert either of them for a
comparison
Thanks,
Ash
http://www.ashleysheridan.co.uk
Re: [PHP] A really wacky design decision
tedd wrote: At 9:21 PM +1000 10/3/09, clanc...@cybec.com.au wrote: Daevid Vincent is surprised that: $num = 123; $num = $num++; print $num; //this prints 123 and not 124 ?!! I can understand why someone might think this is not correct, but they need to understand what is happening and why the above second assignment statement is in bad form (IMO). The first statement assigns 123 to $num. Everyone is OK with that. The next statement assigns 123 to $num, but then tries to increment $num, but doesn't because the assignment overrides the ++ operator -- this is bad form (IMO). While I absolutely agree that it is bad form, I think you got the actual flow wrong. I think the $num++ copies the current value of $num, then increments $num to 124, then the previously copied value is returned at which point the assignment operator receives it and then overwrites the 124 with the copy of 123. Cheers, Rob. -- http://www.interjinn.com Application and Templating Framework for PHP -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] A really wacky design decision
On 10/3/09 12:25 PM, "Ashley Sheridan" wrote:
> On Sat, 2009-10-03 at 11:57 -0400, Tom Worster wrote:
>
>> On 10/3/09 7:21 AM, "clanc...@cybec.com.au" wrote:
>>
>>> However there is one feature of PHP which, to my mind, is really bad design.
>>> How many of
>>> you can see anything wrong with the following procedure to search a list of
>>> names for a
>>> particular name?
>>>
>>> $i = 0; $j = count ($names); while ($i < $j)
>>> { if ($names[$i] == $target) { break; }
>>> ++$i;
>>> }
>>>
>>> As long as the names are conventional names, this procedure is probably safe
>>> to use.
>>> However if you allow the names to be general alphanumeric strings, it is not
>>> reliable. One
>>> of my programs recently broke down in one particular case, and when I
>>> eventually isolated
>>> the bug I discovered that it was matching '2260' to '226E1'. (The logic of
>>> this is: 226E1
>>> = 226*10^1 = 2260).
>>>
>>> I agree that I was well aware of this trap, and that I should not have used
>>> a
>>> simple
>>> comparison, but it seems to me to be a bizarre design decision to assume
>>> that
>>> anything
>>> which can be converted to an integer, using any of the available notations,
>>> is
>>> in fact an
>>> integer, rather than making the default to simply treat it as a string.
>>
>> this is odd.
>>
>> i might think it ok for (2260 == '226E1') to be true since php would be
>> doing type juggling in a logical left-to-right manner: we start with an
>> integer 2260, next is the juggling comparison operator, then a string, so it
>> might reasonably try to convert the string to an integer and then compare.
>>
>> but with ('2260' == '226E1'), where both lhs and rhs are already of the same
>> time, it seems elliptical, to say the least, that php should search the
>> types to which it can convert the strings looking for one in which they are
>> equal.
>>
>
> I don't know what you mean by elliptical, but I'd expect and certainly
> hope that PHP wouldn't try to convert both strings to something which
> would mean they had the same value. Also, afaik, if the variables types
> are exactly the same, PHP won't try to convert either of them for a
> comparison
i once had such hope too.
$ php -r "var_dump('2260' == '226E1');"
bool(true)
elliptical: tending to be ambiguous, cryptic, or obscure: an elliptical
prose that is difficult to translate.
(http://dictionary.reference.com/browse/elliptical)
--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] A really wacky design decision
Tom Worster wrote:
On 10/3/09 12:25 PM, "Ashley Sheridan" wrote:
On Sat, 2009-10-03 at 11:57 -0400, Tom Worster wrote:
On 10/3/09 7:21 AM, "clanc...@cybec.com.au" wrote:
However there is one feature of PHP which, to my mind, is really bad design.
How many of
you can see anything wrong with the following procedure to search a list of
names for a
particular name?
$i = 0; $j = count ($names); while ($i < $j)
{ if ($names[$i] == $target) { break; }
++$i;
}
As long as the names are conventional names, this procedure is probably safe
to use.
However if you allow the names to be general alphanumeric strings, it is not
reliable. One
of my programs recently broke down in one particular case, and when I
eventually isolated
the bug I discovered that it was matching '2260' to '226E1'. (The logic of
this is: 226E1
= 226*10^1 = 2260).
I agree that I was well aware of this trap, and that I should not have used
a
simple
comparison, but it seems to me to be a bizarre design decision to assume
that
anything
which can be converted to an integer, using any of the available notations,
is
in fact an
integer, rather than making the default to simply treat it as a string.
this is odd.
i might think it ok for (2260 == '226E1') to be true since php would be
doing type juggling in a logical left-to-right manner: we start with an
integer 2260, next is the juggling comparison operator, then a string, so it
might reasonably try to convert the string to an integer and then compare.
but with ('2260' == '226E1'), where both lhs and rhs are already of the same
time, it seems elliptical, to say the least, that php should search the
types to which it can convert the strings looking for one in which they are
equal.
I don't know what you mean by elliptical, but I'd expect and certainly
hope that PHP wouldn't try to convert both strings to something which
would mean they had the same value. Also, afaik, if the variables types
are exactly the same, PHP won't try to convert either of them for a
comparison
i once had such hope too.
$ php -r "var_dump('2260' == '226E1');"
bool(true)
Numeric strings are special :)
Cheers,
Rob.
--
http://www.interjinn.com
Application and Templating Framework for PHP
--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP] Whacky increment/assignment logic with $foo++ vs ++$foo
> ... and, in fact, that /is/ how C behaves. The following code:
>
> int a = 2;
> a = a++;
> printf("a = [%d]\n", a);
>
> Will output "a = [3]". At least on Ubuntu 9 using gcc 4.3.3.
>
> So I retract my initial terse reply and apologize for misunderstanding
> your question.
>
> Ben
It's not that difficult to understand ... we are talking about a scripting
language as PHP is
The code you wrote for C is not the equivalent while this is:
int a = 2, b;
b = a++;
printf("b = [%d]\n", b);
and b will be exactly 2.
In PHP you are not referencing that variable, you are overwriting variable $a
with an integer, 2, and that's it.
The incremented integer, 3, is simply lost in the silly logic of the operation.
The equivalent of your C code, in PHP, would be just this:
$a = 2;
$a++;
print $a; // of course is 3, the initial $a is not lost
or, to be more explicit ...
$a = 2;
($a = &$a) and $a++;
print $a;
Regards
_
Keep your friends updated—even when you’re not signed in.
http://www.microsoft.com/middleeast/windows/windowslive/see-it-in-action/social-network-basics.aspx?ocid=PID23461::T:WLMTAGL:ON:WL:en-xm:SI_SB_5:092010
[PHP] problem with mod_php
I'm trying to install a webmail in a new server with the following items: Debian 2.6.26-2-amd64 horde 3.2.2 imp 4.2.4 apache 2.2.9 php 5.2.6 when I try to install for the first time to configure it by web, it show the following: Internal Server Error The server encountered an internal error or misconfiguration and was unable to complete your request. Please contact the server administrator, [no address given] and inform them of the time the error occurred, and anything you might have done that may have caused the error. More information about this error may be available in the server error log. And the log (apache2 error.log) shows the following: [Wed Sep 30 12:31:26 2009] [error] [client 200.60.166.10] (13)Permission denied: exec of '/var/www/horde3/login.php' failed [Wed Sep 30 12:31:26 2009] [error] [client 200.60.166.10] Premature end of script headers: login.php These are the permissions -r--r--r-- 1 www-data www-data 8740 ene 29 2009 login.php smtp:/var/www# ls -l lrwxrwxrwx 1 root root 18 sep 27 22:31 horde3 -> /usr/share/horde3/ smtp:/usr/share# ls -l drwxr-xr-x 18 www-data www-data 4096 sep 27 17:09 horde3 I hope you can help to resolve this problem -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP] A really wacky design decision
if we compare via "==" there is an implicit cast to the most primitive form.
These are all true, and all have a reason, and make sense:
// (int)'abc' is 0
var_dump('abc' == 0);
// 'abc' is not an empty string
var_dump('abc' == true);
// 2 is not 0, which would be casted into false, so it's true
var_dump(2 == true);
A common error is usually in MySQL queries without explicit cast comparing
strings to numbers as well ... this is bad, specially because every programmer
should have at least low level programming languages basis ... that can only
help to better understand today high level programming languages.
The reason we use, love, hate PHP as loose type scripting language does not
mean we should avoid to understand how php works internally (C)
Loose type is only manifested to the developer, but it will never be behind
(still C)
If you use APD or you think about the low level logic behind comparing string,
num and bool you'll probably forget the "==" operator and you'll never miss
again the "===" one ... then you'll start to explicit cast everything, when
necessary, to have all your code truly under control, and that is the moment
you'll realize PHP is not for you 'cause you are forcing a typeless language to
be strict ... and then you'll start to develop via C, Python, Java, or C#,
ending up with JavaScript on server side 'cause is the only scripting language,
without pretending classic OOP, that makes sense ... (sorry for the last part
of this reply, that's just what happened to me)
Regards
_
Windows Live: Friends get your Flickr, Yelp, and Digg updates when they e-mail
you.
http://www.microsoft.com/middleeast/windows/windowslive/see-it-in-action/social-network-basics.aspx?ocid=PID23461::T:WLMTAGL:ON:WL:en-xm:SI_SB_3:092010
Re: [PHP] A really wacky design decision
Andrea Giammarchi wrote: If you use APD or you think about the low level logic behind comparing string, > num and bool you'll probably forget the "==" operator and you'll never miss > again the "===" one ... then you'll start to explicit cast everything, when > necessary, to have all your code truly under control, and that is the moment > you'll realize PHP is not for you 'cause you are forcing a typeless language > to be strict ... and then you'll start to develop via C, Python, Java, or C#, PHP allows you to do either. If I find myself being more strict in no way does that mean I'll suddenly jump to another language. It just means I have a bit of code that requires a bit more strictness. Should I suddenly switch languages because when using the strpos() function I must use the === operator to check for existence of a substring? Utter silliness IMHO. Cheers, Rob. -- http://www.interjinn.com Application and Templating Framework for PHP -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP] A really wacky design decision
You introduced the word "suddenly", it's about 10 years I develop in PHP Regards > PHP allows you to do either. If I find myself being more strict in no > way does that mean I'll suddenly jump to another language. It just means > I have a bit of code that requires a bit more strictness. Should I > suddenly switch languages because when using the strpos() function I > must use the === operator to check for existence of a substring? Utter > silliness IMHO. > > Cheers, > Rob. > -- > http://www.interjinn.com > Application and Templating Framework for PHP _ Keep your friends updated—even when you’re not signed in. http://www.microsoft.com/middleeast/windows/windowslive/see-it-in-action/social-network-basics.aspx?ocid=PID23461::T:WLMTAGL:ON:WL:en-xm:SI_SB_5:092010
Re: [PHP] A really wacky design decision
At 1:37 PM -0400 10/3/09, Robert Cummings wrote: tedd wrote: At 9:21 PM +1000 10/3/09, clanc...@cybec.com.au wrote: Daevid Vincent is surprised that: $num = 123; $num = $num++; print $num; //this prints 123 and not 124 ?!! I can understand why someone might think this is not correct, but they need to understand what is happening and why the above second assignment statement is in bad form (IMO). The first statement assigns 123 to $num. Everyone is OK with that. The next statement assigns 123 to $num, but then tries to increment $num, but doesn't because the assignment overrides the ++ operator -- this is bad form (IMO). While I absolutely agree that it is bad form, I think you got the actual flow wrong. I think the $num++ copies the current value of $num, then increments $num to 124, then the previously copied value is returned at which point the assignment operator receives it and then overwrites the 124 with the copy of 123. Cheers, Rob. -- Rob: That could very well be -- I really don't know the flow. That was my best guess and what made sense to me. Cheers, tedd -- --- http://sperling.com http://ancientstones.com http://earthstones.com -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Whacky increment/assignment logic with $foo++ vs ++$foo
Ben Dunlap wrote:
... and, in fact, that /is/ how C behaves. The following code:
No, that's implementation's behaviour. AFAIK, the normative document
give to compiler the behaviour implementation. So, it can do
optimization, that gives strange behaviour for a people how think
increment operators had a wall defined behaviour.
int a = 2;
a = a++;
printf("a = [%d]\n", a);
Will output "a = [3]". At least on Ubuntu 9 using gcc 4.3.3.
That's gcc way :)
--
Mickaël Wolff aka Lupus Michaelis
http://lupusmic.org
--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
[PHP] Missing php5apache2.dll
Hello, I've downloaded the VC6 PHP 5.3.0 windows zip (php-5.3.0-nts-Win32-VC6-x86.zip) and I don't see the file php5apache2.dll in it. php5apache.dll is in there, but the apache 2 file isn't. Where can I find this file? -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
[PHP] [SOLVED] Re: Missing php5apache2.dll
Floydian wrote: Hello, I've downloaded the VC6 PHP 5.3.0 windows zip (php-5.3.0-nts-Win32-VC6-x86.zip) and I don't see the file php5apache2.dll in it. php5apache.dll is in there, but the apache 2 file isn't. Where can I find this file? I've found the dll :) The php5apache2.dll and php5apache2_2.dll files are in the thread safe version. php-5.3.0-Win32-VC6-x86.zip Cheers -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] windows 5.2.10 PHP not working with phpinfo
--- On Mon, 8/31/09, hack988 hack988 wrote: > From: hack988 hack988 > Subject: Re: [PHP] windows 5.2.10 PHP not working with phpinfo > To: "Fred Silsbee" > Cc: php-general@lists.php.net > Date: Monday, August 31, 2009, 6:35 AM > Please set > log_error=on,error_reporting=E_ALL,error_log=syslog in > php.ini and then,see error detail in syslog. > > 2009/8/31 Fred Silsbee : > > I got 5.3 working but found out there was no > php_mssql.dll for it. > > Somebody (who didn;t know) said I had to return to > 5.2.8 but I found no 5.2.8 so I am trying 5.2.10 > > _problem: > > under IE8: > > http://72.47.28.128:8080/phpinfo.php > > with: > > > phpinfo(); > > ?> > > > > I get : > > The website cannot display the page > > HTTP 500 > > Most likely causes: > > •The website is under maintenance. > > •The website has a programming error. > > ___ > > > > I installed : > > php-5.2.10-Win32-VC6-x86.zip and put php.ini in C:\PHP > and C:\PHP\ext > > AND C:\WINDOWS, C:\WINDOWS\system and > C:\WINDOWS\system32 > > > > I installed FastCGI 1.5 ! > > > > In php.ini I put : > > > > > > cgi.force_redirect = 0 // > for CGI > > > > extension_dir = "C:\PHP\ext" > > > > commented out > > ;doc_root = "C:\inetpub\wwwroot" // for IIS/PWS > > leaving > > doc_root = > > _ > > IIS 5.1 properties->configuration I added .php > C:\PHP\php5ts.dll > > GET,HEAD,POST,DEBUG > > > > Maybe php-win.exe > > _ > > > > I added to the XP Prof environment path > ;C:\PHP\;C:\PHP\ext\ > > > > I created an environment variable (and rebooted) PHPRC > = C:\PHP;C:\PHP\ext > > > > > > I never found any statement of the necessity of > requiring CGI > > > > The instructions ramble around > > > > > > > > > > > > > > -- > > PHP General Mailing List (http://www.php.net/) > > To unsubscribe, visit: http://www.php.net/unsub.php > > > > > thanks! Weeks back I got it to work by retreating to 5.2.6 and altering permissions in admin. This alteration may open the way for 5.3 to work! __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
