Home / Section index www.icosaedro.it

PHPLint - FAQ

Page updated: 2018-05-29

Contents

Where the PHPLint directory should be saved on my HD?

Once uncompressed, save the PHPLint package anywhere you want. I recommend to name that directory simply "phplint" so paths referring to it never change as the package gets updated later. If you plan to use PHPLint and its library along with your web server, save the PHPLint directory above the document root of the web server, as no PHPLint file needs public visibility. For example, once installed the WAMP Server under Windows under the C:\wamp directory, put the phplint directory just inside it.

How can I start the php and the phpl scripts from any terminal?

Under Linux: edit the file $HOME/.bash_profile and add this last line: export PATH=$PATH:/path/to/phplint
where /path/to/phplint is the path to the PHPLint directory; logout and login again to make this change effective.

Under Windows: edit the value of the user's environment variable named Path by adding this string to its very end:
;C:\path\to\phplint
where C:\path\to\phplint is the path to the PHPLint directory; the change will be effective for any new open terminal from now on.

How can I know which version of PHPLint I'm using right now?

Start the phpl program from the command line with the --version option. The GUI program phplint.tcl also displays the current version of PHPLint used after each parsing of a source. Under each PHPLint directory there is also a file named VERSION.txt you may inspect.

How can I know if a new release of PHPLint is available? How can I update?

Periodically check the download page and check the displayed version available. For example, 3.1_20180416 means: major version 3, minor version 1, release date 2018-04-16. It is safe to save your current PHPLint directory with some name, for example "phplint_OLD", then replace that directory with the new one. Typically you will need to copy these files from the old directory

phpl[.bat]
stdlib/php.ini
stdlib/errors.php

as these files should have been already customized by you during the installation process; and do not forget to copy also your custom files you may have added to the stdlib tree.
You may also consider to use CVS to keep in synch with the development version of PHPLint; the download page explains how to do that.

Issues validating my source code

Why hundredths of errors signaled in my otherwise perfectly working program?

It's normal, but “working” does not implies it's also safe, secure, fully documented and easy to understand and to maintain. As an experiment, try to consider each complain of PHPLint one by one, fix it, and once you program passes validation compare the resulting source code with the original one, then take your conclusions. The article Worth the effort shows an experience of porting an existing source code to PHPLint and contains useful suggestions.

Can I turn off some boring error PHPLint signals?

No. A program either passes validation or does not. There are only two exceptions to this rule: checking for control characters in literal strings, and checking for non-ASCII characters in literal strings; these exceptions to the rule above are still here because I still don't know how exactly handle these cases, but in general it's better to leave these checks on, especially while parsing library files .

Typical message:

        $f = fopen("mydata.txt", "rb"); \_ HERE ==== 3: ERROR: unresolved function fopen You must indicate which modules (that is, PHP extensions) your program depends on, as explained in the reference manual, chapter Importing modules. In this case you will need the core and the file modules: /*. require_module 'core'; require_module 'file'; .*/ Or, you may want to require the standard module which in turn requires most of the common functions typically available under PHP. Cannot include anything, PHPLint complains the path is relative! Typical message:  require_once "MyLib.php"; \_ HERE (Linux) ==== 4: ERROR: invalid file "MyLib.php": cannot resolve relative path: "MyLib.php" Hint: expected absolute path (PHPLint safety restriction). The magic constant __DIR__ gives the directory of the current source. (Windows) ==== 4: ERROR: invalid file "MyLib.php": missing drive or remote host in path: "MyLib.php" Hint: expected absolute path (PHPLint safety restriction). The magic constant __DIR__ gives the directory of the current source. PHP applies a quite articulated and hardly predictable heuristic to find included files with relative path, so as a safety measure PHPLint requires all paths be absolute. You may build an absolute path starting from the directory of the current file by using the __DIR__ constant, for example: require_once __DIR__ . "/MyLib.php"; PHPLint does not recognize my functions defined in the same file! PHPLint is a single-pass parser, so it needs to see the definition of a function first, then its invocation. This implies all the functions must be defined in bottom-up order: if function b() invokes function a() then you must define a() first and b() next. This also implies the "main" function, or the program body, must be located at the very end of the source, for example: <?php function a() { ... } function b() { a(); } function main() { a(); b(); } main(); The same holds for any other item: constants, variables, classes and class members. The general rule then is: definitions first, usage next. PHPLint does not recognize my functions defined in another file! Every PHP file must explicitly include any other file it depends on, and these files must be included using the require_once statement. Class autoloading is very handy and efficient: consider to use it instead, see Class autoloading. The other inclusion statements include, include_once and require are allowed, but these files are not parsed recursively by PHPLint; only files included with require_once are; these statements can be used to include chunks of HTML code, for example, or other PHP code that does not defines functions or classes or other items. I can't do anything with$_GET and $_POST values because are "mixed"! Those superglobal variables may contain several types of data not predictable by the program, so a value-typecast operator must be applied to get the expected type of value, for example: $n = (int) $_GET['n'];$name = (string) $_GET['name']; See the Tutorial for more. The standard library also contains utilities to acquire and sanitize untrusted data coming from the browser, see the Input class. For more specific types and data structures, consider using the magic cast() function. Cannot not use arrays: it keeps telling I'm mixing elements of different types! Under PHPLint arrays are intended to collect elements all of the same type; avoid arrays to store heterogeneous collections of data, use classed for that purpose. If you really need to build an array of mixed types, first declare an empty array of type mixed[] then add the elements one by one: $a = /*. (mixed[]) .*/ array();
$a[0] = 1234;$a[1] = "some string";

But again, avoid doing that because accessing those element will require a type-cast each time.

It complains “unhandled error E_WARNING” for EVERY single I/O function!

PHPLint does its best to ensure the programmer and the program he writes are fully aware of which errors could be generated and from where these errors could come from, so errors must be either handled locally or declared to be triggered by functions. Please read the Errors handling chapter of the reference manual for more. The standard library normally maps errors into ErrorException because exceptions are safer and simpler to handle.

Still stuck. What else can I do?

Try with this troubleshooting check-list:

• Double-check the error message; if the message is related to some file path, carefully check that path and check if it matches your expectation; evaluate each error and warning message from the very beginning of the report and in the order, one by one.
• Look at the Tutorial as it contains several practical use-case examples.
• Look at the Reference Manual for issues related to the language syntax, DocBlock syntax, PHPLint meta-code syntax, built-in functions usage, types and type-cast operators, importing of packages and modules, class auto-loading.
• Look for a similar usage example in the standard library under the stdlib/ directory.
• For problems related to the usage of some specific package of the standard library or some specific module, look for a similar usage example in the standard library and in the test code under the test/ directory.
• Create the smaller chunk of source code that reproduces the issue and try working on it alone; the PHPLint on-line tool comes handy for this purpose.


 Umberto Salsi Comments Contact Site map Home / Section index