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


Groups > comp.lang.c > #369484

Re: Call to a function

From Keith Thompson <Keith.S.Thompson+u@gmail.com>
Newsgroups comp.lang.c
Subject Re: Call to a function
Date 2023-10-26 16:27 -0700
Organization None to speak of
Message-ID <877cn9j77a.fsf@nosuchdomain.example.com> (permalink)
References (6 earlier) <uha85r$ha56$1@dont-email.me> <20231024233859.368@kylheku.com> <uhcnnv$1b5bv$1@dont-email.me> <87msw5kgf5.fsf@nosuchdomain.example.com> <20231026091057.177@kylheku.com>

Show all headers | View raw


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

Back to comp.lang.c | Previous | NextPrevious 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