All of lore.kernel.org
 help / color / mirror / Atom feed
From: Petr Vorel <pvorel@suse.cz>
To: ltp@lists.linux.it
Subject: [LTP] [PATCH] common_timers: staticize all definitions
Date: Tue, 28 Apr 2020 09:25:16 +0200	[thread overview]
Message-ID: <20200428072516.GA8764@dell5510> (raw)
In-Reply-To: <CAK8P3a0On9euT2mzx+LsXVe21cqwNMR4Hzj3eVDhbCS_KeGb4w@mail.gmail.com>

Hi,

...
> > > -clock_t clock_list[] = {
> > > +static clock_t clock_list[] = {
> > >       CLOCK_REALTIME,
> > >       CLOCK_MONOTONIC,
> > >       CLOCK_PROCESS_CPUTIME_ID,
> > > @@ -34,7 +34,7 @@ clock_t clock_list[] = {
> > >       case def_name:          \
> > >               return #def_name;

> > Unfortunately this still generates warning:

> > warning: ?clock_list? defined but not used

> > I missed seeing this earlier in the full build and saw it now while
> > building a single test case.
I overlooked that too, sorry.

> > I think we need to move this to some .c file and remove the "static"
> > part. But I am not sure which one to. If we do that, then rest of the
> > series will not be affected by it.

> That is probably the cleanest way, yes
Yes, but it's a bit complicated, lapi headers were expected to be not part of
the library. As you write, -fno-common make use variables in header files a bit
complicated.

> > Or we can simply drop the "static" part and multiple copies of this
> > will be present in different .c files. Which I don't really like to be
> > honest.

> There is usually no warning about variables in header files
> that are marked 'static const' rather than just 'static', as that
> is a common way to do things in C++.
Correct, static const clock_t clock_list[] would work.
I'd be for this solution.

> > Or we can simply drop the "static" part and multiple copies of this
> > will be present in different .c files. Which I don't really like to be
> > honest.

> With gcc-10 and clang-10 this will cause a link-time failure, because
> they now both default to "-fno-common" behavior.
True, we build in travis with -fno-common (fixed recently).

>        Arnd

Kind regards,
Petr

  reply	other threads:[~2020-04-28  7:25 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-04-27 11:43 [LTP] [PATCH 1/4] syscalls/timer_gettime: Add support for time64 tests Viresh Kumar
2020-04-27 11:43 ` [LTP] [PATCH 2/4] syscalls/timer_settime: " Viresh Kumar
2020-04-27 11:43 ` [LTP] [PATCH 3/4] syscalls/timerfd: " Viresh Kumar
2020-04-27 11:43 ` [LTP] [PATCH 4/4] syscalls/sched_rr_get_interval: " Viresh Kumar
2020-04-27 14:52 ` [LTP] [PATCH 1/4] syscalls/timer_gettime: " Petr Vorel
2020-04-28  5:00   ` [LTP] [PATCH] common_timers: staticize all definitions Viresh Kumar
2020-04-28  6:14     ` Viresh Kumar
2020-04-28  7:19       ` Arnd Bergmann
2020-04-28  7:25         ` Petr Vorel [this message]
2020-04-28  7:47           ` Viresh Kumar
2020-04-28  6:22     ` Petr Vorel
2020-04-28  5:01   ` [LTP] [PATCH 1/4] syscalls/timer_gettime: Add support for time64 tests Viresh Kumar

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=20200428072516.GA8764@dell5510 \
    --to=pvorel@suse.cz \
    --cc=ltp@lists.linux.it \
    /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.