From: jinhui huang <huangjh.jy@cn.fujitsu.com>
To: ltp@lists.linux.it
Subject: [LTP] [PATCH 2/3] syscalls/pipe*: Fix compiler warnings
Date: Tue, 6 Mar 2018 09:41:33 +0800 [thread overview]
Message-ID: <5A9DF1CD.40706@cn.fujitsu.com> (raw)
In-Reply-To: <20180305080334.amcwf4ghvb7cxv7c@dell5510>
于 2018/03/05 16:03, Petr Vorel 写道:
> Hi Jinhui,
>
>> Signed-off-by: Jinhui Huang<huangjh.jy@cn.fujitsu.com>
>> ---
>> testcases/kernel/syscalls/pipe/pipe04.c | 2 +-
>> testcases/kernel/syscalls/pipe/pipe05.c | 4 ++--
>> testcases/kernel/syscalls/pipe/pipe07.c | 2 +-
>> testcases/kernel/syscalls/pipe/pipe08.c | 2 ++
>> testcases/kernel/syscalls/pipe/pipe11.c | 6 +++---
>> 5 files changed, 9 insertions(+), 7 deletions(-)
>> diff --git a/testcases/kernel/syscalls/pipe/pipe04.c b/testcases/kernel/syscalls/pipe/pipe04.c
>> index b3d255b..a3c56e3 100644
>> --- a/testcases/kernel/syscalls/pipe/pipe04.c
>> +++ b/testcases/kernel/syscalls/pipe/pipe04.c
>> @@ -235,7 +235,7 @@ void c2func(void)
>> tst_resm(TBROK | TERRNO, "[child 2] pipe write failed");
>> }
>> -void alarmfunc(int sig)
>> +void alarmfunc(int sig LTP_ATTRIBUTE_UNUSED)
>> {
>> /* for some reason tst_brkm doesn't seem to work in a signal handler */
>> tst_brkm(TFAIL, cleanup, "one or more children did't die in 60 second "
>> diff --git a/testcases/kernel/syscalls/pipe/pipe05.c b/testcases/kernel/syscalls/pipe/pipe05.c
>> index fe5ec37..4105988 100644
>> --- a/testcases/kernel/syscalls/pipe/pipe05.c
>> +++ b/testcases/kernel/syscalls/pipe/pipe05.c
>> @@ -59,7 +59,7 @@ void sig11_handler(int sig);
>> int main(int ac, char **av)
>> {
>> - int lc;
>> + volatile int lc;
> Why volatile?
>
Hi Petr,
The compiler warning:
pipe05.c: In function ‘main’:
pipe05.c:62:6: warning: variable ‘lc’ might be clobbered by ‘longjmp’ or
‘vfork’ [-Wclobbered]
int lc;
We may avoid this warning by declaring "lc" as volatile which tells the
optimizer not to optimize it.
>> struct sigaction sa, osa;
>> tst_parse_opts(ac, av, NULL, NULL);
>> @@ -120,7 +120,7 @@ void setup(void)
>> /******************************************************************
>> * sig11_handler() - our segfault recover hack
>> ******************************************************************/
>> -void sig11_handler(int sig)
>> +void sig11_handler(int sig LTP_ATTRIBUTE_UNUSED)
>> {
>> longjmp(sig11_recover, 1);
>> }
>> diff --git a/testcases/kernel/syscalls/pipe/pipe07.c b/testcases/kernel/syscalls/pipe/pipe07.c
>> index b09df71..55bb9f4 100644
>> --- a/testcases/kernel/syscalls/pipe/pipe07.c
>> +++ b/testcases/kernel/syscalls/pipe/pipe07.c
>> @@ -129,7 +129,7 @@ static void record_open_fds(void)
>> if (fd == dir_fd)
>> continue;
>> - if (rec_fds_max>= ARRAY_SIZE(rec_fds)) {
>> + if (rec_fds_max>= (int)ARRAY_SIZE(rec_fds)) {
>> tst_brkm(TBROK, cleanup,
>> "Too much file descriptors open");
>> }
>> diff --git a/testcases/kernel/syscalls/pipe/pipe08.c b/testcases/kernel/syscalls/pipe/pipe08.c
>> index cdb2a4d..9f8d9cc 100644
>> --- a/testcases/kernel/syscalls/pipe/pipe08.c
>> +++ b/testcases/kernel/syscalls/pipe/pipe08.c
>> @@ -98,6 +98,8 @@ int main(int ac, char **av)
>> * sent
>> */
>> written = write(pipefd[1], wrbuf, length);
>> + if (written> 0)
>> + tst_brkm(TBROK, cleanup, "write succeeded expectedly");
> Did you mean "unexpectedly"?
>
Yes.
Best regards,
Jinhui
>> }
>> cleanup();
>> tst_exit();
>> diff --git a/testcases/kernel/syscalls/pipe/pipe11.c b/testcases/kernel/syscalls/pipe/pipe11.c
>> index e11c556..e3b2741 100644
>> --- a/testcases/kernel/syscalls/pipe/pipe11.c
>> +++ b/testcases/kernel/syscalls/pipe/pipe11.c
>> @@ -198,7 +198,8 @@ void do_child_uclinux(void)
>> */
>> void setup(void)
>> {
>> - int i, j;
>> + int i;
>> + unsigned int j;
>> tst_sig(FORK, DEF_HANDLER, cleanup);
>> @@ -230,9 +231,8 @@ void setup(void)
>> j = 0;
>> for (i = 0; i< szcharbuf;) {
>> wrbuf[i++] = rawchars[j++];
>> - if (j>= sizeof(rawchars)) {
>> + if (j>= sizeof(rawchars))
>> j = 0;
>> - }
>> }
>> }
> Otherwise LGTM, thanks!
>
>
> Kind regards,
> Petr
>
>
> .
>
next prev parent reply other threads:[~2018-03-06 1:41 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-03-02 8:02 [LTP] [PATCH 1/3] syscalls/fchmod*: Fix compiler warnings Jinhui Huang
2018-03-02 8:02 ` [LTP] [PATCH 2/3] syscalls/pipe*: " Jinhui Huang
2018-03-05 8:03 ` Petr Vorel
2018-03-06 1:41 ` jinhui huang [this message]
2018-03-06 15:03 ` Petr Vorel
2018-03-02 8:02 ` [LTP] [PATCH 3/3] syscalls/mknod*: " Jinhui Huang
2018-03-05 9:21 ` Petr Vorel
2018-03-05 7:48 ` [LTP] [PATCH 1/3] syscalls/fchmod*: " Petr Vorel
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=5A9DF1CD.40706@cn.fujitsu.com \
--to=huangjh.jy@cn.fujitsu.com \
--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.