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

Groups > comp.lang.c > #373479

Re: Call to a function

Show all headers | View raw

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

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

csiph-web