Conference turris::c_plus_plus

Try using the DEC C++ -ieee switch (if you are not already using it).

>                                 -< Try -ieee >-
>
>Try using the DEC C++ -ieee switch (if you are not already using it).
> 

Using -ieee, the program seems to run. Thanks.

There are several cases in the original code, which pass compilation with g++,
but give an error when compiled using DEC C++. I would like to ask the author
to modify his code, however I would like to know first whether the syntax 
which causes the errors is not standard.

These are the types of errors DEC C++ prints:

1. cxx: Error: common.h, line 161: In this declaration, the parameter 
							"newseq" has 
	a default value in both this and a previous declaration of "Sequence".
	Sequence::Sequence(const char* newname,const char* newseq=""){
	-------------------------------------------------^

2. cxx: Error: synsite.h, line 44: In this declaration, "x" has no linkage 
								and has 
	a prior declaration in this scope at line number 36 in file synsite.h.
	            for (int x=0; x<4; x++)
	---------------------^

3. cxx: Warning: SynDiffClass.h, line 37: Non-void function 
	"SynDiffClass::Diff0" does not contain a return statement.
	double SynDiffClass::Diff0(){
	^

If you want to see the code, please read .0 for a pointer.

Thx,
Yossi.

The errors that you see that DEC C++ prints are incompatibilities
with g++, but are valid:

1.  It is illegal to redeclare a function with the same default parameter,
even if it has the same value.  In the C++ ANSI standard this is stated
in section 8.3.6 paragraph 4 (2 Dec 1996, and earlier).

2. For the statement "for(int x=0; x<4; x++)", the ARM specified that the
scope of x was in the block containing the for loop.  This has been changed
in the current language to put a block around the for statement.  The
DEC C++ compiler will fix the scope of the loop variable in V6.0.

3.  I couldn't find anywhere in the standard that says the compiler
should give a diagnostic for missing return statements, but many (most?)
do.  I think it would be good idea to have the author modify the code
since he's probably returning garbage from these functions (or make them
void).  If you want to disable certain messages you could add "#pragma
message disable missingreturn" in the sources.

Thanks for the feedback,
Coleen Phillimore
DEC C++ development

Summary of what we have done so far with this package:

- I was asked by an Alpha/UNIX customer to see why a package he has 
  copied from somebody in Japan, doesn't work on Alpha/UNIX.
- We got it from:
	ftp://may.genes.nig.ac.jp/pub/wina
- The package has been developed on a SUN system, using g++.
- Using some help, we managed to compile this package using 
  'cxx -ieee' on Alpha/UNIX,
  after performing some minor (syntactic) modifications to the code.
- I sent the modified code to the developer, and he could compile it on
  his SUN system, although he got some warning messages. These
  messages are in the file "mail.txt".
- When running on Alpha/UNIX 
  (
  The package is invoked using the following command:
        "./wina < test.aln"  
  )
  we get incorrect OUTPUT (the package generates a file called 'OUTPUT'.
  our, incorrect, output, is in "OUTPUT" and the original, correct
  output, is in "OUTPUT.org").
  
The three questions that we have:
- Why do we get different OUTPUT
- Why does g++ generate warnings on the customer's system, while DEC
  C++ doesn't issue any warning?
- Why can't we build the package using g++ on Alpha/UNIX

Where the files are:
- the original package is at:
	ftp://may.genes.nig.ac.jp/pub/wina
- the modified package, with a "README" file which explains what the files
  are (including correct and incorrect OUTPUT) are in the anonymous ftp
  directory of tavosf.iso.dec.com (16.190.64.193), under "pub", in the
  file "wina_new.tar.gz" 
  (ftp as anonymous to tavosf.iso.dec.com, 'cd pub', and 'get wina_new.tar.gz').

Please have a look if you like.

Thx,
Y.

1. - Why do we get different OUTPUT

Try compiling -O0: that gave me mostly the same output, varying
only in lines involving NaNs and INFs; but the rest of the line matched.
So this is a workaround.  
(I was using DEC CXX T5.6-003 on Digital UNIX (Alpha))

At higher optimization levels, the output varied starting at the first
line.  So, it looks like the potential for a bug, which I have entered
as bug number 4305.


2. - Why does g++ generate warnings on the customer's system, while DEC
  C++ doesn't issue any warning?
Here are the warnings I get from g++ on alpha:
In file included from wina.cc:13:
synsite.h:44: warning: name lookup of `x' changed for new ANSI `for' scoping
synsite.h:36: warning:   using obsolete binding at `x'
SynDiffClass.h: In method `void SynDiffClass::Diff1()':
In file included from wina.cc:14:
SynDiffClass.h:61: warning: name lookup of `X' changed for new ANSI `for' scoping
SynDiffClass.h:54: warning:   using obsolete binding at `X'
SynDiffClass.h: In method `int SynDiffClass::PrintAll() const':
SynDiffClass.h:237: warning: name lookup of `p1' changed for new ANSI `for'
scoping
SynDiffClass.h:230: warning:   using obsolete binding at `p1'
SynDiffClass.h: In method `void SynDiffClass::SynSiteTable()':
SynDiffClass.h:269: warning: name lookup of `X' changed for new ANSI `for'
scoping
SynDiffClass.h:258: warning:   using obsolete binding at `X'

(note, the file mail.txt does NOT contain the warning messages from
the user).

Most of these messages have to do with the new ANSI declaration scopes
of for statements.


3. - Why can't we build the package using g++ on Alpha/UNIX
I was able to build it, but it immediately core dumped with 
a floating point exception, trying to divide by zero.  This is
because g++ doesn't have a -ieee flag or mode (that I could find),
so with cxx -ieee, the generated code is different and the kernel
fixes up div by zero.  Without that special code in the g++ version,
the kernel does not do fixup, and instead you die immediately.


Mark Davis
c/c++ team

in common.h, Sequence::Sequence(...) has:

    seq=new char[SEQLEN+1];
    len=0;// *seq=0;
    AddSeq(newseq);
}

and AddSeq starts looking at *seq to see if it should append or start
immediately at *seq.

There is no guarantee that "new char[...]" will return a zeroed char array;
and in fact, it does not in this case!  That's the reason we get different
answers.

Note that the "fix", doing "*seq=0;" is already coded but COMMENTED OUT!

If you remove the "//", it works fine!


It took a day of debugging and experimenting to find the Programming error....


Other things that can be fixed:
1. There were 4 loops (identified in .5 with the g++ warnings)
that you had to modify because they looked like this:

	for (int X=...){}
	for (int X=...){}

and decc complained (according to the ARM), and you changed them to:

	for (int X=...){}
	for (X=...){}

which decc is happy with, but an ANSI Draft std compiler will complain
about (as g++ did).  A better way to write these is:

	int X;
	for (X=...){}
	for (X=...){}

which will work for all compilers.

2. The program uses both printf and c++ "<<" to produce outputs.

		printf(">%s x %s\n",List->Name(i),List->Name(j));
		for (int x=0; x<=List->MinLength()-WindowSize; x+=Shift)
		    List->DistNG(i,j,x,x+WindowSize-1);//calls printf
		cout <<"//\n";

Since both of these do their own buffering, they get interspersed 
differently.  Instead, one or the other approach should be used.
(Otherwise the output files look different :)

Mark Davis
c/c++ team

I saw Mark's reply, which looks correct. I thought that this looked like the
type of problem that can be uncovered bt ATOM third degree. See man atom(1),
third(5) on a Digital UNIX V4.0* system or see the web page on the Digital
Intranet at http://www.zk3.dec.com/dude/program_analysis/

Third Degree is a tool for detecting memory leaks, uses of uninitalized memory
locations, uses of invalid addresses, and wasted heap memory.

Here's how you can use Third Degree to help hunt down these types of problems:

  // Build the application non_shared, with debug symbols

  % cxx -ieee -non_shared -g   wina.cc -lm -o wina

  // ATOMize the resulting application, using third degree

  % atom wina -tool third

  { you can sometimes exclude system libraries using -excobj libcxx.so, etc. }

  % wina.third < test.aln > /dev/null


This generated a wina.3log file, which contains a clue to the problem that Mark
pointed out in -.1:

The clue is to look for the problem with this statement:

    while (*seq1 && p-seq < SEQLEN){


As Mark points out, *seq1 was never initialized.
With Mark's fix, third degree no longer reports this error.

---------------------------------------------------------------- rih -- 0 --

common.h~alt~deccxx_9E66EB0C: 180: 
reading invalid heap 4 bytes beyond 10001-byte block
    Sequence::AddSeq(const char*)
                                    wina, common.h~alt~deccxx_9E66EB0C, line 180
    Sequence::Sequence(const char*, const char*)
                                    wina, common.h~alt~deccxx_9E66EB0C, line 169
    SeqArray::AddSeq(const char*, const char*)
                                    wina, common.h~alt~deccxx_9E66EB0C, line 270
    SeqArray::ReadAln(istream&) wina, common.h~alt~deccxx_9E66EB0C, line 289
    run(istream&)                  wina, wina.cc, line 118
    main                           wina, wina.cc, line 151
    __start                        wina

This block at address 0x14002d7f0 was allocated at:
    operator new(unsigned long)    wina
    Sequence::Sequence(const char*, const char*)
                                    wina, common.h~alt~deccxx_9E66EB0C, line 167
    SeqArray::AddSeq(const char*, const char*)
                                    wina, common.h~alt~deccxx_9E66EB0C, line 270
    SeqArray::ReadAln(istream&) wina, common.h~alt~deccxx_9E66EB0C, line 289
    run(istream&)                  wina, wina.cc, line 118
    main                           wina, wina.cc, line 151
    __start                        wina