[PHP] A really wacky design decision

2009-10-03 Thread clancy_1
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

2009-10-03 Thread Kim Madsen

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=downloadtrack_id=357

GET /?action=downloadtrack_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=downloadtrack_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=downloadtrack_id=357
Cookie: login_email=kim%40emax.dk;
PHPSESSID=fbb5d6adec802766cf6f638c99ab4f1d
Content-Type: application/x-www-form-urlencoded
Content-Length: 131
action=ask_questionsdownload_zipfile=1version_id
%5B1065%5D=1version_id%5B1066%5D=1version_id%5B1067%5D=1version_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=357member_id=1string=41e0cd250ca3a40598e2019fd4c813cckbit=320zipfile=1

GET /download.php?
track_id=357member_id=1string=41e0cd250ca3a40598e2019fd4c813cckbit=320zipfile=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,application/xhtml+xml,application/xml;q=0.9,*/
*;q=0.8

RE: [PHP] A really wacky design decision

2009-10-03 Thread Andrea Giammarchi

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

2009-10-03 Thread Andrea Giammarchi

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=downloadtrack_id=357
 
 GET /?action=downloadtrack_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=downloadtrack_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=downloadtrack_id=357
 Cookie: login_email=kim%40emax.dk;
 PHPSESSID=fbb5d6adec802766cf6f638c99ab4f1d
 Content-Type: application/x-www-form-urlencoded
 Content-Length: 131
 action=ask_questionsdownload_zipfile=1version_id
 %5B1065%5D=1version_id%5B1066%5D=1version_id%5B1067%5D=1version_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
 

[PHP] Problem with Filesystem Functions

2009-10-03 Thread Andrew Burgess
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

2009-10-03 Thread Ashley Sheridan
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

2009-10-03 Thread Ralph Deffke
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

clanc...@cybec.com.au 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?

2009-10-03 Thread Tom Worster
On 10/2/09 10:24 AM, tedd tedd.sperl...@gmail.com 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

2009-10-03 Thread Ashley Sheridan
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
 
 clanc...@cybec.com.au 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

2009-10-03 Thread Ralph Deffke
yes for using
$num = $num++;
yes !!

Ashley Sheridan a...@ashleysheridan.co.uk 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
 
  clanc...@cybec.com.au 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

2009-10-03 Thread Ashley Sheridan
On Sat, 2009-10-03 at 15:46 +0200, Ralph Deffke wrote:

 yes for using
 $num = $num++;
 yes !!
 
 Ashley Sheridan a...@ashleysheridan.co.uk 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
  
   clanc...@cybec.com.au 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

2009-10-03 Thread Ralph Deffke
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 a...@ashleysheridan.co.uk 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 a...@ashleysheridan.co.uk 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
   
clanc...@cybec.com.au 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

2009-10-03 Thread Ralph Deffke
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 bdun...@agentintellect.com 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?

2009-10-03 Thread tedd

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?

2009-10-03 Thread tedd

At 9:42 AM -0400 10/3/09, Tom Worster wrote:

On 10/2/09 10:24 AM, tedd tedd.sperl...@gmail.com 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

2009-10-03 Thread kranthi
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

2009-10-03 Thread tedd

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

2009-10-03 Thread tedd

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

2009-10-03 Thread tedd

At 5:12 PM -0400 10/2/09, Robert Cummings wrote:

Daevid Vincent wrote:

?PHP
$num = 123;
$num = $num++;
print $num;  //this prints 123 and not 124 ?!!

$num = 123;
$num = ++$num;
print $num; //this prints 124 as expected

$num = 123;
$num++;
print $num;  //this prints 124 as expected

$num = 123;
print $num++; //this prints 123 and not 124 ?!!
print $num++; //this NOW prints 124
?

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:


?php

$index = 1;
foreach( @items as @item )
{
   echo 'tr'
   .'td'.($index++).'/td'
   .'td'.$item.'/td'
   .'/tr';
}

?

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:


?php

$index = 0;
foreach( @items as @item )
{
   echo 'tr'
   .'td'.(++$index).'/td'
   .'td'.$item.'/td'
   .'/tr';
}

?

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

2009-10-03 Thread tedd

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

2009-10-03 Thread tedd

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

2009-10-03 Thread tedd

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

2009-10-03 Thread Andrew Burgess
On Sat, Oct 3, 2009 at 9:29 AM, Ashley Sheridan
a...@ashleysheridan.co.uk 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?

2009-10-03 Thread Tom Worster
On 10/2/09 10:06 AM, MEM tal...@gmail.com 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

2009-10-03 Thread Daniel Brown
On Sat, Oct 3, 2009 at 10:49, tedd tedd.sperl...@gmail.com 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 P. Brown
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

2009-10-03 Thread Tom Worster
On 10/3/09 9:53 AM, Ralph Deffke ralph_def...@yahoo.de 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 kr 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

2009-10-03 Thread Tom Worster
On 10/3/09 7:21 AM, clanc...@cybec.com.au 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

2009-10-03 Thread Ashley Sheridan
On Sat, 2009-10-03 at 11:57 -0400, Tom Worster wrote:

 On 10/3/09 7:21 AM, clanc...@cybec.com.au 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

2009-10-03 Thread Robert Cummings



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

2009-10-03 Thread Tom Worster
On 10/3/09 12:25 PM, Ashley Sheridan a...@ashleysheridan.co.uk wrote:

 On Sat, 2009-10-03 at 11:57 -0400, Tom Worster wrote:
 
 On 10/3/09 7:21 AM, clanc...@cybec.com.au 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

2009-10-03 Thread Robert Cummings

Tom Worster wrote:

On 10/3/09 12:25 PM, Ashley Sheridan a...@ashleysheridan.co.uk wrote:


On Sat, 2009-10-03 at 11:57 -0400, Tom Worster wrote:


On 10/3/09 7:21 AM, clanc...@cybec.com.au 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

2009-10-03 Thread Andrea Giammarchi

 ... 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

2009-10-03 Thread JC

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

2009-10-03 Thread Andrea Giammarchi

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

2009-10-03 Thread Robert Cummings

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

2009-10-03 Thread Andrea Giammarchi

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

2009-10-03 Thread tedd

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

2009-10-03 Thread Lupus Michaelis

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

2009-10-03 Thread Floydian
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

2009-10-03 Thread Floydian

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

2009-10-03 Thread Fred Silsbee


--- On Mon, 8/31/09, hack988 hack988 hack...@dev.htwap.com wrote:

 From: hack988 hack988 hack...@dev.htwap.com
 Subject: Re: [PHP] windows 5.2.10 PHP not working with phpinfo
 To: Fred Silsbee fredsils...@yahoo.com
 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 fredsils...@yahoo.com:
  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:
      ?php
        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