×
The internal search function is temporarily non-functional. The current search engine is no longer viable and we are researching alternatives.
As a stop gap measure, we are using Google's custom search engine service.
If you know of an easy to use, open source, search engine ... please contact support@midrange.com.
I've seen this sort of thing happen before during OS upgrades - i.e., a
previously working program is "broken" after an upgrade. Invariably -
in my experience - the root cause has always been a defect in the
affected program. In this case (assuming the code was posted verbatim),
the primary defect is the use of an uninitialized automatic variable.
The problem with the while() loop would have been caught during
development were it not for the uninitialized variable.
Sometimes during the development of an OS upgrade, certain behaviors
that were previously ambiguous or undefined (but may have nonetheless
behaved in a consistent manner) get tweaked - resulting in a new
behavior that is still legal but different than before. The value of
uninitialized automatic variables in C are undefined by the language,
and so the implementation may do whatever it wishes with them. An
implementation may always set their value to zero, or to one, or to any
other or random value. If an OS upgrade changes that behavior - such as
defaulting an uninitialized automatic variable to zero - that is
perfectly legal, language-wise. But that (legal) change in behavior can
expose previously-hidden bugs in programs.
In the past, I've seen cases (during an OS/400 upgrade) where malloc()
was "tightened". malloc() should always, of course, return the
requested amount of memory, but many implementations actually return
_more_ than what was requested, which is legal. In the cases that I am
referring to, several programs had defects in that they overstepped the
amount of memory that was originally requested. Up until the OS upgrade
(I don't recall which version offhand), the programs worked normally,
because malloc() had returned enough extra memory to keep the
overstepping from causing a problem. After the upgrade, though,
malloc() began returning less memory than before (always at least the
requested amount, though, of course.) As a result, these programs that
were overstepping their boundaries began corrupting memory outside the
malloc()ed area - resulting in strange, random failures. That was fun
to track down (as a consultant.)
Mike Mills
mikem@xxxxxxxx
ConsulTech Information Systems, Inc.
Lim Hock-Chai wrote:
I think that is it. In V5R2, somehow the compiled object has a
unintialized value of non 0, which made the loop to be working. After
upgraded to V5R3, the unintialized value somehow become 0, which made it
to stop working.
Thanks.
-----Original Message-----
From: c400-l-bounces+lim.hock-chai=usamobility.com@xxxxxxxxxxxx
[mailto:c400-l-bounces+lim.hock-chai=usamobility.com@xxxxxxxxxxxx] On
Behalf Of Jevgeni Astanovski
Sent: Monday, April 16, 2007 9:59 AM
To: C programming iSeries / AS400
Subject: Re: [C400-L] upgrade from V5R2 to V5R3.
The most probable explanation is uninitialized variable num together
with a programming error.
Obviously in C
while(num=num)
is equivalent to
while(num)
And I cannot imagine a programmer, who is so "typing hungry" :-)
midrange.com
