This is the mail archive of the gcc@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: rfc: macros accepting constructors


On Fri, 28 Jun 2002, Aldy Hernandez wrote:

> well they should... especially since ansi says that library functions
> (ahem, printf, strlen, etc), can be implemented as macros.  they *should*
> behave like functions.

The standard warns users in footnote 156 that the macros may not contain
the sequence points that the functions do.  This is actually a more
serious issue for users since it makes it potentially unsafe to call
multiple functions from <math.h> in one expression in case more than one
modifies errno between sequence points.  You could submit a defect report
suggesting a footnote be added to warn users about the cases in which they
may need to add parentheses because an expression contains a comma.  But
the problem here is clearly with a user programming error failing to
include parentheses in arguments to what may be a macro - an error which
any competent user familiar with the language will immediately see the
cause of when they see the diagnostic - not a case where an extension
would make any improvement to the expressiveness of the language that
would make such an extension worthwhile.  (We shouldn't add any more cases
of default nonconformingness on valid code.  If you add a new syntax for
such macro definitions, you still need to define how such macros work in
the presence of braces and parentheses interwoven - {(}) etc. - issues
that cannot arise with just one type of grouping known to the preprocessor
- and ensure that there is zero performance cost for code not using that
extension.)

-- 
Joseph S. Myers
jsm28@cam.ac.uk


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]