[PHP-DOC] #30836 [Opn->Csd]: Call to undefined function: cpdf_place_inline_image()

[irchtml]

 ID:   30836
 Updated by:   [EMAIL PROTECTED]
 Reported By:  Peter dot Albertsson at naturesown dot se
-Status:   Open
+Status:   Closed
 Bug Type: Documentation problem
 Operating System: WinXP SP2
 PHP Version:  5.0.2
 New Comment:

This bug has been fixed in the documentation's XML sources. Since the
online and downloadable versions of the documentation need some time
to get updated, we would like to ask you to be a bit patient.

Thank you for the report, and for helping us make our documentation
better.




Previous Comments:


[2005-01-12 23:48:03] [EMAIL PROTECTED]

cpdf_place_inline_image() is available only if PHP was compiled with GD
1.3.x.
Making it documentation problem, as it should be stated somewhere in
the docs.




[2004-11-19 13:26:54] Peter dot Albertsson at naturesown dot se

Description:

I get a fatal error:

Fatal error: Call to undefined function: cpdf_place_inline_image()

even though php_cpdf.dll is loaded and other cpdf functions are
working.


Reproduce code:
---
$cpdf = cpdf_open(0);
cpdf_page_init($cpdf, 1, 0, 842, 595, 1.0);
$logo = imagecreatefromgif(dirname(__FILE__) .
'/gfx/scandinavia_logo.gif');
cpdf_place_inline_image($cpdf, $logo, 50, 700, 0, imagesx($logo),
imagesy($logo), 0);

Actual result:
--
Fatal error: Call to undefined function: cpdf_place_inline_image()





-- 
Edit this bug report at http://bugs.php.net/?id=30836&edit=1

[PHP-DOC] #31407 [Opn->Asn]: move_uploaded_file() documentation incohenrent

[irchtml]

 ID:   31407
 Updated by:   [EMAIL PROTECTED]
 Reported By:  php at dreams4net dot com
-Status:   Open
+Status:   Assigned
 Bug Type: Documentation problem
 Operating System: n/a
 PHP Version:  Irrelevant
-Assigned To:  
+Assigned To:  irchtml


Previous Comments:


[2005-01-04 14:24:14] php at dreams4net dot com

Description:

Here the two notes that are in the documentation for
move_uploaded_file() :

Note: When safe mode is enabled, PHP checks whether the files or
directories you are about to operate on have the same UID (owner) as
the script that is being executed.

Note: move_uploaded_file() is not affected by the normal safe mode
UID-restrictions. This is not unsafe because move_uploaded_file() only
operates on files uploaded via PHP.


One may be true : either safe_mode check UIDs, either it doesn't, but
not both. If I'm correct, whe should delete the first note.






-- 
Edit this bug report at http://bugs.php.net/?id=31407&edit=1

[PHP-DOC] #31407 [Asn->Csd]: move_uploaded_file() documentation incohenrent

[irchtml]

 ID:   31407
 Updated by:   [EMAIL PROTECTED]
 Reported By:  php at dreams4net dot com
-Status:   Assigned
+Status:   Closed
 Bug Type: Documentation problem
 Operating System: n/a
 PHP Version:  Irrelevant
 Assigned To:  irchtml
 New Comment:

This bug has been fixed in the documentation's XML sources. Since the
online and downloadable versions of the documentation need some time
to get updated, we would like to ask you to be a bit patient.

Thank you for the report, and for helping us make our documentation
better.




Previous Comments:


[2005-01-04 14:24:14] php at dreams4net dot com

Description:

Here the two notes that are in the documentation for
move_uploaded_file() :

Note: When safe mode is enabled, PHP checks whether the files or
directories you are about to operate on have the same UID (owner) as
the script that is being executed.

Note: move_uploaded_file() is not affected by the normal safe mode
UID-restrictions. This is not unsafe because move_uploaded_file() only
operates on files uploaded via PHP.


One may be true : either safe_mode check UIDs, either it doesn't, but
not both. If I'm correct, whe should delete the first note.






-- 
Edit this bug report at http://bugs.php.net/?id=31407&edit=1

[PHP-DOC] #31473 [Ver->Csd]: Grammar errors on Magic Methods

[irchtml]

 ID:   31473
 Updated by:   [EMAIL PROTECTED]
 Reported By:  ssnoyes at hotmail dot com
-Status:   Verified
+Status:   Closed
 Bug Type: Documentation problem
 Operating System: irrelevant
 PHP Version:  Irrelevant
 Assigned To:  sean
 New Comment:

This bug has been fixed in the documentation's XML sources. Since the
online and downloadable versions of the documentation need some time
to get updated, we would like to ask you to be a bit patient.

Thank you for the report, and for helping us make our documentation
better.




Previous Comments:


[2005-01-10 16:53:31] ssnoyes at hotmail dot com

Description:

If so, that function is *being* run prior to any serialization.
should be
If so, that function is run prior to any serialization.

*committing* pending data or perform similar cleanup tasks.
should be
commit pending data or perform similar cleanup tasks.



Reproduce code:
---
http://www.php.net/manual/en/language.oop5.magic.php






-- 
Edit this bug report at http://bugs.php.net/?id=31473&edit=1

[PHP-DOC] #27944 [Asn->Opn]: features section has nothing on Sessions

[irchtml]

 ID:   27944
 Updated by:   [EMAIL PROTECTED]
 Reported By:  [EMAIL PROTECTED]
-Status:   Assigned
+Status:   Open
 Bug Type: Documentation problem
 Operating System: irrelevant
 PHP Version:  Irrelevant
 Assigned To:  irchtml


Previous Comments:


[2004-04-11 10:36:22] [EMAIL PROTECTED]

Ok, That's fine.  I wanted to check before I did anything.



[2004-04-11 09:21:20] [EMAIL PROTECTED]

I just wanted a short tutorial like introduction, similar to what we
have for file uploads. All other information for this is in the manual
too, but not grouped in any way. Moving the session stuff to the
features section is not a good idea IMO.



[2004-04-11 09:12:25] [EMAIL PROTECTED]

I agree with Goba (infos compact and all-in-one reference 
sections). 
Although a short introduction to sessions as core feature 
of php might be feasible. 
 
Friedhelm 
 



[2004-04-11 07:06:58] [EMAIL PROTECTED]

Kenneth offered to move the session info from ref.session to
features.session. The intention so far was to work the other way around
(and provide compact and all-in-one reference sections). See the preg
section for example. It contains info on preg formatting. Though
regular expressions would be a possible feature section cadidate, we
decided to keep the documentation for one extension in one place.

This does not mean that pointers might not be added to the features
section (short pages on regex extensions or session handling). But I am
strongly opposed to the idea to move out stuff from the reference
sections to the features section, since we have worked the other way
around so far. There used to be an image generation section in the
features part which we moved to the gd docs for example...

[Kenneth, it is better to store comments in the bug system for future
reference...]



[2004-04-10 13:00:46] [EMAIL PROTECTED]

Description:

The features section (http://www.php.net/manual/en/features.php) in the
Manual misses a short introduction/tutorial on sessions. It doesn't
have to be covering everything, but the basic session_start() and use
of $_SESSION[] would be a very good idea. (And of course points to more
information in the manual about it).






-- 
Edit this bug report at http://bugs.php.net/?id=27944&edit=1

[PHP-DOC] #27959 [Opn->Csd]: mcal_time_valid proto wrong

[irchtml]

 ID:  27959
 Updated by:  [EMAIL PROTECTED]
 Reported By: meus at ut dot ee
-Status:  Open
+Status:  Closed
 Bug Type:Documentation problem
 PHP Version: Irrelevant
 New Comment:

This bug has been fixed in the documentation's XML sources. Since the
online and downloadable versions of the documentation need some time
to get updated, we would like to ask you to be a bit patient.

Thank you for the report, and for helping us make our documentation
better.




Previous Comments:


[2004-04-12 03:30:53] meus at ut dot ee

Description:

at mcal_time_valid description you have 

mcal_time_valid --  Returns TRUE if the given year, month, day is a
valid time 

but should be

mcal_time_valid --  Returns TRUE if the given hour, minutes, seconds is
a valid time



sry if im wrong with this bug;

PS there is so much resistance just for writing about this stuff






-- 
Edit this bug report at http://bugs.php.net/?id=27959&edit=1

[PHP-DOC] #27960 [Opn->Csd]: typo in pcntl_alarm documentation

[irchtml]

 ID:  27960
 Updated by:  [EMAIL PROTECTED]
 Reported By: rpons at rinu dot org
-Status:  Open
+Status:  Closed
 Bug Type:Documentation problem
 PHP Version: Irrelevant
 New Comment:

This bug has been fixed in the documentation's XML sources. Since the
online and downloadable versions of the documentation need some time
to get updated, we would like to ask you to be a bit patient.

Thank you for the report, and for helping us make our documentation
better.




Previous Comments:


[2004-04-12 07:21:03] rpons at rinu dot org

Description:

In http://www.php.net/manual/en/function.pcntl-alarm.php

it is said "that will send a SIGALARM signal". It should say:

"that will send a SIGALRM signal".



Note SIGALRM != SIGALARM.



Thanks !








-- 
Edit this bug report at http://bugs.php.net/?id=27960&edit=1

[PHP-DOC] #27944 [Asn]: features section has nothing on Sessions

[irchtml]

 ID:   27944
 Updated by:   [EMAIL PROTECTED]
 Reported By:  [EMAIL PROTECTED]
 Status:   Assigned
 Bug Type: Documentation problem
 Operating System: irrelevant
 PHP Version:  Irrelevant
 Assigned To:  irchtml
 New Comment:

Ok, That's fine.  I wanted to check before I did anything.


Previous Comments:


[2004-04-11 09:21:20] [EMAIL PROTECTED]

I just wanted a short tutorial like introduction, similar to what we
have for file uploads. All other information for this is in the manual
too, but not grouped in any way. Moving the session stuff to the
features section is not a good idea IMO.



[2004-04-11 09:12:25] [EMAIL PROTECTED]

I agree with Goba (infos compact and all-in-one reference 

sections). 

Although a short introduction to sessions as core feature 

of php might be feasible. 

 

Friedhelm 

 



[2004-04-11 07:06:58] [EMAIL PROTECTED]

Kenneth offered to move the session info from ref.session to
features.session. The intention so far was to work the other way around
(and provide compact and all-in-one reference sections). See the preg
section for example. It contains info on preg formatting. Though
regular expressions would be a possible feature section cadidate, we
decided to keep the documentation for one extension in one place.



This does not mean that pointers might not be added to the features
section (short pages on regex extensions or session handling). But I am
strongly opposed to the idea to move out stuff from the reference
sections to the features section, since we have worked the other way
around so far. There used to be an image generation section in the
features part which we moved to the gd docs for example...



[Kenneth, it is better to store comments in the bug system for future
reference...]



[2004-04-10 13:00:46] [EMAIL PROTECTED]

Description:

The features section (http://www.php.net/manual/en/features.php) in the
Manual misses a short introduction/tutorial on sessions. It doesn't
have to be covering everything, but the basic session_start() and use
of $_SESSION[] would be a very good idea. (And of course points to more
information in the manual about it).






-- 
Edit this bug report at http://bugs.php.net/?id=27944&edit=1

[PHP-DOC] #27944 [Opn->Asn]: features section has nothing on Sessions

[irchtml]

 ID:   27944
 Updated by:   [EMAIL PROTECTED]
 Reported By:  [EMAIL PROTECTED]
-Status:   Open
+Status:   Assigned
 Bug Type: Documentation problem
 Operating System: irrelevant
 PHP Version:  Irrelevant
-Assigned To:  
+Assigned To:  irchtml


Previous Comments:


[2004-04-10 13:00:46] [EMAIL PROTECTED]

Description:

The features section (http://www.php.net/manual/en/features.php) in the
Manual misses a short introduction/tutorial on sessions. It doesn't
have to be covering everything, but the basic session_start() and use
of $_SESSION[] would be a very good idea. (And of course points to more
information in the manual about it).






-- 
Edit this bug report at http://bugs.php.net/?id=27944&edit=1

[PHP-DOC] #27941 [Asn->Csd]: signature of the error handler function is not documented

[irchtml]

 ID:   27941
 Updated by:   [EMAIL PROTECTED]
 Reported By:  [EMAIL PROTECTED]
-Status:   Assigned
+Status:   Closed
 Bug Type: Documentation problem
 Operating System: irrelevant
 PHP Version:  Irrelevant
 Assigned To:  irchtml
 New Comment:

This bug has been fixed in the documentation's XML sources. Since the
online and downloadable versions of the documentation need some time
to get updated, we would like to ask you to be a bit patient.

Thank you for the report, and for helping us make our documentation
better.




Previous Comments:


[2004-04-10 06:56:36] [EMAIL PROTECTED]

Description:

The parameters that the function handling errors (as set by
set_error_handler()) receives are not documented like handlers for the
XML parser functions. The last note on the set_error_handler
documentation page describes all 5 parameters.






-- 
Edit this bug report at http://bugs.php.net/?id=27941&edit=1

[PHP-DOC] #27941 [Opn->Asn]: signature of the error handler function is not documented

[irchtml]

 ID:   27941
 Updated by:   [EMAIL PROTECTED]
 Reported By:  [EMAIL PROTECTED]
-Status:   Open
+Status:   Assigned
 Bug Type: Documentation problem
 Operating System: irrelevant
 PHP Version:  Irrelevant
-Assigned To:  
+Assigned To:  irchtml


Previous Comments:


[2004-04-10 06:56:36] [EMAIL PROTECTED]

Description:

The parameters that the function handling errors (as set by
set_error_handler()) receives are not documented like handlers for the
XML parser functions. The last note on the set_error_handler
documentation page describes all 5 parameters.






-- 
Edit this bug report at http://bugs.php.net/?id=27941&edit=1

[PHP-DOC] #27919 [Opn->Csd]: [chm and php.net] bug on function.rand.html

[irchtml]

 ID:   27919
 Updated by:   [EMAIL PROTECTED]
 Reported By:  kingoleg at mail dot ru
-Status:   Open
+Status:   Closed
 Bug Type: Documentation problem
 Operating System: windows
 PHP Version:  4.3.4
 New Comment:

This bug has been fixed in the documentation's XML sources. Since the
online and downloadable versions of the documentation need some time
to get updated, we would like to ask you to be a bit patient.

Thank you for the report, and for helping us make our documentation
better.

RAND_MAX is [about] 32768 on windows. 'echo getrandmax()' should give
you that value.  That is the value used for the 'max' argument _if one
is not specified_.  That's not to say a larger max cannot be used,
RAND_MAX is the default.  As the manual says, "If called without the
optional min, max arguments rand() returns a pseudo-random integer
between 0 and RAND_MAX."



The note was a bit deceiving as it is entirely possible to specify a
range much larger than 32768.


Previous Comments:


[2004-04-08 07:30:50] kingoleg at mail dot ru

Description:

I have found a bug on page
http://www.php.net/manual/en/function.rand.php

[chm date: 2003-09-06]:

"On some platforms (such as Windows) RAND_MAX is only 32768. If you
require a range larger than 32768, consider using mt_rand() instead."

It is not correct for example on WinXp.





Reproduce code:
---


Expected result:

first run:

127534874 (it is >larger than 32768)

second run

59053744 (it is >larger than 32768)



Actual result:
--
I think, that word "range" in this note is from early PHP version, when
syntax was rand(start, rand). Now it rand(start, end).

I think, that words "such as Windows" must be replaced with "such as
early versions of Windows".

Or, this note can be fully rewrited.





-- 
Edit this bug report at http://bugs.php.net/?id=27919&edit=1

[PHP-DOC] #26200 [Opn->Csd]: Terminology and more

[irchtml]

 ID:   26200
 Updated by:   [EMAIL PROTECTED]
 Reported By:  lm at latchezarmintcheff dot com
-Status:   Open
+Status:   Closed
 Bug Type: Documentation problem
 Operating System: All
 PHP Version:  4.3.4
 New Comment:

Was fixed per Zeev's e-mail.


Previous Comments:


[2003-11-11 05:23:51] lm at latchezarmintcheff dot com

Description:

Dear Sirs,



Here I'm putting my short correspondence with Mr Zeev Suraski from
www.zend.com in which the errors I found in the last PHP manual is
detailfully explained.



I hope this to be of use to you.



Regards,



Latchezar Mintcheff





Dear Zeev,



Thank you for the kind reply (below).



As you suggested, I posted the same message to bugs.php.net, but I
think that it will be of use or at least of interest to you.



No doubt, people that work on PHP are doing great job, especially
having in mind they are volunteers.



Unfortunately, the terms below are often messed up, and this makes many
manuals unclear and even wrong in some parts.



To avoid other errors in the future PHP manuals, the correct matter is
as follows:



The CHARACTER is a separate basic symbol of a given alphabet.



The ALPHABET is a system of characters, used for writing and shared by
certain group of people, nation, group of nations, countries etc. The
alphabet may be Latin, Cyrillic, Greek etc.



The CHARACTER SET is a collection of alphabetical and other symbols
that satisfies a specific writing system.



The CHARACTER CODE is the machine/computer/program representation
(coding) of a specific character or other writing symbol.



The CODEPAGE is a list of selected character codes in a certain order.



The CODE TABLE or CHARACTER TABLE is the table in which a particular
codepage codes and their respective characters (and other symbols) are
structured.



The codepage in most cases specifies:



a) the alphabet;

b) the character set;

c) the national (or some other) keyboard layout.



