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

Groups > comp.lang.c > #349688 > 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 Tim Rentsch <tr.17687@z991.linuxsc.com> - 2023-10-24 20:54 -0700
    Re: Call to a function Richard Damon <richard@damon-family.org> - 2023-10-24 21:27 -0700
    Re: Call to a function Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2023-10-24 21:58 -0700
    Re: Call to a function James Kuyper <jameskuyper@alumni.caltech.edu> - 2023-10-25 01:13 -0400
      Re: Call to a function Kaz Kylheku <864-117-4973@kylheku.com> - 2023-10-25 06:46 +0000
    Re: Call to a function Kaz Kylheku <864-117-4973@kylheku.com> - 2023-10-25 06:37 +0000

#349688 — Re: Call to a function

Keith Thompson <Keith.S.Thompson+u@gmail.com> writes:

> Tim Rentsch <tr.17687@z991.linuxsc.com> writes:
> [...]
>
>> The point isn't quite the same.  The C standard explicitly says
>> integers may be converted to any pointer type.  The C standard
>> does not say that a pointer to an object type may be converted
>> to a pointer to function type.  Every implementation is within
>> its rights to reject any program whose static text includes[*] a
>> cast from a pointer to an object type to a pointer to function
>> type, regardless of whether the cast has any chance of being
>> executed.
>>
>> [*] meaning, still present as source of any preprocessor
>> conditionals have been processed, etc.
>
> I disagree.  (I think we've discussed this before.)
>
> Concretely, I believe that this program violates no syntax error
> or constraint.  It includes code whose behavior would be undefined
> if it were executed, but the `if (0)` prevents that.
>
> On what basis do you think a conforming implementation may reject
> it?

First let me ask a question.  Does the C standard allow an
implementation to reject any program that is not strictly
conforming?

[toc] | [next] | [standalone]

#349910

On 10/24/23 8:54 PM, Tim Rentsch wrote:
> Keith Thompson <Keith.S.Thompson+u@gmail.com> writes:
> 
>> Tim Rentsch <tr.17687@z991.linuxsc.com> writes:
>> [...]
>>
>>> The point isn't quite the same.  The C standard explicitly says
>>> integers may be converted to any pointer type.  The C standard
>>> does not say that a pointer to an object type may be converted
>>> to a pointer to function type.  Every implementation is within
>>> its rights to reject any program whose static text includes[*] a
>>> cast from a pointer to an object type to a pointer to function
>>> type, regardless of whether the cast has any chance of being
>>> executed.
>>>
>>> [*] meaning, still present as source of any preprocessor
>>> conditionals have been processed, etc.
>>
>> I disagree.  (I think we've discussed this before.)
>>
>> Concretely, I believe that this program violates no syntax error
>> or constraint.  It includes code whose behavior would be undefined
>> if it were executed, but the `if (0)` prevents that.
>>
>> On what basis do you think a conforming implementation may reject
>> it?
> 
> First let me ask a question.  Does the C standard allow an
> implementation to reject any program that is not strictly
> conforming?

No, to reject a program it must violate some constraint.

Not being 'strictly conforming' (a technical term in the Standard) is 
not a requirement for a program to be accepted.

Now, there is the escape clause, that allows an implementation to fail 
to actually be able to run anything but the one specified program that 
meets all the minimum requirements, but that isn't grounds to 'reject' 
programs.

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

#350134

Tim Rentsch <tr.17687@z991.linuxsc.com> writes:
> Keith Thompson <Keith.S.Thompson+u@gmail.com> writes:
>> Tim Rentsch <tr.17687@z991.linuxsc.com> writes:
>> [...]
>>> The point isn't quite the same.  The C standard explicitly says
>>> integers may be converted to any pointer type.  The C standard
>>> does not say that a pointer to an object type may be converted
>>> to a pointer to function type.  Every implementation is within
>>> its rights to reject any program whose static text includes[*] a
>>> cast from a pointer to an object type to a pointer to function
>>> type, regardless of whether the cast has any chance of being
>>> executed.
>>>
>>> [*] meaning, still present as source of any preprocessor
>>> conditionals have been processed, etc.
>>
>> I disagree.  (I think we've discussed this before.)
>>
>> Concretely, I believe that this program violates no syntax error
>> or constraint.  It includes code whose behavior would be undefined
>> if it were executed, but the `if (0)` prevents that.
>>
>> On what basis do you think a conforming implementation may reject
>> it?
>
> First let me ask a question.  Does the C standard allow an
> implementation to reject any program that is not strictly
> conforming?

Not just for that reason.

This program:

#include <stdio.h>
int main(void) {
    printf("%zu\n", sizeof (int));
}

is not strictly conforming, since it depends on the
implementation-defined size of int.  A hosted implementation that
rejected it would violate 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.

(A perverse implementation could claim that it exceeds its capacity, but
I think we can ignore that.)

What is your answer to your own question?

And I hope we're not going to go back and forth too many times before
you answer mine.

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

#350223

On 10/24/23 8:54 PM, Tim Rentsch wrote:
> Keith Thompson <Keith.S.Thompson+u@gmail.com> writes:
> 
>> Tim Rentsch <tr.17687@z991.linuxsc.com> writes:
>> [...]
>>
>>> The point isn't quite the same.  The C standard explicitly says
>>> integers may be converted to any pointer type.  The C standard
>>> does not say that a pointer to an object type may be converted
>>> to a pointer to function type.  Every implementation is within
>>> its rights to reject any program whose static text includes[*] a
>>> cast from a pointer to an object type to a pointer to function
>>> type, regardless of whether the cast has any chance of being
>>> executed.
>>>
>>> [*] meaning, still present as source of any preprocessor
>>> conditionals have been processed, etc.
>>
>> I disagree.  (I think we've discussed this before.)
>>
>> Concretely, I believe that this program violates no syntax error
>> or constraint.  It includes code whose behavior would be undefined
>> if it were executed, but the `if (0)` prevents that.
>>
>> On what basis do you think a conforming implementation may reject
>> it?
> 
> First let me ask a question.  Does the C standard allow an
> implementation to reject any program that is not strictly
> conforming?

"A strictly conforming program shall use only those features of the
language and library specified in this International Standard.3) It
shall not produce output dependent on any unspecified, undefined, or
implementation-defined behavior, and shall not exceed any minimum
implementation limit." (4p5)

DR 109 addresses a function named foo() which contains the line "1/0;",
but there was no guarantee that the function would ever be called - in
fact, the function definition was the only part of the program mentioned
in the DR. The committee ruled that:

"... if every possible execution of a given program would result in
undefined behavior, the given program is not strictly conforming.
A conforming implementation must not fail to translate a strictly
conforming program simply because some possible execution of that
program would result in undefined behavior. Because foo might never be
called, the example given must be successfully translated by a
conforming implementation. "

In DR 109, the program was not guaranteed to execute 1/0. The program
that Keith provided (which you snipped) is much safer - it uses an if(0)
to guarantee that the code that might have undefined behavior will NOT
be executed. If the DR109 code doesn't prevent the program from being
strictly conforming, this certainly should not.

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.

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

#350954

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. 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? If
"accept" means "translate and execute", then the above quoted
requirement means that the implementation must accept every possible
such program, not just "a" program.

Might "accept" might mean, roughly, parse the syntax, check constraints
and report no issues that would stop further translation?

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

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

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

#350866

On 2023-10-25, Tim Rentsch <tr.17687@z991.linuxsc.com> wrote:
> First let me ask a question.  Does the C standard allow an
> implementation to reject any program that is not strictly
> conforming?

I think, yes.

"This document 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;"

"The implementation shall be able to translate and execute a program
that uses but does not exceed the following limitations for these
constructs and entities ..."

There can be programs which stay within the limits, and are even
strictly conforming, which an implementation might not handle.

An implementation has to demonstrate translating and executing only one
("a") program which strains all the limits. It is not spelled out who
gets to choose the test case. Either the implementors choose the test
case, or else if their users choose the test cases, the implementors can
fix whatever it takes to make just one of them pass, and then the
conformance requirement is satisfied.

That leaves margin for the existence of strictly conforming programs
that are not handled.

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

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

csiph-web