public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
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..


      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