On Mon, 14 Apr 2008, Sven Schreiber wrote:
Hi,
we stumbled over a nasty genr command bug recently that screwed up the
results and almost went unnoticed.
We have a genr command line which is very long due to the 100 involved
variables and their originally longish names. The result series is completely
bogus as we now know. The command length was about 4400 bytes (more or less,
maybe line endings in some aux editor program were counted or not). When the
variables names are shortened such that the line length drops to about 2400
bytes, everything is ok.
The max. admissible line length should have been increased in gretl 1.7.0 due
to the changelog, but we observed this with more recent versions. (on
windows; one could have been 1.7.1, the other the most recent 1.7.4 or 1.7.3
I think.) What's worse, there wasn't any error message.
Of course I can provide a test case if needed, but just not right now :-)
In principle, this is a bug; as such, it needs to be fixed.
However, let me point out that 4400 bytes as a command line is *insane* by
any coding standard. If the worst comes to the worst, use functions and
lists for such things. I'm unable to imagine a real-world case when a genr
line cannot be tidied up decently (of course, it may be my limited
imagination).
The fix I'd propose would be: when a command line exceeds n bytes, just
stop execution and issue an error message, possibly complete with creative
expletives. :-)
Riccardo (Jack) Lucchetti
Dipartimento di Economia
Università Politecnica delle Marche
r.lucchetti(a)univpm.it
http://www.econ.univpm.it/lucchetti