The KEYBOARD LAYOUT is the accordance of the keys of the keyboard with
the order of some alphabet and/or with other elements of a specific
writing system. The keyboard may be hardware or software defined - by
the manufacturer or by a codepage.



That's why we have alphabets - Latin, Cyrillic, Greek etc. This is the
main thing. And, from other hand, we have codepages - ISO-8859-1
(Latin), Windows-1251 (Cyrillic), DOS-855 (Cyrillic Bulgarian), IBM-866
(Cyrillic Russian) etc. We use them to write on a specific keyboard in
a specific language with a specific character set.



I sincerely hope that you won't accept the above as a boring input in
your matter, and that it will help to clarify the parts in the PHP
manual the said terms concern.



Best regards,



Latchezar Mintcheff



Latchezar Mintcheff Publishers

Complex Nadejda, bl. 319, en. K

1229 Sofia

Bulgaria



Telephone (359 2) 375735

E-mail: [EMAIL PROTECTED]

http://www.latchezarmintcheff.com







Date: Mon, 10 Nov 2003 01:41:37 +

From:Zeev Suraski <[EMAIL PROTECTED]>

Subject: Re: FW: [CONTENT] Contact from zend.com

To: [EMAIL PROTECTED]

Reply To: [EMAIL PROTECTED]







Dear Latchezar,



Thanks for your comment! Note that PHP is an opensource, volunteer
based project, involving hundreds of people around the globe.
Generally, comments (including problem reports) about the PHP manual
can be submitted at bugs.php.net, classified as 'Documentation
Problem'. The guys who wrote



PHP have little to do with the quality of the PHP manual. They're
simply not the guys who wrote it. The PHP manual on Zend.com is a
mirror of the PHP manual, which is published regularly by the PHP
Documentation Team.



Specifically regarding your comment, to minimize efforts, I fixed the
descriptions as you suggested. They'll be updated with the next few
days, when the manual rebuilds.



Thanks!



Zeev







comment:  Sirs,  The character set and it aliases below:  cp866,
ibm866, 866, cp1251, Windows-1251, win-1251, 1251  are not "DOS and
Windows specific charset for Russian", as specified at:



http://www.zend.com/manual/function.htmlspecialchars.php



and at the entire PHP documentation. As it's well known all over the
world, these are only two of many existing CYRILLIC encodings. The name
of the respective alphabet is "CYRILLIC", not Russian. The Russians
have only Russian language and Russian keyboard layout. They use the
Cyrillic alphabet, which is of Bulgarian origin. There is no time and
room to dicuss why it's called "Cyrillic", but in two words, it's after
the names of St Cyrill and St Methodius. It's strange and partly
amusing that all the peaple know this,

excepting the creators and the developers of PHP. Regards.  Latchezar
Mintcheff, Latchezar Mintcheff Publishers, Sofia, Bulgaria






-- 
Edit this bug report at http://bugs.php.net/?id

[PHP-DOC] #25460 [Asn->Csd]: mysql_list_fields does NOT use link_identifier

[irchtml]

 ID:   25460
 Updated by:   [EMAIL PROTECTED]
 Reported By:  beckman at purplecow dot com
-Status:   Assigned
+Status:   Closed
 Bug Type: Documentation problem
 Operating System: FreeBSD 5.0-RELEASE #0
 PHP Version:  4.3.3
 Assigned To:  georg
 New Comment:

There are notes on the mysql_* function pages of deprecated functions
and alternatives to use.  The mysql_field_* functions are not
deprecated.


Previous Comments:


[2003-09-10 16:39:29] beckman at purplecow dot com

Please also add to the documentation an example of what to replace the
now depreciated mysql_list_fields with:



 replace: $result = mysql_list_fields($db, $table [, $link])

with: $result = mysql_query("SELECT * FROM ".$db.".".$table." LIMIT
1" [, $link])



 Works with mysql_field_* functions (at least it seems to) correctly.



 Since mysql_list_fields is now depreciated, you might want to check
your code out soon/now to make sure you don't get screwed when the PHP
team takes mysql_list_fields out of PHP entirely.



[2003-09-10 15:19:57] beckman at purplecow dot com

changed to Documentation problem (if in fact mysql_field_* functions
are depreciated and not listed as such).



[2003-09-10 15:09:49] beckman at purplecow dot com

So are mysql_field_* depreciated as well?  Should they be marked as
such in the documentation?  



You might want to put a nice replacement function in the documentation
for mysql_list_fields (and other depreciated functions) to allow people
to migrate away from mysql_list_fields smoothly and easily without
doing trial and error.  I haven't yet figured out how to do this while
continuing using mysql_field_* functions.  mysql_query("SHOW FIELDS
FROM db.table") doesn't return the same data in the same format as
mysql_list_fields does.



[2003-09-10 13:03:01] beckman at purplecow dot com

Whoops.  Now that you've marked it depreciated, I withdrawal my bug
report!  I'll get phpMyAdmin to stop using it, and thus this bug goes
away.  But just for me feeling good, can you not mark it bogus?  That
makes me feel like less of a man, and much less of a geek... :-)  A
closed would be so much better.



[2003-09-10 13:00:46] beckman at purplecow dot com

If your supposition is correct (phpMyAdmin is broken), then why would
mysql_list_fields("crt", "assignments") with a currently valid open
link to the database attempt to use the table mysql.assignments?  Even
if you give it a link, it uses the mysql database to find the table.



While I'm not a C/C++ programmer, I read the code for that function.  I
noticed that ZEND_FETCH_RESOURCE2 was added in 4.0 beta 3, and wonder
if THAT function is somehow causing this obscure occurence of this bug.
 



Why do I think it is a bug?  Because mysql_list_fields DOES work as
advertised in the code I could come up with.  HOWEVER, in that specific
example in phpMyAdmin, it does not.  I'm wondering if somehow
ZEND_FETCH_RESOURCE2 is returning the wrong mysql->conn that is being
used to connect to the DB and list the fields from a table.  



If any connection to a database can be used to read any DB from that
connection, and just before running mysql_list_fields I can do a "show
fields from crt.assignments" and it works using both a defined
link_resource or leaving it blank (using the currently selected
connection), why would mysql_list_fields("crt", "assignments") fail on
the next line?



I swear it isn't bogus.  And if it is, I'll buy you a beer or something
and hang my head in shame.



The remainder of the comments for this report are too long. To view
the rest of the comments, please view the bug report online at
http://bugs.php.net/25460

-- 
Edit this bug report at http://bugs.php.net/?id=25460&edit=1

[PHP-DOC] #25552 [Opn->Bgs]: Documentation unclear about persistent database connections

[irchtml]

 ID:  25552
 Updated by:  [EMAIL PROTECTED]
 Reported By: grange at club-internet dot fr
-Status:  Open
+Status:  Bogus
 Bug Type:Documentation problem
 PHP Version: Irrelevant
 New Comment:

Quote from the manual:



They cause the child process to simply connect only once for its entire
lifespan, instead of every time it processes a page that requires
connecting to the SQL server. This means that for every child that
opened a persistent connection will have its own open persistent
connection to the server. For example, if you had 20 different child
processes that ran a script that made a persistent connection to your
SQL server, you'd have 20 different connections to the SQL server, one
from each child.

---

Each child would have it's own connection, so the latter case in your
report would be true.  Hope that clears it up.  If you have any further
suggestions please feel free to e-mail [EMAIL PROTECTED]  Thank
you!


Previous Comments:


[2003-09-15 17:44:07] grange at club-internet dot fr

Description:

Hello,



The documentation about persistent db connections (ie. chapter 21 of
the manual) should probably be more clear whether connections are
persistent across *subsequent http requests served by different apache
child processes* or persistent across *subsequent http requests served
by the same child process* (or is it none if the above... oh well 8-)).




The french translation clearly states the first, while as I'm reading
the english documentation (and the first user contributed note), I
understand the oci8 extension (as well as other extensions providing
persistent connections) behaves the second way.



Theorically, in the second case, the number of db connections should
increase to MaxClients, where in the first case, (ignoring peak
activity) it should be less, depending on the percentage of db-driven
pages out of static pages (ie for 5% of db pages, 5% of MaxClients).



Anyway, thanks for the great work !






-- 
Edit this bug report at http://bugs.php.net/?id=25552&edit=1

[PHP-DOC] #25075 [Opn->Bgs]: mysql_insert_id return value

[irchtml]

 ID:   25075
 Updated by:   [EMAIL PROTECTED]
 Reported By:  hans at nyphp dot org
-Status:   Open
+Status:   Bogus
 Bug Type: Documentation problem
 Operating System: All
 PHP Version:  Irrelevant
 New Comment:

I used the exact code you posted and mysql_insert_id() as documented
(on php.net), returning the id 5 for the last insert as the
last_insert_id is not reset unless a new auto_increment value is
created (as said in the php.net docs).  Running the same script again
(with the same data), the id's are 0, as advertised.


Previous Comments:


[2003-08-14 06:06:50] hans at nyphp dot org

That code doesn't reproduce the bug.  This does:



The table:  



CREATE TABLE `links` (

  `linkid` int(10) unsigned NOT NULL auto_increment,

  `link` varchar(255) NOT NULL default '',

  PRIMARY KEY  (`linkid`),

  UNIQUE KEY `link` (`link`)

) TYPE=MyISAM;



