From: "John W. Eaton" <jwe@bevo.che.wisc.edu>
Cc: guile-user@gnu.org, Neil Jerram <neil@ossau.uklinux.net>
Subject: Re: deprecated symbol warnings
Date: Sat, 14 May 2005 23:17:04 -0400 [thread overview]
Message-ID: <17030.48944.683011.894315@devzero.bogus.domain> (raw)
In-Reply-To: <28ae757805033aac63a3f7bf8f4b1ccd@raeburn.org>
On 14-May-2005, Ken Raeburn wrote:
| >> /* N.B.: Application code will sometimes test whether one of these
| >> macros is defined, to figure out if the version of Guile in use
| >> predates the creation of the macro. So at deprecation time, we
| >> still want the macro to be visible. ANSI C says "#define foo foo"
| >> is okay, but if we get complaints about it, try switching the
| >> non-macro name to "foo_" or "foo_deprecated" or something; make it
| >> a simple concatenation so that we can make the other macros
| >> continue to be simple. */
| >
| > I think we should assume in advance that we'll hit trouble with this
| > on some platforms. Otherwise it's just another hiccup to push people
| > away from trying Guile out.
|
| *sigh* I was afraid of that. So when do we start requiring "real"
| ANSI C support? :-(
Can you point to a widely used compiler that will actually have
trouble with this? If not, then maybe it is not worth worrying about?
| Doing this means the compile-time messages will give the wrong symbol
| names. They'll be close to the names used by the application, but not
| the same. Still, getting messages that are close is probably better
| than explaining to people why this strange use of the preprocessor is
| actually valid and it's their compiler that's broken. I wonder if it's
| really a problem these days, though, a decade and a half after the spec
| was published....
Having the messages use the wrong names might cause a lot more
confusion than having to explain to people that their compiler is
broken.
jwe
--
jwe at octave dot org | Peace would shock and awe me.
_______________________________________________
Guile-user mailing list
Guile-user@gnu.org
http://lists.gnu.org/mailman/listinfo/guile-user
next prev parent reply other threads:[~2005-05-15 3:17 UTC|newest]
Thread overview: 24+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <E1CmxC0-0003DB-Gx@sc8-sf-web1.sourceforge.net>
2005-01-07 17:31 ` SCM_LENGTH ??? Bruce Korb
2005-01-07 18:07 ` Marius Vollmer
2005-01-07 18:27 ` Bruce Korb
2005-01-10 17:26 ` Marius Vollmer
2005-01-10 18:03 ` Bruce Korb
2005-01-10 20:59 ` Greg Troxel
2005-01-11 18:08 ` Marius Vollmer
2005-01-11 23:40 ` Kevin Ryde
2005-01-12 10:33 ` Marius Vollmer
2005-01-10 20:34 ` Ken Raeburn
2005-01-11 16:12 ` Bruce Korb
2005-01-11 18:32 ` Marius Vollmer
2005-05-14 2:52 ` deprecated symbol warnings Ken Raeburn
2005-05-14 12:40 ` Neil Jerram
2005-05-14 18:48 ` Ken Raeburn
2005-05-15 3:17 ` John W. Eaton [this message]
2005-05-15 10:19 ` Neil Jerram
2005-05-16 5:52 ` Ken Raeburn
2005-05-18 4:22 ` tomas
2005-05-18 12:20 ` Ludovic Courtès
2005-05-18 17:17 ` automated testing (was Re: deprecated symbol warnings) Ken Raeburn
2005-05-26 18:58 ` deprecated symbol warnings Neil Jerram
2005-05-28 21:55 ` Ken Raeburn
2005-05-18 19:18 ` deprecated symbol warnings and Windows Ken Raeburn
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
List information: https://www.gnu.org/software/guile/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=17030.48944.683011.894315@devzero.bogus.domain \
--to=jwe@bevo.che.wisc.edu \
--cc=guile-user@gnu.org \
--cc=neil@ossau.uklinux.net \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).