[wave] Error when parsing files from ACE (Adaptive Communication Environment)
Hi. I use the ACE library (http://www.cs.wustl.edu/~schmidt/ACE.html) which is known for being highly portable. When using wave to pre-process my code, which includes files from the ACE lib, wave fails on the following code snippet: -------------snippet------------------- // The number of bytes in a short. # if !defined (ACE_SIZEOF_SHORT) # if (USHRT_MAX) == 255U # define ACE_SIZEOF_SHORT 1 # elif (USHRT_MAX) == 65535U # define ACE_SIZEOF_SHORT 2 # elif (USHRT_MAX) == 4294967295U # define ACE_SIZEOF_SHORT 4 # elif (USHRT_MAX) == 18446744073709551615U <===[fails here] # define ACE_SIZEOF_SHORT 8 # else # error: unsupported short size, must be updated for this platform! # endif /* USHRT_MAX */ # endif /* !defined (ACE_SIZEOF_SHORT) */ -------------end snippet------------------- Note: USHRT_MAX is defined as 0xffff The failure occurs at the designated line, due to an ill-formed number. I suppose that the number is just too big, but shouldn't the comparison never even be "reached"? (since the previous elif would have been true) I am not too familiar with the standard, so I don't know if emitting an error for this case is correct, but my intuition is that even if this is not standard conforming, there should at least be a flag allowing this, since I assume (if it is used in such a highly portable library) that it _IS_ supported by most preprocessors out there. Apart from that, great lib! I just started using it, but I already love it. Yariv Tal.
Yariv Tal wrote:
I use the ACE library (http://www.cs.wustl.edu/~schmidt/ACE.html) which is known for being highly portable. When using wave to pre-process my code, which includes files from the ACE lib, wave fails on the following code snippet: -------------snippet------------------- // The number of bytes in a short. # if !defined (ACE_SIZEOF_SHORT) # if (USHRT_MAX) == 255U # define ACE_SIZEOF_SHORT 1 # elif (USHRT_MAX) == 65535U # define ACE_SIZEOF_SHORT 2 # elif (USHRT_MAX) == 4294967295U # define ACE_SIZEOF_SHORT 4 # elif (USHRT_MAX) == 18446744073709551615U <===[fails here] # define ACE_SIZEOF_SHORT 8 # else # error: unsupported short size, must be updated for this platform! # endif /* USHRT_MAX */ # endif /* !defined (ACE_SIZEOF_SHORT) */ -------------end snippet------------------- Note: USHRT_MAX is defined as 0xffff
The failure occurs at the designated line, due to an ill-formed number. I suppose that the number is just too big, but shouldn't the comparison never even be "reached"? (since the previous elif would have been true)
That's fixed now (CVS::HEAD and CVS::RELEASE_1_33_0). Thanks for reporting.
I am not too familiar with the standard, so I don't know if emitting an error for this case is correct, but my intuition is that even if this is not standard conforming, there should at least be a flag allowing this, since I assume (if it is used in such a highly portable library) that it _IS_ supported by most preprocessors out there.
The Standard is not very specific about how to handle these situations. It's merely 'implementation defined'... But guessing from what gcc does, it's the correct way to ignore range errors in 'passive' #if/#elif expressions.
Apart from that, great lib! I just started using it, but I already love it.
Thanks! Regards Hartmut
participants (2)
-
Hartmut Kaiser -
Yariv Tal