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

Groups > comp.lang.c > #371874 > 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-27 01:42 -0400
    Re: Call to a function Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2023-10-27 01:53 -0700
      Re: Call to a function James Kuyper <jameskuyper@alumni.caltech.edu> - 2023-10-27 12:35 -0400
        OT: Retirement (was Re: Call to a function) Vir Campestris <vir.campestris@invalid.invalid> - 2023-10-29 21:05 +0000
      Re: Call to a function Tim Rentsch <tr.17687@z991.linuxsc.com> - 2023-11-09 13:25 -0800
    Re: Call to a function gazelle@shell.xmission.com (Kenny McCormack) - 2023-10-27 09:18 +0000
      Re: Call to a function Kaz Kylheku <864-117-4973@kylheku.com> - 2023-10-27 16:27 +0000
      Re: Call to a function James Kuyper <jameskuyper@alumni.caltech.edu> - 2023-10-27 12:41 -0400

#371874 — Re: Call to a function

On 10/26/23 03:10, Keith Thompson wrote:
> James Kuyper <jameskuyper@alumni.caltech.edu> writes:
>> On 10/25/23 02:46, Kaz Kylheku wrote:
...
>>> ... 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?

It has a completely useless definition of "conforming". It has 5.2.4.1,
cited by you below, which is flawed in a way that renders it essentially
useless. Why shouldn't it have other useless clauses? The committee can
make mistakes, and has even doubled down on many of them.

It has been decades since the first time I saw someone point out that
"accept" is not defined by the standard, with active committee members
participating in the discussion. I have to accept that the committee
does not feel that this is a flaw urgently in need of correction - which
I consider a mistake by the committee.

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

If the "one program" for a given implementation of C is strictly
conforming, that would render 5.2.4.1 redundant.
If the "one program" is not strictly conforming, then 5.2.4.1 serves
merely to mandate something for one program which was not strictly
conforming, which was already mandated for all strictly conforming ones.

The combination of those clauses makes sense to me only if "accept" were
meant to be somewhat less strong of a requirement than "successfully
translate and execute".

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

It does so by mandating the existence of only one program that must be
constrained by those requirements, which are minima for that program,
not maxima. That's a lousy way to specify maxima that were intended to
apply to programs other than the "one program". I agree that this seems
to have been the intent, but it fails to express that intent.

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

And as a result of the way that the standard expressed those
requirements, an implementation could have capacity limits that prevent
it from translating and executing any program other than the "one
program" that it's required to translate and execute, without failing to
conform to the standard.

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

I can agree that a conforming implementation is required to accept that
code, whatever it is that "accept" means - your conclusion follows from
your beliefs about what "accept" means. For myself, I believe that after
accepting such code, a fully conforming implementation can then fail to
translate and execute that code, due to it exceeding that
implementation's capacity.

[toc] | [next] | [standalone]

#373479

James Kuyper <jameskuyper@alumni.caltech.edu> writes:
> On 10/26/23 03:10, Keith Thompson wrote:
>> James Kuyper <jameskuyper@alumni.caltech.edu> writes:
>>> On 10/25/23 02:46, Kaz Kylheku wrote:
> ...
>>>> ... 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?
>
> It has a completely useless definition of "conforming". It has 5.2.4.1,
> cited by you below, which is flawed in a way that renders it essentially
> useless. Why shouldn't it have other useless clauses? The committee can
> make mistakes, and has even doubled down on many of them.

"Conforming" (defined as "acceptable to a conforming implementation") is
not particularly useful, but it's a definition of a term, not a
requirement.  I don't think anything in the standard depends on any
program being "conforming".

I don't agree that 5.2.4.1 is as flawed as you suggest it is.

