public inbox for libc-alpha@sourceware.org
 help / color / mirror / Atom feed
From: Joseph Myers <joseph@codesourcery.com>
To: Paul Pluzhnikov <ppluzhnikov@google.com>
Cc: GLIBC Devel <libc-alpha@sourceware.org>
Subject: Re: [patch] Add tests for atexit/on_exit firing order
Date: Mon, 10 Jul 2017 15:55:00 -0000	[thread overview]
Message-ID: <alpine.DEB.2.20.1707101552310.30742@digraph.polyomino.org.uk> (raw)
In-Reply-To: <CALoOobOapmq-XJa5jR8BO5sO0yUbraq1iMMyq5E=AwK6MwxF1A@mail.gmail.com>

On Mon, 10 Jul 2017, Paul Pluzhnikov wrote:

> On Mon, Jul 10, 2017 at 8:18 AM, Joseph Myers <joseph@codesourcery.com> wrote:
> 
> >> This patch adds such test. I am using on_exit here because it
> >> conveniently allows passing an argument.
> >
> > I'd think that it would make sense to test all of atexit, on_exit,
> > at_quick_exit this way.
> 
> I could be missing something, but I don't see an easy way to test
> atexit and at_quick_exit the same way due to them not taking an
> argument.
> 
> To test atexit, I would have to implement separate fn1 .. fn8 and
> hard-code expected call sequence into each of them, wouldn't I?

You might have more separate functions, however the call sequence is 
encoded.  There are various ways with wrapper functions, macros etc. it 
should be possible to share the same test structure for all the functions 
(e.g. have wrappers for each function that call it with different 
arguments, and have my_on_exit select such a wrapper from an array).

> That would make for a more verbose and more difficult to modify test,
> and given that all 3 functions currently share implementation, that
> seems like an overkill. Of course if later the implementation is
> un-shared, it would be nice to have a test case for each. But it seems
> unlikely to ever happen.

Every public interface should have adequate test coverage.  All three are 
public interfaces, so all three should have test coverage.

-- 
Joseph S. Myers
joseph@codesourcery.com

      parent reply	other threads:[~2017-07-10 15:55 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-07-10 15:01 Paul Pluzhnikov
2017-07-10 15:09 ` Carlos O'Donell
2017-07-10 15:18 ` Joseph Myers
2017-07-10 15:39   ` Paul Pluzhnikov
2017-07-10 15:45     ` Szabolcs Nagy
2017-07-10 15:56       ` Joseph Myers
2017-07-24 15:50         ` Paul Pluzhnikov
2017-07-24 17:05           ` Paul Pluzhnikov
2017-07-31 18:05             ` Paul Pluzhnikov
2017-08-07 14:54               ` Paul Pluzhnikov
2017-08-16 16:36             ` Carlos O'Donell
2017-08-28  2:16               ` Paul Pluzhnikov
2017-07-10 15:55     ` Joseph Myers [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=alpine.DEB.2.20.1707101552310.30742@digraph.polyomino.org.uk \
    --to=joseph@codesourcery.com \
    --cc=libc-alpha@sourceware.org \
    --cc=ppluzhnikov@google.com \
    /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).