[aspectc-user] UINT_MAX and an Assertion Failure

[Gary Duzan]

In Message <3F324EB5.8040105 at pure-systems.com> ,
   Matthias Urban <matthias.urban at pure-systems.com> wrote:

=>Gary Duzan wrote:
=>> ===========================================================================
=>> /home/gduzan/work/ACE_wrappers/ace/Basic_Types.h:126: error,: unsupported int size, must be updated for this platform!
=>> ===========================================================================
=>> 
=>>    The Basic_Types code looks like this:
=>> 
=>> ===========================================================================
=>> // The number of bytes in an int.
=>> # if !defined (ACE_SIZEOF_INT)
=>> #   if (UINT_MAX) == 65535U
=>> #     define ACE_SIZEOF_INT 2
=>> #   elif (UINT_MAX) == 4294967295U
=>> #     define ACE_SIZEOF_INT 4
=>> #   elif (UINT_MAX) == 18446744073709551615U
=>> #     define ACE_SIZEOF_INT 8
=>> #   else
=>> #     error: unsupported int size, must be updated for this platform!
=>> #   endif /* UINT_MAX */
=>> # endif /* !defined (ACE_SIZEOF_INT) */
=>> ===========================================================================
=>> 
=>>    I tried setting UINT_MAX in the puma.config and on the command line
=>> with -D, but neither one changes the result.
=>
=>
=>This is a bug in the PUMA C preprocessor that uses strtol() instead of 
=>strtoul() for converting large decimal numbers. It will be fixed in the 
=>next release (0.7.1) of AspectC++ comming very soon.

   Ok. For now, is the #error directive stopping the parsing, or does it
continue on?

=>>    As for the assertion failure, I ran ac++ under gdb and got the
=>> following information:
=>> 
=>> ===========================================================================
=>> (gdb) frame 4
=>> #4  0x08072479 in ThisJoinPoint::setup (this=0x8a2dce8, func=0x84ce4e0)
=>>     at /home/gduzan/local/build/ac-sources-0.7/native/Puma/include/Puma/CObjectInfo.h:269
=>> 269      { return _Tree; }
=>> (gdb) print func->_Tree->NodeName()
=>> $1 = 0x81e4f03 "InitDeclarator"
=>> (gdb) print CT_FctDef::NodeId()
=>> $2 = 0x81e4e88 "FctDef"
=>> (gdb) 
=>> ===========================================================================
=>> 
=>>    If I leave out the "-p aspects" option (I've put *.ah in an aspects
=>> subdirectory) I still get the Basic_Types message, but it does manage
=>> to make it through all the translation units (weaving in nothing).
=>
=>
=>Sorry, but I can't reproduce this failure. It seems that there is a 
=>problematic advice declaration in your TestTrace4. I would need to take 
=>a look into the aspect declaration to find the reason.

   I commented out TestTrace3 and added:

===========================================================================
aspect TestTrace4 : public Trace {
  public:
        pointcut methods() = call ("% echo_%::%(...)");
};
===========================================================================

The only other change to my copy of the Trace code was to move the
mangle.h file and adjust the #includes accordingly.

					Gary Duzan
					BBN Technologies
					A Verizon Company