This is the mail archive of the gcc@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [PATCH] C undefined behavior fix


Linus Torvalds <torvalds@transmeta.com> writes:

> I brought up the issue of "implementation defined" simply because the
> arguments I saw were bogus. They claimed that the behaviour was undefined,
> which it isn't, with some simple syntactic changes.

You mean "semantic changes", I think.  We aren't talking about syntax.

> To take the example that Richard had, for example, which was something
> like:
>
> 	int a[5];
> 	int b[5];
>
> 	for (i = 0; i < 10; i++)
> 		a[i] = b[0];
>
> and Richard (correctly, in my opinion) claims that the compiler can and
> should be able to see that b[0] is constant, even if the programmer laid
> out "a" and "b" consecutively in memory (and thus changing "a[5]" really
> does change the memory location that b[0] has).

The programmer didn't lay out "a" and "b" consecutively in memory, at
least if the above code is from a C program.

>  - the C language clearly _does_ have different rules for pointer
>    arithmetic and for "integer arithmetic with cast pointers" (the first
>    one ends up being undefined and allows more aggressive optimization,
>    while the second one is implementation-defined and thus tends to
>    disallow some of those optimizations).

Repeating this over and over again doesn't make it true.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]