> It has been decades since the first time I saw someone point out that
> "accept" is not defined by the standard, with active committee members
> participating in the discussion. I have to accept that the committee
> does not feel that this is a flaw urgently in need of correction - which
> I consider a mistake by the committee.
>
>> I suggest that "accept" *does* (or at least should) mean "successfully
>> translate and execute".
>
> If the "one program" for a given implementation of C is strictly
> conforming, that would render 5.2.4.1 redundant.
> If the "one program" is not strictly conforming, then 5.2.4.1 serves
> merely to mandate something for one program which was not strictly
> conforming, which was already mandated for all strictly conforming ones.

My interpretation (perhaps not fully supported by the wording of the
standard) is that the requirement to accept any strictly conforming
program is conditional on that program not exceeding the
implementation's capacity.  You could construct a strictly conforming
program (which does not exceed any of the minimum translation limits)
that's so huge and complex that an implementation could not reasonably
be expected to translate it.  A compiler might run out of memory trying
to compile it, and either crash or die with an error message before it
could even determine that the program is strictly conforming.  I don't
think it's reasonable to call that "accepting" the program.

The "one program" must be one that does not exceed the implementation's
capacity.  It's a way of strongly encouraging implementers to have
reasonable capacity limits.

> The combination of those clauses makes sense to me only if "accept" were
> meant to be somewhat less strong of a requirement than "successfully
> translate and execute".
>
>> 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.)
>
> It does so by mandating the existence of only one program that must be
> constrained by those requirements, which are minima for that program,
> not maxima. That's a lousy way to specify maxima that were intended to
> apply to programs other than the "one program". I agree that this seems
> to have been the intent, but it fails to express that intent.
>
> ...
>> 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.
>
> And as a result of the way that the standard expressed those
> requirements, an implementation could have capacity limits that prevent
> it from translating and executing any program other than the "one
> program" that it's required to translate and execute, without failing to
> conform to the standard.

Yes, of course.  A very perverse implementation could detect the "one
program" and generate code for it (the "one program" might print "hello,
world", for example), and print a fatal capacity error for anything
else.  I've been tempted to create such an implementation myself.
(Yes, I have odd ideas of fun.)

But it would have to be a deliberately useless implementation.  If
you're trying to create a *useful* implementation, the easiest way to
satisfy the "one program" requirement is to have reasonably large
capacity limits, for example by having all compiler internal data
structures be dynamic so the capacity is exceeded only when there's not
enough memory.

>> 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".
>
> I can agree that a conforming implementation is required to accept that
> code, whatever it is that "accept" means - your conclusion follows from
> your beliefs about what "accept" means. For myself, I believe that after
> accepting such code, a fully conforming implementation can then fail to
> translate and execute that code, due to it exceeding that
> implementation's capacity.

Sure, capacity is not clearly defined, and is explicitly outside the
scope of the standard.  But no real compiler is going to run out of
resources trying to compile that 8-line program.  My whole point is
that, in my opinion, a compiler may not use the conversion from int* to
func* as a justification for rejecting it.  Capacity limits, interesting
as they are, are a distraction from the point I was making with that
program.

-- 
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]

#377480

On 10/27/23 04:53, Keith Thompson wrote:
> James Kuyper <jameskuyper@alumni.caltech.edu> writes:
...
>> And as a result of the way that the standard expressed those
>> requirements, an implementation could have capacity limits that prevent
>> it from translating and executing any program other than the "one
>> program" that it's required to translate and execute, without failing to
>> conform to the standard.
> 
> Yes, of course.  A very perverse implementation could detect the "one
> program" and generate code for it (the "one program" might print "hello,
> world", for example), and print a fatal capacity error for anything
> else.  I've been tempted to create such an implementation myself.
> (Yes, I have odd ideas of fun.)

