| Number | 100
|
| Category | errata
|
| Synopsis | 10.2.3: output arguments of automatic tasks not initialized
|
| State | lrmdraft
|
| Class | errata-discuss
|
| Arrival-Date | Aug 17 2002
|
| Originator | sharp@cadence.com
|
| Release | 2001b: 10.2.3
|
| Environment |
105 |
| Description |
Section 10.2.3 specifies that variables declared in automatic tasks shall be initialized to the default initialization value whenever execution enters their scope. However, it does not specify initialization for output arguments. Input and inout arguments are not a problem, since they get set to the values passed in. But output arguments don't. This means that their value is not defined in the task before they are set, and if the task does not set them, neither is the value that gets passed back from them when the task exits. Also see section 10.2.2 on argument passing. |
| Fix |
In 10.2.3, para. 2, REPLACE "Variables declared in static tasks shall retain their values between invocations. They shall be initialized to the default initialization value as described in 3.2.2. Variables declared in automatic tasks shall be initialized to the default initialization value whenever execution enters their scope." WITH "Variables declared in static tasks, including input, output, and inout type arguments, shall retain their values between invocations. They shall be initialized to the default initialization value as described in 3.2.2. Variables declared in automatic tasks, including output type arguments, shall be initialized to the default initialization value whenever execution enters their scope. Input and inout type arguments shall be initialized to the values passed from the expressions corresponding to these arguments listed in the task enabling statements." |
| Audit-Trail |
From: Shalom Bresticker <Shalom.Bresticker@motorola.com> To: sharp@cadence.com Cc: etf-bugs@boyd.com Subject: Re: errata/100: output arguments of automatic tasks not initialized Date: Sun, 25 Aug 2002 11:03:39 +0300 Isn't this covered, at least implicitly, by the statement you mention in your first sentence? An output argument is also a variable declared in the task. I agree it could and should be clearer. Shalom sharp@cadence.com wrote: > Section 10.2.3 specifies that variables declared in > automatic tasks shall be initialized to the default > initialization value whenever execution enters their > scope. However, it does not specify initialization > for output arguments. Input and inout arguments are > not a problem, since they get set to the values passed > in. But output arguments don't. This means that their > value is not defined in the task before they are set, > and if the task does not set them, neither is the value > that gets passed back from them when the task exits. > > Also see section 10.2.2 on argument passing. From: Steven Sharp <sharp@cadence.com> To: sharp@cadence.com, Shalom.Bresticker@motorola.com Cc: etf-bugs@boyd.com Subject: Re: errata/100: output arguments of automatic tasks not initialized Date: Mon, 26 Aug 2002 16:26:57 -0400 (EDT) >Isn't this covered, at least implicitly, by the statement you >mention in your first sentence? > >An output argument is also a variable declared in the task. But if it is interpreted that way, then there is another problem. An input argument is also a variable declared in the task. So those would also get initialized on entry to the task, destroying the value that was passed in. Same thing for inout. >I agree it could and should be clearer. But now you have turned it from "simple" to "discuss", by discussing it. :-( Steven Sharp sharp@cadence.com From: Shalom Bresticker <Shalom.Bresticker@motorola.com> To: Steven Sharp <sharp@cadence.com> Cc: etf-bugs@boyd.com Subject: Re: errata/100: output arguments of automatic tasks not initialized Date: Tue, 27 Aug 2002 08:46:01 +0300 Yes, I know, I was conveniently ignoring that. But my point was that, it is not really an error in the standard, just not clear enough. It requires an "interpretation". I have two reasons to classify it that way. One, if we classify it as an error, IEEE may decide that a correction is a "substantive change" in the standard. Two, if we ever count the number of real errors in the standard, I would like it to be as low as honestly possible. Shalom Steven Sharp wrote: > >Isn't this covered, at least implicitly, by the statement you > >mention in your first sentence? > > > >An output argument is also a variable declared in the task. > > But if it is interpreted that way, then there is another problem. > > An input argument is also a variable declared in the task. So those > would also get initialized on entry to the task, destroying the value > that was passed in. Same thing for inout. > > >I agree it could and should be clearer. |
| Unformatted |
|
Hosted by Boyd Technology