Re: __attribute__ ((deprecated))

Re: __attribute__ ((deprecated))

[Anthony Green]

Stan wrote:
> 3. If yes, what are the implementation caveats to watch out for?
>    (needs to work for all of C/ObjC/C++)

This looks cool, but how would this work with localized compilers?

> 	extern int worse_fn (char)
> 	  __attribute__ ((deprecated "use new_good_fn instead"));
> 
> to get
> 
> 	warning: worse_fn is deprecated; use new_good_fn instead

We would need some scheme for localizing these messages, or just put
up with mixed language compiler warnings.

AG

Re: __attribute__ ((deprecated))

[Philipp Thomas]

* Anthony Green (green@redhat.com) [20010424 06:05]:

> This looks cool, but how would this work with localized compilers?

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.

The only problem would be the linker message, as the linker would only
output the english message. But IMO we could live with that, coudn't we?

Philipp

-- 
Penguins shall save the dinosaurs
                          -- Handelsblatt about Linux on S/390

RE: __attribute__ ((deprecated))

[Anthony Green]

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.

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

AG

Re: __attribute__ ((deprecated))

[Tom Tromey]

>>>>> "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

Re: __attribute__ ((deprecated))

[Tim Hollebeek]

On Tue, Apr 24, 2001 at 11:47:26AM -0600, Tom Tromey wrote:
> >>>>> "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?

I'd rather not see useful functionality be lost because of an i18n
problem.  Some functions are deprecated because they are out of date;
others are deprecated because they have severe security implications.
There should be a mechanism to convey this information to the user,
even if it has to be in English.

RE: __attribute__ ((deprecated))

[Anthony Green]

Tim wrote:
> There should be a mechanism to convey this information to the user,
> even if it has to be in English.

...assuming the authors of the libraries are writing in English.

Why not just have the warning refer to the source of the annotated
declaration?

AG

Re: __attribute__ ((deprecated))

[Stan Shebs]

Anthony Green wrote:
> 
> Tim wrote:
> > There should be a mechanism to convey this information to the user,
> > even if it has to be in English.
> 
> ...assuming the authors of the libraries are writing in English.
> 
> Why not just have the warning refer to the source of the annotated
> declaration?

I like that idea - it's easier to be expansive on the details of a
situation in a comment block in the header, plus then we don't
have to dink around with storing the warning string in trees.

Stan

Re: __attribute__ ((deprecated))

[Stan Shebs]

Tom Tromey wrote:
> 
> 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?

They would want to be able to mention releases, dates or packages
"only available if QuickTime 53.89 not installed" :-) or there
might be two functions that the developer would have to choose
between.

The situation is actually similar to #warning, which Apple uses
now to warn people about header changes, but which has no way
to be localized.

So the i18n aspect is mildly interesting, but I don't think anybody
will really worry about that until after we translate all the docs
for our 20,000 function API into a language other than English...

Stan

Re: __attribute__ ((deprecated))

[Philipp Thomas]

* Anthony Green (green@redhat.com) [20010424 19:20]:

> > (which would mark it as translatable string and thus it would appear in
> > gcc.pot) and have the compiler call gettext.
> 
> Are you sure?  I guess I don't understand GCC's i18n support.  Stan's
> proposal has part of the message in the user's source code.  How would that
> ever end up in gcc.pot?

Forget it. I wrote that much too late for me and didn't think straight. Of
course this is user code so it would always be in the language it was
written in.

Philipp

-- 
Penguins shall save the dinosaurs
                          -- Handelsblatt about Linux on S/390

Re: __attribute__ ((deprecated))

[Philipp Thomas]

* Anthony Green (green@redhat.com) [20010424 19:20]:

> > (which would mark it as translatable string and thus it would appear in
> > gcc.pot) and have the compiler call gettext.
> 
> Are you sure?  I guess I don't understand GCC's i18n support.  Stan's
> proposal has part of the message in the user's source code.  How would that
> ever end up in gcc.pot?

Forget it. I wrote that much too late for me and didn't think straight. Of
course this is user code so it would always be in the language it was
written in.

Philipp

-- 
Penguins shall save the dinosaurs
                          -- Handelsblatt about Linux on S/390

Re: __attribute__ ((deprecated))

[Joern Rennecke]