The code:



http://hans.zaunere.com',

   'http://zaunere.com',

   'http://hans.zaunere.com',

   'http://nyphp.org',

   'http://lists.nyphp.org',

   'http://nyphp.org'

  );





foreach( $links as $key => $link ) {



   $tmp = mysql_escape_string($link);



   mysql_query("INSERT INTO xxx.links (linkid,link)

VALUES (NULL,'$tmp')", $MYDB);



   $R_linkid = mysql_insert_id($MYDB);



   echo "Array key: $key Link: $link Linkid: $R_linkid
";

}





This is not a bogus bug; MySQL has identified it as a documentation
bug, as I pointed to with:



http://lists.mysql.com/list.php?3:mss:9598:200308:ikdgphkkkddmffiinjik



[2003-08-14 04:12:51] [EMAIL PROTECTED]

I just had a test :



// code

mysql_query('insert into foo values (1)'); // foo have 2 fields, first
one is an auto_increment

var_dump(mysql_insert_id());



// output

Column count doesn't match value count at row 1

int(0)



>From the documentation : "mysql_insert_id() returns 0 if the previous
query does not generate an AUTO_INCREMENT value."



The documentation seems okay. bogus bug ?



Mehdi



[2003-08-13 08:21:11] hans at nyphp dot org

Description:

It's recently come to my attention that the documentation for the
mysql_insert_id wasn't indicating the correct return behavior of the
function.  I double checked this with a small C program, and found the
results to be the same.  Finally, after raising this issue with the
MySQL folks, they indicated this was a documentation error.  The
correct behavior is indicated at:



http://lists.mysql.com/list.php?3:mss:9598:200308:ikdgphkkkddmffiinjik



Thanks,



Hans






-- 
Edit this bug report at http://bugs.php.net/?id=25075&edit=1

[PHP-DOC] #24928 [Opn->Csd]: error_log inconsistent in adding newline to files

[irchtml]

 ID:   24928
 Updated by:   [EMAIL PROTECTED]
 Reported By:  phpbugs at localpin dot com
-Status:   Open
+Status:   Closed
 Bug Type: Documentation problem
 Operating System: Windows XP Home Edition
 PHP Version:  4.3.1
 New Comment:

This bug has been fixed in the documentation's XML sources. Since the
online and downloadable versions of the documentation need some time
to get updated, we would like to ask you to be a bit patient.

Thank you for the report, and for helping us make our documentation
better.




Previous Comments:


[2003-08-04 10:49:48] [EMAIL PROTECTED]

This is the correct and expected behaviour. Using the type '3' for
logging errors is supposed to be flexible, someone might NOT want any
linefeeds appended, ie. if they want to log in binary format, for
example.





[2003-08-04 01:12:03] phpbugs at localpin dot com

The observant reader will notice that the sample code should use the
the variable $msg rather than $fileline:



error_log($msg, 3, $dev_filename);



error_log($msg);



;-)



[2003-08-04 01:07:53] phpbugs at localpin dot com

Description:

There is an inconsistency whether error_log gives a newline or not when
sending output, only based upon whether the file is not named (message
type 0) or named explicitly (message type 3).



i.e. when doing "error_log($msg)" a newline is automatically appended,
but when doing "error_log($msg, 3, $myfile)" a newline is not
automatically appended.



e.g. error_log($msg) gives:

1. My msg

2. My msg

3. My msg

4. My msg



but error_log($msg, 3, $another_file) gives:

1. My msg 2. My msg 3. M

y msg 4. My msg



Since in both cases the output is to a file, it seems to me that this
is inconsistent.  Either BOTH should give an automatic newline, or
NEITHER.



One can even imagine the case where the filename for both is identical
(e.g. both use the file "error.log"), yet because you specify the name
of the file explicitly, you don't get a 'free' newline char.

Reproduce code:
---
var $counter = 1;

var $log_elsewhere = true;

var $msg_prefix = "This is test number: ";

var $dev_filename = "c:/Program Files/Apache
Group/Apache/logs/dev_error.log";$elsewhere_log_name = 



while (true) {

  $msg = $msg_prefix . $counter;

  if ($log_elsewhere) {

error_log($fileline, 3, $dev_filename);



// The following line should not be necessary

error_log("\n", 3, $dev_filename);

  }

  else {

error_log($fileline);

  } 



  $counter++;

}

Expected result:

Without the extra newline sending, I would like the output to be
identical in both cases.






-- 
Edit this bug report at http://bugs.php.net/?id=24928&edit=1

[PHP-DOC] #25356 [Ver->Csd]: ?: (ternary) - shold operate as in C, but does not

[irchtml]

 ID:   25356
 Updated by:   [EMAIL PROTECTED]
 Reported By:  matschek at gmx dot de
-Status:   Verified
+Status:   Closed
 Bug Type: Documentation problem
 Operating System: Irrelevant
 PHP Version:  Irrelevant
 New Comment:

This bug has been fixed in the documentation's XML sources. Since the
online and downloadable versions of the documentation need some time
to get updated, we would like to ask you to be a bit patient.

Thank you for the report, and for helping us make our documentation
better.

Removed note.


Previous Comments:


[2003-09-02 08:24:49] [EMAIL PROTECTED]

To get the correct result do this:



  echo $c1 ? 1 : ($c2 ? 2 : 3);



Isn't that much readable too? :)

Anyway, that note about ternary being same as in C is wrong.





[2003-09-02 06:30:51] matschek at gmx dot de

Description:

The documentation says in the section Comparison Operators:



"Another conditional operator is the "?:" (or ternary) operator, which
operates as in C and many other languages"



This is not true, because in C and other languages the ternary-operator
is parsed/compiled from left to right, and therefore cases other
results.



The included code returns "1" in C and JavaScript, for example, but "2"
in PHP

Reproduce code:
---
$c1=true;

$c2=false;



echo $c1 ? 1 : $c2 ? 2 : 3;



Expected result:

1

Actual result:
--
2





-- 
Edit this bug report at http://bugs.php.net/?id=25356&edit=1

[PHP-DOC] #27900 [Opn->Csd]: Default installation-dir seems to be /usr/local/msql3

[irchtml]

 ID:   27900
 Updated by:   [EMAIL PROTECTED]
 Reported By:  oliver dot leischner at gmx dot de
-Status:   Open
+Status:   Closed
 Bug Type: Documentation problem
 Operating System: Gentoo-Linux
 PHP Version:  Irrelevant
 New Comment:

This bug has been fixed in the documentation's XML sources. Since the
online and downloadable versions of the documentation need some time
to get updated, we would like to ask you to be a bit patient.

Thank you for the report, and for helping us make our documentation
better.




Previous Comments:


[2004-04-07 11:52:32] oliver dot leischner at gmx dot de

I forgot to write down the address: 

http://www.php.net/manual/en/ref.msql.php



[2004-04-07 04:53:28] oliver dot leischner at gmx dot de

Description:

The default installation directory of msql (msql-3.4) is
/usr/local/msql3










-- 
Edit this bug report at http://bugs.php.net/?id=27900&edit=1

[PHP-DOC] #23563 [Opn->Csd]: base_convert is broken

[irchtml]

 ID:   23563
 Updated by:   [EMAIL PROTECTED]
 Reported By:  jaakkoho at paju dot oulu dot fi
-Status:   Open
+Status:   Closed
 Bug Type: Documentation problem
 Operating System: Linux 2.4 (Debian)
 PHP Version:  4.3.1
 Assigned To:  hholzgra
 New Comment:

This bug has been fixed in the documentation's XML sources. Since the
online and downloadable versions of the documentation need some time
to get updated, we would like to ask you to be a bit patient.

Thank you for the report, and for helping us make our documentation
better.




Previous Comments:


[2003-09-10 21:15:23] [EMAIL PROTECTED]

see also 23564



[2003-05-11 02:07:13] [EMAIL PROTECTED]

PHP attempts to convert the numeric string to a double value within
base_convert() function. And during this conversion, some lower digits
may be lost due to the precision of the double value, which depends on
the platform.



http://www.php.net/manual/en/language.types.float.php





[2003-05-09 08:37:03] jaakkoho at paju dot oulu dot fi

Converting a decimal to n-base and then back to decimal 

failed: 

 

print base_convert(base_convert("10001", 10, 

36), 36, 10); 

 

output: 1 (the last '0' should be '1') 

 

Bug appears only if strlen($value_to_convert) > 16. 

 




-- 
Edit this bug report at http://bugs.php.net/?id=23563&edit=1

[PHP-DOC] #23564 [Opn->Csd]: base_convert() ignores last character

[irchtml]

 ID:   23564
 Updated by:   [EMAIL PROTECTED]
 Reported By:  jaakkoho at paju dot oulu dot fi
-Status:   Open
+Status:   Closed
 Bug Type: Documentation problem
 Operating System: Linux 2.4 (Debian)
 PHP Version:  4.3.2RC3-dev
 Assigned To:  hholzgra
 New Comment:

This bug has been fixed in the documentation's XML sources. Since the
online and downloadable versions of the documentation need some time
to get updated, we would like to ask you to be a bit patient.

Thank you for the report, and for helping us make our documentation
better.




Previous Comments:


[2003-09-10 21:15:10] [EMAIL PROTECTED]

see also  23563



[2003-05-15 09:10:33] [EMAIL PROTECTED]

Okay, this is definitely not trivial to fix and making this a
documentation problem instead: base_convert() loses precision on big
numbers due to float properties.



Derick



[2003-05-15 07:33:45] [EMAIL PROTECTED]

Found the problem... the float (internally) reaches maximum precision
in the case. Going to try to fix it in some way.



[2003-05-09 09:22:00] jaakkoho at paju dot oulu dot fi

Both the following commands outputs same value: 

 

base_convert("aaa", 36, 10); 

base_convert("aab", 36, 10); 

 

output: 37606201097790608 

 

In fact, the last character can be whatever between 0-z, 

and the output is always same. 

 

This bug appears only if strlen($string_to_convert) > 10. 

 




-- 
Edit this bug report at http://bugs.php.net/?id=23564&edit=1

[PHP-DOC] #22771 [Opn->Csd]: session_id(...) causes same cookie to be sent more than once

[irchtml]

 ID:   22771
 Updated by:   [EMAIL PROTECTED]
 Reported By:  johannes dot hilpold at s-planet dot de
-Status:   Open
+Status:   Closed
 Bug Type: Documentation problem
 Operating System: Windows XP SP1
 PHP Version:  4.3.0
 New Comment:

This bug has been fixed in the documentation's XML sources. Since the
online and downloadable versions of the documentation need some time
to get updated, we would like to ask you to be a bit patient.

Thank you for the report, and for helping us make our documentation
better.




Previous Comments:


[2003-03-18 20:05:27] [EMAIL PROTECTED]

Not bug in PHP but just missing docs.





[2003-03-18 12:20:02] johannes dot hilpold at s-planet dot de

The following seems not to be an important bug, but a little
modification to PHP behaviour or some documentation on this could be
useful:



If you use session_id("...") [ "..." means a normal SESSID] to force a
special SESSID, session_start() will always(!) send the session cookie
- even if the client sent the cookie with exactly this SESSID in the
request.



Now the Problem:



--> At least IE6 will hang endless (looks as if still loading the page)
when receiving an identical session cookie the third time.



The normal way:

===

session_start() - without using session_id(...) before - will send the
session cookie only if it was not received from the client. This is the
behaviour one would expect and which should be implemented for the case
using session_id(...) too.



Of course there is a workaround available:



if (!$_REQUEST['SESSID'] == "...")

session_id("...");

session_start();





--> At least a hint in the manual should be included since this may
also cause others to lose some hours for debugging their sript, as me. 




-- 
Edit this bug report at http://bugs.php.net/?id=22771&edit=1

[PHP-DOC] #22115 [Asn->Csd]: Lack of detail to the installation instructions!

[irchtml]

 ID:   22115
 Updated by:   [EMAIL PROTECTED]
 Reported By:  stephen dot edmonds5 at btinternet dot com
-Status:   Assigned
+Status:   Closed
 Bug Type: Documentation problem
 Operating System: All
 PHP Version:  4.3.0
 Assigned To:  betz
 New Comment:

Closing as Friedhelm commented the docs were updated.


Previous Comments:


[2003-03-29 10:08:11] [EMAIL PROTECTED]

@stephen dot edmonds5 at btinternet dot com:

the docs has been updated and will show up soon on the website. You can
take a look at
http://cvs.php.net/co.php/phpdoc/en/chapters/install.apache.xml?login=2&r=1.17

Feel free to add your comments.

@mawebb at rocketmail dot com

The complete list of configure options will be soon available along
with more verbose explanations of each option. Meanwhile consult the
extension specific configure options in the function reference.



Thanks for your report.



Friedhelm





[2003-02-08 06:02:27] [EMAIL PROTECTED]

Alright verified.



If someone is already working on that, let me know or I will do it.



[2003-02-07 23:42:43] mawebb at rocketmail dot com

Hi-



What this guy says is right on - there is simply not enough explanation
in the install section. I would like to add one comment, though:



An especially glaring ommission is an explanation of what features are
built into the base install of 4.3.0, and what options need to be added
to 'configure'. The heading of the chapter says that it contains a
"complete list of configuration options", yet when I take a look at
past comments from users, they are referencing configuration options
not listed in the chapter!!?!? Among the ones of interest are the
settings for enabling MySQL, PostgreSQL, and apache support. 



