changed priority and severity

Changed host and compiler values above to All

OK, It juts dawned upon me that I've put some information about this bug into
#1824 which I'll promptly reproduce here.

The "meat" in that information is that all TAO releases up to and including TAO
1.5.4 is OK. In other words - the bug was introduced in TAO 1.5.5. The following
is a simple IDL file that shows how to reproduce the bug. Just compile it with
tao_idl with no options.


############### Sample IDL ##################
#ifndef _DEFINES_DEF_
#define _DEFINES_DEF_

#pragma prefix "omc.brutus"

module BRUTUS {

        typedef unsigned long BDEFINE;
	typedef BDEFINE PT_TYPE;

        const PT_TYPE BRUTUS_PT_LONG = 0x00000004;

        const BDEFINE BRUTUS_pidExchangeXmitReservedMin = 0x3FE0;

	const BDEFINE BRUTUS_PR_AUTO_RESPONSE_SUPPRESS = BRUTUS_PT_LONG |
((BRUTUS_pidExchangeXmitReservedMin - 0x01)<<16);
}; // End of module BRUTUS


#endif
####################### END ##########################

A mail from Doug seems to indicate that changes submitted to "idl.ll" by Chad
Elliott <elliott_c@ociweb.com> are responsible for this bug. These changes was
commented in ChangeLog-07a under the entry:

 Tue Nov 28 19:32:46 UTC 2006  Jeff Parsons <j.parsons@vanderbilt.edu>
 - Added patches to the lex file and to the corresponding
   generated C++ file that (1) corrects inconsistencies
   between these two files and (2) fixes problems with
   the SunCC preprocessor. Also patched the corresponding
   lex.yy.cpp.diff file. Thanks to Chad Elliott
   <elliott_c@ociweb.com> for supplying the patches.

They correspond to this changeset:

https://svn.dre.vanderbilt.edu/viewvc/Middleware/trunk/TAO/TAO_IDL/fe/idl.ll?r1=75647&r2=75650

HTH,
  jules

Chad, can you check this bugzilla report, it could be caused by some changes at
your side

