Hi Michael,
Hi Bernhard,
I am not really sure in what way this is related to this Core Update. I guess it is not.
You are right. I was just thinking about a post to the mailing list, when your annoucement about the new test release arrived. Because of the relation to testing, I posted my proposal in this thread.
On Thu, 2015-06-11 at 15:55 +0200, Bernhard Bitsch wrote:
Hi,
a thread in the forum showed up a little issue in our tests.
Which one?
https://forum.ipfire.org/viewtopic.php?f=22&t=13965&p=86585#p86576 When looking at the code of this web page, I found errors ( the standard language files are not used, "undefined" vars ) which are reported by switching on the debug output.
Some parts, don't know how many, just have a status of "untouched for a long time".
Indeed, we won't touch the web user interface in order to clean up the code if we do not need to. It has been a nightmare from the very beginning since we forked the project. We never invested much into cleaning up the code because there will be a complete rewrite of the entire thing.
Nevertheless there are possible errors or "issues" in this code.
That does not mean that we don't fix bugs though.
This is mainly true for Perl scripts in the WUI.
Yes. Some other things have been replaced over time. The most recent example is the setddns.pl script that was replaced by ddns.
If we don't know the errors, they can't be fixed. My proposal reports those deficiencies. Even whilst testing phase this should be done.
I would be a big effort to check all this files. But some issues will come in sight, if at least during test period these files contain the lines
use strict; use warnings; use CGI::Carp 'fatalsToBrowser';
Perl does tolerate so much dirty coding. In such cases it isn't sure whether the intentions of the programmer meet the interpretation of the interpreter. These three lines force a check and log possible errors to the WUI.
I am not really sure what you are saying here. If you want to clean up the code that would be helpful. Eventually we will have to update our version of perl and we know that huge chunks of the web user interface code are incompatible to that. I have never done any actual testing if it works but we have many features in the code that have been removed. There is for example the smart match operator.
A new version of Perl doesn't really help. The Perl interpreter is built around compatibility to older versions and coding styles. To achieve this assumptions about the semantics of the "dirty code" are made. These must not meet the intention of the programmer of the original code.
I fear, without these statements a couple of faulty test cases are reported as error-free.
Of course we cannot ship code that will show error messages to the user.
This is an old discussion in software development: "Should the released code contain checks for correctness ( 'assert' in C, 'use strict' in Perl, ...)?" My (personal) answer: Yes! Because these errors shouldn't show up in the shipped product, but the conditions proven are essential for a effective functioning.
Those changes should be also very small so that they can be easily reviewed and should not cause too much damage. It is just essential to keep the development process tidy to not create an even bigger mess.
In first application the addition proposed is small ( 3 lines per cgi file) and doesn't change processing of programs without "issues". The corrections for errors shown may be of a greater extent. But they are necessary, thus the effort is legitimate.
Bernhard