Signed only index?

[Vijay Kumar R. Zanvar]

Why does this program print 1 for a[-1]. I thought it should be an
OOB access situation!

#include <stdio.h>
#include <stdlib.h>

int main()
{
int a[6]={1,2,3,4,5};
printf("%d\n", a[-1]);
return EXIT_SUCCESS;
}

Thanks,
Vijay Zanvar
http://faq.zanvar.in

[Ben Pfaff]

"Vijay Kumar R. Zanvar" <vi*****@gmail.comwrites:

Why does this program print 1 for a[-1]. I thought it should be an
OOB access situation!

....

int a[6]={1,2,3,4,5};

The result of accessing an out-of-bounds array element is
undefined behavior. That means that anything can happen. You
cannot depend on the results, which are likely to change from one
run of the compiler or linker, or even the program itself, to the
next.
--
"It would be a much better example of undefined behavior
if the behavior were undefined."
--Michael Rubenstein

[vippstar]

On Jan 11, 4:52 pm, "Vijay Kumar R. Zanvar" <[e-mail]:

Why does this program print 1 for a[-1]. I thought it should be an
OOB access situation!
#include <stdio.h>
#include <stdlib.h>

int main()
{
int a[6]={1,2,3,4,5};
printf("%d\n", a[-1]);
return EXIT_SUCCESS;
}

It prints 1 (or better, it only happened to print 1 the times you have
ran it) because it invokes undefined behavior.
In a hypothetical array 'foo' of size N where N is 1 to SIZE_MAX, only
foo[0] to foo[N - 1] is accessible.

[Mark Bluemel]

Vijay Kumar R. Zanvar wrote:

Why does this program print 1 for a[-1]. I thought it should be an
OOB access situation!

#include <stdio.h>
#include <stdlib.h>

int main()
{
int a[6]={1,2,3,4,5};
printf("%d\n", a[-1]);
return EXIT_SUCCESS;
}

By the standard 'a[-1]' is equivalent to "*(a-1)", and as that
references outside the array you get Undefined Behaviour...

On my machine it just produced 134513293, but Richard H's system
may produce a suffusion of yellow...

[Richard Tobin]

In article <e8**********************************@p69g2000hsa. googlegroups.com>,
Vijay Kumar R. Zanvar <vi*****@gmail.comwrote:

>Why does this program print 1 for a[-1]. I thought it should be an
OOB access situation!

It's not practical to detect all out-of-bounds accesses with a normal
C implementation on standard hardware. Typically they will only be
detected when they go outside the bounds of all the program's data.

-- Richard
--
:wq

[jameskuyper]

Vijay Kumar R. Zanvar wrote:

Why does this program print 1 for a[-1]. I thought it should be an
OOB access situation!

#include <stdio.h>
#include <stdlib.h>

int main()
{
int a[6]={1,2,3,4,5};
printf("%d\n", a[-1]);
return EXIT_SUCCESS;
}

What did you expect to happen? Why?

[Malcolm McLean]

"Vijay Kumar R. Zanvar" <vi*****@gmail.comwrote in message

Why does this program print 1 for a[-1]. I thought it should be an
OOB access situation!

#include <stdio.h>
#include <stdlib.h>

int main()
{
int a[6]={1,2,3,4,5};
printf("%d\n", a[-1]);
return EXIT_SUCCESS;
}

Almost certainly the bytes at the location immediately before the array "a"
will be 0x00000001. It simply and blindly treats the -1 as a legitimate
index.

A better compiler will give you a segmentation fault for this, in debug mode
at any rate, because you do not "own" the memory you are accessing.

--
Free games and programming goodies.
http://www.personal.leeds.ac.uk/~bgy1mm

[Walter Roberson]

In article <PP******************************@bt.com>,
Malcolm McLean <re*******@btinternet.comwrote:

>"Vijay Kumar R. Zanvar" <vi*****@gmail.comwrote in message

>Why does this program print 1 for a[-1]. I thought it should be an
OOB access situation!

#include <stdio.h>
#include <stdlib.h>

int main()
{
int a[6]={1,2,3,4,5};
printf("%d\n", a[-1]);
return EXIT_SUCCESS;
}