I think it would be useful if I copy the content of another mail from Doug as it
explicitly points to the regular expressions that might be responsible for the
bug. Please forgive me for the whitespace disaster that bugzilla comments
continue to be :-(

################### Mail from Doug #######################
Hi Jeff,

According to SVN you made a bunch of changes to idl.ll last fall.  A
bunch of these changes affected the regular expressions with '-' in
them, e.g.:

parsons 2006-11-28 13:43:35 -0600 (Tue, 28 Nov 2006) ("-"[
\t]*)?(([0-9]+"."[0-9]*)|("."[0-9]+))([eE][+-]?[0-9]+)?[lLfF]?
parsons 2006-11-28 13:43:35 -0600 (Tue, 28 Nov 2006) ("-"[
\t]*)?[0-9]+[eE][+-]?[0-9]+[lLfF]?  {
parsons 2006-11-28 13:43:35 -0600 (Tue, 28 Nov 2006) "-"[ \t]*[1-9][0-9]* {
parsons 2006-11-28 13:43:35 -0600 (Tue, 28 Nov 2006) "-"[ \t]*0[xX][a-fA-F0-9]+ {
parsons 2006-11-28 13:43:35 -0600 (Tue, 28 Nov 2006) 0[xX][a-fA-F0-9]+ {
parsons 2006-11-28 13:43:35 -0600 (Tue, 28 Nov 2006) "-"[ \t]*0[0-7]* {

Can you please take a look at this stuff to see how that may have
affected the problems that Jules reported?

Thanks,

Doug

I can't think of a way to do this to where the initial problem doesn't come
back.  I will probably have to revert the change since it now seems kind of
strange that this should be an acceptable negative integer:  - 9.

I think the SunCC preprocessor is just wrong.

Mon Feb 26 14:44:07 UTC 2007  Chad Elliott  <elliott_c@ociweb.com>

        * TAO_IDL/fe/idl.ll:
        * TAO_IDL/fe/lex.yy.cpp:

          Reverted my change (committed by Jeff Parsons on my behalf) from
          Tue Nov 28 19:32:46 UTC 2006.  While it fixed an issues with the
          Sun preprocessor (e.g., negative numbers coming out like "- 9"),
          it causes problems with normal subtraction.  Thanks to Jules
          Colding <olding at omesc dot com> for reporting this.  This fixes
          bugzilla bug #2821.

Will check tomorrow.

Chad, I am reopening this because I think we need this in our regression test
suite. Can you take the test idl Jules added to 1824 and add it to idl_test? I
think then with a ifdef you can disable this idl file for the suncc
preprocessors that are broken to handle this correctly. Can you report the
preprocessor problem to sun?

I added the following lines to constants.idl in my workspace:

// const values created through mathematic operations
const long neg = -8;
const long sub1 = 0x10 - 0x01;
const long sub2 = 0x10 + (-0x01);
const unsigned long add1 = 16 + 1;
const unsigned long mul1 = 0x80 * 0x70;
const unsigned long div1 = 99 / 12;

And with CC: Sun C++ 5.8 Patch 121017-08 2006/12/06, this caused no problems at
all.  I'm going to check it in as is and see which Sun compilers have the problem.

Chad, check the Solaris10_Studio11_Debug build on the scoreboard, this now gives
an error after the revert. Maybe change the example that gives the error to not
use negative numbers and move the idl that gives a problem also to the idl-test
and ifdef it out for the broken sun preprocessor

Chad, can you disable the broken example code just for the 5.8 version of
sunc++? That is the only version that we know is broken. You can report issues
to sun online at http://bugs.sun.com/services/bugreport/index.jsp

Actually, I was able to test SunCC 5.0 through SunCC 5.8 and all of the
preprocessor output looked the same.

it looks the same but the difference between a tab or a space is not real
visible from a plain editor. For example the studio 10 build on the scoreboard
which uses CC: Sun C++ 5.7 Patch 117831-08 2006/07/12 doesn't show the error in
the example, only the 5.8 compiler. Can you disable the code just for 5.8 and
then check the scoreboard tomorrow again?

The type of whitespace is irrelevant.  They are treated exactly the same by the
lexer.  As far as the versions, I just tested processing the union.idl (with the
SunCC guard commented out) with the following versions of SunCC.

CC: Sun C++ 5.8 Patch 121017-08 2006/12/06
CC: Sun C++ 5.7 Patch 117830-09 2006/11/01
CC: Sun C++ 5.6 2004/07/15
CC: Sun C++ 5.5 2003/03/12                
CC: Forte Developer 7 C++ 5.4 2002/03/09
CC: Sun WorkShop 6 update 2 C++ 5.3 2001/05/15
CC: Sun WorkShop 6 update 1 C++ 5.2 Patch 109508-03 2001/04/07
CC: Sun WorkShop 6 2000/08/30 C++ 5.1 Patch 109490-01

They all give the same results.

The Solaris10-x86-Studio10 build on corona has the following in the config.h:

#define TAO_IDL_PREPROCESSOR "cc"

This would explain why it doesn't have the problem.

I've just tried to test this today. svn HEAD (or whatever it is called in
subversion) failed to compile on Windows 2003 with VC++ 8:

MCAST_Parser.cpp
.\MCAST_Parser.cpp(61) : error C2146: syntax error : missing ')' before
identifier 'ACE_ENV_ARG_PARAMETER'
.\MCAST_Parser.cpp(61) : error C2059: syntax error : ')'

head is broken at this moment, see http://remedy.nl, can always happen, we are
waiting for Ossama, he broke it but he is probably not online yet

I believe that the bug is not in the SunCC preprocessor, but the tao_idl parser
or related code.  According to the IDL grammar, the following idl should be legal:

union foo switch (short)
{
  case 10 >> 1: string foo_str_member;
  case +1: long foof;
}; 

However, neither case label is accepted.  I think that if these are fixed, the
"case - 1:" problem would come along for the ride.

OK, I can confirm that all of my IDL files now compiles with tao_idl. 

in TAO 1.5.7....

Closing