[lkml]   [2003]   [Feb]   [25]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: [PATCH] s390 (7/13): gcc 3.3 adaptions.
On Tue, 25 Feb 2003, Linus Torvalds wrote:

> On Tue, 25 Feb 2003, Andreas Schwab wrote:
> > |>
> > |> The point is that the compiler should see that the run-time value of i is
> > |> _obviously_never_negative_ and as such the warning is total and utter
> > |> crap.
> >
> > This requires a complete analysis of the loop body, which means that the
> > warning must be moved down from the front end (the common type of the
> > operands only depends on the type of the operands, not of any current
> > value of the expressions).
> So? Gcc does that anyway. _Any_ good compiler has to.
> And if the compiler isn't good enough to do it, then the compiler
> shouldn't be warning about something that it hasn't got a clue about.
> > |> and anybody who writes 'array[5UL]' is considered a stupid git and a
> > |> geek. Face it.
> >
> > But array[-1] is wrong. An array can never have a negative index (I'm
> > *not* talking about pointers).
> You're wrong.
> Yes, when declaring an array, you cannot use "array[-1]". But that's not
> because the thing is unsigned: the standard says that the array
> declaration has to be a "integer value larger than zero". It is not
> unsigned: it's _positive_.
> However, in _indexing_ an array (as opposed to declaring it), "array[-1]"
> is indeed perfectly fine, and is defined by the C language to be exactly
> the same as "*(array-1)". And negative values are perfectly fine, even for
> arrays. Trivial example:
> int x[2][2];
> int main(int argc, char **argv)
> {
> return x[1][-1];
> }
> the above is actually a well-defined C program, and 100%
> standards-conforming ("strictly conforming").
> Linus

I'm glad you tackled that. I was going to write a response, but
backed off because I'm getting meek in my old age. I do wish to
add that, even in ix86 assembly language, indexing by using a
register and a memory oprand is a signed displacement, i.e,

here: .byte 0
foo: .byte 0

movl $0xffffffff, %ebx
movl foo,(%ebx), %eax

... accesses a memory location one byte before label foo, i.e.,
foo[-1] or here[0]. This means that with a N-bit addressing,
indexed addressing cannot access more than 2^(N-1) memory locations.

Something to consider when trying to access large arrays. For
instance, if an operating system were to allow flat-mode access from
0x00000000 to 0xffffffff memory addresses in 32-bit user-mode, could
you actually use all that address space in 'C'?

Dick Johnson
Penguin : Linux version 2.4.18 on an i686 machine (797.90 BogoMips).
Why is the government concerned about the lunatic fringe? Think about it.

To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
More majordomo info at
Please read the FAQ at

 \ /
  Last update: 2005-03-22 13:33    [W:0.088 / U:7.464 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site