Are all these built in now? It's not made clear in the doc. Also, it
would be great if there was more explanation of what the different
options mean.



The reason why this is so critical is that a wrong setting here can
cause many hours of frustration and tweaking of PHP config files,
messing with other installed programs (basically hosing your system)
when it all could have been avoided by having the info upfront about
which config flags to include...



[2003-02-07 15:17:13] stephen dot edmonds5 at btinternet dot com

Basically, the installation file in the Apache section does not provide
the level of detail that is really needed. Far too often I see emails
where people can not get php to work. Why? Because they have simply
followed this instruction:



After you've set up the file layout properly, you're ready to finally
configure Apache to load the PHP4 module. Just add the following lines
to your httpd.conf:



   LoadModule php4_module c:/php/sapi/php4apache.dll

   AddModule mod_php4.c

   AddType application/x-httpd-php .php



Followed liturally, the user then goes and plonks them all in one big
group. Guess what happens then? If you said it mess's up, then you are
correct! Basically, to help all the new users to php/php installation,
I suggest the following change: (This is taken from an email I have
sent out several times, so some gramatic change may be in order!)



LoadModule php4_module C:\PHP\sapi\php4apache.dll



This has to be in the same place as all the other LoadModule commands.
If you look through your httpd.conf file for Apache, you will see a
whole load of LoadModules with #'s in front of them. You need to place
the above line

at the end of that list.



If you then scroll down a bit the next section should be 'AddModule'.
In this section, you have to put the line

   AddModule mod_php4.c

at the bottom of the list. Both commands are needed to properly load
PHP.



Once that is done, you will need to run a search for



" # AddType allows you to tweak mime.types without actually editing it,
or to "



Below that line should be a series of AddType commands. Again, you need
to put



AddType application/x-httpd-php .php



at the end of the list.



AddType application/x-httpd-php-source .phps



is an optional feature, I personnally do not use it as I do not want
people to be able to view my source code. However it is up to you. If
you do want to include it, put it in the same section as the previous
command.




-- 
Edit this bug report at http://bugs.php.net/?id=22115&edit=1

[PHP-DOC] #23250 [Asn->Csd]: Description of "HTML-ENTITIES" is missing in mbstring docs

[irchtml]

 ID:   23250
 Updated by:   [EMAIL PROTECTED]
 Reported By:  [EMAIL PROTECTED]
-Status:   Assigned
+Status:   Closed
 Bug Type: Documentation problem
 Operating System: Any
 PHP Version:  4.3.0
 Assigned To:  moriyoshi
 New Comment:

This bug really isn't helpful to anyone other than [EMAIL PROTECTED],
would be nice if there was a short description of what needs to be
added.  Since you've been getting reminders for almost a year, I guess
closing it won't hurt.



Status -> Closed


Previous Comments:


[2003-04-21 16:19:49] [EMAIL PROTECTED]

IIRC, I think we're trying to discourage opening bugs just for
reminders.  If you yourself intend to update the docs, please don't
file a bug for it.  If you found a bug and you are not going to fix it
(i.e. don't know how, inadequite knowledge of the extension, etc..)
then file a bug (or start a thread on phpdoc).  Thanks :)



[2003-04-21 14:48:00] [EMAIL PROTECTED]

I decided to wipe my own ass :)





[2003-04-16 21:05:00] [EMAIL PROTECTED]

Registered as a reminder




-- 
Edit this bug report at http://bugs.php.net/?id=23250&edit=1

[PHP-DOC] #18680 [Ana->Csd]: Logical OR fails if value is a string

[irchtml]

 ID:   18680
 Updated by:   [EMAIL PROTECTED]
 Reported By:  su-php at bossi dot com
-Status:   Analyzed
+Status:   Closed
 Bug Type: Documentation problem
 Operating System: any
 PHP Version:  4.3.2-dev 5CVS-2003-03-10
 New Comment:

This bug has been fixed in the documentation's XML sources. Since the
online and downloadable versions of the documentation need some time
to get updated, we would like to ask you to be a bit patient.

Thank you for the report, and for helping us make our documentation
better.




Previous Comments:


[2003-03-10 13:32:14] [EMAIL PROTECTED]

Should be a documentation problem for the sake of backwards
compatibility, though I don't think this feature is useful anyhow.







[2003-03-09 19:28:03] [EMAIL PROTECTED]





If a bitwise operation are performed between two string nodes, that
ends up with the results of that operation of the values of each
character's character codes.



[2002-08-01 15:22:00] su-php at bossi dot com

It is not a session related problem, but a string conversion problem.
Below is a script which shows the problem. When doing test, remember
that the values should be based on a power of two, that is: 0x01, 0x02,
0x04, 0x08, 0x10, 0x20, ...

-



ORing Values

















Value 1

Value 2

Raw OR

strval OR

0+ OR





Number















Text



















-



[2002-07-31 18:57:18] [EMAIL PROTECTED]

Please add a short but COMPLETE example script which clearly
demonstrates the problem. 







[2002-07-31 15:03:38] su-php at bossi dot com

I stated that strval() does not work. However a kludge that DOES work
is:



echo "Val : ".((0 + $opt['time']) | (0 + $opt['date']));



The remainder of the comments for this report are too long. To view
the rest of the comments, please view the bug report online at
http://bugs.php.net/18680

-- 
Edit this bug report at http://bugs.php.net/?id=18680&edit=1

[PHP-DOC] #17653 [Opn->Csd]: FAQ: use same png libraries with PHP and GD.

[irchtml]

 ID:   17653
 Updated by:   [EMAIL PROTECTED]
 Reported By:  huberfelix at web dot de
-Status:   Open
+Status:   Closed
 Bug Type: Documentation problem
 Operating System: Linux
 PHP Version:  4.0CVS-2002-06-08
 New Comment:

This bug has been fixed in the documentation's XML sources. Since the
online and downloadable versions of the documentation need some time
to get updated, we would like to ask you to be a bit patient.

Thank you for the report, and for helping us make our documentation
better.




Previous Comments:


[2002-06-13 09:48:16] [EMAIL PROTECTED]

Yup, good idea, reclassifying.



[2002-06-13 09:46:13] huberfelix at web dot de

Correct with libpng-1.0.8 as GD and PHP source it works fine... 



an entry for the faq?



[2002-06-09 10:41:18] [EMAIL PROTECTED]

Forgot..make sure your GD library is linked with the SAME

libpng as PHP is.



--Jani





[2002-06-09 10:40:32] [EMAIL PROTECTED]

I just tried with libpng-1.2.0, latest PHP (4.3.0-dev) and gd 2.0.1
(the 'original' without our fixes) and could not 

reproduce this segfault. 



Please try the latest (non stable!) snapshot from
http://snaps.php.net/



--Jani





[2002-06-09 07:27:27] huberfelix at web dot de

hmm i compiled cvs of today with --with-png-dir=/tmp/libpng-1.0.8



and still finds the newer libpng in /usr



0x0049 in ?? ()

(gdb) bt

#0  0x0049 in ?? ()

#1  0x00a33f49 in png_create_write_struct_2 () from
/usr/lib/libpng.so.3

#2  0x00a35371 in png_create_write_struct () from /usr/lib/libpng.so.3

#3  0x00aa6d59 in gdImagePngCtx (im=0x8172318, outfile=0x81722ec) at
gd_png.c:461

#4  0x0047ee80 in object.11 () from
/usr/local/apache/current/libexec/libphp4.so

#5  0x004838fa in object.11 () from
/usr/local/apache/current/libexec/libphp4.so

#6  0x005f8b07 in object.11 () from
/usr/local/apache/current/libexec/libphp4.so

#7  0x005e5dd4 in object.11 () from
/usr/local/apache/current/libexec/libphp4.so

#8  0x005aeca5 in object.11 () from
/usr/local/apache/current/libexec/libphp4.so

#9  0x005fde00 in object.11 () from
/usr/local/apache/current/libexec/libphp4.so

#10 0x005fed78 in object.11 () from
/usr/local/apache/current/libexec/libphp4.so

#11 0x005fee02 in object.11 () from
/usr/local/apache/current/libexec/libphp4.so

#12 0x08055fd9 in ap_invoke_handler ()

#13 0x0806bb4f in ap_some_auth_required ()

#14 0x0806bbba in ap_process_request ()

#15 0x08062756 in ap_child_terminate ()

#16 0x08062935 in ap_child_terminate ()

#17 0x08062ab6 in ap_child_terminate ()

#18 0x0806314d in ap_child_terminate ()

#19 0x080639cc in main ()

#20 0x0019b571 in __libc_start_main () from /lib/libc.so.6



The remainder of the comments for this report are too long. To view
the rest of the comments, please view the bug report online at
http://bugs.php.net/17653

-- 
Edit this bug report at http://bugs.php.net/?id=17653&edit=1

[PHP-DOC] #27788 [Opn->Csd]: array_multisort doesn't mantain index associations with numeric arrays

[irchtml]

 ID:   27788
 Updated by:   [EMAIL PROTECTED]
 Reported By:  mail at spybreak dot de
-Status:   Open
+Status:   Closed
 Bug Type: Documentation problem
 Operating System: Win2K
 PHP Version:  4.3.4
 Assigned To:  andrei
 New Comment:

This bug has been fixed in the documentation's XML sources. Since the
online and downloadable versions of the documentation need some time
to get updated, we would like to ask you to be a bit patient.

Thank you for the report, and for helping us make our documentation
better.




Previous Comments:


[2004-03-31 02:08:59] [EMAIL PROTECTED]

Making this a documentation problem, as it is the correct behavior.



[2004-03-30 19:30:58] mail at spybreak dot de

Description:

The manual says that array_multisort mantains key associations. This is
only true if the keys are strings. If the keys are integers on the
other hand, key association is not mantained. I don't think that this
is a bug since it's so obvious. But I wish feedback on this to clear
this issue up. Thanks alot!

Reproduce code:
---


Expected result:

I expect this:



// _should_ return

//

// array

//   5  => 'Peter'

//   34 => 'Robert'

//   7  => 'Jim'

//   33 => 'John'

//   11 => 'Martin'

Actual result:
--
// returns the following for me

//

// array

//   0 => 'Peter'   

//   1 => 'Robert'

//   2 => 'Jim'   

//   3 => 'John'   

//   4 => 'Martin' 





-- 
Edit this bug report at http://bugs.php.net/?id=27788&edit=1

[PHP-DOC] OO-interface documentation

[irchtml]

I was documenting the XSL functions (or at least getting the skeletons
done so the manual would build with the XSL ref) and I was wondering if
there was an agreed upon convention for documenting the OO interfaces. 
I was going to use the same method that Georg is using for MySQLi, I
wanted to check and make sure that is indeed the correct way (if there
are any viable alternatives anyway).

Thanks--

Kenneth Schwartz

[PHP-DOC] #27753 [Opn->Csd]: Logic bug in empty() documentation

[irchtml]

 ID:  27753
 Updated by:  [EMAIL PROTECTED]
 Reported By: chris+php at chrullrich dot de
-Status:  Open
+Status:  Closed
 Bug Type:Documentation problem
 PHP Version: Irrelevant
 New Comment:

This bug has been fixed in the documentation's XML sources. Since the
online and downloadable versions of the documentation need some time
to get updated, we would like to ask you to be a bit patient.

Thank you for the report, and for helping us make our documentation
better.




Previous Comments:


[2004-03-29 09:59:44] chris+php at chrullrich dot de

Description:

The documentation for empty() states:



"empty() returns FALSE if var has a 

 non-empty or non-zero value."



Leaving aside the fact that empty()'s behavior of returning TRUE if the
variable contains the string "0" is completely useless, the
documentation is wrong. It should read:



"empty() returns FALSE if var has a 

 non-empty and non-zero value."

   ^^^










-- 
Edit this bug report at http://bugs.php.net/?id=27753&edit=1

[PHP-DOC] #27624 [Opn]: some apache_* functions advertised as being in 4.3.2 instead of 4.3.4

[irchtml]

 ID:   27624
 Updated by:   [EMAIL PROTECTED]
 Reported By:  hellekin at free dot Fr
 Status:   Open
 Bug Type: Documentation problem
 Operating System: na
 PHP Version:  Irrelevant
 New Comment:

apache_get_version() and apache_get_modules() were both added to the
HEAD version of sapi/apache/php_apache.c, after the branch point of PHP
4.3.  apache_get_version() was later added to that branch, getting it
into PHP 4.3.4 and apache_get_modules() was not added.  The version
information for the docs is autogenerated and for some reason it is
picking up that both functions were added in 4.3.2.  Hopefully someone
else can comment on this. ;)



>From what I understand there will be no 4.3.6 release but I'll let an
actual developer comment on that.


Previous Comments:


[2004-03-17 07:48:32] [EMAIL PROTECTED]

I changed the version information for apache_get_version().

But i can't find apache_get_modules() to be mentioned in the changelog
of 4.3.4 and it's not working on 4.3.4.



hellekin: "The Changelog says they were added in 4.3.4." which
changelog have you been looking at to see that apache_get_modules() was
added in 4.3.4?



[2004-03-17 06:42:28] hellekin at free dot Fr

Description:

The documentation for apache_get_version() and apache_get_modules()
advertise the functions for being added in PHP-4.3.2 but they're not
working in 4.3.3.

The Changelog says they were added in 4.3.4.








