From mboxrd@z Thu Jan  1 00:00:00 1970
From: Tom Tromey <tromey@redhat.com>
To: <green@redhat.com>
Cc: "Philipp Thomas" <pthomas@suse.de>, <shebs@apple.com>, <gcc@gcc.gnu.org>
Subject: Re: __attribute__ ((deprecated))
Date: Tue, 24 Apr 2001 10:38:00 -0000
Message-id: <87g0ey8a1d.fsf@creche.redhat.com>
References: <NEBBKJDPKLNNENPPIHCPKEIMLBAA.green@redhat.com>
X-SW-Source: 2001-04/msg01124.html

>>>>> "Anthony" == Anthony Green <green@redhat.com> writes:

>> Philipp wrote:
>> With the compiler it wouldn't be such a problem. Mark the message
>> with N_()
>> (which would mark it as translatable string and thus it would appear in
>> gcc.pot) and have the compiler call gettext.

Anthony> Are you sure?  I guess I don't understand GCC's i18n support.
Anthony> Stan's proposal has part of the message in the user's source
Anthony> code.  How would that ever end up in gcc.pot?

I don't see how it could.

Note that we already have this problem in gcj, because like other Java
compilers gcj will recognize `@deprecated' in javadoc comments and
print a message -- which might include user text.

For C and C++, is arbitrary text really needed?  What if we allowed:

    int foo (int) __attribute__ ((deprecated "bar(int)"));

... and then used `printf ("%s is deprecated; use `%s' instead")

This would solve the i18n problem at the loss of some generality.  Is
the generality really a requirement?

Tom