Home / Section index www.icosaedro.it

# PHPLint - BUGS

Last updated: 2018-05-10

## Known bugs and missing features

• Arguments of variadic function cannot be passed by reference. This restriction makes impossible to declare functions like scanf("...", $x) as PHPLint always complains "$x is not defined".
• Parameters unpacking "... EXPR" not supported.
• The EXPR in the argument of the foreach(EXPR as $x){} statement must be a proper variable, not a generic expression. For example, foreach(array(1,2,3) as$x){} isn't allowed by PHP but still passes PHPLint validation.
• PHPLint pretends the [] operator be the very last in a sequence of selector indices, so for example:
	$a = /*. (int[int][int]) .*/ array();$a[][1] = 3;

gives a fatal error.
Workaround: build rows one at a time and add them to the $a array as last step. • Namespace resolution is performed in the order of declaration, while PHP resolves names after the parsing stage. Then, for example:  namespace xxx; echo strlen("aaa"); function strlen($s)
{
return $s; }  Here PHPLint assumes "echo" will invoke \strlen() because at the time it parses that statement the following new strlen() function is still unknown to it; instead PHP will call \xxx\strlen(). Things go in the right way if all the declarations appears before the code. In general, being PHPLint a single pass parser, all should be declared in bottom-up order. • PHP (at least up to 7.0.0) does not allow to lower the visibility of the constructor in a derived class. For example: class A { public function __construct(){} } class B extends A { private function __construct() { parent::__construct(); } }  causes this fatal error at compile-time: Fatal error: Access level to B::__construct() must be public (as in class A) in ... PHPLint, instead, passes that code as valid because constructors do not extend constructors, so the general visibility rule does not apply here. Discussion still open at https://bugs.php.net/bug.php?id=61970. • The constructor of an anonymous class cannot have formal arguments passed by reference, like in this example: $o = new class($x) { function __construct(int &$n){ $n = 123; } };  Here PHPLint signals error because it parses the actual argument$x before the constructor definition, and it assumes pass by value. The fix would require a double-pass parser.
• In the type model of PHPLint there is an "object" class and any class extends this latter, so all classes (abstract and concrete) have a common base class that matches an object of any class. This is not true at runtime, because in PHP there is not an "object" class and there is not a common base class, so there is not an "object" type hint and there is not way to match an object of any class. "$x instanceof object" must be rewritten as "is_object($x)".
• The division operator always returns a float value, also when the two operators are statically evaluated numbers and the result has no fractional part. This means a simple expression like 6/2 is assumed to give 3.0, not 3. Implications:
	$i = 6/2;  is of the float type 3.0, while PHP evaluates it as 3. A programmer expecting int gets float instead. So a variable that was statically parsed being float, may get an int instead at runtime. cast("float[int]",$v) may fail if some value result int rather than float. Although this issue could be fixed for static expressions, it cannot be fixed in the general case because PHP sets the type only at runtime.
• Numeric values and static expressions are evaluated using the currently available PHP installation, and overflow is not detected. This means that large numbers may bring to unexpected results, or the same value might be within the allowed range on a system but not on another. For example, 0xffffffff overflows the int capacity on a 32-bits system, but it is valid on a 64-bits system. Example:
	const X = 0xffffffff;
if(X);
var_dump(X);

Here PHPLint tells that X is int, but running on a 32-bits system displays float(4294967295). Possible ways to address this problem:

1. Add a --32-bits and --64-bits options that validates the source vs. a given platform, being 32-bits the default; the generated report should then display the int width the source has been validated for.

2. Detect possible overflow on some platform, reporting the source compatibility or incompatibility against each possible platform.

Whatever the solution, expressions may overflow anyway at runtime so the programmer should take extra care where very big numbers could be involved.

## Known missing features which is unlikely will ever be implemented

• Assignment of a single char to a string not allowed in PHPLint:
  $s = "abc";$s[1] = "z"; // invalid left hand side in assignment

