Re: what is 'trap representation'?

In article <clcm-20051113-0016@xxxxxxxxxxxx>, sgganesh@xxxxxxxxx (Ganny)
wrote:

> In standard, 6.2.6[5] Representations of types, there is a description
> of 'trap representation'.
>
> "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.) Such a representation is called
> a trap representation."
>
> I couldn't understand the para - what does it mean? Any examples will be
> of great help.

One example would be floating-point Not a Number values. Some C
implementations will produce a special value meaning "this is not a valid
floating-point number" in response to code like:

double a, b;
a = sqrt(4.0)-2.0; /* get zero without compile-time warning */
b = 1/a;

Some implementations will issue some kind of exception, such as a SIGFPE,
when they evaluate b, while others will just store a NaN (not-a-number)
value in b. As far as I can see, your paragraph makes the NaN behaviour
legal, as well as similar behaviour for other types. I've never run across
a system that had Not an Integer values, although I can just about imagine
ones that could require it.

Quite a few implementations can behave in either way, according to
controls that are accessible through C library calls that are specific to
the implementation, and therefore not part of standard C.

It's important to realise that quite a bit of C standardisation is about
recognising the unavoidable behaviour of various kinds of computer and
making it legal C. Other languages may try to define a set of abstract
behaviour and then require it to be implemented on any computer that
supports the standard, but C isn't like that.

And yes, this means that a perverse implementation of C could provide
"features" that are legal, but not generally useful, thus making the
implementation less usable, while still being perfectly standard-
conformant. Like, say, making a byte-addressed machine appear to be a
word-addressed machine. The scope for perverse implementations of C is so
awesome that nobody tries. Why do so much work to no good effect?

---
John Dallman, jgd@xxxxxxxxx, HTML mail is treated as probable spam.
--
comp.lang.c.moderated - moderation address: clcm@xxxxxxxxxxxx -- you must
have an appropriate newsgroups line in your header for your mail to be seen,
or the newsgroup name in square brackets in the subject line. Sorry.
.

Relevant Pages

  • Re: value bits
    ... >see how the language in the standard backs up your assertions. ... is a trap representation or a normal value. ... this text introduces an exception. ... Such a representation is called a trap representation. ...
    (comp.lang.c)
  • Re: ...malloc ...from Rome :-)
    ... > This is more wording that is not in the actual standard. ... NOTE An unspecified value cannot be a trap representation. ... invokes undefined behavior; if it's merely unspecified, ...
    (comp.lang.c)
  • Re: value bits
    ... > any arbitrary exceptions here, ... I don't disagree that that is the intent of the standard, ... Such a representation is called a trap representation. ...
    (comp.lang.c)
  • Re: memcpy() with unitialised memory
    ... Is this undefined behaviour? ... Here's how it follows from the standard ... representation is valid and has a different value). ... confirm our suspicion that this trap representation, whatever it is, is one ...
    (comp.lang.c)
  • Re: Trap respresentation
    ... >> used until a proper value is stored in it. ... trap rep. and thus not a representation of a value. ... trap representation", which hardly seems clearer. ... The text of the C Standard is concise and more explanation ...
    (comp.std.c)
Loading