62664

Can an implementation specify undefined behavior

Question:

<blockquote>

3.4.1 <br />1 implementation-defined behavior<br /> unspecified behavior where each implementation documents how the choice is made

</blockquote>

Can an implementation specify that, implementation-defined behavior is undefined behavior in cases where undefined behavior is a possible outcome?

For example:

<blockquote>

6.3.1.3 Signed and unsigned integers<br /> 3 Otherwise, the new type is signed and the value cannot be represented in it; <em>either the result is implementation-defined</em> or an implementation-defined signal is raised.

</blockquote>

So as long as it is documented, can this result be undefined by the implementation and cause undefined behavior, or it <em>must</em> have a defined result for that implementaion?

Answer1:

No, semantically this is not possible. Undefined behavior is what the term states, behavior that is not defined by the standard. If the standard requests implementation defined behavior, it explicitly request the implementation to specify what it does when a certain error occurs.

<blockquote>

<strong>undefined behavior</strong>

behavior, upon use of a nonportable or erroneous program construct or of erroneous data, for which this International Standard imposes no requirements

</blockquote>

So an implementation could say <em>"under that and that circumstances this implementation raises a blurb signal"</em> but it can't say <em>"under that and that circumstances we don't tell you what we are doing"</em>.

Don't mystify undefined behavior as something that will happen or even as something that can be defined.

Answer2:

You can find a more detailed explanation of what "implementation defined" is intended to mean in the <em>C Rationale</em> - not a standard document <em>per se</em>, but a good reference.

In chapter 1.6 <a href="http://www.lysator.liu.se/c/rat/a.html#1-6" rel="nofollow"><em>Definition of terms</em></a>:

<blockquote>

<em>Implementation-defined behavior</em> gives an implementor the freedom to choose the appropriate approach, but requires that this choice be explained to the user. Behaviors designated as implementation-defined are generally those in which a user could make meaningful coding decisions based on the implementation definition. Implementors should bear in mind this criterion when deciding how extensive an implementation definition ought to be. As with unspecified behavior, simply failing to translate the source containing the implementation-defined behavior is not an adequate response.

</blockquote>

You can't make a "reasonable coding decision" based on undefined behavior.

The C FAQ (again, not a standard, but a well-know reference) is <a href="http://c-faq.com/ansi/undef.html" rel="nofollow">quite clear too</a>:

<blockquote>

<strong>implementation-defined:</strong> The implementation must pick some behavior; it may not fail to compile the program. (<strong>The program using the construct is not incorrect.</strong>) The choice must be documented. The Standard may specify a set of allowable behaviors from which to choose, or it may impose no particular requirements

</blockquote>

Neither unspecified and implementation-defined behaviors are errors - compiler can't fail the translation. They are meant to give the implementation options to produce optimal code for the targeted environment.

Answer3:

The assignment of integers to smaller types is something of an oddball, since the standard clearly recognizes that some implementations may trap, but--uniquely--it requires that the trapping abide by the rules of signals; the decision to impose that requirement here but not elsewhere is somewhat curious, since in many cases it would impede what would otherwise be a straightforward optimization--replacing a signed integer variable whose type shorter than int, and whose address is never taken, with an int.

