From: Takashi Iwai <tiwai@suse.de>
To: Lennart Poettering <mznyfn@0pointer.de>
Cc: alsa-devel@alsa-project.org
Subject: Re: Guide to Linux Sound APIs
Date: Fri, 26 Sep 2008 11:44:33 +0200 [thread overview]
Message-ID: <s5hfxnnckce.wl%tiwai@suse.de> (raw)
In-Reply-To: <20080925194028.GB26113@tango.0pointer.de>
At Thu, 25 Sep 2008 21:40:28 +0200,
Lennart Poettering wrote:
>
> On Thu, 25.09.08 12:15, Takashi Iwai (tiwai@suse.de) wrote:
>
> > Anyway, I'd like to mark async stuff as obsolete in a future version.
> > This is a broken design, and should rest in piece.
> > Meanwhile, I'm not in favor of adding deprecated link warning. A
> > compile warning is fine, but link warning is way too annoying. And
> > there are programs right now using async, we are responsible to keep
> > them running as they are.
>
> You are aware that the linking warnings are only shown during build-time --
> not during runtime when dynamic linking happens. So basically the
> difference between compiler and linker warnings are not that big. Link
> time warnings just appear a little bit later during build time than
> compile time warnings.
OK, then I must have misunderstood that. I thought I did see link
warning message some time ago, so the idea was stuck to my head.
> The big advantage of linker warnings is that you can add arbitrary
> warning strings when a symbol is used. Doing that with just the compiler is
> impossible to my knowledge.
>
> I.e. just define this:
>
> #ifdef __GNUC__
> #define WARN_REFERENCE(sym, msg) \
> __asm__(".section .gnu.warning." #sym); \
> __asm__(".asciz \"" msg "\""); \
> __asm__(".previous")
> #else
> #define WARN_REFERENCE(sym, msg)
> #endif
We have already a similar macro link_warning() in alsa-lib/include/local.h.
However, I still prefer deprecated warning at compile time, not at
link time. Regardless we like or not, we must keep supporting the old
API. In that sense, warning at compile time looks saner to me.
Takashi
prev parent reply other threads:[~2008-09-26 9:44 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-09-24 22:48 Guide to Linux Sound APIs Lennart Poettering
2008-09-24 23:05 ` Ben Finney
2008-09-25 0:17 ` Aaron J. Grier
2008-09-25 0:23 ` Lennart Poettering
2008-09-25 10:15 ` Takashi Iwai
2008-09-25 19:40 ` Lennart Poettering
2008-09-26 9:44 ` Takashi Iwai [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=s5hfxnnckce.wl%tiwai@suse.de \
--to=tiwai@suse.de \
--cc=alsa-devel@alsa-project.org \
--cc=mznyfn@0pointer.de \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.