> > Are you sure?  I guess I don't understand GCC's i18n support.  Stan's
> > proposal has part of the message in the user's source code.  How would that
> > ever end up in gcc.pot?
> 
> Forget it. I wrote that much too late for me and didn't think straight. Of
> course this is user code so it would always be in the language it was
> written in.

No, it is library code.  The provider of the library might speak a different
labguage than the user.
So it does make sense to provide a few standard phrases with translations,
and recommend to use one of these to get internationalized warnings.

__attribute__ ((deprecated))

[Stan Shebs]

Now that Mac OS X has had its first release, the library people are
already thinking of ways to change the API for the next release
(hopefully for the better, but I won't editorialize further. :-) )
To help out developers, they've asked that the compiler support some
way to warn people that a particular function or variable may
go away or be changed at some point.

The obvious thing would be to add a new attribute, so that a header
could have something like

	extern int old_bad_fn (int) __attribute__ ((deprecated));

then any calls or references to old_bad_fn would get something like

	warning: old_bad_fn is deprecated

As an enhancement, the library folks would also like to be able
to add a more specific message:

	extern int worse_fn (char)
	  __attribute__ ((deprecated "use new_good_fn instead"));

to get

	warning: worse_fn is deprecated; use new_good_fn instead

Before we jump into implementing this, we'd like to get some input.

1. Does this seem like a worthwhile feature to add?
2. If no, what would be an equivalent alternative?
3. If yes, what are the implementation caveats to watch out for?
   (needs to work for all of C/ObjC/C++)

Thanks for any and all advice!

Stan

Re: __attribute__ ((deprecated))

[Geoff Keating]

Stan Shebs <shebs@apple.com> writes:

> 	warning: worse_fn is deprecated; use new_good_fn instead
> 
> Before we jump into implementing this, we'd like to get some input.
> 
> 1. Does this seem like a worthwhile feature to add?
> 2. If no, what would be an equivalent alternative?
> 3. If yes, what are the implementation caveats to watch out for?
>    (needs to work for all of C/ObjC/C++)

It seems worthwhile.  The ELF people have never needed it because the
ELF linker can warn when a particular function is used, but it strikes
me that you could integrate the two features and have the new attribute
put the right things in the object file to trigger the linker warning,
as well as warning at source level.

-- 
- Geoffrey Keating <geoffk@geoffk.org>

Re: __attribute__ ((deprecated))

[Marcus G. Daniels]

SS> The obvious thing would be to add a new attribute, so that a header
SS> could have something like

SS>	extern int old_bad_fn (int) __attribute__ ((deprecated));

Sounds good, but how the heck do you get the Objective C parser to
accept __attribute__ for methods?

Re: __attribute__ ((deprecated))

[Stan Shebs]

"Marcus G. Daniels" wrote:
> 
> SS> The obvious thing would be to add a new attribute, so that a header
> SS> could have something like
> 
> SS>     extern int old_bad_fn (int) __attribute__ ((deprecated));
> 
> Sounds good, but how the heck do you get the Objective C parser to
> accept __attribute__ for methods?

By modifying it, presumably. :-)  The immediate request is for the
Carbon API I believe, which is C-based, but yeah, if we make it
available for Carbon, the Cocoa folks will probably get envious and
want it for their framework too.  Thanks for the observation, I'll
take a look at the ObjC parser and see what it would take.

Stan

Re: __attribute__ ((deprecated))

[Joseph S. Myers]

On Tue, 24 Apr 2001, Stan Shebs wrote:

> > Sounds good, but how the heck do you get the Objective C parser to
> > accept __attribute__ for methods?
> 
> By modifying it, presumably. :-)  The immediate request is for the
> Carbon API I believe, which is C-based, but yeah, if we make it
> available for Carbon, the Cocoa folks will probably get envious and
> want it for their framework too.  Thanks for the observation, I'll
> take a look at the ObjC parser and see what it would take.

You might want to look first at what's needed to get rid of the
shift/reduce conflicts in the ObjC parser, since anything touching
attributes has tended to be very fragile in terms of adding more conflicts
(and so in terms of being able to be reasonably sure that the change does
not cause incorrect parsing in some cases).  (Once I've checked in my C
parser patch, that is - which will be once I can get a working bootstrap
of unmodified mainline in a reasonable time (the current problem being the
libjava tests hanging that's just been noted).)

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