From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: by sourceware.org (Postfix, from userid 48) id E97D13858C74; Tue, 2 Apr 2024 17:35:58 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org E97D13858C74 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gcc.gnu.org; s=default; t=1712079358; bh=nNC8rLKuN6b2cwIFfqogY7g1O+JuDdvNKrAg4I+ZBWA=; h=From:To:Subject:Date:In-Reply-To:References:From; b=U/BUAHbIm1f4s7qHlcjkC179XMHWGq0mLUZF+/v5zdMdga5T5boqcNXKTweCsr2K0 GDKW3wcFrp0bUUSXDJtR4O1sb+2ZViP6DUnpXU/nFe+YDsMC5s1LGmBh+aUHQReu35 9WQDQY7pwgbisot+B/N0YdTEmQ2p+GJnWqOF5Acg= From: "kkylheku at gmail dot com" To: gcc-bugs@gcc.gnu.org Subject: [Bug c/114526] ISO C does not prohibit extensions: fix misconception. Date: Tue, 02 Apr 2024 17:35:58 +0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: gcc X-Bugzilla-Component: c X-Bugzilla-Version: 14.0 X-Bugzilla-Keywords: diagnostic, documentation X-Bugzilla-Severity: normal X-Bugzilla-Who: kkylheku at gmail dot com X-Bugzilla-Status: RESOLVED X-Bugzilla-Resolution: DUPLICATE X-Bugzilla-Priority: P3 X-Bugzilla-Assigned-To: unassigned at gcc dot gnu.org X-Bugzilla-Target-Milestone: --- X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: http://gcc.gnu.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 List-Id: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=3D114526 --- Comment #13 from Kaz Kylheku --- (In reply to Joseph S. Myers from comment #11) > I think that simply failing to say whether a value of type X may be > converted to type Y is clearly enough for it at least to be unspecified > whether or when such conversions are possible in a cast at all (which is > enough for rejecting the translation unit). "Unspecified (Behavior)" is a normative term though. Unspecified situations occur when the standard gives the implementation a choice from among a fini= te number of behaviors (none of those being anything like "stop the program", = or "behave unpredictably"), but the implementation is not required to document which behavior is selected. The difference between "unspecified" and "implementation-defined" is that u= nder the latter, the choice must be documented. E.g. order of evaluation of function argument expressions is unspecified, therefore we don't know whether G or H is called first in F(G(), H()), and = the implementation doesn't have to provide any documented requirements about it. When the standard doesn't define a behavior, not mentioning any possible choices or anything of the sort, it is undefined. "behave unpredictably" or "stop the program" are possible behaviors then.=