This is the mail archive of the gcc@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

May an implementation document implementation-defined behavior as undefined? (fwd)


Here's an unofficial ruling from a member of the C standards commitee.

Please do not cc: me on further discussion.

zw

------- start of forwarded message -------
Path: news.panix.com!panix!bloom-beacon.mit.edu!newsswitch.lcs.mit.edu!news-spur1.maxwell.syr.edu!news.maxwell.syr.edu!sn-xit-03!sn-post-02!sn-post-01!supernews.com!corp.supernews.com!not-for-mail
From: "James Kuyper Jr." <kuyper@wizard.net>
Newsgroups: comp.std.c
Subject: Re: May an implementation document implementation-defined behavior as 
 undefined?
Date: Sat, 05 Jan 2002 11:06:38 -0500
Organization: Posted via Supernews, http://www.supernews.com
Message-ID: <3C37248E.6315F50F@wizard.net>
X-Mailer: Mozilla 4.7 [en] (X11; I; Linux 2.2.12-20 i686)
X-Accept-Language: en
MIME-Version: 1.0
References: <a15k99$ce5$1@panix1.panix.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
X-Complaints-To: newsabuse@supernews.com
Lines: 52
Xref: news.panix.com comp.std.c:52958

Zack Weinberg wrote:
> 
> There is currently a loud argument on the gcc development lists over
> whether or not we (as an implementation) may declare that certain
> constructs which have implementation-defined semantics, have undefined
> semantics in this implementation.

No. Implementation-defined behavior is unspecified behavior (3.4.1p1),
and unspecified behavior is "behavior where this International Standard
provides two or more possibilities and imposes no further requirements
on which is chosen". It's supposed to always be clear what the range of
possibilities is, and an implementation is never permitted to choose any
behavior that's not in that list. Some considerable effort was put into
making sure that the list of possibilities was always inferrable from
the standard.

> The precise situation under debate involves the difference between
> these two expressions:
> 
>    "foo" + 5
>    (const char *) ((uintptr_t)"foo" + 5)
> 
> Everyone agrees that the first expression produces undefined behavior
> if the resultant pointer is used for anything. However, since conversion
> between pointers and integers is implementation-defined, certain people
> insist that the compiler must produce a pointer with an implementation-
> defined value, which can then be safely used by (implementation-
> dependent) code which knows what that value is.

What I said above doesn't apply here, because the behavior is already
undefined, GCC doesn't need to say anything new to make it so.

The relevant points here are that, if UINTPTR_MAX is defined, then the
cast to 'uintptr_t' is permitted, and produces an implementation-defined
value. Having been converted, it's an ordinary unsigned integer of some
type, and adding 5 to it is certainly permitted. However, the standard
says nothing about what happens to that new integer value when it's
converted to 'const char *'. The only applicable guarantees are for the
original value, not for any other value, no matter how that value was
obtained. Therefore, you don't need to invent any new undefined
behavior, the standard already leaves this as undefined behavior (by
lack of definition, rather than explicitly). GCC is free to define this
behavior, but doesn't have to. The citation you provide below leaves
this behavior explicitly undefined, which is perfectly legal.

...
> #  When casting from pointer to integer and back again, the resulting
> #  pointer must reference the same object as the original pointer,
> #  otherwise the behavior is undefined. That is, one may not use
> #  integer arithmetic to avoid the undefined behavior of pointer
> #  arithmetic as proscribed in 6.5.6/8.
> (from http://gcc.gnu.org/onlinedocs/gcc/Arrays-and-pointers-implementation.html)
------- end of forwarded message -------


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]