Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > C Programming > trap representation

Reply
Thread Tools

trap representation

 
 
Michael Wojcik
Guest
Posts: n/a
 
      12-06-2005

In article <439456f6$0$243$(E-Mail Removed). com>, Thad Smith <(E-Mail Removed)> writes:
> pemo wrote:
>
> > 6.2.6.1.5
> >
> > ...
> >
> > 41) Thus, an automatic variable can be initialized to a trap representation
> > without causing undefined behavior, but the value of the variable cannot be
> > used until a proper value is stored in it.
> >
> > ...
> > For example, I've gone to great pains to draw a distinction between
> > initialization vs. assignment - int i = 10, as opposed to int i; i = 10;
> > However, I also realize that I've *said* that autos are *initialized* with
> > unknown values, or garbage.

>
> Your choice of words is unfortunate. "Initialized," in C, means given
> an explicit value in a declaration.


Except, apparently, in 6.2.6.1.5 note 41, which uses "initialized" to
mean "the value that results when no explicit value was given in a
declaration". Which, I believe, was pemo's point.

Footnotes are not normative (a term which has specific meaning in ISO
standards, and it's not "of no consequence whatsoever"), but they are
nonetheless part of the text of the standard.

Thus it would be more accurate to say that "initialized" *usually*
means "given an explicit value in a declaration" - but the standard
is not entirely consistent in that usage.

> > Once explained, they were quite happy, but it's made me think that I ought
> > not to use the word initialized when talking about autos, or else that the
> > footnote should perhaps be reworded to something like:
> >
> > * Thus, an automatic variable can be initialized by the implementation to a
> > trap representation .

>
> That would not be initialization.


It's still an improvement on the existing wording.

> > * Thus, an automatic variable can be set to a trap representation by the
> > implementation .

>
> It could be, as mentioned above. More typically, the trap
> representation is something left over from prior use, which was not a
> variable of the same type.


That's still "set ... by the implementation". It doesn't matter
whether the implementation expressly sets it to a trap representation
(or any other value) or simply allows it to take on such a value over
the course of the program's execution; from the program's point of
view, it's still the result of the implementation's behavior.

It's also beside the point, which is the misleading wording of this
footnote in the standard.

> > * Thus, an automatic variable can be covertly initialized to a trap
> > representation .


I think introducing "covertly" to the standard, as a term with
technical meaning that is not currently used (much less defined) in
the text, is the wrong way to go.

> > * Thus, an automatic variable's value can be initialized to any arbitrary
> > value, it can be initialized to a trap representation .


This is a comma splice (two independent clauses joined with only a
comma), which is awkward (and wrong, if you're a prescriptivist).
And this still suffers from the discrepant use of "initialized".

Better wording might be something like:

41) Thus, an automatic variable without an explicit initializer can
initially contain a trap representation without causing undefined
behavior, but the value of the variable cannot be used until a proper
value is stored in it.

--
Michael Wojcik http://www.velocityreviews.com/forums/(E-Mail Removed)

Q: What is the derivation and meaning of the name Erwin?
A: It is English from the Anglo-Saxon and means Tariff Act of 1909.
-- Columbus (Ohio) Citizen
 
Reply With Quote
 
 
 
 
Tim Rentsch
Guest
Posts: n/a
 
      12-14-2005
"pemo" <(E-Mail Removed)> writes:

> Ambiguous?
>
> I have a student who's asked me to explain the following std text (esp. the
> footnote).
>
> 6.2.6.1.5
>
> Certain object representations need not represent a value of the object
> type. If the stored
> value of an object has such a representation and is read by an lvalue
> expression that does
> not have character type, the behavior is undefined. If such a representation
> is produced
> by a side effect that modifies all or any part of the object by an lvalue
> expression that
> does not have character type, the behavior is undefined.41) Such a
> representation is called a trap representation.
>
> Footnote
>
> 41) Thus, an automatic variable can be initialized to a trap representation
> without causing undefined behavior, but the value of the variable cannot be
> used until a proper value is stored in it.
>
> On hearing him explain what he *thought* it meant, I've come to the
> conclusion that the standard's either badly worded, or else I've been using
> an incorrect term when I teach.
>
> For example, I've gone to great pains to draw a distinction between
> initialization vs. assignment - int i = 10, as opposed to int i; i = 10;
> However, I also realize that I've *said* that autos are *initialized* with
> unknown values, or garbage. Nevertheless, I must have said the latter a lot
> less than the former - as the student certainly read 'programmer specified
> initialization' for 'an automatic variable can be initialized' into the
> sense of the footnote's text.
>
> Let me paraphrase footnote 41 with the substance of what they were saying:
>
> 41) Thus, an automatic variable can be *explicitly initialized* to a trap
> representation without causing undefined behavior, but the value of the
> variable cannot be used until a proper value is stored in it.
>
> I.e., the student thought that a *trap representation* was something
> useful - I guess they were thinking of it as a kind of guard mechanism, that
> could somehow benefit them.
>
> Once explained, they were quite happy, but it's made me think that I ought
> not to use the word initialized when talking about autos, or else that the
> footnote should perhaps be reworded to something like: [several possible
> rewordings snipped]


The question you're asking isn't so much about what the Standard says as
how to reconcile, or to explain to the students, how it says it. If it
were me, I would try an explanation like this:

"The Standard defines the term _initializer_ but doesn't actually give
definitions for initialize, initialized, initialization, or initial
value. Usually these terms are used in a way that is more or less
synonymous with what happens when using an _initializer_, but the
Standard doesn't precisely insist on this point. The wording in
the footnote is probably meant to point out that a conforming
program can arrange for an object to be set to a particular trap
representation without transgressing on undefined behavior. This
setting can be accomplished with, eg, 'memcpy()'."

The footnote might reasonably be reworded thusly:

41) Thus, an automatic variable can be given a specific trap
representation value, before any other accesses, without
causing undefined behavior; but the value of the variable
cannot be used (without possibly causing a trap) until a
proper value is stored in it.

I don't find it confusing to use the word "initialized" in the sense
of "given a specific initial value, by whatever means", nor
contradictory to how the Standard uses the terms; but I've
specifically avoided the phrase "initial value" in the footnote
rewording above.

Incidentally, it is possible using an initializer to give an object a
specific initial value that's a trap representation (ie, without UB).
See if you can figure out a way to do that.
 
Reply With Quote
 
 
 
Reply

Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
Can "all bits zero" be a trap representation for integral types? Army1987 C Programming 6 07-07-2007 12:01 PM
Trap representation Richard Tobin C Programming 10 06-22-2007 11:42 PM
trap representation junky_fellow@yahoo.co.in C Programming 6 01-13-2007 05:47 AM
Trap representation ramu C Programming 2 01-31-2006 04:17 PM
trap representation Mantorok Redgormor C Programming 18 09-19-2003 04:09 PM



Advertisments