{5} Assigned, Active Tickets by Owner (Full Description) (40 matches)

<?php # vim600:syn=php:
$filename = tempnam("/tmp", "phpt");

$fp = fopen($filename, "w+") or die("can't open $filename for append");
fwrite($fp, "quxbar");
fseek($fp, 3, SEEK_SET);
fread($fp, 1);
fseek($fp, 4, SEEK_SET);
fwrite($fp, '!');
fseek($fp, 0, SEEK_SET);
var_dump(fread($fp, 4095));

ftruncate($fp, 0);
rewind($fp);

fwrite($fp, "barfoo");
fseek($fp, 3, SEEK_SET);
fread($fp, 1);
fwrite($fp, '!');
fseek($fp, 0, SEEK_SET);
var_dump(fread($fp, 4095));

fclose($fp);
unlink($filename);
?>


ADDITIONAL INFORMATION:
File "../phpoo/runtime/ext/standard/./php-files.scm", line 730, character 24221:
#		(else (error "fopen" "invalid file mode" mode)))))))
#		      ^
# *** ERROR:bigloo:fopen
# invalid file mode -- w+
    0. fopen
    1. php-funcall
    2. apply
    3. evaluate (3 times)
    6. evaluate-block
    7. evaluate-default2438
    8. evaluate (2 times)
   10. interpret
   11. php-commandline

<?php

$class = 'foo';
echo "$class{";

?>


ADDITIONAL INFORMATION:
[weyrick@hikari:tmp]$ php -f bug.php
foo{
[weyrick@hikari:tmp]$ pcc -f bug.php

File "./lexers.scm", character 3633:

*** ERROR:bigloo:parser:
bug.php:4: bug.php:4: parse error (unexpected token `*eoi*') -- #eof-object

this produces a parse error in pcc, works in php:

<?php

class foo {
  function foo() {
    $this -> foo = 22;
  }
}

$bar = new foo();
echo $bar -> foo . "\n";
echo "{$bar -> foo}\n";

?>

<?php
class foo {
    function foo($vararray) {
        $this->_tpldata['switch_user_logged_out.'][]['switch_allow_autologin.'][] = $vararray;
    }
}

$foo = new foo("foo");
?>

<?php

class foo {}
$foo = new foo();
$bar = $foo->width;
$bar = $foo->height;

var_dump($foo);

?>

like this one:

Warning: fopen(/tmp/asdfasdfasdf): failed to open stream: No such file or directory in /tmp/foo.php on line 3

var_dump can tell if it was passed a reference or not:

<?php

$foo = 2;
var_dump(&$foo);
var_dump($foo);

?>

If you include the same file via a different path, pcc doesn't recognize that it's the same file which causes it to be included again evein if it's an include_once.

This was making pcc think that a function was getting re-defined when it shouldn't have been.


<---------include.php----------->
<?
function foo() {
        echo "in foo\n";
}
?>
<------------------------------->


<---------test.php-------------->
<?
$pwd = getcwd();

include('include.php');
include_once($pwd . '/include.php');

foo();

?>
<------------------------------->

<?php

$foo[2147483647] = "foo";

$foo[] = "bar";

$foo[2147483649] = "baz";

$foo[] = "bling";

var_dump($foo);

$bar[1] =  "at one";
$bar["1"] =  "at one";
var_dump($bar);

?>

echo "$foo{2,20}"
php: {2,20}
pcc: (error)


ADDITIONAL INFORMATION:
Original source via phpgroupware package:

phpgroupware/email/inc/class.mail_msg_base.inc.php:3907: parse error
          (unexpected token `comma') -- comma

right now this fails:

echo ("pages[".$pageCount++."] = new realmPage(\"{$pageInfo["pageTitle"]}\",\"{$pageInfo["pageID"]}\"); \n");

but this is ok:

echo ("pages[".$pageCount++."] = new realmPage(\"{$pageInfo[pageTitle]}\",\"{$pageInfo[pageID]}\"); \n");

as is this:

echo ("pages[".$pageCount++."] = new realmPage(\"{$pageInfo['pageTitle']}\",\"{$pageInfo['pageID']}\"); \n");

it would enable warnings for undefined functions at compile time, for one thing.

Given a php-builtin defined like this:

(define *scheme-var* 10)
(defbuiltin (some-builtin (opt-arg1 *scheme-var*))
   opt-arg1))

The following PHP script:

<?php echo some-builtin()."\n"; ?>

produces the _string_:

*scheme-var*

because the default value gets quoted before being evaluated and then when it eventually gets evaluated, it evaluates to the symbol *scheme-var* and not the value of *scheme-var*. 


ADDITIONAL INFORMATION:
changing compiler/generate.scm line 947 from:

,(let ((default (optional-formal-param-default-value p)))

to:
	  
,(let ((default (eval (optional-formal-param-default-value p))))

fixes the problem and doesn't break anything else.

Also, changing line 1552 (or so) in php-runtime.scm from:

((quote ?FOO) FOO)

to:

((quote ?FOO) (eval FOO))

did not fix the problem.

# test.php <?php

$include='test2.php'; include($include); class c{

function d($pp){

return $pp->b();

}

} $y=new c(); echo $y->d($x);

?>

#test2.php <?php

class a{

function b(){

return 'qq';

}

}

$x=new a();

?>

pcc test.php ./test Runtime error in file test.php on line 6: Type pair' expected, bstring' provided

pcc test.php test2.php ./test qq

If you replace in test2.php return 'qq'; with $x='qq';return $x; it works. So it all comes down to constant return values not being returned properly from a runtime interpreted class to a compiled class.

EOM

one report of session segfault, another test case of failure (microserver):

page1.php

<?php
session_start();
echo 'Welcome to page #1';
$_SESSION['favcolor'] = 'green';
$_SESSION['animal'] = 'cat';
// Works if session cookie was accepted
echo '<br /><a href="page2.php">page 2</a>';
?>

page2.php

<?php
session_start();
echo 'Welcome to page #2<br />';
echo 'favcolor=' . $_SESSION['favcolor'] . '<br>'; // green
echo 'animal=' . $_SESSION['animal'] .'<br>' ; // cat
echo '<br /><a href="page1.php">page 1</a>';
?>

and of course a suitable mhttpd_startup.inc

The interpretor seems to be cacheing the environmental change of frontend files that have exactly the same code and worked upon exactly the same state variables - and thus not executing the files if the result is cached already.

I wrote that in very general terms as I don't know exactly what it is doing. So explained loosely from my point of view...

My system has lots of files sitting in different directories that are identical. These files should execute differently because they execute as a function of the directories they are in. They are all frontends to my system, and the directory that they are in specifies what aspect of the system is called up.

we still get object comparison wrong, with respect to greater and less than.

at least with bigloo 3.1a, the PDO extension does not initialize correctly when used for compiled applications (works ok interpreted). there appears to be a problem with initialization order, as pdo_init.php can't find pdo_mysql.php which is compiled into the same library.

the tests/basic.php returns:

File "php-errors.scm", character 6103:
*** ERROR:error-handler:
couldn't find include file pdo_mysql.php (include path was ./) -- error-handler
    0.php-error, php-errors.scm:176
    1.find-include, include.scm:200
    2.do-include, include.scm:145
    3.php-require, include.scm:79

quick investigation shows php-pdo-make-lib_s.c does the init calls in the right order.

In Zend, when an attempt is made to access an unaccessible private or protected property, the request is passed to get or set overload functions, if provided; to me, this makes sense. In PCC an error is thrown.