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

Groups > comp.lang.c > #360703 > unrolled thread

Re: Call to a function

Back to article view | Back to comp.lang.c

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.

Contents

  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

#360703 — Re: Call to a function

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".

...
> Might "accept" might mean, roughly, parse the syntax, check constraints

No, not entirely. A minimally-conforming implementation need only
determine that no #error directive survives conditional compilation,
something that only requires processing through translation phase 4. It
can meet the requirement by accepting all code that passes that check,
without further analysis (unless it identifies the "one program" that
it's required to do more with).

> and report no issues that would stop further translation?

Everything that would render such a report mandatory would also prevent
the code from qualifying as strictly conforming.

> Or possibly, successfully translate and link the program, without
> assurance that it can be executed?

Each implementation is required to translate and execute only one
program. That alone would be sufficient to render it unlikely that any
particular program must be executed, but the "one program" that must be
translated and executed has to meet minimum complexity requirements that
render it EXTREMELY unlikely to be the same as any particular program
that you actually want executed.

> The thing is, if it can't execute, that's as good as rejected.

Users are what requires an implementation of C to do anything useful;
the standard does not. They won't use one that doesn't. The C standard
only determines which useful things it should do, if it chooses to do them.

[toc] | [next] | [standalone]

#362593

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 */

[toc] | [prev] | [next] | [standalone]

#368595

On 2023-10-26, Keith Thompson <Keith.S.Thompson+u@gmail.com> wrote:
> 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?

Because it forgot to define what "accept" means. Stuff happens!

ISO 2382-1 1993 doesn't define "accept" but uses the word in a way that
means receiving input before processing it:

  01.03.05
  analog computer
  A computer whose operations are analogous to
  the behaviour of another system and that accepts,
  processes, and produces analog data.

To accept an input in this sense, all you have to do is buffer it and
generate any required acknowledgement signal, and then throw it away.

A definition of "accept" that is compatible with everything else in the
standard is "do not abruptly terminate without having completed
translation, and combination of translation units into a program,
regardless of the issuance of any diagnostics".

Now the host environment where translated programs execute is usually
not considered part of the implementation. The implementation may add
something to the program (like a library) but host environments exist
independently of the C language. Some host environments are produced
using tools having nothing to do with C, but are targeted by C
implementations.

The limits in what program may be executed, having been translated and
linked, are not coming from the C implementation.

Therefore, it is not reasonable to have requirements that the
implementaton must execute a program, since there are limitations in
the host environment to which the ISO C document doesn't speak,
and which the implementors may not be able to do anything about.

A C program could be compiled for a family of host systems. Some models
or installations of them may be equipped without enough resources to run
it, others not.

-- 
TXR Programming Language: http://nongnu.org/txr
Cygnal: Cygwin Native Application Library: http://kylheku.com/cygnal
Mastodon: @Kazinator@mstdn.ca
NOTE: If you use Google Groups, I don't see you, unless you're whitelisted.

[toc] | [prev] | [next] | [standalone]

#369484

Kaz Kylheku <864-117-4973@kylheku.com> writes:
> On 2023-10-26, Keith Thompson <Keith.S.Thompson+u@gmail.com> wrote:
>> 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?
>
> Because it forgot to define what "accept" means. Stuff happens!

Yes, they forgot to define what "accept" means.  I'm expressing skepticism
that they intended to define it in such a useless manner.

> ISO 2382-1 1993 doesn't define "accept" but uses the word in a way that
> means receiving input before processing it:
>
>   01.03.05
>   analog computer
>   A computer whose operations are analogous to
>   the behaviour of another system and that accepts,
>   processes, and produces analog data.
>
> To accept an input in this sense, all you have to do is buffer it and
> generate any required acknowledgement signal, and then throw it away.
>
> A definition of "accept" that is compatible with everything else in the
> standard is "do not abruptly terminate without having completed
> translation, and combination of translation units into a program,
> regardless of the issuance of any diagnostics".

That sounds about right -- and is not consistent with printing "Program
accepted" and doing nothing else.

> Now the host environment where translated programs execute is usually
> not considered part of the implementation. The implementation may add
> something to the program (like a library) but host environments exist
> independently of the C language. Some host environments are produced
> using tools having nothing to do with C, but are targeted by C
> implementations.

Perhaps not part of the implementation, but it's within the scope of the
standard.

Section 5 (Environment):

    An implementation translates C source files and executes C
    programs in two data-processing-system environments, which
    will be called the *translation environment* and the *execution
    environment* in this International Standard. Their characteristics
    define and constrain the results of executing conforming C
    programs constructed according to the syntactic and semantic
    rules for conforming implementations.

> The limits in what program may be executed, having been translated and
> linked, are not coming from the C implementation.
>
> Therefore, it is not reasonable to have requirements that the
> implementaton must execute a program, since there are limitations in
> the host environment to which the ISO C document doesn't speak,
> and which the implementors may not be able to do anything about.

Much of the standard defines the execution-time behavior of programs.
There is no such behavior without a working execution environment.
If `puts("hello")` prints "good-bye" because of something in the
environment, the implementation is non-conforming because it failed
to arrange for the right thing to happen at run time.

> A C program could be compiled for a family of host systems. Some models
> or installations of them may be equipped without enough resources to run
> it, others not.

True.  I'd say that there has to be at least one target system that can
execute the program for the implementation to be conforming.

-- 
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 */

[toc] | [prev] | [standalone]

Back to top | Article view | comp.lang.c

csiph-web