Re: C++ ansi/pedantic problem

[Darin Adler <darin bentspoon com>]

I think that the change Karl suggests is fine.

But there's a part of the discussion that's off track.

>> The only way to get the (...) meaning is to write a declarator with (...).

Karl Nelson wrote:
> Not with the GNU C compiler.  () means (...) when in an extern "C"
> statement when ansi compience is on.  To my knowledge and the
> documentation of the compiler this is completely correct behavior.

This is a non-standard GNU behavior that does not match the standard and
other compilers. As you say, it's intentional on the part of the GNU
implementers and it's described in the GNU C compiler documentation.

Using extern "C" is not supposed to change language rules in this way,
although someone working on GNU C thought it would be useful for easier
reuse of C headers; an interesting alternate design, but not standard C++.

That's why -ansi is causing the problem. Because the GNU C implementers
added a non-standard extension to 'extern "C"' which is turned off by the
-ansi switch (or maybe it's the -pedantic switch).

Karl's solution works:

  #ifdef __cplusplus
  typedef void (*GtkSignalFunc) (void);
  #else
  typedef void (*GtkSignalFunc) ();
  #endif

A slightly better solution would be:

  #ifdef __cplusplus
  typedef void (*GtkSignalFunc) (...);
  #else
  typedef void (*GtkSignalFunc) ();
  #endif

In this case, the GtkSignalFunc type would correctly have an unknown number
of parameters. The point is moot for C++ code, though. You'll almost always
have to cast anyway.

C does not allow a "..." as the only item in a parameter list, although C++
does. If C did allow "..." you could get rid of the ifdef and just use:

  typedef void (*GtkSignalFunc) (...);

    -- Darin