The behavior of PHP here is mostly undefined or erratic, see https://bugs.php.net/bug.php?id=71572.
Rationale: mostly undefined behavior; leads to write unsafe and very inefficient programs.
• Literal binary numbers like 0b1010. Hint: use decimal, octal o hex numbers instead.
Rationale: useless.
• Variable variable: $$v. Variable function: f(). Variable class: new c(). Variable method: obj->m(). Rationale: can't validate. Possible alternatives:$$v: usually an associative array.
$f($x): interface defining a method F, then use a specific class for every kind of value for $x, then$x->F() to perform the action F on $x. new$c(): either use reflection to create an instance of a named class whose ctor does not require parameters, or simply replace with an object already instantiated, or use a builder.
$obj->$m(): interface defining a method M, then use a specific class for every kind of value for $obj, then$obj->M() to perform the action M on $obj. • Variable name in curly braces${xxx}.
Rationale: useless flexibility in a statically validated source; mostly obscure syntax.
• Not implemented:
goto LABEL;
break EXPR; (only "break;" without argument is implemented)
continue EXPR; (only "continue;" without argument is implemented)
list() = EXPR
Rationale: very difficult where impossible to validate at all; leads to bad practices.
• Alternate syntax for control structures, example:
if(EXPR): ... endif;
switch(EXPR): endswitch;
... then the following keywords are forbidden by PHPLint: enddeclare, endwhile, endfor, endswitch, endif, endforeach.
Rationale: redundant legacy syntax.
• "case LABEL": under PHPLint the label must be a static expression evaluable at parse time, then cannot include variables nor functions.
Rationale: static expression allows optimizations in future compilers.
Workaround: when non-static expressions are required, the if() statement should be used instead.
• Under PHPLint, require*() and include*() are statements, not functions. So, the the included file cannot return a value nor it can simply return. In other words, these statements are forbidden at global scope of an included file:
	return;
return EXPR;


Rationale: improper programming practice where a simple function would fit.
Workaround: properly using functions and static methods of class result in a cleaner source code (and makes happy PHPLint).
• Traits.
Rationale: redundant; leads to improper usage of classes in place of arrays or other more specific data structures.
Workaround: large amount of redundant data can be handled conveniently using array a specific objects.
• Anonymous functions (also known as "closures").
Rationale: big complexity added for little gain; very difficult to document their behaviour, their interface, and then very difficult to be used by the programmer, bringing to unsafe, obscure code.
Workaround: use classes and anonymous classes instead.
• Generators.
Rationale: big complexity added for little gain.


 Umberto Salsi Comments Contact Site map Home / Section index

2018-05-11 by Umberto Salsi <salsi@icosaedro.it>
Re: Too much "hard coded". [That is, using 3rd party sources with PHPLint]
Eitan M. wrote: [...] mysqli_stmt->get_result() if defined in the modules/mysqli.php file, at least since 2013-05-13 according to my CVS; I do my best to keep these modules files in synch with the evolving PHP, but it is a huge task. [...] PHPLint cannot pass code which cannot validated. Dot. Choose one: 1. Do not use third party sources that cannot pass validation; write your own implementations or use the tools of the PHPLint stdlib. 2. Keep you validable sources separated from non-validable third party source as much as you can, applying validation only where possible. 3. Adjust third party sources so to pass validation. Read my article at http://www.icosaedro.it/phplint/worth-the-effort.html for my experience. 4. Exotic: include third party sources with include(), include_once() or require() so PHPLint does not parse them; define a dummy module as they where PHP extension written in C code; require that stub module. For example, your program could contain something like this: requi[...][more...]