-- 
Edit this bug report at http://bugs.php.net/?id=27624&edit=1

[PHP-DOC] #27703 [Opn->Csd]: max_execution time exceeded

[irchtml]

 ID:   27703
 Updated by:   [EMAIL PROTECTED]
 Reported By:  anarchy_rulz14 at hotmail dot com
-Status:   Open
+Status:   Closed
 Bug Type: Documentation problem
 Operating System: Windows XP
 PHP Version:  4.3.4
 New Comment:

This bug has been fixed in the documentation's XML sources. Since the
online and downloadable versions of the documentation need some time
to get updated, we would like to ask you to be a bit patient.

Thank you for the report, and for helping us make our documentation
better.




Previous Comments:


[2004-03-25 16:12:26] anarchy_rulz14 at hotmail dot com

Sorry, I put it there at first, then I accidentally moved it when I
update the report. Sorry.



[2004-03-25 16:10:29] [EMAIL PROTECTED]

It's a deocumentation problem.



[2004-03-25 15:28:46] anarchy_rulz14 at hotmail dot com

PS. THis is the file manager i am using

http://platon.sk/projects/phpWebFileManager/home.php



[2004-03-25 15:25:24] anarchy_rulz14 at hotmail dot com

Description:

I am using PHP4.3.4 (as a module) on Apache 1.3.29 on a WinXP box.



I put this as a documentation error, because I don't know where else to
put an erroneous error message.



I am currently running a file-management script on my server, and it
always seemed to give me max_execution_time exceeded errors while
uplaodign large files, regardless of what value I set in php.ini. After
much trial and error, I have found that in fact it is NOT the
max_execution time value that is being exceeded, but it is the
max_input_time value that is being exceeded. For example (using a
default version of php.ini):



max_execution_time = 6000

max_input_time = 60



will produce the error, while:



max_execution_time = 30

max_input_time = 6000



will produce no error. For the record, NO other values (besides
max_execution_tiem and max_input_time) were modified in php.ini.



So it would seem that the error message being output is erroneous,
since it is infact the max_input_time which is being exceeded. The
error message makes it difficult to track down the real culprit in this
situation.






-- 
Edit this bug report at http://bugs.php.net/?id=27703&edit=1

[PHP-DOC] #27745 [Csd]: OCI8 doc for oci_new_descriptor uses call-time reference parameter

[irchtml]

 ID:  27745
 Updated by:  [EMAIL PROTECTED]
 Reported By: cjbj at hotmail dot com
 Status:  Closed
 Bug Type:Documentation problem
 PHP Version: Irrelevant
 New Comment:

This bug has been fixed in the documentation's XML sources. Since the
online and downloadable versions of the documentation need some time
to get updated, we would like to ask you to be a bit patient.

Thank you for the report, and for helping us make our documentation
better.




Previous Comments:


[2004-03-29 02:10:58] [EMAIL PROTECTED]

Passing the variable by [call-time] reference (&$lob) is not needed,
I'll fix the example in just a moment.



[2004-03-29 02:04:20] cjbj at hotmail dot com

Looks like it still assumes access to global variables too.

If I may presume, there is a related example that doesn't

have these problems at
http://otn.oracle.com/tech/opensource/php/php_troubleshooting_faq.html#uplobs



[2004-03-29 01:59:27] cjbj at hotmail dot com

Description:

The example in the newly revamped manual entry
http://www.php.net/manual/en/function.oci-new-descriptor.php

has the line:



  oci_bind_by_name($stmt, ':the_blob', &$lob, -1, OCI_B_BLOB);



Using this syntax I get "Warning: Call-time pass-by-reference has been
deprecated"








-- 
Edit this bug report at http://bugs.php.net/?id=27745&edit=1

[PHP-DOC] #27745 [Opn->Csd]: OCI8 doc for oci_new_descriptor uses call-time reference parameter

[irchtml]

 ID:  27745
 Updated by:  [EMAIL PROTECTED]
 Reported By: cjbj at hotmail dot com
-Status:  Open
+Status:  Closed
 Bug Type:Documentation problem
 PHP Version: Irrelevant


Previous Comments:


[2004-03-29 02:10:58] [EMAIL PROTECTED]

Passing the variable by [call-time] reference (&$lob) is not needed,
I'll fix the example in just a moment.



[2004-03-29 02:04:20] cjbj at hotmail dot com

Looks like it still assumes access to global variables too.

If I may presume, there is a related example that doesn't

have these problems at
http://otn.oracle.com/tech/opensource/php/php_troubleshooting_faq.html#uplobs



[2004-03-29 01:59:27] cjbj at hotmail dot com

Description:

The example in the newly revamped manual entry
http://www.php.net/manual/en/function.oci-new-descriptor.php

has the line:



  oci_bind_by_name($stmt, ':the_blob', &$lob, -1, OCI_B_BLOB);



Using this syntax I get "Warning: Call-time pass-by-reference has been
deprecated"








-- 
Edit this bug report at http://bugs.php.net/?id=27745&edit=1

[PHP-DOC] #27745 [Opn]: OCI8 doc for oci_new_descriptor uses call-time reference parameter

[irchtml]

 ID:  27745
 Updated by:  [EMAIL PROTECTED]
 Reported By: cjbj at hotmail dot com
 Status:  Open
 Bug Type:Documentation problem
 PHP Version: Irrelevant
 New Comment:

Passing the variable by [call-time] reference (&$lob) is not needed,
I'll fix the example in just a moment.


Previous Comments:


[2004-03-29 02:04:20] cjbj at hotmail dot com

Looks like it still assumes access to global variables too.

If I may presume, there is a related example that doesn't

have these problems at
http://otn.oracle.com/tech/opensource/php/php_troubleshooting_faq.html#uplobs



[2004-03-29 01:59:27] cjbj at hotmail dot com

Description:

The example in the newly revamped manual entry
http://www.php.net/manual/en/function.oci-new-descriptor.php

has the line:



  oci_bind_by_name($stmt, ':the_blob', &$lob, -1, OCI_B_BLOB);



Using this syntax I get "Warning: Call-time pass-by-reference has been
deprecated"








-- 
Edit this bug report at http://bugs.php.net/?id=27745&edit=1

Re: [PHP-DOC] mysqli-fetch-assoc

[irchtml]

> Hi,
> 
> There is a paragraph that i don´t understand that says:
> 
> If two or more columns in the result set have the same column name, the
> associative array
>  returned by the mysqli_fetch_assoc function
> will contain the value of
>  the last column of that name. If you must work with result sets
> with this properity, the
>  mysqli_fetch_row should be used which returns
> an numerically-indexed
>  array instead.
> 
> In the part where is said:
>If you must work with result sets with this properity, the
> mysqli_fetch_row 
>should be used which returns an numerically-indexed array instead.
> 
> For my understanding, it should be :
>If you must NOT work with result sets with this property, the
> mysqli_fetch_row 
>should be used which returns an numerically-indexed array instead.
> 

I believe the way georg wrote it is correct, aside from a misspelling
and 'function' should be after mysqli_fetch_row.  I think it may be best
to e-mail georg any suggestions/patches you may have as he is working
hard on the mysqli docs.

> Or something similar. But of course it is just my opinion, so I’ll wait
> for advice.
> 
> Enrique García Briones
> 
> 

Kenneth

[PHP-DOC] #19464 [Asn->Csd]: "Oracle Collections" functions (ocicol*) in manual are not documented for ages.

[irchtml]

 ID:   19464
 Updated by:   [EMAIL PROTECTED]
 Reported By:  aloner at telephone dot ru
-Status:   Assigned
+Status:   Closed
 Bug Type: Documentation problem
 Operating System: n/a
 PHP Version:  4.2.3
 Assigned To:  thies
 New Comment:

The OCI8 documentation has been recently updated (including the OCI
collection functions).  The online/downloadable versions of the PHP
manual take a while to sync with the CVS version so please be patient.



Thank you for your report.  Please feel free to e-mail any suggestions
you may have for improvement to [EMAIL PROTECTED]


Previous Comments:


[2002-09-18 06:16:10] [EMAIL PROTECTED]

Assigned to Thies, the extension maintainer.



[2002-09-18 01:53:32] aloner at telephone dot ru

"Oracle Collections" functions (ocicol*) in manual are not documented
for ages.



At lest for a year as I can remember.




-- 
Edit this bug report at http://bugs.php.net/?id=19464&edit=1

[PHP-DOC] #27510 [Opn->Csd]: shm_put_var() return type incorrect

[irchtml]

 ID:   27510
 Updated by:   [EMAIL PROTECTED]
 Reported By:  adam at trachtenberg dot com
-Status:   Open
+Status:   Closed
 Bug Type: Documentation problem
 Operating System: *
 PHP Version:  Irrelevant
 New Comment:

This bug has been fixed in the documentation's XML sources. Since the
online and downloadable versions of the documentation need some time
to get updated, we would like to ask you to be a bit patient.

Thank you for the report, and for helping us make our documentation
better.

Fixed function proto and added note regarding return values.


Previous Comments:


[2004-03-06 01:30:47] adam at trachtenberg dot com

Description:

shm_put_var() is documented to return an int. This is 

incorrect. The function returns a boolean.



If the function sucessfully puts the variable, it 

returns true. If the index is wrong or there is 

insufficient memory, it returns false.



(See also the user contributed note on the page.)






-- 
Edit this bug report at http://bugs.php.net/?id=27510&edit=1

Re: [PHP-DOC] cvs: phpdoc /en/reference/domxml/functions DomDocument-add-root.xml /en/reference/ircg/functions ircg-notice.xml /en/reference/ming/functions swfbutton.setdown.xml /en/reference/network/functions socket-get-status.xml socket-set-blocking.xml socket-set-timeout.xml /en/reference/objaggregation/functions aggregate-info.xml aggregate-methods-by-list.xml aggregate-methods-by-regexp.xml aggregate-methods.xml aggregate-properties-by-list.xml aggregate-properties-by-regexp.xml aggregate-properties.xml aggregate.xml aggregation-info.xml /en/reference/pcre pcre.pattern.modifiers.xml pcre.pattern.syntax.xml reference.xml /en/reference/pcre/functions pcre.pattern.modifiers.xml pcre.pattern.syntax.xml /en/reference/pdf/functions pdf-set-horiz-scaling.xml /en/reference/recode/functions recode.xml /en/reference/strings/functions join.xml strchr.xml /en/reference/zlib/functions gzputs.xml

[irchtml]

Erm, these files were put in the functions directory so they would show
under the 'Table of Contents' on ref.pcre.  If you build the pcre part
of the manual from CVS you'll notice that both pattern.modifiers and
pattern.syntax are no longer linked.  I don't know any other way of
accomplishing this than leaving them in the functions directory.

Kenneth

> vrana Tue Mar  2 07:50:23 2004 EDT
> 
>   Added files: 
> /phpdoc/en/reference/pcre pcre.pattern.modifiers.xml 
>   pcre.pattern.syntax.xml 
> 
>   Removed files:   
> /phpdoc/en/reference/pcre/functions   pcre.pattern.modifiers.xml 
>   pcre.pattern.syntax.xml 

[PHP-DOC] Horizontal/Vertical spans

[irchtml]

I'm trying to get horizontal and vertical spans working within a 
(note en/reference/strings/functions/nl-langinfo.xml).

See http://docs.php.net/?q=function.nl-langinfo  for the current copy.

The "LC_* Category" cells should span both columns but as you can see,
they do not.  I tried  and setting namest and nameend in the
specific  (along with the  giving symbolic names to the
columns) but neither of those worked.  I was wondering if anyone else
had any suggestions.

Also, am trying to get a vertical span (a cell spanning 2 rows).  I
tried morerows="1" but that also did not work.  Any suggestions on that
would also be greatly appreciated.

Thanks,

Kenneth

[PHP-DOC] #21331 [Opn->Csd]: SIGINT handler not called during socket_accept() (revive of Bug #20745)

[irchtml]

 ID:   21331
 Updated by:   [EMAIL PROTECTED]
 Reported By:  piotr at t-p-l dot com
-Status:   Open
+Status:   Closed
 Bug Type: Documentation problem
 Operating System: Linux
 PHP Version:  4.3.0
 New Comment:

This bug has been fixed in the documentation's XML sources. Since the
online and downloadable versions of the documentation need some time
to get updated, we would like to ask you to be a bit patient.

Thank you for the report, and for helping us make our documentation
better.

Added a note on the pcntl_signal page that declare must be used in
order for signal handling to function properly (as of PHP 4.3.0).


Previous Comments:


[2003-01-10 02:17:39] piotr at t-p-l dot com

alright I supose its ok to close this bug then .. since the ticks thing
did make it work in the end .. and the ticks problems are prety much me
not understanding what really ticks do



[2003-01-10 02:12:21] polone at townnews dot com

The "ticks" aspect isn't really a change from the previous behaviour,
when set as:



declare(ticks=1);



Though I would like to point out that anything using
register_tick_function() will now magically get executed ALL THE TIME,
even though this has to be enabled for signal handling support.



[2003-01-02 15:37:05] piotr at t-p-l dot com

using define(ticks=1); it seems to have gotten rid of the problem with
it executing extra code here is a sample



$foo = socket_accept($sock);

echo "Line One...\n";

echo "Line Two...\n";



with define(ticks=2); "Line One..." shows up before the signal handler
is called .. with ticks=1 it doesnt .. so again knowing what exactly
this ticks define does would help.