Now that I'm retired, I've actually started working on such an
implementation. I call it MinimalC. I decided to make it a more
interesting project by including support for multiple different versions
of the C standard, starting with C90. I decided to use it as an excuse
to get familiar with several development tools that I didn't have much
time to learn while I was employed, such as flex, bison, Doxygen,
BibTeX, and the Eclipse IDE, as well as the new Unicode support provided
by recent versions of C and C++. While I've used SVN before, this is the
first time I've been the person who sets up SVN. I'm learning a lot. I'm
also getting stuck a lot - but nothing depends upon me meeting a
schedule anymore.
However, due to taking care of twin 8-year olds and being a househusband
while my (younger) wife continues working, I've found that my retirement
doesn't leave me with anywhere near as much free time as I'd hoped.
Don't hold your breath waiting for me to release MinimalC.

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

#379396 — OT: Retirement (was Re: Call to a function)

On 27/10/2023 17:35, James Kuyper wrote:
> However, due to taking care of twin 8-year olds and being a househusband 
> while my (younger) wife continues working, I've found that my retirement 
> doesn't leave me with anywhere near as much free time as I'd hoped. 
> Don't hold your breath waiting for me to release MinimalC.

James, my wife quit before I did (and acted as project manager for our 
house, which needed lots of work. Our house is older than your country).

We have no grandchildren.

And yet still I don't have free time. I've got a lot fitter though, and 
the garden is much neater!

Andy

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

#379493

Keith Thompson <Keith.S.Thompson+u@gmail.com> writes:
> 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)  [...]
>>>
>>> What does "accept" mean?  I don't see it defined. ...

I would like to address the meaning of "accept".  Please bear with
me as I work through excerpts from two postings, the second one
the grandchild of this first one.  (Some text may be pruned or
reordered, but I have made an effort to keep the attributions
intact and correct.)

The term "accept" is commonly used in the field of automata theory.
It means something like "to admit as satisfying the criteria" of the
automata in question.  For example, if an automata to determine
primality accepts an input it means the input is a prime number.
This sense of accept is close to what the C standard means.

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

It's more likely that the ISO C committee meant "accept" in some
more technical sense (probably similar to the usage explained above)
than in the sense of an ordinary English meaning.

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

The word "accept" has lots of antonyms:  deny, veto, snub, shun,
spurn, demur, reject, refuse, resist, rebuff, oppose, decline,
dismiss, disallow, renounce, repudiate, blackball, and disapprove
are just some of the dozens of easily findable antonyms.  Looking
over the list, I think a better opposite word is not "reject" but
"dismiss", which suggests these definitions:

accept:      admit as suitable for translation (by this implementation)
(opposite):  dismiss as unsuitable for translation (by this implementation)

These definitions provide a good fit to how the word "accept" is
used in the C standard, including other parts of the standard that
talk about translation or execution but don't use the word "accept"
explicitly.

Note in particular that "accept" is a prerequisite for translation,
not the other way around, which is consistent with how the standard
uses these terms.