2018-05-11 by Umberto Salsi <salsi@icosaedro.it>
Re: singleton classes and __clone
Guest wrote: [...] The __clone() method is one of those magic methods the PHP interpreter may invoke from outside the object, so their visibility must be public. To disable cloning you may then implement that method by throwing an exception: function __clone(){ throws new \RuntimeException("cannot clone singleton"); } In this way a meaningful error message is generated in an attempt to clone the object. Instead, by setting that method as private, like in private function __clone(){} 1. You still get an error, but the text is quite confusing (tested on PHP7): Uncaught Error: Call to private XXX::__clone() from context '' 2. Moreover, this does not prevent the object from being cloned by one of its own methods: class MyClass { private function __clone(){} function m(){ return clone $this; } } 3. Although (currently) PHP does not enforce the visibility of these magic methods, things could change in future. So in my opinion these magic methods are and should be public. P.S. - And if you ar[...][more...] 2015-11-19 by Umberto Salsi Re: unknown variable , if variable not in current file, but in included file? dreamin wrote: [...] Hi dreamin, the reason why that variable cannot be seen from another module is due to the fact that this latter module imports the first one using include(), include_once() or require() instead of require_once(). Sources imported with require(), include and include_once() are not parsed recursively because these statements are unreliable and are not safe when external code has to be included. Only require_once() garantees the external package will be loaded or a fatal error is raised, and garantees that the package will be loaded just once. You may find more about this feature here: http://www.icosaedro.it/phplint/phplint2/doc/reference.htm?p=packages Regards, - U.Salsi[more...] 2015-11-19 by dreamin unknown variable , if variable not in current file, but in included file? As the title described, such as the variable "$AAA" defined in def.php but referenced in ref.php; ref.php file like this: <?php> include('def.php') #$AAA defined in 'def.php' --using$AAA here-- <?> if i run phpl ref.php, i'll get error msg: $AAA not exist. if i run phpl def.php ref.php, the error msg will be disappeared. if i run php ref.php def.php, the error appears again... Then I concluded that: if I wanna get more accurate msg, I should manually specify included|required file in the executable command.... To do one-time checking is ok for me, but for the whole project, I need to firstly manually parse the source file to let the scanner to find the included php file, and give the file-location as the command options .. yesterday, I experienced this tool, awesome~, today, I dive into some usage and read the architecture document.. awesome... PHP-built-in "php -l" feature satisfy basic needs, phplint satisfy upper needs. I have not experienced pfff, hhvm, phan, compared to phplint,[...][more...] 2015-07-18 by Guest thanx to provide this type tools very helpfull tool, i was irritate but this tool helped me alot, i got exact error and solved in 2 minutes, which was not solving since 12 hours[more...] 2014-11-11 by Entropy Re: PHPLint finding errors with var_dump() Umberto Salsi wrote: [...] Hi Umberto, I have read up more on PHPLint and PHP. Based on your reply and my own research I think that I now have a much better understanding of how PHPLint works. Thank you, Peter [more...] 2014-11-10 by Entropy Re: PHPLint finding errors with var_dump() Umberto Salsi wrote: [...] (PLEASE ADD YOUR COMMENTS HERE) Hi Umberto, Thank you for the reply. When I use /*. require_module 'filter'; .*/ I obtain this warning message: Warning: using deprecated package /home/salsi/src/phplint/modules/filter.php: Very poorly written interface with too many 'mixed' values, difficult to validate automatically, leaving to the programmer all the responsibility to handle properly arguments and returned values. The returned values are also 'mixed' with a complex semantic based on the special values NULL, FALSE/TRUE, etc. It is questionable if this library really adds security. What is your suggestion, either not use the likes of filter_var($checkEmail, FILTER_VALIDATE_EMAIL); at all or else use /*. require_module 'filter'; .*/ just to suppress the errors and manually check arguments and returned values? Regarding the use of \x should I ignore the warnings, or use the likes of %0A , %0D , %08 , %09 instead of \r \n \t etc? Many thanks again, Peter [more...]