>Almost certainly the bytes at the location immediately before the array "a"
will be 0x00000001.

Did I miss some evidence that on Vijay's machine,
int is 32 bits rather than (say) 16 ?
Did I miss some evidence that "almost certainly" compilers these
days use 32 bit ints?
--
"History is a pile of debris" -- Laurie Anderson

[Richard]

"Malcolm McLean" <re*******@btinternet.comwrites:

"Vijay Kumar R. Zanvar" <vi*****@gmail.comwrote in message

>Why does this program print 1 for a[-1]. I thought it should be an
OOB access situation!

#include <stdio.h>
#include <stdlib.h>

int main()
{
int a[6]={1,2,3,4,5};
printf("%d\n", a[-1]);
return EXIT_SUCCESS;
}

Almost certainly the bytes at the location immediately before the
array "a" will be 0x00000001. It simply and blindly treats the -1 as a
legitimate index.

A better compiler will give you a segmentation fault for this, in
debug mode at any rate, because you do not "own" the memory you are
accessing.

A better compiler will most certainly NOT give you a segmentation fault
for this.

[Walter Roberson]

In article <j6************@news.individual.net>,
Richard <rg****@gmail.comwrote:

>"Malcolm McLean" <re*******@btinternet.comwrites:

>"Vijay Kumar R. Zanvar" <vi*****@gmail.comwrote in message

>>int a[6]={1,2,3,4,5};
printf("%d\n", a[-1]);

>A better compiler will give you a segmentation fault for this, in
debug mode at any rate, because you do not "own" the memory you are
accessing.

>A better compiler will most certainly NOT give you a segmentation fault
for this.

What would a "better compiler" do instead? Keeping in mind that
the program is not erroneous if the invalid array indexing is
not actually evaluated, so the compiler cannot refuse to
compile the program, unless perhaps it could prove that the
invalid indexing would always be executed in the program.

--
"Beware of bugs in the above code; I have only proved it correct,
not tried it." -- Donald Knuth

[Ben Pfaff]

"Malcolm McLean" <re*******@btinternet.comwrites:

"Walter Roberson" <ro******@ibd.nrc-cnrc.gc.cawrote in message

>Malcolm McLean <re*******@btinternet.comwrote:

>>Almost certainly the bytes at the location immediately before the
array "a"
will be 0x00000001.

Did I miss some evidence that on Vijay's machine,
int is 32 bits rather than (say) 16 ?

Yes. Vijay is posting to Usenet, which implies that he is using a
fairly modern desktop computer.

I've seen a surprising number of posters here who appear to be
using antique compilers for DOS, such as Turbo C 2.0, which had
16-bit int.
--
"I'm not here to convince idiots not to be stupid.
They won't listen anyway."
--Dann Corbit

[Walter Roberson]

In article <aY******************************@bt.com>,
Malcolm McLean <re*******@btinternet.comwrote:

>"Walter Roberson" <ro******@ibd.nrc-cnrc.gc.cawrote in message

>Malcolm McLean <re*******@btinternet.comwrote:

>>>Almost certainly the bytes at the location immediately before the array
"a"
will be 0x00000001.

>Did I miss some evidence that on Vijay's machine,
int is 32 bits rather than (say) 16 ?

>Yes. Vijay is posting to Usenet, which implies that he is using a fairly
modern desktop computer.

One wonders, then, how all those Turbo C questions manage to end
up in clc -- quantum telepathy directly affecting what my newsreader
receives, without the questions actually having been posted at all??
--
"No one has the right to destroy another person's belief by
demanding empirical evidence." -- Ann Landers

[Malcolm McLean]

"Walter Roberson" <ro******@ibd.nrc-cnrc.gc.cawrote in message

Malcolm McLean <re*******@btinternet.comwrote:

>>Yes. Vijay is posting to Usenet, which implies that he is using a fairly
modern desktop computer.

One wonders, then, how all those Turbo C questions manage to end
up in clc -- quantum telepathy directly affecting what my newsreader
receives, without the questions actually having been posted at all??