>>> [it seems inconsistent for "accept" to mean "successfully
>>>  translate and execute"]
>>
>> 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.  [...]

This statement implicitly offers a false dichotomy.  What "accept"
means can be less stringent than "translate and execute" but still
imply more than just printing a "program accepted" message.

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

Obviously this statement cannot be right.  For one thing, it's not
possible.  Perhaps more to the point, it is well established that
the C standard allows an implementation to be conforming even if
it can translate and execute only one program.  There were heated
debates on the topic when the original C standard was formed.  The
meaning of "accept" needs to be determined by what the standard
actually says about its requirements, not what we might want it to
say.

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

These paragraphs confuse several distinct notions and entities.  The
term "limits" is used (in many places) in relation to implementations.
The term "capacity" appears in the standard exactly twice, once in
relation to a data-processing system, and once in relation to a
processor.  The compound term "capacity limits" is never used.  The
last item in 1p2 

    [the standard does not specify] all minimal requirements of a
    data-processing system that is capable of supporting a conforming
    implementation.

makes it clear that "implementations" and "data-processing systems"
are two different things (and of course processors occupy yet a third
category).  This distinction makes sense:  if I run gcc on my colo
server (which has 1GB of RAM), or if I run gcc on my compute server
(which has 128GB of RAM), in both cases the implementation is gcc (and
glibc or similar);  it is only the underlying data-processing system
that is different.


> [...]
>
> 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**.

Implementations have implementation limits (described in many places
in the standard).  Data-processing systems (and also processors) have
capacities, about which the standard has nothing to say, not even
implicitly.  The compound phrase "capacity limits" is meaningless.

[and now on to the second message]

Keith Thompson <Keith.S.Thompson+u@gmail.com> writes:
> James Kuyper <jameskuyper@alumni.caltech.edu> writes:
>> On 10/26/23 03:10, Keith Thompson wrote:

>>> I suggest that "accept" *does* (or at least should) mean
>>> "successfully translate and execute".
>>
>> If the "one program" for a given implementation of C is strictly
>> conforming, that would render 5.2.4.1 redundant.
>> If the "one program" is not strictly conforming, then 5.2.4.1
>> serves merely to mandate something for one program which was not
>> strictly conforming, which was already mandated for all strictly
>> conforming ones.
>
> My interpretation (perhaps not fully supported by the wording of
> the standard) is that the requirement to accept any strictly
> conforming program is conditional on that program not exceeding
> the implementation's capacity.

A. It isn't.  The standard means what it says.  It's up to us to
find a definition for "accept" that's consistent with what the C
standard does say, not with what we think it ought to say.  The
definitions I gave above for "accept" and "dismiss" (meant as
opposite to accept) are consistent with what the standard actually
says, without any problem from what might occur when an attempt is
made to translate a program.

B. Perhaps a better way to understand what "accept" means is to
look at its opposite.  This program

    int
    main(void){
        return  (((0)));
    }

must be accepted (that is, an implementation must deem it suitable
for translation, and attempt to translate it), because it is
strictly conforming.  The attempt to translate is key.  On the
flip side, this program

    int
    main(void){
        return
            ((((((((((((((((((((((((((((((((((((((((((((((((((
            ((((((((((((((((((((((((((((((((((((((((((((((((((
                0
            ))))))))))))))))))))))))))))))))))))))))))))))))))
            ))))))))))))))))))))))))))))))))))))))))))))))))))
        ;
    }

does not have to be accepted (it isn't strictly conforming, because
it exceeds a minimum implementation limit).  An implementation is
free to dismiss the program as being unsuitable for translation (by
that implementation), by virtue of not meeting all the requirements
for a strictly conforming program.

Similarly, consider this source file

    extern char big[2305843009213693952];

An implementation is free to dismiss (and so not accept) this source
file, because it exceeds a minimum implementation limit.  In fact,
trying to compile it with clang gives an error (under -pedantic),
complaining that the array is too large.  Compiling with gcc works
without complaint.  Furthermore, this source file

    extern char big[2305843009213693951];

is accepted (and successfully translated) by both gcc and clang.
Clearly clang is exercising its "editorial discretion" not to
accept the larger array declaration, which it is entitled to do
because the size of the object 'big' exceeds a specified minimum
implementation limit (for a hosted implementation, which surely gcc
and clang are both meant to be).

> You could construct a strictly conforming program (which does not
> exceed any of the minimum translation limits) that's so huge and
> complex that an implementation could not reasonably be expected to
> translate it.  A compiler might run out of memory trying to
> compile it, and either crash or die with an error message before
> it could even determine that the program is strictly conforming.
> I don't think it's reasonable to call that "accepting" the
> program.

The implementation is accepting the program by virtue of trying to
translate it.  If during the attempted translation some unsuitable
condition is discovered the program can be dismissed with an error
message.  If on the other hand some resource is exhausted and the
compiler has to give up, it is still accepting the program, which
is, as far as the compiler can tell up to that point, suitable for
translation by this implementation.  Deeming an input suitable for
translation doesn't mean an attempted translation will succeed
(which is unknowable, and certainly cannot be guaranteed);  it
means only that as far as the compiler can tell there is nothing
in the program text seen up to that point that would make it
unsatisfactory under that implementation.  The C standard draws
a bright line for what the lower bar is for which programs must
be deemed suitable for translation;  anything above that lower
bar is left up to implementation, and is purely a quality-of-
implementation matter, not a conformance question.

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

#373700

In article <uhfija$249ng$1@dont-email.me>,
James Kuyper  <jameskuyper@alumni.caltech.edu> wrote:
...
>It has been decades since the first time I saw someone point out that
>"accept" is not defined by the standard, with active committee members
>participating in the discussion. I have to accept that the committee
>does not feel that this is a flaw urgently in need of correction - which
>I consider a mistake by the committee.
>
>> I suggest that "accept" *does* (or at least should) mean "successfully
>> translate and execute".

But if they did that (defined "accept" as shown above), then wouldn't they
then have to define "successfully", "translate", and "execute"?

And so on, and so on...

-- 
The randomly chosen signature file that would have appeared here is more than 4
lines long.  As such, it violates one or more Usenet RFCs.  In order to remain
in compliance with said RFCs, the actual sig can be found at the following URL:
	http://user.xmission.com/~gazelle/Sigs/RepInsults

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

#377434

On 2023-10-27, Kenny McCormack <gazelle@shell.xmission.com> wrote:
> In article <uhfija$249ng$1@dont-email.me>,
> James Kuyper  <jameskuyper@alumni.caltech.edu> wrote:
> ...
>>It has been decades since the first time I saw someone point out that
>>"accept" is not defined by the standard, with active committee members
>>participating in the discussion. I have to accept that the committee
>>does not feel that this is a flaw urgently in need of correction - which
>>I consider a mistake by the committee.
>>
>>> I suggest that "accept" *does* (or at least should) mean "successfully
>>> translate and execute".
>
> But if they did that (defined "accept" as shown above), then wouldn't they
> then have to define "successfully", "translate", and "execute"?

It depends. Translate is what the implementation does; it has
translation phases. So it can be understood from that.

Successfully is nuanced, and could benefit from a definition:

  successful execution: performance of all requirements in relation to
  the semantics of a specific, strictly conforming program,
  uninterrupted by an abrupt termination. Note that this concept is
  independent of the termination status of the program; a program
  whose termination status is unsuccessful is successfully executed
  if it passes that point whereupon it indicates that termination status
  to the host environment.

Someone should write a program which tabulates all words used in the
standrad, and then go through them one by one, identifying which ones
need a definition.

The standard should also cite a specific edition of a specific
English-language dictionary, as the source of definitions of words
that are not defined in the document, or in that ridiculous ISO 2382-1.

Speaking of which, ISO 2382-1 is replete with embarassing drivel; it
should be discontinued as a normative reference.  You will never find a
satisfying answer to any matter of terminology in that reference;
I suspect that including might just some boilerplate imposed by ISO.

-- 
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]

#377523

On 2023-10-27, Kenny McCormack <gazelle@shell.xmission.com> wrote:
> In article <uhfija$249ng$1@dont-email.me>,
> James Kuyper  <jameskuyper@alumni.caltech.edu> wrote:
> ...
>>It has been decades since the first time I saw someone point out that
>>"accept" is not defined by the standard, with active committee members
>>participating in the discussion. I have to accept that the committee
>>does not feel that this is a flaw urgently in need of correction - which
>>I consider a mistake by the committee.
>>
>>> I suggest that "accept" *does* (or at least should) mean "successfully
>>> translate and execute".
>
> But if they did that (defined "accept" as shown above), then wouldn't they
> then have to define "successfully", "translate", and "execute"?

The meaning of "translate" is implicitly adequately defined by the
translation phases section. The meaning of "execute" is adequately clear
from the semantics sections is part 6 and 7. Of those phrases, "accept"
is the only problematic one.

[toc] | [prev] | [standalone]

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

csiph-web