× 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.


  • Subject: Re: Terminating a C program
  • From: "Simon Coulter" <shc@xxxxxxxxxxxxxxxxx>
  • Date: Thu, 10 Aug 00 19:38:30 +1000


Hello Bob,

Me:
>Interesting, I would expect automatic storage to be reinitialised
>regardless of activation group persistence.

You:
>Simon, given all of the great information that you share with the mailing
>list, I was surprised by your last statement (above).  Perhaps I
>misunderstood.

Just me not being clear in what I meant -- but that's OK.  I'd pick others up 
on such 
things so it's only fair to get it in return :)  I didn't spend much time 
thinking about 
the example code -- which is using static storage anyway.  I read the statement 
"all the 
storage associated with that program is still allocated and in a 'last-used' 
state" as 
meaning ALL storage and not just all static storage and was surprised by the 
implication 
that automatic storage would retain state.

My use of the word 'reinitialised' was not correct but I tend to think of 
automatic 
storage as always being re-initialised due to it being allocated on every call 
even 
though I know it's values are undetermined unless explicitly initialised.  I 
should have 
said "Interesting, I would not expect automatic storage to retain state 
regardless of 
activation group persistence".

If the declaration of invocation_count in the Apendix H example were moved into 
main then 
it would implicitly use automatic storage and would be initialised to 0 on 
every 
invocation -- because of the explicit initialiser rather than implicitly 
regardless of 
activation group state.

>The information cited from the Programmer's Guide applies only to static
>data.  For C and C++, initialization of automatic storage is not defined by
>the language, and, independent of the activation group, automatic storage
>is never initialized (by the compiler or machine) for these languages.  It
>would be very wrong, for example, to assume that automatic variables are
>initialized to zero.

Not only wrong but dangerous.  Hence the convention to initialise variables 
when 
declaring them.  Automatic variables must either be initialised on declaration, 
assigned 
a value before use, or first used to hold a result to ensure valid values -- 
else they 
will contain any old value.  One thing to note is that this is a language 
semantics issue 
and some languages do initialise automatic storage.

For Mikes benefit:

Variables declared outside a function (by convention, above main but actually 
anywhere in 
the source) are implicitly static and generally have global scope.  Variables 
declared 
inside a function are implicitly automatic and generally have local scope.  The 
static 
and auto modifiers can be used to override the default behaviour.

If I have some function that declares and initialises variables they will 
always be set 
to that value because the storage is implicitly declared as automatic and 
therefore 
allocated on every call.

For example:

int someFunction( void )
{
        int count = 0;
        count++;
        return count;
} 

will always return 1.  However If I forget to initialise and declare count as 
int count; 
then the returned value could be any number at all.  If I specify the static 
modifier and 
declare static int count = 0; then the count will increment on each invocation 
unless the 
activation group containing the storage is destroyed between invocations.

If I attempt the same thing in main(), e.g.,

int main( void )
{
        static int count = 0;
        count++;
        return count;
} 

and expect the count to increment I will be disappointed unless I also use a 
named 
activation group.

Regards,
Simon Coulter.

«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»
«» FlyByNight Software         AS/400 Technical Specialists       «»
«» Eclipse the competition - run your business on an IBM AS/400.  «»
«»                                                                «»
«» Phone: +61 3 9419 0175      Mobile: +61 0411 091 400           «»
«» Fax:   +61 3 9419 0175      mailto: shc@flybynight.com.au      «»
«»                                                                «»
«» Windoze should not be open at Warp spe
.                      «»
«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»
+---
| This is the C/400 Mailing List!
| To submit a new message, send your mail to C400-L@midrange.com.
| To subscribe to this list send email to C400-L-SUB@midrange.com.
| To unsubscribe from this list send email to C400-L-UNSUB@midrange.com.
| Questions should be directed to the list owner/operator: bob@cstoneindy.com
+---

As an Amazon Associate we earn from qualifying purchases.

This thread ...


Follow On AppleNews
Return to Archive home page | Return to MIDRANGE.COM home page

This mailing list archive is Copyright 1997-2024 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].

Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.