2014-11-10 by Umberto Salsi
Re: PHPLint finding errors with var_dump()
Hi Peter, currently PHP allow to insert invalid escaped sequences, for example "\m": in this case, PHP simply passes all these characters verbatim without complaining. But, at the same time, the PHP developers team adds new escape sequences from time to time that break the compatibility with the existing code. For example \v \e \f are new sequences recently added; existing sources that contains that sequences do not work properly anymore. PHPLint, instead, is very pedantic while parsing literal strings, and always it pretends the backslash character '\' be used to enter an actual escape sequence choosen from a set of established, well know, escape sequences, exactly those he lists in its error messages. In this way the compatibility of the validated source is ensured with any past and future version of PHP. For example, some day a \u sequence might be added to support Unicode without breaking the compatibility with any source validated by PHPLint, where such a sequence is (by now) forb[...][more...]

2014-11-09 by Entropy
PHPLint finding errors with var_dump()
Hi Umberto, I must say I am most impressed with PHPLint. lt has found many errors in my code, thank you. Additionally the Reference Manual and the PHPLint Tutorial are very informative about problem areas even if one was not to use PHPLint. I have learnt much just by reading those. I am using the online verssion http://www.icosaedro.it/phplint/phplint-on-line2.html as I will not be able to install PHP on my computer. I have obtained some warnings and errors as follows: PHPLint issues warnings for back slashes From Example #4 Strip whitespace (please see below) located on the php.net site http://us3.php.net/manual/en/function.preg-replace.php <?php $str = 'foo o';$str = preg_replace('/\s\s+/', ' ', $str); // This will be 'foo o' now echo$str; ?> Warning: invalid escape sequence. Hint: allowed escape sequences are only \' \\ This is objecting to the back slash before the s, as in \s PHPLint issues warnings for back slashes in the format parameter string for d[...][more...]

2014-10-28 by Umberto Salsi
Re: list() unimplemented
Anonymous wrote: [...] Hi Peter, the problem with the list() construct is that I don't know how to define and garantee the correct types of the variables, their number and even if they get really assigned at all after this statement. In fact, the right-hand side of list() can be an array containing any number of variables of any type. For these reasons you should replace this construct with a regular array: list($a,$b) = f(); becomes $res = f();$a = $res[0];$b = $res[1]; The current version of PHPLint available from CVS still reject list(), but with a much more cleaner message: list($a) = 123; \\_ HERE ==== 3: ERROR: (FATAL) list() is unimplemented For now, just a bit better that before :-) Regards, - Umberto [more...]

2014-10-28 by Guest
list() unimplemented
Hi Umberto I'd really like to use your software but it reports: Uncaught exception 'RuntimeException' with message 'list() unimplemented' in C:\\phplint-2.0_20140824\\stdlib\\it\\icosaedro\\lint\\expressions\\ListFunction.php:24 and then stops with a stack trace rather than continuing. When do you think this functionality might be ready or, at least, ignored in a way that allows the rest of the code to be parsed? Thanks Peter[more...]

2014-02-11 by Guest
Anonymous functions

2013-05-23 by Eitan M.
Too much "hard coded".
There are some difficulties: 1. New version of php (not too old, i.e 5.3) has some methods, i.e mysqli_stmt->get_result(). phplint doesn't know that specific method (I persume many others, and many news that will be in future). 2. I want to use 3rd party object (it is well debuged, not by php lint, and for me it's a black-box, that I don't want to change anyway). I don't want phplint to compile thos 3rd party object, but if it is not compiled by php lint, it is annoying messages. Can I ignore those errors. (i.e new phpmailer object, that has call, i.e I can do: new phpmailer(true), while on phplint I cannot, or swiftmailer, or any ...) Thanks :)[more...]

2013-01-16 by Guest
__DIR__
Some time ago, you added a hard edit to prevent using relative paths in require_once. You suggested adding __DIR__. This works fine for PHP5.3+, but it fails for earlier releases. My ISP uses PHP5.2, so I can't both lint my code successfully and run it on my site. Prior releases of PHP can use the equivalent construction dirname(__FILE__), but PHPlint currently balks at that. Would it be possible for you to detect the use of dirname(__FILE__) in this circumstance, treating it as if it were __DIR__?[more...]

