C Quiz
 

Does the following program invoke undefined behaviour?

int x;
int f(void) {
x = 1;
return 2;
}
int main(void) {
x = f();
}

Re: C Quiz
 

On 06/18/10 09:28 PM, flameice9 wrote:
> Does the following program invoke undefined behaviour?
>
> int x;
> int f(void) {
> x = 1;
> return 2;
> }
> int main(void) {
> x = f();
> }

No.

--
Ian Collins

Re: C Quiz
 

Il 18/06/2010 11:28, flameice9 ha scritto:
> Does the following program invoke undefined behaviour?
>
> int x;
> int f(void) {
> x = 1;
> return 2;
> }
> int main(void) {
> x = f();
> }

Its behaviour is pretty well-defined:

1) x==0 before calling f
2) x==1 before returning from f
3) x==2 before returning(?) from main

--
Vincenzo Mercuri

Re: C Quiz
 

Le 18/06/2010 11:28, flameice9 a écrit :
> Does the following program invoke undefined behaviour?
>
> int x;
> int f(void) {
> x = 1;
> return 2;
> }
> int main(void) {
> x = f();
> }

No. However, in a hosted environment, the termination status returned to
the host environment is unspecified.
To fix this, before the last } in main() add this line:
return 0;

Francois Grieu

Re: C Quiz
 

On Jun 18, 4:31*am, Ian Collins <ian-n...@hotmail.com> wrote:
> On 06/18/10 09:28 PM, flameice9 wrote:
>
> > Does the following program invoke undefined behaviour?
>
> > int x;
> > int f(void) {
> > * *x = 1;
> > * *return 2;
> > }
> > int main(void) {
> > * *x = f();
> > }
>
> No.

The standard says only that the updating of the stored value of the
left
operand of the = operator is performed between the previous and next
sequence point. What stops an implementation from noticing f always
returns 2 and deciding to perform this update prior to the call to f?
Worse, what stops an implementation from deciding to perform this
update
"at the same time" as the x = 1 expression inside f, thus modifying x
twice between sequence points?

Re: C Quiz
 

On Fri, 18 Jun 2010, flameice9 wrote:

> On Jun 18, 4:31*am, Ian Collins <ian-n...@hotmail.com> wrote:
>> On 06/18/10 09:28 PM, flameice9 wrote:
>>
>>> Does the following program invoke undefined behaviour?
>>
>>> int x;
>>> int f(void) {
>>> * *x = 1;
>>> * *return 2;
>>> }
>>> int main(void) {
>>> * *x = f();
>>> }
>>
>> No.
>
> The standard says only that the updating of the stored value of the left
> operand of the = operator is performed between the previous and next
> sequence point. What stops an implementation from noticing f always
> returns 2 and deciding to perform this update prior to the call to f?
> Worse, what stops an implementation from deciding to perform this update
> "at the same time" as the x = 1 expression inside f, thus modifying x
> twice between sequence points?

An implementation must comply with the workings of the abstract machine.

In main(), x can't be assigned to until f() is evaluated (= until f()
returns). When f() returns, the "x = 1" assignment is complete. (There is
a sequence point after that expression in f().) In main(), you need the
value returned by f() to evaluate the assignment operator. At that time,
"x = 1" is already complete.

Somewhat related:

http://www.open-std.org/Jtc1/sc22/wg...cs/dr_087.html

lacos

Re: C Quiz
 

Francois Grieu wrote:

> Le 18/06/2010 11:28, flameice9 a écrit :
>> Does the following program invoke undefined behaviour?
>>
>> int x;
>> int f(void) {
>> x = 1;
>> return 2;
>> }
>> int main(void) {
>> x = f();
>> }
>
> No. However, in a hosted environment, the termination status returned to
> the host environment is unspecified.
> To fix this, before the last } in main() add this line:
> return 0;
>
> Francois Grieu

C99 5.1.2.2.3: "... reaching the } that terminates the main function returns
a value of 0."

(I have only the N1256 draft, though)

Re: C Quiz
 

flameice9 <flameice9@gmail.com> wrote:

> On Jun 18, 4:31=A0am, Ian Collins <ian-n...@hotmail.com> wrote:
> > On 06/18/10 09:28 PM, flameice9 wrote:
> >
> > > Does the following program invoke undefined behaviour?

[ I've rearranged it slightly for legibility; no behaviour changes. ]

> > > int x;
> > >
> > > int f(void)
> > > {
> > > x = 1;
> > > return 2;
> > > }
> > >
> > > int main(void)
> > > {
> > > x = f();
> > > }
> >
> > No.
>
> The standard says only that the updating of the stored value of the left
> operand of the = operator is performed between the previous and next
> sequence point. What stops an implementation from noticing f always
> returns 2 and deciding to perform this update prior to the call to f?

The sequence points. There's one just before the call to f(), and one
just after each statement inside f().

Richard

Re: C Quiz
 

Francois Grieu <fgrieu@gmail.com> writes:

> Le 18/06/2010 11:28, flameice9 a écrit :
>> Does the following program invoke undefined behaviour?
>>
>> int x;
>> int f(void) {
>> x = 1;
>> return 2;
>> }
>> int main(void) {
>> x = f();
>> }
>
> No. However, in a hosted environment, the termination status returned to
> the host environment is unspecified.

Not in C99. Omitting the return is permitted.

> To fix this, before the last } in main() add this line:
> return 0;

That's the effect, in C99, of leaving out the return.

--
Ben.

Re: C Quiz
 

On Jun 18, 6:04 am, "Ersek, Laszlo" <la...@caesar.elte.hu> wrote:
> On Fri, 18 Jun 2010, flameice9 wrote:
>> On Jun 18, 4:31 am, Ian Collins <ian-n...@hotmail.com> wrote:
>>> On 06/18/10 09:28 PM, flameice9 wrote:
>
>>>> Does the following program invoke undefined behaviour?
>
>>>> int x;
>>>> int f(void) {
>>>> x = 1;
>>>> return 2;
>>>> }
>>>> int main(void) {
>>>> x = f();
>>>> }
>
>>> No.
>
>> The standard says only that the updating of the stored value of the left
>> operand of the = operator is performed between the previous and next
>> sequence point. What stops an implementation from noticing f always
>> returns 2 and deciding to perform this update prior to the call to f?
>> Worse, what stops an implementation from deciding to perform this update
>> "at the same time" as the x = 1 expression inside f, thus modifying x
>> twice between sequence points?
>
> An implementation must comply with the workings of the abstract machine.
>
> In main(), x can't be assigned to until f() is evaluated (= until f()
> returns).

This makes sense intuitively, but there appears to be nothing
requiring a function call to be evaluated prior to its returned value
being used. Of course, this is possible only for functions for which
the returned value can be deduced prior to the call.