code cleanliness bug

code cleanliness bug

[John Jannotti]

EGCS folks:
  I don't think that gcc/system.h should
  #define _(String) String

Perl folks:
  I don't think CORE/config.h should
  #ifdef CAN_PROTOTYPE
  #define	_(args) args
  #else
  #define	_(args) ()
  #endif


Generally, shouldn't leading underscores (and by extension, a single
underscore) be reserved for system macros?  I'm not just being
pedantic, I ran into a conflict when trying to embed perl in cpp (ok,
perhaps a sick thing to do, but it works now if anyone is interested).
Interestingly enough, although you are using _ for two completely
different things (egcs uses it in preparation for gettext), I got by
happily with the same definition for both purposes.

  jj


ps.  perl folks:  it also seems bad to prototype main() in
CORE/proto.h  It means that if I don't declare my main with an env
pointer (I generally don't), I get conflicts.  (In particular, in this 
case, gcc's cpp wasn't prototyped that way.)

Re: code cleanliness bug

[Tuomas Lukka]

> 
> EGCS folks:
>   I don't think that gcc/system.h should
>   #define _(String) String
> 
> Perl folks:
>   #define	_(args) args
> 
> 
> Interestingly enough, although you are using _ for two completely
> different things (egcs uses it in preparation for gettext), I got by
> happily with the same definition for both purposes.

You wouldn't if you lived in a non-English-speaking country, as then
you'd also have

	#define _(String) (gettext(String))

  Tuomas

Re: code cleanliness bug

[Martin von Loewis]

> Generally, shouldn't leading underscores (and by extension, a single
> underscore) be reserved for system macros?

Leading underscores are reserved only if followed by an uppercase
letter, or another underscore. So, technically they are not reserved,
and it is your fault that you try to mix these applications...

The GNU internationalization project suggests the _ macro to indicate
translateable strings. With more and more GNU software following this
convention, every other definition will go away: resistance is futile
:-)

Regards,
Martin