From: Markus Armbruster <armbru@redhat.com>
To: Alex Williamson <alex.williamson@redhat.com>
Cc: mst@redhat.com, weifuqiang@huawei.com, qemu-devel@nongnu.org,
arei.gonglei@huawei.com, huangzhichao@huawei.com,
"Longpeng \(Mike,
Cloud Infrastructure Service Product Dept.\)"
<longpeng2@huawei.com>, Laszlo Ersek <lersek@redhat.com>
Subject: Re: [PATCH RESEND 1/3] vfio/pci: fix a null pointer reference in vfio_rom_read
Date: Wed, 11 Mar 2020 08:08:16 +0100 [thread overview]
Message-ID: <87ftefl673.fsf@dusky.pond.sub.org> (raw)
In-Reply-To: <20200310193624.402fdb18@x1.home> (Alex Williamson's message of "Tue, 10 Mar 2020 19:36:24 -0600")
Alex Williamson <alex.williamson@redhat.com> writes:
> On Wed, 11 Mar 2020 00:14:31 +0100
> Laszlo Ersek <lersek@redhat.com> wrote:
[...]
>> So from a memcpy() and range perspective, the patch looks OK. But
>> there's still a wart I dislike: we should never perform pointer
>> arithmetic on a (void*). I suggest casting (vdev->rom) to (uint8_t*) or
>> (unsigned char*) first.
>>
>> Here's an excerpt from the ISO C99 standard:
>>
>> -v-
>> 6.5.6 Additive operators
>>
>> Constraints
>>
>> 2 For addition, either both operands shall have arithmetic type, or one
>> operand shall be a pointer to an object type and the other shall have
>> integer type. [...]
>> -^-
>>
>> A "pointer-to-void" is not a "pointer to an object type", because "void"
>> is not an object type -- it is an incomplete type that cannot be completed:
>>
>> -v-
>> 6.2.5 Types
>>
>> 1 [...] Types are partitioned into object types (types that fully
>> describe objects), function types (types that describe functions), and
>> incomplete types (types that describe objects but lack information
>> needed to determine their sizes).
>>
>> [...]
>>
>> 19 The void type comprises an empty set of values; it is an incomplete
>> type that cannot be completed.
>> -^-
>>
>> For a different illustration, (vdev->rom + addr) is equivalent to
>> &(vdev->rom[addr]) -- and we clearly can't have an "array of void".
>>
>> This anti-pattern (of doing pointer arithmetic on (void*)) likely comes
>> from a guarantee that the standard does make, in the same "6.2.5 Types"
>> section:
>>
>> -v-
>> 27 A pointer to void shall have the same representation and alignment
>> requirements as a pointer to a character type. 39) [...]
>>
>> Footnote 39: The same representation and alignment requirements are
>> meant to imply interchangeability as arguments to
>> functions, return values from functions, and members of
>> unions.
>> -^-
>>
>> It does not extend to the "+" operator.
>
> GNU C specifically allows arithmetic on pointers and defines the size
> of a void as 1. I'll comply, but this makes me want to stab myself in
> the face :-\ Thanks,
We rely on GNU C extensions all over theplace. Making the code uglier
to avoid relying on this one here makes no sense to me.
next prev parent reply other threads:[~2020-03-11 7:09 UTC|newest]
Thread overview: 23+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-02-24 6:42 [PATCH RESEND 0/3] fix some warnings by static code scan tool Longpeng(Mike)
2020-02-24 6:42 ` [PATCH RESEND 1/3] vfio/pci: fix a null pointer reference in vfio_rom_read Longpeng(Mike)
2020-02-24 16:04 ` Alex Williamson
2020-02-24 23:48 ` Longpeng (Mike, Cloud Infrastructure Service Product Dept.)
2020-03-10 16:11 ` Alex Williamson
2020-03-10 23:14 ` Laszlo Ersek
2020-03-11 1:36 ` Alex Williamson
2020-03-11 7:08 ` Markus Armbruster [this message]
2020-03-11 10:28 ` Laszlo Ersek
2020-03-11 10:26 ` Laszlo Ersek
2020-03-11 11:54 ` Markus Armbruster
2020-03-11 13:00 ` Laszlo Ersek
2020-03-11 7:04 ` Markus Armbruster
[not found] ` <20200311093939.494bfe27@w520.home>
2020-03-12 5:50 ` Markus Armbruster
2020-03-12 14:07 ` Alex Williamson
2020-02-24 6:42 ` [PATCH RESEND 2/3] vhost: fix a null pointer reference of vhost_log Longpeng(Mike)
2020-03-10 2:11 ` Longpeng (Mike, Cloud Infrastructure Service Product Dept.)
2020-03-10 5:57 ` Michael S. Tsirkin
2020-03-10 8:04 ` Longpeng (Mike, Cloud Infrastructure Service Product Dept.)
2020-03-10 8:23 ` Michael S. Tsirkin
2020-03-10 12:02 ` Longpeng (Mike)
2020-03-10 12:18 ` Michael S. Tsirkin
2020-02-24 6:42 ` [PATCH RESEND 3/3] util/pty: fix a null pointer reference in qemu_openpty_raw Longpeng(Mike)
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=87ftefl673.fsf@dusky.pond.sub.org \
--to=armbru@redhat.com \
--cc=alex.williamson@redhat.com \
--cc=arei.gonglei@huawei.com \
--cc=huangzhichao@huawei.com \
--cc=lersek@redhat.com \
--cc=longpeng2@huawei.com \
--cc=mst@redhat.com \
--cc=qemu-devel@nongnu.org \
--cc=weifuqiang@huawei.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 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.