2012-08-16 by Guest
Great job! Thanks.
Though I'm not a fan of php I have to work with it. And I'm no fan of fancy POS'es like IDE's, I use vim, and I hate plugins. So I had no good way of checking php code since 'php -l', well mostly sucks. Now THIS is great tool and not some crappy plugin targeted only to some lame environment, its a general command line tool easily integratable anywhere/everywhere! Thank you very much.[more...]

2012-04-08 by Pierre Rudloff
Re: False positives
Umberto Salsi wrote: [...] I was confused because the doc only talks about 2 arguments for this function. But I have added /*., args.*/. [...] Well, the doc does say it is an interface, but when I try to implement it, I get: Fatal error: xDOMImplementation cannot implement DOMImplementation - it is not an interface in /var/www/assoquest/classes/DOMElement.php on line 2 [...] It works, thanks! [more...]

2012-04-08 by Umberto Salsi
Re: False positives
Pierre Rudloff wrote: [...] If the original method you are overriding accepts /*.args.*/, that is, it accepts 0 or more values of any type, also the overriding method must accept 0 or more values of any type; then, you cannot restrict its signature. If you really need such a method m(string[,string]), then either define a new method with a different name, or throw an unchecked exception UnexpectedValueException or InvalidArgumentException if the client calls the method with more than 2 args or with a second arg which is not string respectively. [...] If DOMImplementation really is an interface, it cannot be instantiated by definition. Only concrete classes can be instantiated. [...] The prototype of the get_headers() function as defined in the standard module is wrong, you may correct it yourself so that it reads: /*. string[] .*/ function get_headers(/*. string .*/ $url,$format = 0) { trigger_error("", E_WARNING); } Note that, according to the official manual, the second argument is [...][more...]

