From: Robert Hancock <hancockr@shaw.ca>
To: linux-kernel@vger.kernel.org
Subject: Re: compile time warnings
Date: Fri, 02 Jan 2009 14:03:36 -0600 [thread overview]
Message-ID: <495E7318.4010904@shaw.ca> (raw)
In-Reply-To: <495d3100@wupperonline.de>
Ingo Brueckl wrote:
> Maybe somebody noticed already, with kernel 2.6.28 and gcc 4.3.2 there are a
> few compile time warnings:
> drivers/acpi/tables/tbfadt.c: In function 'acpi_tb_create_local_fadt':
> /usr/src/linux/arch/x86/include/asm/string_32.h:75: warning: array subscript is above array bounds
I noticed this as well. This one looks like the compiler's getting a bit
confused.
ACPI_MEMCPY(&acpi_gbl_FADT, table,
ACPI_MIN(length, sizeof(struct acpi_table_fadt)));
and somehow that falls into __constant_memcpy because somehow
__builtin_constant_p() on the length parameter returns true. Huh? It's a
non-static function where length is passed in, and ACPI_MIN is a simple
(((a)<(b))?(a):(b)) expression. How can it think that's a compile time
constant I don't know. Maybe it's not and just generating warnings from
the code path it's seeing but not using?
The cause of the complaint might be the fact that the memcpy may appear
to read past the end of the "table" structure which points to struct
acpi_table_header. Presumably that memory is bigger than the actual
struct acpi_table_header though. The text of the warning itself is
bizarre though, as there is no array style access happening, and I don't
see how the compiler can know what the actual bounds of the "array" are.
>
> drivers/usb/core/hcd.c: In function 'usb_hcd_poll_rh_status':
> /usr/src/linux/arch/x86/include/asm/string_32.h:75: warning: array subscript is above array bounds
This one makes a little more sense. This is presumably:
memcpy(urb->transfer_buffer, buffer, length);
where transfer_buffer is a void*, buffer is char[4] and length comes
from hcd->driver->hub_status_data(hcd, buffer) which I assume fills in
the buffer. It's true the memcpy could read past the end of the buffer
array, but only if the hub_status_data could fill in and return a length
greater than 4, which it hopefully can't..
prev parent reply other threads:[~2009-01-02 20:04 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-01-01 21:13 compile time warnings Ingo Brueckl
2009-01-01 22:52 ` Jesper Juhl
2009-01-02 1:35 ` Tom Spink
2009-01-02 1:39 ` Harvey Harrison
2009-01-02 2:07 ` Jesper Juhl
2009-01-02 9:57 ` Ingo Molnar
2009-01-02 12:53 ` [PATCH] " Ingo Brueckl
2009-01-02 13:01 ` Ingo Molnar
2009-01-02 13:42 ` Ingo Brueckl
2009-01-02 14:42 ` Ingo Molnar
2009-01-02 16:07 ` Jesper Juhl
2009-01-02 16:10 ` Jesper Juhl
2009-01-02 2:48 ` Ingo Brueckl
2009-01-02 20:03 ` Robert Hancock [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=495E7318.4010904@shaw.ca \
--to=hancockr@shaw.ca \
--cc=linux-kernel@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