Bug in memory, but not revealed

I compile the following code with gcc and then I run it. It doesn't
give any memory error. Is there any flag for compiler to avoid this or
a method to guaranty me the access only to the valid memory?

int main() {
int v[10];
v[17] = 33;
}

Thank you,
Stefan Istrate

re: Bug in memory, but not revealed

In article <457b4429-4c19-41d2-ab91-4a91013b54a9@m44g2000hsc.googlegroups.com>,
Stefan Istrate <stefan.istrate@gmail.comwrote:No. C systems don't check this. You will only get an error if there
is no memory at that address, and there is likely to be memory after
the end of the array because of the way operating systems allocate it.

There are debugging tools such as valgrind, but they generally
only check malloc()ed memory.

-- Richard
--
In the selection of the two characters immediately succeeding the numeral 9,
consideration shall be given to their replacement by the graphics 10 and 11 to
facilitate the adoption of the code in the sterling monetary area. (X3.4-1963)

re: Bug in memory, but not revealed

On Jun 4, 3:53 pm, Stefan Istrate <stefan.istr...@gmail.comwrote:For integer constants, a warning could be possible, but pointless.
Think about it, how many times have you used an integer constant
(other than 0) in "real-world" developing?
For non-constant expressions, the compiler can't do that. Such warning
is not very useful.

re: Bug in memory, but not revealed

vippstar@gmail.com writes:
Nearly every day, for me.

--
Chris.

re: Bug in memory, but not revealed

Stefan Istrate wrote:
Most C implementations do not do bounds checking by default. While many
implementations have no means to do so, most mainstreams ones *will*
compile extra code to check memory access if you tell it do so, (and
possibly link with the appropriate external libraries). You need to
read the documentation for your compiler to find out the details, but
for gcc I think the '-fmudflap' option might do the trick. You also
need to provide a linker command to link with the "mudflap" library.

You might also try external tools like ElectricFence or Valgrind for
heap checking.

re: Bug in memory, but not revealed

Stefan Istrate <stefan.istrate@gmail.comwrites:
<off topic>
If you install the mudflap library and compile (and link) with the
right flags you get (pretty much) what you want.
</off topic>

--
Ben.

re: Bug in memory, but not revealed

On Jun 4, 5:40 pm, Chris McDonald <ch...@csse.uwa.edu.auwrote:Alright, fine. My point is that having an integer constant bigger than
the arrays size is quite rare.
Just curious, but is it possible to tell me a situation or two where
you see the integer constants in array indexes?
Surely in cryptographic functions, and anything that has to do with
parsing of things whose size is always known. (IP addresses, etc)
But other than that? I might just be missing the obvious. Regardless,
I haven't done much "real" programming, so you most certainly know
better.

re: Bug in memory, but not revealed

In article <42ff03c9-965e-4bfc-8635-f17ebe6cb49b@f36g2000hsa.googlegroups.com>,
<vippstar@gmail.comwrote:
Arrays are often used as a form of data structuring. For example,
it is common to have 2D arrays whose rows are [X, Y, Z] triples.
This -could- be implemented as an array of
struct {double X; double Y; double Z} but with the possible
padding between elements of a struct this could take more room than
it needs to -- and there are times where the appropriate coordinate
number needs to be calculated and so a struct can become cumbersome.

I mostly program in MATLAB these days; it is quite common in MATLAB
to see constructs such as V(:,3) meaning the 3rd column of all rows
of V, or W(2,:) meaning all columns of the 2nd row of W.

--
"Allegories are in the realm of thoughts, what ruins are in
the realm of things." -- Walter Benjamin