public inbox for libc-alpha@sourceware.org
 help / color / mirror / Atom feed
From: Rafal Luzynski <digitalfreak@lingonborough.com>
To: libc-alpha@sourceware.org, Paul Eggert <eggert@cs.ucla.edu>
Subject: Re: [RFC][PATCH v2 3/6] Implement the %OB specifier - alternative month names (bug 10871)
Date: Wed, 01 Jun 2016 23:54:00 -0000	[thread overview]
Message-ID: <480412909.686000.92369107-bdae-4a8b-b71f-99b919bc0cf0.open-xchange@poczta.nazwa.pl> (raw)
In-Reply-To: <37aa7442-e282-a3bd-a7ce-6e06aed9172a@cs.ucla.edu>

2.06.2016 00:20 Paul Eggert <eggert@cs.ucla.edu> wrote:
>
> [...] However, if
> glibc uses the old behavior when the application links to the old
> strftime, and the new behavior when the application links to the new
> strftime, then old executables will have the same old behavior even when
> linked to new glibc, which was Dmitry's point.

Aaah, that's it! I did not know such a feature exists. So AFAIU this
means that an executable provides to glibc some info what glibc version
it was originally compiled with and if glibc is newer it is still able
to provide the old behavior for old executables. Sounds nice, I will
have to read more about it. (Any hints, links etc. are welcome.)

> Even if the new behavior is standardized and is more likely to be what
> the user wants, there will almost surely be cases where the old behavior
> is preferable (if only to make regression tests pass :-), and the
> natural way to tell programmers about this is to say that old programs
> get the old behavior and new programs get the new one.

What if a programmer, for example an author of cal(1), just rebuilds
the unmodified source while it should be modified? Is there a way to
tell them they should at least verify their source code?

Anyway, I understand that I have to provide the old behavior for
old executables. You're welcome to provide feedback about other issues.

Regards,

Rafal

  reply	other threads:[~2016-06-01 23:54 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-03-25  0:55 Rafal Luzynski
2016-03-29  9:02 ` Florian Weimer
2016-03-29 10:59   ` keld
2016-11-04 13:36   ` Florian Weimer
2016-11-05 10:42     ` Rafal Luzynski
2016-03-29 14:15 ` Carlos O'Donell
2016-03-29 23:23   ` Rafal Luzynski
2016-03-29 14:31 ` Dmitry V. Levin
2016-03-29 23:31   ` Rafal Luzynski
2016-06-01 10:42     ` Dmitry V. Levin
2016-06-01 21:51       ` Rafal Luzynski
2016-06-01 22:20         ` Paul Eggert
2016-06-01 23:54           ` Rafal Luzynski [this message]
2016-06-02  7:03             ` Paul Eggert
2016-06-03  7:08               ` Rafal Luzynski

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=480412909.686000.92369107-bdae-4a8b-b71f-99b919bc0cf0.open-xchange@poczta.nazwa.pl \
    --to=digitalfreak@lingonborough.com \
    --cc=eggert@cs.ucla.edu \
    --cc=libc-alpha@sourceware.org \
    /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).