Perl Error Use Of Uninitialized Value.

What happens if an array element is assigned a value, in which its subscript exceeds the size of an array?

Very. Bad. Things. in languages that allocate memory directly, you can get invalid values, crashes, memory errors, file corruption, etc.Some languages catch such violations, and issue an error or raise an exceptionthat can be dealt with.pythona = []

a[22] = "cat"

Traceback (most recent call last):
File "array.py", line 4, in
a[22] = "cat"
IndexError: list assignment index out of range
But it is just regular programming in languages that allow it.bash, for instance, will just go with it.# array.bash

declare -a X # X is declared an array

X[56]="doggie"
X[5]="kittie"
X[13]="horsey"
echo "${X[@]}" # bash array syntax is weird.
# X[@] means "all the elements of array X"

# run the script
bash -x array.bash
declare -a X
+ X[56]=doggie
+ X[5]=kittie
+ X[13]=horsey
+ echo kittie horsey doggie

kittie horsey doggie # the order is right, there are no
# elements in between indexes 5,13,56
Perl does something strange :my @demo = ("one", "two", "three", "four");
$demo[9] = 20;
print $demo[1] . "\n";
print $demo[-1] . "\n\n";

for my $i (0 .. $#demo)
{
print $i . " " . $demo[$i] . "\n";
}

two
four

0 one
1 two
2 three
3 four
4
5
6
7 20
Perl can do better, of course, with strict and warnings for uninitialized value use and checks for undefined values.use strict;
use warnings;

my @demo = ("one", "two", "three", "four");

print $demo[-1] . "\n\n";

print $demo[9] . "\n\n";

$demo[7] = 20;

print $demo[7] . "\n\n";

for my $i (0 .. $#demo)
{
if ( $demo[$i] ) { print $i . " " . $demo[$i] . "\n"; }
}


four

Use of uninitialized value $demo[9] in concatenation (.) or string at array.pl line 8.

20

0 one
1 two
2 three
3 four
7 20

How can one explain a bug in a specific function that happens only once in ten times?

There would in general be three ways this could happen:If exactly once every ten times, you shopuld be able to predict which call will fail and set a breakpoint with skip count to catch that one nad call and single step through the execution to observe where the unexpected happens.A calling function may sometimes present illegal parameter values that are not properly tested for in the failing function. Usually find untested parameter paths by inspection.The failure is connected with a variable shared between the failing function and some other Thread in your process, and access to it is not properly protected. This is typically the most difficult failure to diagnose, and may need a fresh pair of eyes to spot the sharing failure. In my early days I had one of these; a statmmux receiving pick tickets to be printed in a warehouse would fail to process a message maybe once a day; there were six of these devices, and pick tickets could be arriving every second or so. It is really difficult to figure a breakpoint for something that does not happen, even more so when there is no such thing as a breakpoint kind of debugger for an embedded micro executing out of ROM. But I did have a Logic Analyzer, which could be clipped over the CPU chip and provide a cycle by cycle log of everything that happened on the busses, and also had multi-conditional pre-triggers (HP1610 IIRC, might have been HP1611A? Their first one anyway). It took three days sitting on the warehouse floor to catch. The sharing violation had a two instruction window that it turned out was not interrupt protected. The regularity iof the tickets arrivals just happened to resonate to reveal the problem - in a three year old product that had never had dropped packet bugs reported before. I have no idea how to do instruction level tracing on today's re-ordering/paralell execution unit systems to catch this kind of bug, but for certain I double-check shared variable declarations and atomicity garuntees ever since.

Where are the arrays in C stored, in a stack or a heap?

Any statically sized arrays declared globally are going to be part of the program's data segment.  Statically sized arrays declared within a function (and not declared with the 'static' keyword; this would make them a global) are going to be put on the stack.In particular this includes the example that you gave.int arr[n];It doesn't matter that n is computed dynamically; arr will still be stored on the stack.  This declaration essentially translates to a call to alloca(sizeof(int) * n). All that it does is adjust the stack pointer to make room for the arr array.The term 'heap' usually refers to the memory that is managed by malloc and new for dynamic memory allocation.  In this sense the only memory that is on the heap is the memory allocated through these calls.  Of course, it's also possible to create arrays that are neither in the global data section, stack, nor heap using a call like mmap.

What's the easiest programming bug you’ve spent way too much time trying to solve?

It was in my third semester, in Computer Architecture course. We had to first make an emulator for an instruction set (called Simple RISC) we defined for ourselves (very similar to ARM isa). The second assignment was to implement the Karatsuba algorithm for 32 byte hexadecimal numbers in our assembly (very mind boggling task indeed) and run them on our own emulators.Everyone in the course was following a simple strategy - looking at an already implemented instance of Karatsuba in C++ and then trying to convert it to Simple RISC. I, being a believer of team work, did the same. My coding part was complete at least 6 hours before the submission deadline. But the results I was getting were just garbage. I was printing out arrays and arrays of data, checking if there was some trouble in aligning the stack pointer in the recursive calls or the register spilling was overlapping and leading to loss of data. But there wasn't. I went through it again and again to verify that the conversion to assembly was correct, that the invariant conditions for the loops were correct, that the boundary cases for the loops were what they ought to be, but no bugs were found. I was even forced to believe that there might be some error in the emulator that I built in the first assignment, which I was completely confident about since the beginning.As they say, time runs out quickly in such cases. I could not finish the assignment in time. I spent next 1-2 days debugging, but all in vain.Our professor had a nice policy about late submissions. He did not penalize us for it, but gave us an extended version of the same assignment. In this case, for the extended assignment, the input size varied from 2 to 128 bytes, and we had to plot the running time against input sizes to find out a polynomial running time relation. But the thing had started giving me headaches so I left it for some time. After a few days, when I sat down to complete the extended version, I finally found the bug. And it blew me away. I was making recursive calls thrice and in two of them, I was passing register r3 as argument instead of r13. That day was the first time I realized that encounters with '13' can indeed be unlucky. Needless to say, I completed it quick enough this time. But it was a lot of pain to go through all of this.