Nonetheless, for whatever reasons, the authors of the standard have gone out of their way to forbid that optimization. [Note: If I were in charge of the standard, I would specify that an explicit <em>cast</em> to a shorter integer type would yield a value which when cast to an unsigned type of the same size would yield the same result as casting the value directly whenever such a value exists, but that a store of an oversized value directly to an lvalue <em>without a cast</em> would not be thus constrained; I didn't write the standard, though].

It's ironic, actually: given:

uint64t signedpow(int32_t n, uint32_t p) { uint64_t result; while(p--) { n*=n; result+=n; } return result; } uint64t unsignedpow(uint32_t n, uint32_t p) { uint64_t result; while(p--) { n*=n; result+=n; } return result; }

On a platform where int is 32 bits, the latter would have defined semantics for all values of n and p, while the former would not, but on a platform where int is 64 bits, the reverse would be true. A compiler for a typical 64-bit platform which didn't want to waste code on some other defined behavior would be required by the standard to mask off and sign-extended the signed n after each multiplication, but with some unsigned values the compiler could do anything it wanted, including going back in time and pretending that no implementation would ever promise to always perform half-sized unsigned multiplies in a fashion consistent with modular arithmetic.

Answer4:

As per C11 standard, chapter 3.4.1,

<blockquote> <h3>implementation-defined behavior</h3>

unspecified behavior where each implementation documents how the choice is made

</blockquote>

So, each implementation has to make a choice. Otherwise, it won't be <em>conforming</em>. Thus, we can say, it <strong>must</strong> have a defined result for that implementaion. That can be either of the below

<ul><li>a <em>defined</em> behavior, specific to that implementation, which will be exercised if the instruction is encountered. </li> <li>a <em>defined</em> signal which will be raied if the instrcution is encountered. (Mostly, saying that cannot be handled.)</li> </ul>

<strong>Related:</strong>

<ol><li>From C99 <a href="http://www.open-std.org/jtc1/sc22/wg14/www/C99RationaleV5.10.pdf" rel="nofollow">Rationale Document</a>, Chapter 3, (<em>emphasis mine</em>)</li> </ol><blockquote>

Implementation-defined behavior gives an implementor the freedom to choose the appropriate approach, but requires that this choice be explained to the user. Behaviors designated as implementation-defined are generally those in which a <strong><em>user could make meaningful coding decisions based on the implementation’s definition</em></strong>. Implementors should bear in mind this criterion when deciding how extensive an implementation definition ought to be. As with unspecified behavior, simply failing to translate the source containing the implementation defined behavior is not an adequate response.

</blockquote>

Now, nobody can take "meaningful coding decisions" based on undefined behavior.

<ol start="2"><li>From <a href="http://c-faq.com/ansi/undef.html" rel="nofollow">C FAQ</a>, Question 11.33,</li> </ol><blockquote>

<em>implementation-defined:</em> The implementation must pick some behavior; it may not fail to compile the program. (The program using the construct is not incorrect.) The choice must be documented. The Standard may specify a set of allowable behaviors from which to choose, or it may impose no particular requirements.

</blockquote>

The first sentence contains <strong>must</strong>, same as I mentioned before in my answer.

Recommend

  • Axis numerical offset in matplotlib
  • File and Folder Manipulation in Powershell
  • View, how gcc plan (schedule) instructions on tick-by-tick level
  • Selenium, Presence of one of many elements located?
  • Handling Enter key of SIP in windows phone application
  • Angular Firestore: What is the correct syntax for a collection query that uses a where clause?
  • What is the point of MESI on Intel 64 and IA-32
  • Connect to a password protected server with WCF over HTTP
  • Why override the designated initializer of super class?
  • Removing extra padding in DataTables columns
  • JavaFX ComboBox setItems triggers onAction event
  • How does MemberWiseClone create a new object with the cloned properties?
  • Should I create an object or work with an array?
  • Is there a way to choose which files are displayed to the user via the standard OPENFILE dialogs?
  • python: forcing relative imports to search from script file
  • Unable to connect to OnVif enabled camera using C#
  • Get the number 18437736874454810627
  • SyntaxError: (irb):26: both block arg and actual block given
  • How do I display a dialog that asks the user multi-choice questıon using tkInter?
  • Firefox Extension - Monitor refresh and change of tab
  • Grails calculated field in SQL
  • Create DicomImage from scratch using Dcmtk
  • Use of this Javascript
  • C++ Partial template specialization - design simplification
  • How to do unit test for HttpContext.Current.Server.MapPath
  • Scrapy recursive link crawler
  • How to rebase a series of branches?
  • formatting the colorbar ticklabels with SymLogNorm normalization in matplotlib
  • How to add date and time under each post in guestbook in google app engine
  • JSON with duplicate key names losing information when parsed
  • Timeout for blocking function call, i.e., how to stop waiting for user input after X seconds?
  • How to get next/previous record number?
  • Return words with double consecutive letters
  • Python: how to group similar lists together in a list of lists?
  • How does Linux kernel interrupt the application?
  • Authorize attributes not working in MVC 4
  • Does armcc optimizes non-volatile variables with -O0?
  • Busy indicator not showing up in wpf window [duplicate]
  • Python/Django TangoWithDjango Models and Databases
  • Net Present Value in Excel for Grouped Recurring CF