[2003-01-02 15:13:24] piotr at t-p-l dot com

on a side but related issue .. the warning about the interrupted system
call is spewed out twice .. so I guess thats a bug in itself



[2003-01-02 15:10:38] piotr at t-p-l dot com

ok .. so now the handler executes with that third param set to false,
but it looks like code after the call to socket_accept() still a line
or two of it is run before the handler kicks in.



also what is the significance of the value of the ticks define?



The remainder of the comments for this report are too long. To view
the rest of the comments, please view the bug report online at
http://bugs.php.net/21331

-- 
Edit this bug report at http://bugs.php.net/?id=21331&edit=1

Re: [PHP-DOC] cvs: phpdoc /en/reference/mysqli reference.xml /en/reference/mysqli/functions mysqli-affected-rows.xml mysqli-autocommit.xml mysqli-bind-param.xml mysqli-bind-result.xml mysqli-change-user.xml mysqli-character-set-name.xml mysqli-commit.xml mysqli-connect.xml mysqli-data-seek.xml mysqli-errno.xml mysqli-error.xml mysqli-execute.xml mysqli-fetch-array.xml mysqli-fetch-assoc.xml mysqli-fetch-field-direct.xml mysqli-fetch-field.xml mysqli-fetch-fields.xml mysqli-fetch-lengths.xml mysqli-fetch-object.xml mysqli-fetch-row.xml mysqli-fetch.xml mysqli-field-seek.xml mysqli-field-tell.xml mysqli-get-host-info.xml mysqli-get-proto-info.xml mysqli-get-server-info.xml mysqli-get-server-version.xml mysqli-info.xml mysqli-insert-id.xml

[irchtml]

> georg Wed Feb 25 16:59:16 2004 EDT
> 
>   Modified files:  
> /phpdoc/en/reference/mysqli   reference.xml 
> /phpdoc/en/reference/mysqli/functions mysqli-affected-rows.xml 
>   mysqli-autocommit.xml 
>   mysqli-bind-param.xml 
>   mysqli-bind-result.xml 
>   mysqli-change-user.xml 
>   mysqli-character-set-name.xml 
>   mysqli-commit.xml 
>   mysqli-connect.xml 
>   mysqli-data-seek.xml 
>   mysqli-errno.xml 
>   mysqli-error.xml 
>   mysqli-execute.xml 
>   mysqli-fetch-array.xml 
>   mysqli-fetch-assoc.xml 
>   mysqli-fetch-field-direct.xml 
>   mysqli-fetch-field.xml 
>   mysqli-fetch-fields.xml 
>   mysqli-fetch-lengths.xml 
>   mysqli-fetch-object.xml 
>   mysqli-fetch-row.xml 
>   mysqli-fetch.xml 
>   mysqli-field-seek.xml 
>   mysqli-field-tell.xml 
>   mysqli-get-host-info.xml 
>   mysqli-get-proto-info.xml 
>   mysqli-get-server-info.xml 
>   mysqli-get-server-version.xml 
>   mysqli-info.xml 
>   mysqli-insert-id.xml 
>   Log:
>   Minor update:
>   - changed/added samples
>   - all samples use world database now
>   - added url for world db in reference.xml
>   - added output for samples
>   
>   

Line 304 of mysqli/reference.xml breaks make, typo of mysql-fetch-lengths.

Kenneth

[PHP-DOC] #21694 [Asn->Csd]: pcntl_alarm

[irchtml]

 ID:  21694
 Updated by:  [EMAIL PROTECTED]
 Reported By: dbai at lantanet dot cz
-Status:  Assigned
+Status:  Closed
 Bug Type:Documentation problem
 PHP Version: 4.3.0
 Assigned To: jason
 New Comment:

This bug has been fixed in the documentation's XML sources. Since the
online and downloadable versions of the documentation need some time
to get updated, we would like to ask you to be a bit patient.

Thank you for the report, and for helping us make our documentation
better.

Added the pcntl_alarm function (documented) in CVS along with the other
missing pcntl functions (working on those).


Previous Comments:


[2003-07-18 12:11:46] [EMAIL PROTECTED]

Assigning to Jason as he's about to do a lot of work on the pcntl and
socket docs.



[2003-01-18 04:48:51] [EMAIL PROTECTED]

So, then if this is the current policy, then the bugreporting page
should be change. It says: "Never report bugs for missing functions, we
know about them".



[2003-01-16 15:22:02] [EMAIL PROTECTED]

Uhm, this isn't bogus. Please close this bugreport when the
documentation has been written only.



Derick



[2003-01-16 15:21:41] [EMAIL PROTECTED]

It's still not bogus, it's open.



[2003-01-16 15:18:03] [EMAIL PROTECTED]

we know. There's loads of undocumented functions still around We're
constantly documenting new functions, and modifying current
documentation to keep you informed the best we can...!



To see all undocumented features, have a look here:

http://zend.com/phpfunc/nodoku.php



The remainder of the comments for this report are too long. To view
the rest of the comments, please view the bug report online at
http://bugs.php.net/21694

-- 
Edit this bug report at http://bugs.php.net/?id=21694&edit=1

[PHP-DOC] #19692 [Opn->Dup]: register_shutdown_function documentation unclear about output

[irchtml]

 ID:   19692
 Updated by:   [EMAIL PROTECTED]
 Reported By:  asd at suespammers dot org
-Status:   Open
+Status:   Duplicate
 Bug Type: Documentation problem
 Operating System: n/a
 PHP Version:  4.2.3
 New Comment:

This a duplicate to #20447, closing this bug but leaving the other
open.  Will try to figure out in which cases output may still be sent
(perhaps today).


Previous Comments:


[2003-06-20 14:30:07] dchatenay at hotmail dot com

Sorry, I meant bug #20447.



[2003-06-20 14:29:23] dchatenay at hotmail dot com

I don't know how active this bug is. It looks related to bug #10447:
when you register a shutdown function, php used to release the
connection and execute the shutdown function in the background (thus
preventing you from sending any output obviously).

  Now it looks like the execution of the shutdown function will keep
the connection alive, and you may output some information.

  This is annoying since it used to work fine until recently, and I
can't find out what triggered this change in behaviour.



[2002-10-01 10:04:42] asd at suespammers dot org

The register_shutdown_function documentation makes it sound like trying
to output to the web browser during a shutdown function is a no-op.



However, it seems that it isn't always. Sometimes the text goes out
fine; sometimes it goes out after, e.g., zlib compression, etc.



The documenation should probably be changed to state the behavior of
output done by a shutdown function is undefined, and strongly warn
against letting it happen.




-- 
Edit this bug report at http://bugs.php.net/?id=19692&edit=1

[PHP-DOC] #27390 [Opn->Csd]: ibase_trans wrong transaction argument

[irchtml]

 ID:   27390
 Updated by:   [EMAIL PROTECTED]
 Reported By:  cryo28 at rbcmail dot ru
-Status:   Open
+Status:   Closed
 Bug Type: Documentation problem
 Operating System: Any
 PHP Version:  4.3.5RC3
 New Comment:

This bug has been fixed in the documentation's XML sources. Since the
online and downloadable versions of the documentation need some time
to get updated, we would like to ask you to be a bit patient.

Thank you for the report, and for helping us make our documentation
better.




Previous Comments:


[2004-02-25 05:30:15] cryo28 at rbcmail dot ru

Sorry. IBASE_COMMITED != IBASE_COMMITTED.



[2004-02-25 05:28:36] cryo28 at rbcmail dot ru

Description:

PHP Manual. Interbase functions -> ibase_trans.

Begins a transaction. 



trans_args can be a combination of IBASE_READ, IBASE_WRITE,
IBASE_COMMITED, IBASE_CONSISTENCY, IBASE_CONCURRENCY,
IBASE_REC_VERSION, IBASE_REC_NO_VERSION, IBASE_WAIT and IBASE_NOWAIT. 



IBASE_COMMIT != IBASE_COMMITT as defined in php_interbase







Reproduce code:
---
$tr = ibase_trans(IBASE_WRITE, IBASE_WAIT, IBASE_COMMITED,
IBASE_REC_VERSION, $dbci->connection);



Notice: Use of undefined constant IBASE_COMMITED - assumed
'IBASE_COMMITED' in D:\inet\wwwroot\online_sales_procs.inc.php on line
265





$tr = ibase_trans(IBASE_WRITE, IBASE_WAIT, IBASE_COMMITTED,
IBASE_REC_VERSION, $dbci->connection);



NO notices or warnings






-- 
Edit this bug report at http://bugs.php.net/?id=27390&edit=1

[PHP-DOC] #20189 [Asn->Csd]: PCNTL docs need updating to reflect 4.3.0 behavior

[irchtml]

 ID:   20189
 Updated by:   [EMAIL PROTECTED]
 Reported By:  luca dot mariano at email dot it
-Status:   Assigned
+Status:   Closed
 Bug Type: Documentation problem
 Operating System: all
 PHP Version:  4.3.0
 Assigned To:  jason
 New Comment:

Status -> Closed, per [EMAIL PROTECTED] "...which closes this bug..."


Previous Comments:


[2003-01-23 17:07:33] [EMAIL PROTECTED]

Granted this was assigned to Jason, I added some documenation on this
fact which closes this bug but I'm rewriting the summary as all the
pcntl docs need updating.



The following changes took place.

http://cvs.php.net/cvs.php/phpdoc/en/reference/pcntl/reference.xml

http://cvs.php.net/cvs.php/phpdoc/en/reference/pcntl/functions/pcntl-signal.xml



You will see similarities between the changes and Jasons email :)  Note
I added "declare(ticks = 1)" in a couple examples.  I believe Jason
will eventually rewrite these but at least they should work now.



[2002-10-31 08:17:45] [EMAIL PROTECTED]

There has been (udocumented) change to pcntl extension. Take a look at
http://www.zend.com/lists/php-dev/200208/msg00937.html



Changing to documentation problem and assigning to Jason.



[2002-10-31 07:09:01] luca dot mariano at email dot it

I'm currently working with PHP-CLI in order to write a comprensive
multithread server framework, using the following PHP modules:

-PCNTL (for process forking)

-SOCKETS (for managing of sockets...)

-SYSVSEM (semaphores to syncronyze threads)

-SYSVSHM (for sharing data between threads)

-XMLRPC (the best object broking for me)



I noticed a strange behaviour of my apps when i use the PHP4.3
executable; the following test script does not work under 4.3, while it
works under 4.2.







No backtrace avaible, PHP does not crash, simply do nothing.












-- 
Edit this bug report at http://bugs.php.net/?id=20189&edit=1

[PHP-DOC] #27323 [Bgs]: use of Apache 2.0 and PHP 4.3.4 on a Solaris production system

[irchtml]

 ID:   27323
 Updated by:   [EMAIL PROTECTED]
 Reported By:  wzaccone at telcordia dot com
 Status:   Bogus
 Bug Type: Documentation problem
 Operating System: Apache 2.0
 PHP Version:  4.3.4
 New Comment:

Yes, Apache 2 was only released 4 years ago (stable-2 years ago).  It
is far too new to even think about supporting it.



The general procedure is to release a major build and ask questions
later.



Submit again before PHP 6 goes into beta testing.


Previous Comments:


[2004-02-20 21:58:16] [EMAIL PROTECTED]

Apache 2 is still too new. And the SAPI modules we have for it have
proven to be quite buggy too..



And you don't get pretty much anything extra out of Apache2 compared to
Apache1.3 anyway. Enabling Apache2 with threaded MPM, like worker,
makes it really unstable due to 3rd party stuff being non-thread-safe.



Ask again next year. :)









[2004-02-19 17:45:18] wzaccone at telcordia dot com

Description:

 We still see the following warning on php.net in the installation
section of the online documentation:  "Do not use Apache 2.0 and PHP in
a production environment neither on Unix nor on Windows. ".  My
question:  Is this warning still in effect for all releases of PHP??? 
Is warning the documentation still appropriate in our situation--
specifically PHP 4.3.4 on UNIX/Solaris 8 with Apache 1.3.27. We are
considering migrating to Apache 2.0 on Solaris 8.  THANK YOU. 








-- 
Edit this bug report at http://bugs.php.net/?id=27323&edit=1

[PHP-DOC] #20531 [Opn->Csd]: Object property association broken

[irchtml]

 ID:   20531
 Updated by:   [EMAIL PROTECTED]
 Reported By:  tim dot lokot at printsoft dot com
-Status:   Open
+Status:   Closed
 Bug Type: Documentation problem
 Operating System: Win NT 4 Server
 PHP Version:  4.2.3
 New Comment:

This bug was fixed with revision 1.10 of objaggregation/reference.xml
on 12/11/2003.



Status -> Closed


Previous Comments:


[2003-02-21 07:37:08] [EMAIL PROTECTED]

this is a docuprob, as the aggregate page has an example that's illegal
in PHP.



[2002-11-21 16:17:26] tim dot lokot at printsoft dot com

Fair enough, the docs at the url you supplied then contradict the docs
at this url:



http://www.php.net/manual/en/ref.objaggregation.php



You will find that the example I supplied came direct from your online
manual.



I know it says its experimental, but I thought we were supposed to
report these types of inconsistencies and errors so that the
experimental extensions can move to stable versions.



[2002-11-21 00:39:39] [EMAIL PROTECTED]