Actually you are right. Vijay is probably an Indian and Indian schools seem
to use Turbo C quite a bit. So yes, he could well be on a 16 bit int
machine.

--
Free games and programming goodies.
http://www.personal.leeds.ac.uk/~bgy1mm

[J. J. Farrell]

Walter Roberson wrote:

In article <j6************@news.individual.net>,
Richard <rg****@gmail.comwrote:

>"Malcolm McLean" <re*******@btinternet.comwrites:

>>"Vijay Kumar R. Zanvar" <vi*****@gmail.comwrote in message
int a[6]={1,2,3,4,5};
printf("%d\n", a[-1]);

>>A better compiler will give you a segmentation fault for this, in
debug mode at any rate, because you do not "own" the memory you are
accessing.

>A better compiler will most certainly NOT give you a segmentation fault
for this.

What would a "better compiler" do instead? Keeping in mind that
the program is not erroneous if the invalid array indexing is
not actually evaluated, so the compiler cannot refuse to
compile the program, unless perhaps it could prove that the
invalid indexing would always be executed in the program.

I don't think a compiler would find it too onerous to spot the issue in
the program posted to this thread. It doesn't have to be 'all or
nothing'; it's better to report the error clearly in situations where it
can be easily spotted and exhibit some other form of undefined behaviour
in situations where it's more difficult to spot than to always do
something unpleasant.

[Jack Klein]

On Fri, 11 Jan 2008 22:37:03 +0000, "J. J. Farrell" <jj*@bcs.org.uk>
wrote in comp.lang.c:

Walter Roberson wrote:

In article <j6************@news.individual.net>,
Richard <rg****@gmail.comwrote:

"Malcolm McLean" <re*******@btinternet.comwrites:

"Vijay Kumar R. Zanvar" <vi*****@gmail.comwrote in message
int a[6]={1,2,3,4,5};
printf("%d\n", a[-1]);

>A better compiler will give you a segmentation fault for this, in
debug mode at any rate, because you do not "own" the memory you are
accessing.

A better compiler will most certainly NOT give you a segmentation fault
for this.

What would a "better compiler" do instead? Keeping in mind that
the program is not erroneous if the invalid array indexing is
not actually evaluated, so the compiler cannot refuse to
compile the program, unless perhaps it could prove that the
invalid indexing would always be executed in the program.

I don't think a compiler would find it too onerous to spot the issue in
the program posted to this thread. It doesn't have to be 'all or
nothing'; it's better to report the error clearly in situations where it
can be easily spotted and exhibit some other form of undefined behaviour
in situations where it's more difficult to spot than to always do
something unpleasant.

I'm not sure I agree with you on that, although neither am I sure that
I disagree.

A compiler that does a half-assed job of recognizing obvious
invocations of undefined behavior might well lull the user into
thinking that there no undefined issues if the compiler does not issue
diagnostics.

Or not.

But I do for sure believe that one should never trust a compiler to do
the job of a good analysis tool, such as lint. They are built for
different jobs.

--
Jack Klein
Home: http://JK-Technology.Com
FAQs for
comp.lang.c http://c-faq.com/
comp.lang.c++ http://www.parashift.com/c++-faq-lite/
alt.comp.lang.learn.c-c++
http://www.club.cc.cmu.edu/~ajo/docs/FAQ-acllc.html

[jaysome]

On Fri, 11 Jan 2008 13:55:40 -0800, Ben Pfaff <bl*@cs.stanford.edu>
wrote:

>"Malcolm McLean" <re*******@btinternet.comwrites:

>"Walter Roberson" <ro******@ibd.nrc-cnrc.gc.cawrote in message

>>Malcolm McLean <re*******@btinternet.comwrote:

Almost certainly the bytes at the location immediately before the
array "a"
will be 0x00000001.

Did I miss some evidence that on Vijay's machine,
int is 32 bits rather than (say) 16 ?

Yes. Vijay is posting to Usenet, which implies that he is using a
fairly modern desktop computer.

I've seen a surprising number of posters here who appear to be
using antique compilers for DOS, such as Turbo C 2.0, which had
16-bit int.

The C Standard places no restrictions on any relationship between the
host platform and the target platform. Embedded programmers are
thankful for this.

