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

Groups > comp.lang.c > #362593

Re: Call to a function

Show all headers | View raw

James Kuyper <jameskuyper@alumni.caltech.edu> writes:
> On 10/25/23 02:46, Kaz Kylheku wrote:
>> On 2023-10-25, James Kuyper <jameskuyper@alumni.caltech.edu> wrote:
>>> The standard never talks about rejection. It requires that "A conforming
>>> hosted implementation shall accept any strictly conforming program.". No
>>> such requirement applies to any program which is not strictly
>>> conforming. (4p6)
>>>
>>> Therefore, this code must be accepted.
>> 
>> What does "accept" mean? I don't see it defined. ...
>
> Correct. In the absence of a standard-defined meaning, we're left with
> the ordinary English meaning of the word. Since I can accept a gift
> without, in any way, being obligated to do anything with it, I've argued
> that a implementation could meet that requirement by issuing the message
> "Program accepted", and doing nothing else with it. The message, not
> being a mandatory diagnostic, is optional.
>
> The ordinary English meaning of accept is opposite to the meaning of
> reject (which is neither defined nor even used in the standard). As
> such, citing the text requiring strictly conforming code to be accepted,
> is as close as I can come to supporting Keith's skepticism about a
> conforming implementation being allowed to reject this code.
>
>> ... If it means
>> "successfully translate and execute", then what is the point of the
>> requirement that a conforming implementaton must successfully translate
>> and execute "a" program that contains an instance of every limit?
>
> I fully agree. Whatever "accept" means, it must be something less strong
> than "translate and execute".

I don't agree (though I do agree that the standard is unclear on what it
means).

I don't think that printing "Program accepted" and doing nothing else
would satisfy the standard's requirements.  Why would the standard have
such a completely useless requirement?

I suggest that "accept" *does* (or at least should) mean "successfully
translate and execute".

The standard does not specify "the size or complexity of a program and
its data that will exceed the capacity of any specific data-processing
system or the capacity of a particular processor" (Scope, section 1
paragraph 2) -- so *some* programs will exceed an implementation's
capacity.

5.2.4.1 says that "The implementation shall be able to translate and
execute at least one program that contains at least one instance of
every one of the following limits".  That imposes a restriction on an
implementation's capacity limits.  (And it does it in a way that's
straightforwardly specified, but such that the easiest non-perverse way
to conform is to have *reasonable* capacity limits.)

I suggest that the requirements in section 4, Conformance, are all
subject to any capacity limits (the ones the standard doesn't cover).
That includes 4p3:

    A program that is correct in all other aspects, operating on correct
    data, containing unspecified behavior shall be a correct program and
    act in accordance with 5.1.2.3.

and 4p6:

    The two forms of *conforming implementation* are hosted and
    freestanding.  A *conforming hosted implementation* shall accept any
    strictly conforming program.  A *conforming freestanding
    implementation* shall accept [snip]

My reading of all that is that a conforming implementation must
translate and execute any *correct* program and any *strictly
conforming* program **that does not exceed its capacity limits**.
Capacity limits are a valid excuse to:
- reject
- not accept
- fail to translate
- fail to execute
any program other than the "one program" of 5.2.4.1.

The program I posted upthread was:

int main(void) {
    int obj = 42;
    typedef void func(void);
    if (0) {
        func *fptr = (func*)&obj;
        fptr();
    }
}

I assert that a conforming hosted implementation must successfully
translate and execute it (it has no visible runtime behavior other
than returning a successful status) subject to capacity limits.
An implementation is no more or less permitted to reject it than
it is to reject "hello, world".

[...]

-- 
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-10-25 23:51 -0400
  Re: Call to a function Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2023-10-26 00:10 -0700
    Re: Call to a function Kaz Kylheku <864-117-4973@kylheku.com> - 2023-10-26 20:40 +0000
      Re: Call to a function Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2023-10-26 16:27 -0700

csiph-web