Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.c > #369484
| 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> |
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 | Next — Previous in thread | Find similar | Unroll 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