There is no reason whatsoever to assume that because someone posts a
message to Usenet from one platform that they are using a compiler
that targets that same platform. They could well be targeting another
platform, i.e., cross-compiling.

One of numerous examples is the TI Code Composer compiler (see [1] for
another example), which runs on Windows XP and Windows Vista, and
supports cross compilation for the C5501 DSP, which defines the
following:

CHAR_BIT = 16
sizeof(char) = 1 /* by definition in C */
sizeof(short) = 1
sizeof(int) = 1
sizeof(long) = 2

It should be noted that the C5501 is Big Endian.

And, thankfully, all of this is acceptable as far as the C Standard is
concerned.

Regards
--
jay

[1] The Microchip C30 compiler, for some targets, defines the
following:

CHAR_BIT = 8
sizeof(char) = 1 /* by definition in C */
sizeof(short) = 2
sizeof(int) = 2
sizeof(long) = 4

[Keith Thompson]

Jack Klein <ja*******@spamcop.netwrites:
[...]

But I do for sure believe that one should never trust a compiler to do
the job of a good analysis tool, such as lint. They are built for
different jobs.

[...]

Why should the compiler and lint be two separate tools? As far as I
can tell, the separation is a relic of the days there weren't enough
resources for a single tool to do both thorough analysis and code
generation. These days, an optimizer has to do much of the analysis
that a lint-like tool would do anyway.

--
Keith Thompson (The_Other_Keith) <ks***@mib.org>
Nokia
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"

[Kelsey Bjarnason]

On Fri, 11 Jan 2008 21:45:05 +0000, Walter Roberson wrote:

In article <j6************@news.individual.net>,
Richard <rg****@gmail.comwrote:

>>"Malcolm McLean" <re*******@btinternet.comwrites:

>>"Vijay Kumar R. Zanvar" <vi*****@gmail.comwrote in message
int a[6]={1,2,3,4,5};
printf("%d\n", a[-1]);

>>A better compiler will give you a segmentation fault for this, in
debug mode at any rate, because you do not "own" the memory you are
accessing.

>>A better compiler will most certainly NOT give you a segmentation fault
for this.

What would a "better compiler" do instead?

Presumably, compile the code. It's the runtime environment, not the
compiler, which may or may not cause the fault to be generated. Try it on
a computer using DOS, you can probably get away with it. Try it on the
same machine using Linux or an NT derivative, you probably can't.

[Malcolm McLean]

"Kelsey Bjarnason" <kb********@gmail.comwrote in message

>
Presumably, compile the code. It's the runtime environment, not the
compiler, which may or may not cause the fault to be generated. Try it on
a computer using DOS, you can probably get away with it. Try it on the
same machine using Linux or an NT derivative, you probably can't.

The compiler and environment co-operate to produce segfaults. A very
primitive compiler will just assume it owns everything, and a very primitive
OS will give it everything, allowing strange malfunctions rather than error
messages.
However better systems only claim resources they are actually going to use,
and decent OSes report illegal access.

--
Free games and programming goodies.
http://www.personal.leeds.ac.uk/~bgy1mm

[Peter Nilsson]

Jack Klein <[e-mail]:

... I do for sure believe that one should never trust a
compiler to do the job of a good analysis tool,

Question: would or have you ever rewritten a line of
perfectly correct code merely to silence a warning?

I submit that most people will answer Yes. That indicates
to me that programmers, even experts, do trust their
compilers above good analysis tools, even themselves!

I agree that they shouldn't, for the simple fact that
it is the programmer who is responsible for code
correctness, not the tools they use. But I appear to be
in a very insular minority in that regard.

such as lint. *They are built for different jobs.

Compiler warnings are getting closer and closer to those
of lint like tools. Programmers are expecting more and
more that compilers do the job of analysis tools in
addition to their primary role.

--
Peter

[Eric Sosman]

Peter Nilsson wrote:

Jack Klein <[e-mail]:

>... I do for sure believe that one should never trust a
compiler to do the job of a good analysis tool,

Question: would or have you ever rewritten a line of
perfectly correct code merely to silence a warning?