2012-04-08 by Pierre Rudloff
False positives
Hello, I am using PHPLint to check my code and I seem to get 3 false positives: ==== /var/www/assoquest/classes/DOMElement.php:51: ERROR: xDOMDocument::createElement()': the signature xDOMElement(string [, string])' does not match the overridden method DOMDocument::createElement()' declared in modules/dom:427 with signature DOMElement(string, ...)': required variable number of arguments /*.args.*/ The doc says this for createElement: DOMElement DOMDocument::createElement ( string $name [, string$value ] ) So xDOMElement(string [, string]) should be OK. ==== /var/www/assoquest/classes/DOMElement.php:62: ERROR: cannot instantiate interface class DOMImplementation' Why ? This class does have a constructor according to the doc: DOMImplementation::__construct ( void ) ==== 6: ERROR: invalid index of type string, expected int PHPLint seems to expect get_headers() to return array[int], but by using get_headers($url, true), it can return array[string]. Anyway, thanks for this great tool![more...] 2011-05-18 by Guest Re: DateTimeZone::listIdentifiers Permits an Argument Umberto Salsi wrote: [...] (PLEASE ADD YOUR COMMENTS HERE) Works perfectly! Thanks for the speedy response. [more...] 2011-05-17 by Umberto Salsi Re: DateTimeZone::listIdentifiers Permits an Argument Anonymous wrote: [...] The problem is due to the incomplete declaration of the prototype of the method in the 'standard' module. You can download the updated module from the CVS that fix this problem: http://cvs.icosaedro.it:8080/viewvc/*checkout*/public/phplint/modules/standard [more...] 2011-05-17 by Guest DateTimeZone::listIdentifiers Permits an Argument PHPLint handles this line with no problems:$lines = DateTimeZone::listIdentifiers(); However, when I add a permitted argument: $lines = DateTimeZone::listIdentifiers(DateTimeZone::ALL_WITH_BC); PHPLint flags that line: ERROR: DateTimeZone::listIdentifiers()' declared in /home/owen/phplint/modules/standard:1175: too many arguments ERROR: constant DateTimeZone::ALL_WITH_BC' does not exist In fact, this code is valid: http://www.php.net/manual/en/datetimezone.listidentifiers.php The code does execute as expected, returning different results when the argument is specified than when it is omitted. What do I, or you, need to do to get PHPLint to accept it?[more...] 2011-02-09 by Guest singleton classes and __clone I believe it's good practice to override the public __clone function with an empty private __clone function when creating a singleton class (please correct me if I'm wrong). When I do this, PHPLint complains with: ERROR: special method __clone': invalid signature private void()', expected public void()' Should PHPLint allow one to override clone with a private function? Or am I doing something wrong? Thanks for PHPLint! Mike.[more...] 2010-11-21 by Umberto Salsi Re: Null type Anonymous wrote: [...] 1. The type of a variable is the range of the allowed values that a variable can take. Now, that sayd, I do not understand what a variable of type null that can take only one value, NULL, can be useful for: it is just like a type named "two" that can take only 2 as a value. 2. Rejecting the "type juggling" model of PHP because it brings to subtle bugs and cannot be optimized by compilers, with PHPLint I chosen another type model similar to that of the major programming languages like C++, Java, C#. In these languages variables of complex type are actually pointers to dynamically allocated blocks of data (well, this isn't strctly true under C++). Pointers can also be NULL, that is "a pointer to nothing": having this NULL value available is an useful feature that comes at zero cost and may represent a variable still unassigned. Note that simple types like "int" and "float" can't be NULL under PHPLint because there isn't an effective way to implement such value in a[...][more...] 2010-11-15 by Guest Null type In my opinion, the way PHP treats null is actually in the correct direction: null is a type and not a value. Many stongly typed languages go this way: OCaml and Haskell to name some. Why have you chosen to change that?[more...] 2010-07-06 by Umberto Salsi Re: Simplexml Anonymous wrote: [...] The problem are the dynamically created properties, that are not supported by PHPLint (and never will be). Instead you can try to convert the$xml object into an array with $a = get_object_vars($xml); which returns a generic associative array of mixed values. This adds a little overhead due to unnecessary (for PHP) creation of another array that duplicates data that are already available in the $xml object. As an alternative, maybe more efficient, you may use the DOM module. In the following example the process_children(0 function completely traverses an XML document: /*. require_module 'spl'; require_module 'dom'; .*/ /*. void .*/ function process_children(/*. DOMNode .*/$root, $level = 0) {$children = $root->childNodes; foreach($children as $elem){$node = /*. (DOMNode) .*/ $elem; switch($node->nodeType){ case XML_ELEMENT_NODE: $node_element = /*. (DOMElement) .*/$elem; process_children($node_element,$level+1); break; case XML_TEXT_NODE: $node_text = /*. (D[...][more...] 2010-07-05 by Guest Simplexml Nice product! I have successfully run all my scripts through phplint, except for the following. I execute a web service, then process the output:$xml = simplexml_load_file(whatever); $answer =$xml->Result->Answer; That second line results in 2 messages: ERROR: property SimpleXMLElement::\$Result' does not exist or not visible Warning: ->' operator applied to a value of type unknown The script works fine, and I can certainly live with these messages if necessary. But if there is some way of supplying meta information, or even recoding the script, so that the messages aren't generated, that would be even better. Is there something that I can do?[more...]

2010-05-18 by Guest
Ignoring certain code
Hi, First, congratulations on PHPLint. I love static code checkers, they make the developer's life much easier! Is it possible (perhaps by means of specially formatted comments) to ignore certain parts of a document, for example for machine generated code or something like that? //G[more...]

2010-02-24 by Umberto Salsi
Re: parent classes
Anonymous wrote: [...] You may look at the "Importing packages" chapter of the reference manual where the recommended layout of the whole source program is explained. In few words, every class file should import all the classes it depends upon. Then in your case: require_once 'cParent.php'; class cChild extends cParent { ... }[more...]

2010-02-24 by Guest
parent classes
Hello, First at all: tnx a lot for PHPLint! I use PHPLint to analyze a large set of php classes. It's of great help when looking for potential bugs. I have a problem when PHPLint parses classes that make reference to their parents. For example for: class cChild extends cParent { public function __construct() { parent::__construct('mode'); } ... } PHPLint says: FATAL ERROR: invalid parent::': class cChild' do not has a parent [more...]

2010-01-04 by Umberto Salsi
Re: order of methods?
Anonymous wrote: [...] Currently already the WEB pages of PHPLint receive hundreds of distinct visitors every day, with several backlinks from other important WEB sites. So, as far as PHPLint is gaining more and more popularity, it is simple for any interested programmer to find this tool on The Net without difficulty either searcing for "PHP validation" or "PHP static analysis" or even "PHP documentor". [...] PHPLint is a single-pass parser (just like C and C++) for a two good reasons: 1) The program is much more simple tha than double-pass pass parser. Being PHPLint an experimental and rapidly evolving tool, this is an important advantage. 2) Sources written in the bottom-up order (simpler things first, the complex ones next) are easier to read by humans for code review. Recursive functions and methods are quite rare, so prototypes are ususlly not required and, even when required, PHPLint always checks for the consistency between the prototype and the actual declaration. The drawback[...][more...]