Thank you for taking the time to write to us, but this is not
a bug. Please double-check the documentation available at
http://www.php.net/manual/ and the instructions on how to report
a bug at http://bugs.php.net/how-to-report.php

Read the note under the caution block:



http://www.php.net/manual/en/language.oop.php#keyword.class



[2002-11-20 21:50:04] tim dot lokot at printsoft dot com

The following example doesn't work, but is listed in the documentation
as being valid:



now();

  // more code ...

  }



  // more methods ...

}



$rep = new Report(); 

?>



This returns the error:



Parse error: parse error, unexpected T_NEW in test.php on line 14





I have tried this with other classes and basically it seems that you
cannot default a class property to an instatiated class unless through
the constructor.  This is contrary to the documentation.




-- 
Edit this bug report at http://bugs.php.net/?id=20531&edit=1

[PHP-DOC] #23721 [Opn->Csd]: TRUE and FALSE constants slower than keywords in previous versions

[irchtml]

 ID:   23721
 Updated by:   [EMAIL PROTECTED]
 Reported By:  max at fuck dot org
-Status:   Open
+Status:   Closed
 Bug Type: Documentation problem
 Operating System: FreeBSD
 PHP Version:  4.3.1
 New Comment:

The language.types.boolean states that the TRUE/FALSE keywords are
case-insensitive.



I don't believe this requires any updates to the docs, unless someone
is persistent and wants to re-open.



Status -> Closed


Previous Comments:


[2003-05-21 11:14:51] [EMAIL PROTECTED]

PHP groupees sometimes mention:



a) ++$i  is faster than $i++

b) 'foo' is faster than "foo"

c) echo  is faster than print

d) str_* is faster than regex

e) And now true is faster than TRUE!



Woohoo! My PHP scripts will be blazing fast!!! :)



[2003-05-21 10:05:56] [EMAIL PROTECTED]

Code readability always outweights minor performance gains, IMO. :)







[2003-05-21 08:57:42] max at fuck dot org

I don't think I would ever use true/false a million times. This came up
when talking to someone about which way was 'proper', whereas before it
didn't seem to make a difference and now to allow people who want to
write 'True' to get their way, it has been changed. While I don't think
this is a big performance problem or anything, I think in conjuction
with other little slow-downs on a high load site it could have an
effect on the speed. It's obviously faster than older versions
regardless of how you use it, but I don't think I have ever seen it
used in lowercase anywhere on the php website.



[2003-05-21 03:11:08] [EMAIL PROTECTED]

Why do you use 100 times TRUE or FALSE in your programs anyway?



[2003-05-21 02:01:07] [EMAIL PROTECTED]

Use of proper case is faster than "improper" case for case insensitive
constants.  This includes true/false, null, and define()'s third
parameter.  Not sure what others... or even if this really should be
documented? :)  AFAICT, this behavior does not affect magical case
insensitive constants such as __file__.



This difference is as of 4.2.3



The remainder of the comments for this report are too long. To view
the rest of the comments, please view the bug report online at
http://bugs.php.net/23721

-- 
Edit this bug report at http://bugs.php.net/?id=23721&edit=1

[PHP-DOC] #23639 [Opn->Csd]: Wrong italian translation of mt_rand, and inaccurate text also in english

[irchtml]

 ID:   23639
 Updated by:   [EMAIL PROTECTED]
 Reported By:  lapo at lapo dot it
-Status:   Open
+Status:   Closed
 Bug Type: Documentation problem
 Operating System: independent
 PHP Version:  4.3.2RC2
 New Comment:

This bug has been fixed in the documentation's XML sources. Since the
online and downloadable versions of the documentation need some time
to get updated, we would like to ask you to be a bit patient.

Thank you for the report, and for helping us make our documentation
better.




Previous Comments:


[2004-01-30 15:52:57] [EMAIL PROTECTED]

Fixed the italian translation as suggested.



[2003-05-15 05:42:12] lapo at lapo dot it

 says:

"assicura numeri casuali che dovrebbero essere adatti per scopi
crittografici"

which translates to sometihng like "it cerates numbers that surely can
be used for cryptography"... at it is plainly false and negated on the
homepage of MT itself.



don't know if this is just a translation of an old verison of the
english page, but right now the english page says the correct thing:
"can be used to seed..."



A better italian translation would be:

"genera numeri casuali che, con le dovute accortezze, possono perfino
essere usati in crittografia"



Anyway I'd rather REMOVE that citation of cryptography entirely from
every translation, as it is not adequate for it (MT page also says it
in the first lines: "Caution: MT is for MonteCarlo, and is NOT SECURE
for CRYPTOGRAPHY as it is.").

As they say in the FAQ 
"changing a linear congruential PRNG for MT can do no bad" but this is
far from being "cryptographically secure".



A good secure PRNG is Bruce Schneier's Yarrow


Also a good text about security and PRNG is linked in that page:





-- 
Edit this bug report at http://bugs.php.net/?id=23639&edit=1

[PHP-DOC] #27076 [Opn->Csd]: exec() with safe_mode

[irchtml]

 ID:   27076
 Updated by:   [EMAIL PROTECTED]
 Reported By:  not at valid dot email
-Status:   Open
+Status:   Closed
 Bug Type: Documentation problem
 Operating System: linux
 PHP Version:  Irrelevant
 New Comment:

This bug has been fixed in the documentation's XML sources. Since the
online and downloadable versions of the documentation need some time
to get updated, we would like to ask you to be a bit patient.

Thank you for the report, and for helping us make our documentation
better.

Added the entity [EMAIL PROTECTED] created to passthru() and system().


Previous Comments:


[2004-02-09 09:47:24] [EMAIL PROTECTED]

This should also be mentionned in the other functions of ref.exec.
Maybe with an entity ?



[2004-01-28 15:03:42] [EMAIL PROTECTED]

This bug has been fixed in the documentation's XML sources. Since the
online and downloadable versions of the documentation need some time
to get updated, we would like to ask you to be a bit patient.

Thank you for the report, and for helping us make our documentation
better.

I added a warning below the other safe_mode note. Thanks.



[2004-01-28 14:53:20] [EMAIL PROTECTED]

Yes, it's a feature. Couldn't find it documented anywhere.

Reclassifed as documentation problem.







[2004-01-28 12:39:16] not at valid dot email

Description:

safe_mode cause exec command to parse all arguments after the command
as one argument (in quote?)



Is this a bug? is it documented somewhere?



Reproduce code:
---


Expected result:

safe_mode off output is: y

safe_mode on output is: y

Actual result:
--
safe_mode off output is: y

safe_mode on output is: x | echo y





-- 
Edit this bug report at http://bugs.php.net/?id=27076&edit=1

[PHP-DOC] #27248 [Opn->Csd]: php_exif.dll crashes php

[irchtml]

 ID:   27248
 Updated by:   [EMAIL PROTECTED]
 Reported By:  zeger at zeger dot nl
-Status:   Open
+Status:   Closed
 Bug Type: Documentation problem
 Operating System: Windows 2k3 Server
 PHP Version:  5CVS-2004-02-14
 New Comment:

This bug has been fixed in the documentation's XML sources. Since the
online and downloadable versions of the documentation need some time
to get updated, we would like to ask you to be a bit patient.

Thank you for the report, and for helping us make our documentation
better.




Previous Comments:


[2004-02-17 17:14:10] [EMAIL PROTECTED]

This should be documented somewhere..





[2004-02-17 15:20:30] zeger at zeger dot nl

php-cgi.exe works!



php.ini excerpt :



extension=php_mbstring.dll

extension=php_exif.dll



So I guess loading php_mbstring has to be done prior to loading
php_exif.



[2004-02-17 14:06:30] [EMAIL PROTECTED]

Please try this:



php.ini:

extension=php_mbstring.dll

extension=php_exif.dll



NOTE: the order is important.



If that doesn't work, try modifying your PATH to

include the PHP extension dir, then try again.







[2004-02-17 06:46:57] zeger at zeger dot nl

After some further experiments using PHP 5.0.0 snapshots in the command
prompt.



Loading php_exif.dll results in an error "php_mbstring.dll was not
found". Loading php_mbstring.dll works just fine. Loading both
php_exif.dll and mbstring.dll results in "php_mbstring.dll was  not
found".



Next, copying the php_mbstring.dll to the php.exe root results in a php
crash when loading php_exif.dll.



[2004-02-17 05:10:11] mastabog at hotmail dot com

I can confirm this bug.



I'm downloading the php5-win32-latest.zip daily and use it with
apache1.3 and apache2.



Since the release of beta 3, all versions were always crashing while
loading the php_exif.dll (even if php_mbstring.dll was also loaded)
unless php_exif.dll was copied in the php5apache.dll directory (in my
case the php5 dir).



The remainder of the comments for this report are too long. To view
the rest of the comments, please view the bug report online at
http://bugs.php.net/27248

-- 
Edit this bug report at http://bugs.php.net/?id=27248&edit=1

[PHP-DOC] #14165 [Asn->Csd]: include() needs an example for cross-server http inclusion of code.

[irchtml]

 ID:   14165
 Updated by:   [EMAIL PROTECTED]
 Reported By:  steve at petabit dot com
-Status:   Assigned
+Status:   Closed
 Bug Type: Documentation problem
 Operating System: Linux
 PHP Version:  4.0.5
 Assigned To:  irchtml
 New Comment:

This bug has been fixed in the documentation's XML sources. Since the
online and downloadable versions of the documentation need some time
to get updated, we would like to ask you to be a bit patient.

Thank you for the report, and for helping us make our documentation
better.




Previous Comments:


[2004-02-17 15:13:13] [EMAIL PROTECTED]

I'll be more than happy to add a note in the documentation.  Perhaps I
did overlook the fact that it needs more clarification, but that does
not warrant a personal attack.



Thanks for your report.



[2004-02-17 15:02:13] steve at petabit dot com

[EMAIL PROTECTED]  you are an arrogant bastard aren't you?



If six people over 16 months have had to debate what an oversimplified
paragraph means, don't you think that "pretty clear" might not be an
appropriate way to describe said oversimplified paragraph?



Just because it's clear to you, doesn't make it clear.  In my case, the
only clear explanation I've seen is that from elmicha#phpdotnet earlier
in this thread.  



Tim and kenny have both seen that there's missing clarity with respect
to remote servers, and tried to understand and explain the implications
of your "perfectly clear" paragraph.



But those who have been concerned with trying to make themselves feel
smart (like you), or with trying to make me feel stupid for asking
(like brianlmoon), rather than actually thinking about the problem,
simply make me sad for the entire group of geeks to which I once
belonged.  I hope you're all replaced by low-paid Indian and Chinese
programmers and have to flip "pretty clear" hamburgers for a living.  



Have I been "pretty clear"?  Call me, you supercilious geek, and I'll
happily tell you off in person.



Steve Rapaport

Stockholm, Sweden

+46 70 643 9944



[2004-02-17 12:36:16] [EMAIL PROTECTED]

I believe the include() documentation is pretty clear on this issue:



"The include() statement includes and evaluates the specified file."



"When a file is included, the code it contains inherits the variable
scope of the line on which the include occurs. Any variables available
at that line in the calling file will be available within the called
file, from that point forward."



Status -> Closed.



[2004-01-12 12:25:26] steve at petabit dot com

elmicha below has answered my question perfectly well and explained the
results I got too.



To my mind, this docbug should  be considered closed when elmicha's
explanation is included in the docs for include().



Thanks to all who replied,



Steve Rapaport

Steve at Petabit dot com



[2004-01-11 21:27:56] [EMAIL PROTECTED]

It really doesn't imply anywhere that including a remote file will make
it inherit the scope -- in fact, it says that is not the case -- and
the 'include' documentation explains that the data returned will be
parsed as is any included file. That is, if the page were "", the calling script would execute that
assignment in its local scope. If you'd write a better explanation,
I'll be happy to commit it. But since you probably don't care
anymore... :-)



The remainder of the comments for this report are too long. To view
the rest of the comments, please view the bug report online at
http://bugs.php.net/14165

-- 
Edit this bug report at http://bugs.php.net/?id=14165&edit=1

[PHP-DOC] #14165 [Opn->Asn]: include() needs an example for cross-server http inclusion of code.

[irchtml]

 ID:   14165
 Updated by:   [EMAIL PROTECTED]
 Reported By:  steve at petabit dot com
-Status:   Open
+Status:   Assigned
 Bug Type: Documentation problem
 Operating System: Linux
 PHP Version:  4.0.5
-Assigned To:  
+Assigned To:  irchtml
 New Comment:

I'll be more than happy to add a note in the documentation.  Perhaps I
did overlook the fact that it needs more clarification, but that does
not warrant a personal attack.



Thanks for your report.


Previous Comments:


[2004-02-17 15:02:13] steve at petabit dot com

[EMAIL PROTECTED]  you are an arrogant bastard aren't you?



If six people over 16 months have had to debate what an oversimplified
paragraph means, don't you think that "pretty clear" might not be an
appropriate way to describe said oversimplified paragraph?



Just because it's clear to you, doesn't make it clear.  In my case, the
only clear explanation I've seen is that from elmicha#phpdotnet earlier
in this thread.  



Tim and kenny have both seen that there's missing clarity with respect
to remote servers, and tried to understand and explain the implications
of your "perfectly clear" paragraph.



