[PHP-DEV] MFH -R php4/pear/* files
Please, could some kind developer MFH the lastest PEAR files so they could ship in the next 4.2.3 release? I'm able to test and attend fixes it may need fast. Thanks, Tomas V.V.Cox -- PHP Development Mailing List <http://www.php.net/> To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: Suggestion about native DB support.
Yasuo Ohgaki wrote:
>
> Hartmut Holzgraefe wrote:
> > Yasuo Ohgaki wrote:
> >
> >> I think gettext module is also a good one to be enabled by default
> >> or recommend users strongly.
> >
> >
> > well, as everything depending on setlocale() or putenv("LANG=...")
> > is *not* threadsafe this might be a not-so-good idea right now ...
> >
>
> Note in the manual page says setlocale() is not required,
> so I was supposing it's not needed.
>
> Anyway, it seems it's been modified recently and I haven't
> use gettext for long time. Need some research.
I was recently i18n'ing a site and discovered that with RH 6.x (PHP
4.1.1) putenv("LANGUAGE=$lang"); is enough while with RH 7.3 (PHP 4.2.1)
only setlocale(LC_ALL, $lang); works. Plus note the fact that single ISO
codes no longer works with RH 7.3 (for ex. "en" or "es") you have to use
"en_US" or "es_ES".
Tomas V.V.Cox
--
PHP Development Mailing List <http://www.php.net/>
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] PECL != Siberia
"Stig S. Bakken" wrote: > > You tell me :) We currently have no nice way of bootstrapping PEAR on > Windows like we have on Unix (with "make install-pear-installer" and > go-pear). What would be the most sensible way of giving Windows users > something ala go-pear? > What about: php -r "include 'http://pear.php.net/go-pear';" Tomas V.V.Cox -- PHP Development Mailing List <http://www.php.net/> To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] PECL != Siberia
Markus Fischer wrote: > > On Sun, Jun 09, 2002 at 06:35:44PM +0200, Tomas V.V.Cox wrote : > > Jani Taskinen wrote: > > > > > > # make install > > > > > > /usr/src/web/php/php4/sapi/cli/php /usr/src/web/php/php4/pear/install-pear.php >/usr/src/web/php/php4/pear/package-*.xml > > > /usr/src/web/php/php4/pear/PEAR/Frontend/CLI.php(71) : Fatal error - >Frontend::displayLine deprecated > > > > > > . > > > . > > > Installing program: pear > > > cp: pear/scripts/pear: No such file or directory > > > Installing program: phptar > > > cp: pear/scripts/phptar: No such file or directory > > > > I've commited a patch for this one. > > I still get: > > [PEAR] Archive_Tar- installed: 0.9 > [PEAR] Console_Getopt - installed: 0.11 > [PEAR] Mail - installed: 1.0 > [PEAR] PEAR - installed: 0.90 > make[1]: Leaving directory `/home/mfischer/isrc/cvs/php4' > make[1]: Entering directory `/home/mfischer/isrc/cvs/php4' > /home/mfischer/isrc/cvs/php4/sapi/cli/php >/home/mfischer/isrc/cvs/php4/pear/install-pear.php >/home/mfischer/isrc/cvs/php4/pear/packages/*.tar > [PEAR] DB - installed: 1.2 > [PEAR] XML_Parser - installed: 1.0 > [PEAR] XML_RPC- installed: 1.0.3 > make[1]: Leaving directory `/home/mfischer/isrc/cvs/php4' > Installing build environment > Installing header files > Installing program: phpize > Installing program: php-config > Installing program: pear > cp: cannot stat `pear/scripts/pear': No such file or directory > Installing program: phptar > cp: cannot stat `pear/scripts/phptar': No such file or directory > Installing program: phpextdist > > 'pear' seems to get installed properly though, but not peartar: > > $ which pear > /home/mfischer/php4/bin/pear > $ which peartar > $ The 'pear' command is no longer installed by 'make', it's installed by the installer itself (install-pear.php) which has some 'make' capabilities. I've removed the unused parts in Makefile.frag and moved 'phptar' to the Archive_Tar package where makes more sense to be. Tell me if something doesn't work correctly now. Tomas V.V.Cox -- PHP Development Mailing List <http://www.php.net/> To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] PECL != Siberia
Jani Taskinen wrote: > > # make install > > /usr/src/web/php/php4/sapi/cli/php /usr/src/web/php/php4/pear/install-pear.php >/usr/src/web/php/php4/pear/package-*.xml > /usr/src/web/php/php4/pear/PEAR/Frontend/CLI.php(71) : Fatal error - >Frontend::displayLine deprecated > > . > . > Installing program: pear > cp: pear/scripts/pear: No such file or directory > Installing program: phptar > cp: pear/scripts/phptar: No such file or directory I've commited a patch for this one. > How can I use that if 'pear' isn't even installed? :) You always have: lynx -source http://pear.php.net/go-pear|sh :-) Tomas V.V.Cox -- PHP Development Mailing List <http://www.php.net/> To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Re: dbase extension - Contributing Code
Perhaps you might want to take a look at the xbase lib (http://linux.techass.com/projects/xdb/). They seem to support a wide range of dbase formats. Tomas V.V.Cox Geoff wrote: > > I've enhanced Jim Winstead's dbase extension about a year ago by adding > [some] memo support. Over time have kept it up to date with the latest PHP > distribution. I've recently migrated this code into the PHP 4.2.1 release. > What I'd like is to have my code placed in the default PHP distribution, so > that I don't have to keep going back to make changes. > > Currently, my enhancements support dbase_create() and dbase_add_record() to > allow for the insertion of non-binary memo data. I'm close to having the > dbase_get_record() function returning memo data aswell; but this still needs > to be migrated to 4.2.1 before I can complete it. > > So, how do I get my enhanced code into the regular PHP distribution? > Whatever needs to be done, please let me know. > > In the meantime, if you are interested in the dbase module, you can get it > from http://www.jukeware.com/projects.php?id=1 > After a bit more testing, I'll have the 4.2.1 migrated code there. > > Thanks, > Geoff Jukema -- PHP Development Mailing List <http://www.php.net/> To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Re: [PEAR-DEV] Interbase DB, again =)
Ludovico Magnocavallo wrote: > > > What about trying my other solution? > > 1st thing I tried, digging it up from your earlier mail, but not > surprisingly it produces the same results (I guess it's using the same logic > as get_object_vars). Oh, the cast seems to be the same :-/ > > Ah, I see. Yes, can't understand very well why the function doesn't > > return empty values. Change request? :-) > > Guess so, how is it done? For the moment I can only think on disabling ASSOC fetch for the ibase driver and trying to get from php developers that: 1) Implement native ASSOC fetch for the ibase extension 2) Change cast|get_object_vars behavior to set also properties with empty values. bugs.php.net -> Feature|Change request category Tomas V.V.Cox -- PHP Development Mailing List <http://www.php.net/> To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] handling uploads (was: Re: [PEAR-CVS] cvs: php4 /pear/HTML Form.php)
El mié, 30-01-2002 a las 17:39, Bertrand Mansion escribió:
> <[EMAIL PROTECTED]> wrote :
>
> > El mié, 30-01-2002 a las 10:26, Stig Bakken escribió:
> >> ssbWed Jan 30 04:26:25 2002 EDT
> >>
> >> Modified files:
> >> /php4/pear/HTMLForm.php
> >> Log:
> >> * XHTML fixes by Hans Westerbeek
> >>
> >>
> >>
> >>
> >
> >> Index: php4/pear/HTML/Form.php
> >> diff -u php4/pear/HTML/Form.php:1.21 php4/pear/HTML/Form.php:1.22
> >>
> >> @@ -445,30 +445,29 @@
> >> function displayFile($name, $maxsize = HTML_FORM_MAX_FILE_SIZE,
> >> $size = HTML_FORM_TEXT_SIZE, $accept = '')
> >> {
> >> -print " >> SIZE=\"$size\"";
> >> +print " >> size=\"$size\"";
> >> if ($accept) {
> >> -print " ACCEPT=\"$accept\"";
> >> +print " accept=\"$accept\"";
> >> }
> >> -print ">";
> >> +print "/>";
> >>
> >> }
> >>
> >
> > I'm curious about the "maxsize" attrib for setting the max size in a
> > "input file". AFAIK this attrib is not specified in the HTML 4.0 W3
> > Specs and isn't supported by the PHP upload system.
> >
> > So my question is: for what is that attrib there? :-)
> >
> > I guess that the only thing to limit the size (which will limit the size
> > for all files) is with a hidden name MAX_FILE_SIZE.
>
> I am puzzled with file uploads too, for HTML_QuickForm. Setting the
> max_file_size doesn't change anything and it seems that there are
> incompatibilities with Opera browser, at least with version 6.
>
> Does PHP return an error or a message when the uploaded file is larger than
> max_file_size in the hidden field or larger than the php.ini upload
> parameter ?
>
> When testing, it seems that the script just ends without notice if uploaded
> file is too large. This way, I can't unfortunately indicate to the user that
> his file is too large.
In a common upload one get in HTTP_POST_FILES:
userfile => array(
'name' => ..
'tmp_name' => ..
'type' => ..
'size' => ...
)
Previous to 4.1 when the file was too large one got: tmp_name -> 'none'.
But the "name" field filled, so I was able to say to the user: in the
input type file "usefile" you submited a file that exceeded the max
permitted size. In the other hand if the user doesn't submit any file
you get: name -> '', so you could say: you haven't submited any file in
the input "userfile". Not very intuitive but worked fine.
Now in 4.1 if the user exceeded the max size or doesn't submit any file
the HTTP_POST_FILES is empty, so no way to detect what happens.
In the next X release I heared from Jani that a new entry 'error' will
be filled with a new PHP constants (or whatever):
>From CVS main/rfc1867.c
/* Errors */
#define UPLOAD_ERROR_A 1 /* Uploaded file exceeded upload_max_filesize
*/
#define UPLOAD_ERROR_B 2 /* Uploaded file exceeded MAX_FILE_SIZE */
#define UPLOAD_ERROR_C 3 /* Only partiallly uploaded */
#define UPLOAD_ERROR_D 4 /* No file uploaded */
#define UPLOAD_ERROR_E 5 /* Uploaded file size 0 bytes */
As you can see in the next release we will able to get a detailed error
without more tricky work. Cool stuff Jani.
> Hidden fields are low in term of security as they can be modified by user.
Yes, it also limits the developer to set a unique max size for all the
files, plus the fact that is easily falseable as you say. The easy
solution is to only rely in upload_max_filesize from php.ini or just
restrict the size per file in the page that gets the uploads.
> Could someone point me to resources about file uploads handling in PHP (as
> it also seems there are changes in PHP 4.1). I have RTFM but it didn't help.
The test/error was for me the only way to build HTTP_Upload.
Tomas V.V.Cox
> Bertrand Mansion
> Mamasam
--
PHP Development Mailing List <http://www.php.net/>
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]
[PHP-DEV] magic_quotes_gpc Off (was Re: [PEAR-DEV] Pear website and magic quotes)
Lukas Smith wrote: > > Actually the default is on and even though I do not like them myself I > think this is what most people develop against. So I guess it might make > things easier if you keep it on as well. I don't think it makes things easy. See what magic_quotes_gpc means: quote in the MySQL style all the variables that comes from POST, GET or COOKIES. So the default php installation blatanly assumes that: "All the vars you get from forms or cookies will be inserted in a MySQL database by a user who doesn't take care on quoting data before inserting (or it will result in duble quoting)", does this make any sense? Just for informing people about this: turn off magic_quotes_gpc if you use placeholders (prepare/execute) with PEAR DB!! Tell people that they should take care of quoting data by them selves and tell them that there is nice mysql_escape_string() func for that. At least will be kind if the build process could put this directive to Off if you use --without-mysql and also if more backends are specified. > Anyways you can of course make your code aware of this feature and if > its on or off (get_magic_quotes() ... iirc) . That is not always posible as many times you are unable to know if a var comes from "GPC" untouched or not. It's even worse, because people are not able to disable magic_quotes_gpc with ini_set() (for people who doesn't have access to php.ini or .htaccess). Just my wishes to see a change on this. Tomas V.V.Cox -- PHP Development Mailing List <http://www.php.net/> To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
[PHP-DEV] Re: [PEAR-DEV] Re: PECL: is it ok to commit to php4 source tree?
"Stig S. Bakken" wrote: > > Yasuo Ohgaki wrote: > > > > > > Now I understand what you mean. There is no PECL there. > > So I have to ask users to check out repository to test PECL modules? > > I hope there is a better way :) > > We'll have to come up with something. Either a separate download area, > or naming these packages PECL_? > Why not both? A PECL top level category in the web and naming the packages with the PECL prefix. Anyway, a discussion about how to manage C extensions with the PEAR installer would be great. People will start to request that very soon. Tomas V.V.Cox -- PHP Development Mailing List <http://www.php.net/> To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
[PHP-DEV] Re: [PEAR-DEV] PECL: is it ok to commit to php4 source tree?
Yasuo Ohgaki wrote: > > Anyway, I'll just use "session_pgsql" for now. Module name differ > from actual module name, but names like "mod_pgsql" may conflict > other other modules. e.g. pgsql sub module for auth module, etc. imho "session_pgsql" is just perfect :) Tomas V.V.Cox -- PHP Development Mailing List <http://www.php.net/> To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
[PHP-DEV] Re: [PEAR-DEV] Re: PECL: is it ok to commit to php4 source tree?
Yasuo Ohgaki wrote: > > Yasuo Ohgaki wrote: > > > Hi all, > > > > I understand /pear has separate repository for pear development. > > What is the current rule for commiting /pear/PECL/some_module > > to /php4/pear/PECL/some_module? > > > > Thank you. > > > > Oops, PECL supposed to have different place for downloading. > There user can download modules? Cannot find link for download > in pear.php.net. > I can't tell you much about PECL, but yes for PEAR. Open this url: http://pear.php.net/?devme Then open this: http://pear.php.net and go to the package browser. There the people will be able to download the packages or directly remote install with the "pear" script. Tomas V.V.Cox -- PHP Development Mailing List <http://www.php.net/> To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
[PHP-DEV] Re: [PEAR-DEV] PECL: is it ok to commit to php4 source tree?
Yasuo Ohgaki wrote: > > Hi all, > > I understand /pear has separate repository for pear development. > What is the current rule for commiting /pear/PECL/some_module > to /php4/pear/PECL/some_module? > pear/PECL/some_module, no more rules :-) php4/pear has nothing to do with PECL. Tomas V.V.Cox -- PHP Development Mailing List <http://www.php.net/> To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
[PHP-DEV] Re: [PEAR-DEV] Re: [FRC]Session module related issues
Just for curious, do you have some speed comparations over the other handlers and perhaps also with a postgres handler in php? Tomas V.V.Cox El jue, 20-12-2001 a las 12:38, Yasuo Ohgaki escribió: > Yasuo Ohgaki wrote: > > > Martin Jansen wrote: > > > >> On Thu, 20 Dec 2001 14:41:43 +0900, Yasuo Ohgaki wrote: > >> > >> > >>> 4) Where document should be? > >>> > >> > >> If your session handler will be part of PECL, it should be documented > >> in the upcoming PEAR manual. Have a look at the CVS module peardoc > >> to get a feeling for it. > > > > > > > > Thank you for your reply. > > It may be OK to put document for modules that does not have > > function at all and does not work with certain modules is not > > compiled in. :) Any objection for this? > > > > We can live with "undefined symbol" errors also. > > However, I really don't want "undefined symbol" error because > > I'm sure users will submit bug reports for this. Besides, it's > > not the right way to manage software. IMHO. > > > I'll try be more clear on this. > Do you want CGI version to fail to run just because GCI version > does not have session module? > (i.e. session save handler is loaded in php.ini for other SAPI, > and there is line for loading session save handler, or modules > for a module) > > -- > Yasuo Ohgaki > > > >> > >> Basically I think it would be nice to have this in PECL, since it > >> is no real 'core' part of PHP and so it does not really fit in > >> php4/ext, eventhough it requires the session extension to be > >> enabled. > >> > > > > I should explicitly have written about technical issues. > > You missed issues here > > > > 1) It highly depends on Session module. > > 2) It does not work as standalone module at all. > > 3) It will fail to load with undefined symbol when PHP is > >compiled with --disable-session. > > 3) It does not provide any function to users. > > 4) Where document should be? > > 5) How to handle include files required for session save > >handler module? > > > > Session save handler modules are not a usual modules, > > but modules in a module. > > We need to address technical issues also. Technically, > > it is possible to separate session save handlers from > > session module. > > However, it does not mean, it's good idea to do that. > > > > If we decide to separate session save handlers to PECL, > > there must be *clean* way to separate them. > > > > If PHP has *clean* way to provide modules in a module, > > it will be realistic to place session save handlers > > to PECL. I expect changes in current *module* > > initilization code for this. > > > > Anyone has comment on this? > > (Compilation and initialization for modules in a module. > > We can put php_session.h in standard header location. > > Do we really want this? "Undefined Symbol" error is not > > acceptable at least for me, also. It's possible to have > > required globals always in PHP. Do we really want this?) > > > > BTW, currently, mm save handler support is broken partially. > > Clue for proper session save handler module > > initialization with current code is also appreciated :) > > > > > > -- > Yasuo Ohgaki > > > -- > PEAR Development Mailing List (http://pear.php.net/) > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > To contact the list administrators, e-mail: [EMAIL PROTECTED] > -- PHP Development Mailing List <http://www.php.net/> To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
[PHP-DEV] Strange crash
This script crashes for me, but it work if comment out the line 17 (the
var_dump).
Tomas V.V.Cox
fp = $fp;
}
function prepare_connection($nntpserver, $port = 119, $newsgroup)
{
$err = $this->connect($nntpserver, $port);
//var_dump($err);
$this->command("GROUP $newsgroup");
}
function command($cmd, $testauth = true)
{
fputs($this->fp, "$cmd\r\n");
}
}
$news = new Net_NNTP;
$news->prepare_connection('news.php.net', 119, 'php.pear.dev');
echo "works\n";
?>
--
PHP Development Mailing List <http://www.php.net/>
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]
[PHP-DEV] odbc_fetch_into and odbc_error problem
Hi,
I'm having some problems with the Pear DB odbc extension, here is the
talk about them with an Easysoft developer, if it can help on resolving
the bug.
Thanks,
Tomas V.V.Cox
PS.- Please request me any extra info you need.
> "Martin J. Evans" wrote:
> >
> > "Tomas V.V.Cox" wrote:
> > I'm trying this code (if you understand php code):
> >
> > $cols = odbc_fetch_into($result, $rownum, &$row);
> > if (!$cols) {
> > if ($errno = odbc_error($this->connection)) {
> > var_dump($errno);
> > die();
> > }
> > return null;
> > }
> >
> > Sometimes works fine, but sometimes I get corrupted data in $errno (so
> > I'm not able to catch fetch row errors). Ie:
> > string(6) "ft_@("
> > string(4) "ÄÎ"
> > string(6) "thisX"
> > string(1) ""
> >
>
> There are problems in PHP and not the back end.
>
> The problems are:
>
> [1] there is no way in the odbc_fetch_into() to tell the
> difference between
> [a] an empty result-set
> [b] a non-empty result-set but the requested row did not
>exist in the result-set
> [c] and an error
> odbc_fetch_into() returns false for all of these cases.
> [2] the odbc_fetch_into() function rarely calls odbc_sql_error
> (an internal php_odbc.c fn calling the ODBC SQLError fn).
> If SQLGetData to retrieve a column returns an error it will
> call odbc_sql_error but that is about all.
>
> The reason you are seeing garbage is simply that SQLError was
> never called and in any case, if you had an empty result-set or
> asked for a non-existant row there is no ODBC error -
> SQLExtendedFetch simply returns SQL_NO_DATA (which is not
> an error).
>
>
> Incidentally, I ran into problems on PHP 4.0.6 initially
> because I passed 1 for rownum into odbc_fetch_into. In this
> case I simply received the "document contained no data"
> message from my browser with no error in the PHP log and no
> error in my Apache log. I then found the comment in the PHP
> document saying you since 4.0.6 rownum HAS to be a variable.
> Surely this is a bug in PHP as well - my code was incorrect but
> PHP did not output anything in the error log at all - it was
> simply as if Apache had never passed the phtml to PHP.
>
> Martin
> --
> Martin J. Evans
> Easysoft Ltd, UK
> Development
--
PHP Development Mailing List <http://www.php.net/>
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]
[PHP-DEV] Re: [PEAR-DEV] PHP arrays managment bug :-?
Cynic wrote:
>
> >> >
> >> >1) array_pop() bug:
> >> > >> >$a = array();
> >> >$a[] = array('foo', 'bar');
> >> >print_r($a);
> >> >$a[] = array('foo2', 'bar2');
> >> >print_r($a);
> >> >$a = array_pop($a);
> >> >print_r($a);
> >> >?>
>
>
> so, you're questioning the order of the retval assignment, and the
> popped array?
>
> >> >$a = array_pop($a);
> >> >print_r($a);
>
> change that $b = array_pop($a);
> print_r($b);
> and I think you'll see what you expected to see.
Oh, I was really idiot on that, $a is assigned by reference. Sorry, too
much strings :)
Tomas V.V.Cox
--
PHP Development Mailing List <http://www.php.net/>
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]
[PHP-DEV] Re: [PEAR-DEV] PHP arrays managment bug :-?
Cynic wrote:
>
> I don't see any error in the output. What did you expect?
>
> At 14:30 7/27/2001, Tomas V.V.Cox wrote the following:
> --
> >During my test with the pushErrorHandling and popErrorHandling I found
> >strange behavoirs of the PHP array functions (I use last cvs php under
> >Linux).
> >
> >1) array_pop() bug:
> > >$a = array();
> >$a[] = array('foo', 'bar');
> >print_r($a);
> >$a[] = array('foo2', 'bar2');
> >print_r($a);
> >$a = array_pop($a);
> >print_r($a);
> >?>
> >
> >The output:
> >Array
> >(
> >[0] => Array
> >(
> >[0] => foo
> >[1] => bar
> >)
> >
> >)
> >Array
> >(
> >[0] => Array
> >(
> >[0] => foo
> >[1] => bar
> >)
> >
> >[1] => Array
> >(
> >[0] => foo2
> >[1] => bar2
> >)
> >
> >)
Real output:
> >Array
> >(
> >[0] => foo2
> >[1] => bar2
> >)
Expected output:
Array
(
[0] => Array
(
[0] => foo
[1] => bar
)
)
> >2) The array[] statement fails to find the correct last value:
> > >$a = array();
> >$a[] = array('foo', 'bar');
> >print_r($a);
> >$a[] = array('foo2', 'bar2');
> >print_r($a);
> >unset($a[sizeof($a) - 1]);
> >print_r($a);
> >$a[] = array('foo3', 'bar3');
> >print_r($a);
> >?>
> >
> >The output:
> >Array
> >(
> >[0] => Array
> >(
> >[0] => foo
> >[1] => bar
> >)
> >
> >)
> >Array
> >(
> >[0] => Array
> >(
> >[0] => foo
> >[1] => bar
> >)
> >
> >[1] => Array
> > (
> >[0] => foo2
> >[1] => bar2
> >)
> >
> >)
> >Array
> >(
> >[0] => Array
> >(
> >[0] => foo
> >[1] => bar
> >)
> >
> >)
Real output:
> >Array
> >(
> >[0] => Array
> >(
> >[0] => foo
> >[1] => bar
> >)
> >
> >[2] => Array
> >(
> >[0] => foo3
> >[1] => bar3
> >)
> >
> >)
> >
Expected output:
Array
(
[0] => Array
(
[0] => foo
[1] => bar
)
[1] => Array
(
[0] => foo3
[1] => bar3
)
)
Tomas V.V.Cox
--
PHP Development Mailing List <http://www.php.net/>
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]
[PHP-DEV] PHP arrays managment bug :-?
During my test with the pushErrorHandling and popErrorHandling I found
strange behavoirs of the PHP array functions (I use last cvs php under
Linux).
1) array_pop() bug:
The output:
Array
(
[0] => Array
(
[0] => foo
[1] => bar
)
)
Array
(
[0] => Array
(
[0] => foo
[1] => bar
)
[1] => Array
(
[0] => foo2
[1] => bar2
)
)
Array
(
[0] => foo2
[1] => bar2
)
2) The array[] statement fails to find the correct last value:
The output:
Array
(
[0] => Array
(
[0] => foo
[1] => bar
)
)
Array
(
[0] => Array
(
[0] => foo
[1] => bar
)
[1] => Array
(
[0] => foo2
[1] => bar2
)
)
Array
(
[0] => Array
(
[0] => foo
[1] => bar
)
)
Array
(
[0] => Array
(
[0] => foo
[1] => bar
)
[2] => Array
(
[0] => foo3
[1] => bar3
)
)
Isn't those bugs serious or am I loosing something?
Tomas V.V.Cox
--
PHP Development Mailing List <http://www.php.net/>
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]
