From: Vasily Gorbik <gor@linux.ibm.com>
To: Harald Freudenberger <freude@linux.ibm.com>
Cc: linux-s390 <linux-s390@vger.kernel.org>
Subject: Re: [s390:features 73/81] drivers/s390/crypto/ap_queue.c:201:18: warning: format specifies type 'unsigned char' but the argument has type 'int'
Date: Thu, 8 Oct 2020 10:34:26 +0200 [thread overview]
Message-ID: <your-ad-here.call-01602146066-ext-5611@work.hours> (raw)
In-Reply-To: <60ba86ba-8912-1c67-8390-10ebcdee2f19@linux.ibm.com>
On Thu, Oct 08, 2020 at 09:00:00AM +0200, Harald Freudenberger wrote:
>
> On 08.10.20 01:41, kernel test robot wrote:
> > 2ea2a6099ae3d1708f90f43c81a98cba3d4bb74c [73/81] s390/ap: add error response code field for ap queue devices
>
> Fixed ... but why do these warnings not appear with normal build or with C=1 build ?
>
> Maybe there is some pragma needed somewhere at where the debug feature printfs expand to ?
>
> drivers/s390/crypto/ap_debug.h:26:47: note: expanded from macro 'AP_DBF_WARN'
> debug_sprintf_event(ap_dbf_info, DBF_WARN, ##__VA_ARGS__)
It seems to be the same for printk as well.
Variable function arguments which are passed via ... and of smaller
sizes then int are promoted to ints. It's called "default argument
promotion". So, its not like your code would crash or print garbage
if you use "%hhu" format and pass int or use "%d" and pass unsigned
char. It looks like gcc simply does not complain about such things,
while clang does.
prev parent reply other threads:[~2020-10-08 8:34 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-10-07 23:41 [s390:features 73/81] drivers/s390/crypto/ap_queue.c:201:18: warning: format specifies type 'unsigned char' but the argument has type 'int' kernel test robot
2020-10-08 7:00 ` Harald Freudenberger
2020-10-08 8:34 ` Vasily Gorbik [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=your-ad-here.call-01602146066-ext-5611@work.hours \
--to=gor@linux.ibm.com \
--cc=freude@linux.ibm.com \
--cc=linux-s390@vger.kernel.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