Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.c > #379526

Re: Call to a function

Show all headers | View raw

James Kuyper <jameskuyper@alumni.caltech.edu> writes:
[...]
> I appreciate that you feel that way - but the committee resolved DR 109
> in conflict with your feeling. The code referred to by DR 109 divided an
> integer by an integer constant of 0, which wasn't even protected by an
> if(0). It was the only line in the only function defined in that
> translation unit, which was absolutely guaranteed, if function were
> called, to execute that line. The only reason the committee gave for it
> being strictly conforming was that there was no guarantee that the rest
> of the program ever actually called the function. But the committee
> decided that that fact was sufficient to make the code, in itself,
> strictly conforming, and the implementation was therefore required to
> accept it. If the program as a whole did call that function, that fact
> would be sufficient to justify rejecting the whole program, but it was
> not sufficient to justify rejecting that particular translation unit.
>
> Basically, code with undefined behavior prevents a program from being
> strictly conforming only if execution of such code is an inevitable
> consequence of starting the program. If executing that code can be
> avoided, then only a failure to avoid it renders the the behavior
> undefined. If that failure is not realized at compile time, then the
> implementation must still accept it.
>
> If the committee ruled that way on that code, how could you possibly
> expect it to support rejection of this code?
[...]

For context, DR 109 can be seen at:
https://www.open-std.org/jtc1/sc22/wg14/www/docs/dr_109.html

The code the author (Ron Guilmette) asked about was (indentation added):

int array1[5];
int array2[5];
int *p1 = &array1[0];
int *p2 = &array2[0];

int foo()
{
    int i;
    i = (p1 > p2); /* Must this be "successfully translated"? */
    1/0; /* Must this be "successfully translated"? */
    return 0;
}

The committee response was:

    The C Standard uses the term ``indeterminately valued'' not
    ``undefined value.'' Use of an indeterminate valued object
    results in undefined behavior.  The footnote to subclause 5.1.1.3
    points out that an implementation is free to produce any number
    of diagnostics as long as a valid program is still correctly
    translated.  If an expression whose evaulation would result
    in undefined behavior appears in a context where a constant
    expression is required, the containing program is not strictly
    conforming. Furthermore, if every possible execution of a given
    program would result in undefined behavior, the given program
    is not strictly conforming.  A conforming implementation must
    not fail to translate a strictly conforming program simply
    because *some* possible execution of that program would result
    in undefined behavior. Because foo might never be called, the
    example given must be successfully translated by a conforming
    implementation.

The DR was submitted in 1993, and referred to the C90 standard.
I'm not aware of anything in later editions of the standard that
would invalidate the response.

-- 
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
Will write code for food.
void Void(void) { Void(); } /* The recursive call of the void */

Back to comp.lang.c | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll thread

Thread

Re: Call to a function James Kuyper <jameskuyper@alumni.caltech.edu> - 2023-11-10 12:08 -0500
  Re: Call to a function Tim Rentsch <tr.17687@z991.linuxsc.com> - 2023-11-13 08:16 -0800
  Re: Call to a function James Kuyper <jameskuyper@alumni.caltech.edu> - 2023-11-13 14:15 -0500
    Re: Call to a function Tim Rentsch <tr.17687@z991.linuxsc.com> - 2023-11-14 09:02 -0800
    Re: Call to a function James Kuyper <jameskuyper@alumni.caltech.edu> - 2023-11-14 13:10 -0500
      Re: Call to a function Tim Rentsch <tr.17687@z991.linuxsc.com> - 2023-11-18 23:27 -0800
    Re: Call to a function James Kuyper <jameskuyper@alumni.caltech.edu> - 2023-11-19 12:22 -0500
      Re: Call to a function Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2023-11-19 13:31 -0800
      Re: Call to a function Tim Rentsch <tr.17687@z991.linuxsc.com> - 2024-01-22 18:15 -0800

csiph-web