Serial.parseInt() behavior changes with uninvolved loop

I won't bore you with the details of why I'm working on this. What is interesting (and frustrating) is that the position of the for() loop in the code below changes the behavior of the first call to Serial.parseInt().

unsigned int numVelocities;
unsigned int numTrials;

unsigned int velocities[50];

void setup(){
  delay(10);
  Serial.begin(9600);
  delay(10);
  
  getParameters();
  
  for(int i=0; i<sizeof(velocities); i++){
    velocities[i]=(i+1)*2;
  }
}

void loop(){
  
}

void getParameters(){
  Serial.print("Enter number of velocities: ");
  while(Serial.available()==0){
  }
  numVelocities=Serial.parseInt();
  Serial.read();  //Empties buffer
  Serial.println(numVelocities);
  
  Serial.print("Enter number of trials: ");
  while(Serial.available()==0){
  }
  numTrials=Serial.parseInt();
  Serial.read(); //Empties buffer
  Serial.println(numTrials);
}

This code, as is, works just fine. However, if I move the for loop to before the call of "getParameters()"(which is where I want it) instead of after (as it is above), the first call to "Serial.parseInt()" will return a zero (subsequent calls behave as expected) irrespective of user input.

I'm really at a loss for this one. Anyone have any ideas?

What do you think sizeof returns?

Have another guess.

Some languages won't let you write to memory you don't own.
C is not one of them.

AWOL:
What do you think sizeof returns?

Have another guess.

Some languages won't let you write to memory you don't own.
C is not one of them.

:blush: The sizeof was an amature mistake on my part. (I've been spending too much time using R and not enough time using C over the last few months.) I totally get why the loop didn't function properly (which, if I'd bothered to test its output, I would have caught). I still don't understand why it altered the return from Serial.parseInt(). If you (or anyone else) have any insight, I would appreciate it.

. I still don't understand why it altered the return from Serial.parseInt(). I

Simply because you were writing to memory you had no right to.
Once you start doing that crazy stuff may or may not happen, but it is never a good idea to try, particularly with memory-mapped hardware registers.

poeticoddity:

AWOL:
What do you think sizeof returns?

Have another guess.

Some languages won't let you write to memory you don't own.
C is not one of them.

:blush: The sizeof was an amature mistake on my part. (I've been spending too much time using R and not enough time using C over the last few months.) I totally get why the loop didn't function properly (which, if I'd bothered to test its output, I would have caught). I still don't understand why it altered the return from Serial.parseInt(). If you (or anyone else) have any insight, I would appreciate it.

What do you think was in the extra memory you were clobbering? Maybe some of it was part of the serial buffer ... or some of the many other variables associated with the smooth running of the serial subsystem...

Thanks, AWOL and majenko. I've been trying to learn more about the underlying hardware in AVRs since I first found things I could do more easily in C than the Arduino language, but I still tend to overlook the basics.

I've been trying to learn more about the underlying hardware in AVRs since I first found things I could do more easily in C than the Arduino language, but I still tend to overlook the basics.

The most basic thing you're overlooking there is that the "Arduino language" is C/C++.