2010-01-01 by Guest
order of methods?
Dear Umberto, first off, thanks for writing such a great tool and releasing it to the PHP community. Btw, you really should add more meta tags to your site, your PHPLint site is not even found/ranked high when searching for "PHP Lint" on google (yep, "PHPLint" has you ranked #1). Anyway, I have a question. As far as I know and learned, your parser is a single-time parser, so basically, the following code would trigger an error that function "fun" is not found, because it is referenced in the code before it is defined. <?php fun(); function fun() { } ?> This behaviour results in many many PHPLint errors in my classes, because class method are called from other class methods which are defined "earlier" (e.g. a calls b, but b is defined before a). Now, I could reorder my whole libraries, but that's A LOT of work. And it does not solve the problem of recursion (a calls b, and b calls a). Yeah, I could introduce prototypes, but that's again a lot of work. More so, as when the signature of [...][more...]

2009-11-27 by Guest
phplint
Nice work! We used it to check our buggy PHP system. Once the analysis finished... lot of work! Thanks![more...]

2009-08-20 by Guest
Custom types
Hi! PHPLint is useful tool. But it supports only built-in data types: int, float, string and so on. Are you plan to add support for simple custom data types? Examples of custom types: enum, money, temperature, safe_string, unsafe_string. From interpretators point of view such data is built-in type data. But from programmers point of view such data should be treated separately and should not be mixed with other built-in data types. For example enum is set of integer values, but we should not add, substract or divide it. Money and temperature are both float, but we should not assign money to temperature. Safe_string and unsafe_string are both string, but we should not directly assign unsafe_string to safe_string. Best regards, Andrey Epifantsev[more...]

2009-07-14 by Umberto Salsi
Re: PHP Namespaces
PHPLint 0.9 is out, with full support for namespaces, namespaces in DocBlocks, experimental class autoloading feature, magic constants expansion, iterators in foreach() (thank to Jirka Grunt for the code and all the suggestions!), data-flow analysis, and several other improvements. Check the CHANGES page for details. [more...]

2009-06-28 by Umberto Salsi
Re: PHP Namespaces
Anonymous wrote: [...] Full support for namespaces, along with other additions specific of PHP 5.3.0, will be available, I hope, within the next 2 or 3 weeks. I can anticipate that namespaces as implemented under PHPLint will be case-insensitive as required by PHP 5.3.0 but, as usual, PHPLint will enforce the proper spelling of the path. The challanging part is the "namespace" keyword used as operator, the behaviour of the DocBlock with qualified names, and the formatting of the generated documentation, but I plan to resolve all these issues soon.[more...]

2009-06-27 by Guest
PHP Namespaces
Hi, Great tool, PHPLint. What I'm missing now is support for the PHP namespaces. PHPLint halts when it encounters the namespace keyword. And/or can I use a workaround in the form of a pseudo phplint-module that will mock the namespace keyword? Kind regards, Michael van de Ven [more...]