Re: Eric DeLong solves the "Corrupted timestamp" problem and wins the prize!

Reeve,

I would certainly expect the compiler to complain about passing a
non-VARYING field as a VARYING (non-CONST) parameter.  What happens is that
the first two bytes of your parameter are interpreted as a two byte integer
indicating the length of the field.  I am going to check the docs tomorrow.

Joep Beckeringh

----- Original Message -----
From: "Reeve Fritchman" <reeve@ltl400.com>
To: "Rpg400-L@Midrange. Com" <rpg400-l@midrange.com>
Sent: Tuesday, October 23, 2001 10:02 PM
Subject: Eric DeLong solves the "Corrupted timestamp" problem and wins the
prize!


A prototype (ZZR030PR) and subprocedure (ZZR030) had "varying" instead of
"value", and something overflowed into the timestamp.

This raises an interesting question: should the compiler have spotted this
error, or at least built a large enough buffer to prevent crash-and-burn?
If I was working with pointers, I'd expect to hose myself.  But since the
compiler is (supposed to be) doing the housekeeping, is it reasonable to
expect a safety net from RPG?

Thanks, Eric.