But those who have been concerned with trying to make themselves feel
smart (like you), or with trying to make me feel stupid for asking
(like brianlmoon), rather than actually thinking about the problem,
simply make me sad for the entire group of geeks to which I once
belonged.  I hope you're all replaced by low-paid Indian and Chinese
programmers and have to flip "pretty clear" hamburgers for a living.  



Have I been "pretty clear"?  Call me, you supercilious geek, and I'll
happily tell you off in person.



Steve Rapaport

Stockholm, Sweden

+46 70 643 9944



[2004-02-17 12:36:16] [EMAIL PROTECTED]

I believe the include() documentation is pretty clear on this issue:



"The include() statement includes and evaluates the specified file."



"When a file is included, the code it contains inherits the variable
scope of the line on which the include occurs. Any variables available
at that line in the calling file will be available within the called
file, from that point forward."



Status -> Closed.



[2004-01-12 12:25:26] steve at petabit dot com

elmicha below has answered my question perfectly well and explained the
results I got too.



To my mind, this docbug should  be considered closed when elmicha's
explanation is included in the docs for include().



Thanks to all who replied,



Steve Rapaport

Steve at Petabit dot com



[2004-01-11 21:27:56] [EMAIL PROTECTED]

It really doesn't imply anywhere that including a remote file will make
it inherit the scope -- in fact, it says that is not the case -- and
the 'include' documentation explains that the data returned will be
parsed as is any included file. That is, if the page were "", the calling script would execute that
assignment in its local scope. If you'd write a better explanation,
I'll be happy to commit it. But since you probably don't care
anymore... :-)



[2003-08-08 11:26:50] [EMAIL PROTECTED]

If you use

  include('http://some_server/something.php');

something.php is executed on "some_server". It's impossible to return
strings with "return" from there.



But the output of http://some_server/something.php is included in your
script and executed there. So just make _the output_ of something.php a
valid php script which sets your variables - so you can use these
variables in your local script. E.g.:



';

?>



On the local server:



http://some_server/something.php');

  echo $return_value;

?>



As the manual explicitly mentions that you can use a return statement
to pass values from the included script, but does not mention that this
doesn't work via HTTP or FTP, I'd say this is a Documentation problem.
(I don't know what the manual said in 2001, maybe the return statement
could not be used in included files back then.)



The remainder of the comments for this report are too long. To view
the rest of the comments, please view the bug report online at
http://bugs.php.net/14165

-- 
Edit this bug report at http://bugs.php.net/?id=14165&edit=1

[PHP-DOC] #16227 [Opn->Csd]: Using internal hash position is tricky.

[irchtml]

 ID:   16227
 Updated by:   [EMAIL PROTECTED]
 Reported By:  php dot net at alienbill dot com
-Status:   Open
+Status:   Closed
 Bug Type: Documentation problem
 Operating System: ANY
 PHP Version:  Irrelevant
 New Comment:

Closing this as [EMAIL PROTECTED] said the bug was fixed.


Previous Comments:


[2003-01-20 22:54:11] vdvo at vdvo dot net

Well, so is it fixed or is it not? This bug's status is still Open.



[2002-10-01 06:28:18] [EMAIL PROTECTED]

FYI. The bug is fixed. Current CVS version does not swap internal hash
position on assinment.



[2002-10-01 06:13:17] [EMAIL PROTECTED]

The issue is ZendEngine mess up hash position by assignment.

I'll open new one for this.



[2002-07-16 11:22:34] [EMAIL PROTECTED]

each() as a function does not know in which context it was called so it
just returns the 'current' element and advances the internal position
pointer, very similar to the java next_element() iterator (hope i got
the name right). when no more elements are left it returns false until
being reset



each() can not know that it was called from different loop runs so it
will return false forever until reset. one might 

think about auto-reseting it after returning false once, but backwards
compatibility will be in our way once again here



the problem does not happen this way in java because there
next_element() advances the internal pointer before returning values
and you have to use first_element() to get

the first one (which implies a reset)



foreach uses a private copy of the array structure so it has its own
internal pointer which is recreated for every foreach instance so the
problem does occure here



[2002-03-23 20:44:45] [EMAIL PROTECTED]

Oops,



$arr = array('a', 'b', 'c');



does reset position :)



The remainder of the comments for this report are too long. To view
the rest of the comments, please view the bug report online at
http://bugs.php.net/16227

-- 
Edit this bug report at http://bugs.php.net/?id=16227&edit=1

[PHP-DOC] #14165 [Opn->Csd]: include() needs an example for cross-server http inclusion of code.

[irchtml]

 ID:   14165
 Updated by:   [EMAIL PROTECTED]
 Reported By:  steve at petabit dot com
-Status:   Open
+Status:   Closed
 Bug Type: Documentation problem
 Operating System: Linux
 PHP Version:  4.0.5


Previous Comments:


[2004-02-17 12:36:16] [EMAIL PROTECTED]

I believe the include() documentation is pretty clear on this issue:



"The include() statement includes and evaluates the specified file."



"When a file is included, the code it contains inherits the variable
scope of the line on which the include occurs. Any variables available
at that line in the calling file will be available within the called
file, from that point forward."



Status -> Closed.



[2004-01-12 12:25:26] steve at petabit dot com

elmicha below has answered my question perfectly well and explained the
results I got too.



To my mind, this docbug should  be considered closed when elmicha's
explanation is included in the docs for include().



Thanks to all who replied,



Steve Rapaport

Steve at Petabit dot com



[2004-01-11 21:27:56] [EMAIL PROTECTED]

It really doesn't imply anywhere that including a remote file will make
it inherit the scope -- in fact, it says that is not the case -- and
the 'include' documentation explains that the data returned will be
parsed as is any included file. That is, if the page were "", the calling script would execute that
assignment in its local scope. If you'd write a better explanation,
I'll be happy to commit it. But since you probably don't care
anymore... :-)



[2003-08-08 11:26:50] [EMAIL PROTECTED]

If you use

  include('http://some_server/something.php');

something.php is executed on "some_server". It's impossible to return
strings with "return" from there.



But the output of http://some_server/something.php is included in your
script and executed there. So just make _the output_ of something.php a
valid php script which sets your variables - so you can use these
variables in your local script. E.g.:



';

?>



On the local server:



http://some_server/something.php');

  echo $return_value;

?>



As the manual explicitly mentions that you can use a return statement
to pass values from the included script, but does not mention that this
doesn't work via HTTP or FTP, I'd say this is a Documentation problem.
(I don't know what the manual said in 2001, maybe the return statement
could not be used in included files back then.)



[2003-08-06 21:09:41] tim at pmedia dot be

Allow me to rephrase Steve's problem described in #14165 again as I'm
experiencing the same trouble.



When including a remote php-file (a php-file on another server) in a
script, that php-file is parsed (if server configured to) which
basically means the script is runned. 



The problem we experience is that the parsed script's return value(s)
defined at the end in a return() statement don't seem to arrive in the
original script. Steve reports only 'integers'. I have seen only a '1',
which is according the docs just the value returned if no return()
statement is used. 



If the 2 scripts are located on the same server, the problem doesn't
show up.



The remainder of the comments for this report are too long. To view
the rest of the comments, please view the bug report online at
http://bugs.php.net/14165

-- 
Edit this bug report at http://bugs.php.net/?id=14165&edit=1

[PHP-DOC] #14165 [Opn]: include() needs an example for cross-server http inclusion of code.

[irchtml]

 ID:   14165
 Updated by:   [EMAIL PROTECTED]
 Reported By:  steve at petabit dot com
 Status:   Open
 Bug Type: Documentation problem
 Operating System: Linux
 PHP Version:  4.0.5
 New Comment:

I believe the include() documentation is pretty clear on this issue:



"The include() statement includes and evaluates the specified file."



"When a file is included, the code it contains inherits the variable
scope of the line on which the include occurs. Any variables available
at that line in the calling file will be available within the called
file, from that point forward."



Status -> Closed.


Previous Comments:


[2004-01-12 12:25:26] steve at petabit dot com

elmicha below has answered my question perfectly well and explained the
results I got too.



To my mind, this docbug should  be considered closed when elmicha's
explanation is included in the docs for include().



Thanks to all who replied,



Steve Rapaport

Steve at Petabit dot com



[2004-01-11 21:27:56] [EMAIL PROTECTED]

It really doesn't imply anywhere that including a remote file will make
it inherit the scope -- in fact, it says that is not the case -- and
the 'include' documentation explains that the data returned will be
parsed as is any included file. That is, if the page were "", the calling script would execute that
assignment in its local scope. If you'd write a better explanation,
I'll be happy to commit it. But since you probably don't care
anymore... :-)



[2003-08-08 11:26:50] [EMAIL PROTECTED]

If you use

  include('http://some_server/something.php');

something.php is executed on "some_server". It's impossible to return
strings with "return" from there.



But the output of http://some_server/something.php is included in your
script and executed there. So just make _the output_ of something.php a
valid php script which sets your variables - so you can use these
variables in your local script. E.g.:



';

?>



On the local server:



http://some_server/something.php');

  echo $return_value;

?>



As the manual explicitly mentions that you can use a return statement
to pass values from the included script, but does not mention that this
doesn't work via HTTP or FTP, I'd say this is a Documentation problem.
(I don't know what the manual said in 2001, maybe the return statement
could not be used in included files back then.)



[2003-08-06 21:09:41] tim at pmedia dot be

Allow me to rephrase Steve's problem described in #14165 again as I'm
experiencing the same trouble.



When including a remote php-file (a php-file on another server) in a
script, that php-file is parsed (if server configured to) which
basically means the script is runned. 



The problem we experience is that the parsed script's return value(s)
defined at the end in a return() statement don't seem to arrive in the
original script. Steve reports only 'integers'. I have seen only a '1',
which is according the docs just the value returned if no return()
statement is used. 



If the 2 scripts are located on the same server, the problem doesn't
show up.



[2001-11-21 17:32:22] steve at petabit dot com

Okay, there's some simple sample code at bug 14164. 



Basic idea is that I have 2 machines, one public,

one firewalled and non-routed.  The public one should

be able to access the database on the private one, but

nobody else should.



Thanks for the attention!



Steve



The remainder of the comments for this report are too long. To view
the rest of the comments, please view the bug report online at
http://bugs.php.net/14165

-- 
Edit this bug report at http://bugs.php.net/?id=14165&edit=1

[PHP-DOC] #26582 [Opn->Csd]: HEREDOC linefeed requirement mis-documented

[irchtml]

 ID:   26582
 Updated by:   [EMAIL PROTECTED]
 Reported By:  iwd32900 at yahoo dot com
-Status:   Open
+Status:   Closed
 Bug Type: Documentation problem
 Operating System: Darwin/Mac OS X
 PHP Version:  4.3.4
 New Comment:

The documentation seems pretty clear on this.



Status -> Closed


Previous Comments:


[2003-12-18 08:13:49] iwd32900 at yahoo dot com

No, it doesn't work with \r.



I realize that in some sense, \n is the new 'native' 

linefeed for Mac since OS X is Unix based. This doesn't 

change my opinion that PHP should be linefeed-agnostic, 

so that code can easily be transported from one platform 

to another.



[2003-12-18 05:21:18] [EMAIL PROTECTED]

No feedback was provided. The bug is being suspended because
we assume that you are no longer experiencing the problem.
If this is not the case and you are able to provide the
information that was requested earlier, please do so and
change the status of the bug back to "Open". Thank you.





[2003-12-10 09:39:06] [EMAIL PROTECTED]

Does heredoc work for you with \r?



[2003-12-10 09:12:36] iwd32900 at yahoo dot com

Description:

The current manual says this, under the "Heredoc" 

section in "Strings" in "Types":



-

It's also important to realize that the first character 

before the closing identifier must be a newline as 

defined by your operating system. This is \r on 

Macintosh for example.



If this rule is broken and the closing identifier is not 

"clean" then it's not considered to be a closing 

identifier and PHP will continue looking for one. If in 

this case a proper closing identifier is not found then 

a parse error will result with the line number being at 

the end of the script.

-



I have two issues with this.

1. This doesn't appear to be true. I'm using the 

entropy.ch distribution of 4.3.4, and it accepts \n as a 

linefeed before the end marker on my Mac.



2. One of the great things about PHP is that it's cross-

platform portable. The interpretter otherwise seems to 

be linefeed-agnostic; it should be here, too. That way, 

I can write my scripts on any platform and distribute 

them to any other, and no one has to worry about 

something as irritating as linefeeds. Just check for any 

of \n, \r, or \r\n before a heredoc terminator. Should 

be really easy, and it will do a lot for making PHP more 

platform independent.

Reproduce code:
---
$heredoc = <

[PHP-DOC] #27218 [Opn->Csd]: PHP.net Website Problem

[irchtml]

 ID:  27218
 Updated by:  [EMAIL PROTECTED]
 Reported By: info at amico-alpha dot de
-Status:  Open
+Status:  Closed
 Bug Type:Documentation problem
 PHP Version: Irrelevant
 New Comment:

Thank you for your report.  The URL has been corrected in CVS and will
show on php.net when the manual is re-builds.


Previous Comments:


[2004-02-11 08:38:37] info at amico-alpha dot de

Description:

The link on your site http://de3.php.net/install.windows which leads to
the Microsoft Data Access Components (MDAC) has to be changed:

old: http://www.microsoft.com/data/

new: http://msdn.microsoft.com/data/



---

HJK






-- 
Edit this bug report at http://bugs.php.net/?id=27218&edit=1