#687 PRINT interprets FORMAT incorrectly

[Igor]

GDL 0.9.6 stable from source
OS: CentOS 6.4

Expected:

GDL> print, 1, format='(I2.2)'
01
GDL> print, 1, format='(F6.2)'
  1.00

Get:

GDL> print, 1, format='(I2.2)'
*
GDL> print, 1, format='(F6.2)'
1.00

[giloo]

On mandriva (= ubuntu) 64 bits I get:

IDL> print, 1, format='(I2.2)'
01
IDL> print, 1, format='(F6.2)'
  1.00

and

GDL> print, 1, format='(I2.2)'
01
GDL> print, 1, format='(F6.2)'
  1.00

is that a 32 bits machine?

[Igor]

Hmm, strange.
That's a 64 bits machine:

Linux localhost 2.6.32-358.0.1.el6.x86_64 #1 SMP Wed Feb 27 06:06:45 UTC 2013 x86_64 x86_64 x86_64 GNU/Linux

And GDL 0.9.3 and 0.9.5 work as intended.
What should I check out?

[giloo]

Well, no clue on my side...
The test_formats.pro file compares various formats with the idl template, just to see the extent of the disaster...

[Igor]

Thanks! Comparison results are not very good - formats.gdl and formats.idl are attached...

[giloo]

Indeed. Aside numerous whitespace difference (and a spurious ^J between real and imaginary parts)(this probably passes unseeen) the problem is in the blank-leaded formats '(O6)','(B6)' etc where the requested 6 digit is not respected. Code uses standard C++ std:: formatting and works with my gcc 4.9.2. Would that be a C++11 feature of a newer gcc version?

[Ole Streicher]

For Debian, we compile with gcc-5.3.1 and are not affected by this bug; also test_formats is "Passed". gcc-6 does not compile for another reason. My personal CI test compilation is with 4.8.4, BTW. Therefore, it is probably not the compiler version.

[Igor]

I've got gcc 4.4.7. It's pretty old, yes. Should I update it?

[Igor]

OK, I've updated to gcc 4.9.3 and now gdl 0.9.6 prints correctly. Thanks guys! Problem is solved! :)

BTW, gcc 4.7.2 does not solve this issue but makes it even worse.

[Orion Poplawski]

I'm seeing different but still wrong behavior with 0.9.6 and gcc 4.4.7 on stock EL6. I see lots of whitespace output before the number. Was fine with 0.9.5.

[Orion Poplawski]

valgrind is reporting some "Conditional jump or move depends on uninitialised value(s)" errors.

[Orion Poplawski]

So it looks like "w" may be uninitialized. It's "set" here:

#1  0x00000000005495c7 in FMTOut::f (this=0x7fffffffc9e0, _t=...)
    at /usr/src/debug/gdl-0.9.6/src/FMTOut.cpp:328
328                     BaseGDL::DEC);
(gdb) list
323                     int w = i->getW();
324                     int d = i->getD();
325                     int f = i->getFill();
326                     do {
327                     SizeT tCount = actPar->OFmtI( os, valIx, r, w, d, f,
328                     BaseGDL::DEC);

Is that always a valid property? Then in OFmtI():

OFmtI( ostream* os, SizeT offs, SizeT r, int w, int d, char f,
       BaseGDL::IOMode oMode)
{
  if( w < 0) w = (oMode == BIN ? 32 : 12);

In a debug session, I see:

(gdb) print w
$1 = 14586650

[giloo]

pretty strange... 'w' is part of the FMTNode class, is initialised in the constructor to -1 (in fmtnode.hpp). So I see no way it could not be initialized?
BTW valgrind on my GDL version (64 bits, gcc 4.9.2) does not see any errors (and formats correctly).

[Sylwester Arabas]

Closing as resolved, valgrind issues will pop up automatically after enabling valgrind test runs on Travis