I submit that most people will answer Yes. That indicates
to me that programmers, even experts, do trust their
compilers above good analysis tools, even themselves!

I agree that they shouldn't, for the simple fact that
it is the programmer who is responsible for code
correctness, not the tools they use. But I appear to be
in a very insular minority in that regard.

I'm a "change it" programmer, on the grounds that I'm
probably not the only person who will read the code. If my
correct code elicits a compiler warning, it's also likely to
be a red herring for some other programmer further down the
line, diverting his attention toward the mistake I didn't
make and away from the one I did.

Most frequent scenario (for me, anyhow): Compiler moans
about using an uninitialized variable, but I can see that
it will in fact be initialized. I'll often insert the
initialization and a comment that says why it's there:

char *p = NULL; /* initialized to placate compiler */

A program's source has two audiences: The compilers that
translate it, and the programmers who read it. The second
audience is the more important.

--
Er*********@sun.com

[Richard Tobin]

In article <79**********************************@e10g2000prf. googlegroups.com>,
Peter Nilsson <ai***@acay.com.auwrote:

>Question: would or have you ever rewritten a line of
perfectly correct code merely to silence a warning?

>I submit that most people will answer Yes. That indicates
to me that programmers, even experts, do trust their
compilers above good analysis tools, even themselves!

I don't see how this follows. I would rewrite the line so that the
spurious warning doesn't obscure genuine messages, and so that I don't
get mail from users worried about the warnings. If anything, it shows
that I recognise the limitations of my compilers.

Usually I put a comment in, e.g.

int count=0; /* initialised to shut gcc up */

-- Richard
--
:wq

[Charlton Wilbur]

>>>>"PN" == Peter Nilsson <ai***@acay.com.auwrites:

PNQuestion: would or have you ever rewritten a line of perfectly
PNcorrect code merely to silence a warning?

PNI submit that most people will answer Yes. That indicates to
PNme that programmers, even experts, do trust their compilers
PNabove good analysis tools, even themselves!

It only potentially shows that if the "perfectly correct code" is
superior to what it's replaced with.

Take the example (as other respondents have) that the compiler sees an
uninitialized variable and is not sophisticated enough to determine
that the variable will always be initialized before use, so it issues
a warning. Adding an initialization to the variable does not make the
code any less correct.

Further, depending on your approach to writing code, any code that
issues a compiler warning may not qualify as "perfectly correct" -- I
learned long ago, when I started programming in C, that warnings were
a sign that the compiler was probably confused about what I meant and
I should rewrite it for clarity. I had fellow students who decided
that they were the better arbiters of code correctness and thus
ignored warnings. Guess who got the assignments done more quickly,
and who had a more solid library of code when the semester was over?

I'm trying to think of a case where the code is "perfectly correct,"
the compiler issues a warning, and the necessary change to eliminate
the warning makes the code incorrect or materially less efficient. If
you can come up with such an example, I'll be more inclined to believe
your point.

And, as noted, the two audiences for the code you write are the
compiler and the maintenance programmers. If either one has a hard
time understanding your code, no matter how "correct" it may be in a
superficial technical sense, there's a problem somewhere, and as it's
your code it's your problem to deal with.

Charlton
--
Charlton Wilbur
cw*****@chromatico.net

[Richard Tobin]

In article <87************@mithril.chromatico.net>,
Charlton Wilbur <cw*****@chromatico.netwrote:

>I'm trying to think of a case where the code is "perfectly correct,"
the compiler issues a warning, and the necessary change to eliminate
the warning makes the code incorrect or materially less efficient. If
you can come up with such an example, I'll be more inclined to believe
your point.

I doubt you'll find any, except for thoroughly bogus warnings issued a
poor compiler. But one of the goals of a program is to express the
intentions of its author; I only initialise a variable when I intend
it to have a value, so adding one to appease the compiler makes the
program worse in that respect.

-- Richard
--
:wq

[Charlton Wilbur]

>>>>"RT" == Richard Tobin <ri*****@cogsci.ed.ac.ukwrites:

RTIn article <87************@mithril.chromatico.net>,
RTCharlton Wilbur <cw*****@chromatico.netwrote:

>I'm trying to think of a case where the code is "perfectly
correct," the compiler issues a warning, and the necessary
change to eliminate the warning makes the code incorrect or
materially less efficient. If you can come up with such an
example, I'll be more inclined to believe your point.

RTI doubt you'll find any, except for thoroughly bogus warnings
RTissued a poor compiler. But one of the goals of a program is
RTto express the intentions of its author; I only initialise a
RTvariable when I intend it to have a value, so adding one to
RTappease the compiler makes the program worse in that respect.

But this is also a question of quality of implementation.

For instance, I just wrote the following program:

#include <stdio.h>

int main()
{
int i, j;

printf ("%d squared is %d\n", i, j); /* uninitialized use of i & j */

for (i=0; i<25; i++)
{
j = i * i;
printf ("%d squared is %d\n", i, j);
}

return 0;
}

When I compile this with gcc -Wall -O2, I get two warnings on the first
printf -- one for each uninitialized variable. When I remove that line,
it compiles with no warnings, even though I didn't initialize i or j
until I got to the loop.

(gcc requires the optimizer to be invoked before it can determine if
the variables are used or not. This is something I did not realize
until today.)

Now, I could imagine a situation where the program was not a toy
program and it was impossible for the compiler but trivial for the
programmer to determine whether a variable would be initialized before
usage -- but it seems to me that if the compiler cannot rule out the
possibility of a variable being uninitialized, then the programmer is
not doing a good enough job of expressing what he wants to the
compiler. Or, in other words, you need to express to the *compiler*
that the variable will be in a known state before it is used. If the
compiler can't infer it from the code that follows, it needs to be
made more explicit.

Charlton

--
Charlton Wilbur
cw*****@chromatico.net

[Flash Gordon]

Richard Tobin wrote, On 17/01/08 16:50:

In article <87************@mithril.chromatico.net>,
Charlton Wilbur <cw*****@chromatico.netwrote:

>I'm trying to think of a case where the code is "perfectly correct,"
the compiler issues a warning, and the necessary change to eliminate
the warning makes the code incorrect or materially less efficient. If
you can come up with such an example, I'll be more inclined to believe
your point.

I doubt you'll find any, except for thoroughly bogus warnings issued a
poor compiler. But one of the goals of a program is to express the
intentions of its author; I only initialise a variable when I intend
it to have a value, so adding one to appease the compiler makes the
program worse in that respect.

The one I can remember was actually with a Pascal compiler. I did the
Pascal equivalent of
switch (keypressed) {
case CURSOR_UP: ...
break;
a few more cases
default: handler for unknown keypress
}

The compiler gave a warning something like:
Most case values point to the same label
Probably better worded.

I ignored it because what I had written was the clearest way to express
my intent.

I'm sure others have hit situations with C where the clearest code
generated a warning.
--
Flash Gordon

[CBFalconer]

Charlton Wilbur wrote:

Peter Nilsson <ai***@acay.com.auwrites:

>Question: would or have you ever rewritten a line of perfectly
correct code merely to silence a warning?

I submit that most people will answer Yes. That indicates to
me that programmers, even experts, do trust their compilers
above good analysis tools, even themselves!

It only potentially shows that if the "perfectly correct code"
is superior to what it's replaced with.

Take the example (as other respondents have) that the compiler
sees an uninitialized variable and is not sophisticated enough
to determine that the variable will always be initialized before
use, so it issues a warning. Adding an initialization to the
variable does not make the code any less correct.

.... snip ...

>
I'm trying to think of a case where the code is "perfectly
correct," the compiler issues a warning, and the necessary
change to eliminate the warning makes the code incorrect or
materially less efficient. If you can come up with such an
example, I'll be more inclined to believe your point.

Just go back to the 'uninitialized variable' case above. Adding
initialization has installed extra executable code in the program.
It is not even 'occasionally executed' code. This is totally
unnecessary overhead, and the code is measureably less efficient.
I consider that code to be incorrect.

--
[mail]: Chuck F (cbfalconer at maineline dot net)
[page]: <http://cbfalconer.home.att.net>
Try the download section.

--
Posted via a free Usenet account from http://www.teranews.com