Is this return UB ?

[dada]

Is this return UB ?


int someFunt ()
{
static int i = 0 ;

return i++ ;
}

WHat we want is the first time to return 0, next 1, etc

some thoughts ?

Thanks !
Joe
WB2JQT

 

[Richard Heathfield]

dada said:

Is this return UB ?


int someFunt ()
{
static int i = 0 ;

return i++ ;
}

WHat we want is the first time to return 0, next 1, etc

That's fine, until you hit INT_MAX. If you don't plan to get that high,
no problem.

 

[dada]

dada said:




That's fine, until you hit INT_MAX. If you don't plan to get that high,
no problem.

Thanks Richard.
I think there is more logic in the actual function for wrap around,
but the gist of the question was about what was returned.

Joe

 

[Jens Thoms Toerring]

I think there is more logic in the actual function for wrap around,
but the gist of the question was about what was returned.

Sorry, but actually you didn't ask a question (or perhaps there
is but my English isn't up to it). If the question is what the
function returns on the very first call then the answer is 0.
And the return value the second time you call it is 1 (the post-
fix ++ operator is only applied after the value of the expres-
sion has been evaluated).
Regards, Jens

 

[Richard Heathfield]

Jens Thoms Toerring said:

Sorry, but actually you didn't ask a question (or perhaps there
is but my English isn't up to it).

Well, actually he did - he asked if the return statement invoked "UB" -
i.e. undefined behaviour (see above). It doesn't, as long as overflow
doesn't occur. He also pointed out what he wanted. My answer ("That's
fine..." - see above) covered both his explicit question and his
implicit request. Sorry if I didn't make this clearer.

If the question is what the
function returns on the very first call then the answer is 0.
And the return value the second time you call it is 1 (the post-
fix ++ operator is only applied after the value of the expres-
sion has been evaluated).

Er, kindasortakinda, yes. Actually, there's nothing to stop the compiler
doing something like:

INC I
MOV R1, I
DEC R1
RET

(other than the bounds of common sense, of course).

 

declare
static int var = 0;
as global variable not auto variable.....

and
return ( var++ )
now each calling will increment it

for eg.

#include<stdio.h>
static int x = 0;
int ret( void );

int main( void )
{
int i;
for ( i = 0; i < 100; i++ )
{
ret( );
printf( "%d\n", x );
}
_getch( );
return ( 0 );
}

int ret( void )
{
return( x ++ );
}

 

[Richard Heathfield]

@$|-|. DUBEY said:

declare
static int var = 0;
as global variable

Why? What benefit does it confer that overcomes the disadvantage of its
being defined at file scope?

not auto variable.....

He didn't define it as an auto object. Here's his code again:

int someFunt ()
{
static int i = 0 ;

return i++ ;
}

i has static storage duration, not automatic storage duration.

 

[Richard]

Jens Thoms Toerring said:


Well, actually he did - he asked if the return statement invoked "UB" -
i.e. undefined behaviour (see above). It doesn't, as long as overflow
doesn't occur. He also pointed out what he wanted. My answer ("That's
fine..." - see above) covered both his explicit question and his
implicit request. Sorry if I didn't make this clearer.


Er, kindasortakinda, yes. Actually, there's nothing to stop the compiler
doing something like:

INC I
MOV R1, I
DEC R1
RET

(other than the bounds of common sense, of course).

That is totally platform dependant and therefore ... you know.

As far as C goes, he was right. The ++ is applied to "i" after the value
of I is evaluated and handed to the return statement. There is no need
whatsoever to obfuscate this.

To the OP. You code does not exhibit "UB" until overflow. And then its
platform specific I believe.

 

[Richard Heathfield]

Richard said:

That is totally platform dependant and therefore ... you know.

Yes, exactly - that's what I was pointing out. To put it more formally,
I was making it clear that the order of evaluation is unspecified, and
I used a completely hypothetical but easily understood asm-like
pseudocode to make clear one possible (albeit weird) order of
evaluation that runs counter to our intuition. In your rush to post,
you seem to have missed the point of my reply (as ever).

As far as C goes, he was right. The ++ is applied to "i" after the
value of I is evaluated and handed to the return statement.

You also appear to have missed reading it. Your claim here is simply
false. The point at which the increment happens is unspecified.

There is no need whatsoever to obfuscate this.

Nor did I do so. But there is certainly no need to give an incorrect
explanation such as yours.

To the OP. You code does not exhibit "UB" until overflow.

I already pointed this out, some time ago. In your rush to post, you
seem to have missed this. Did you not claim that you do not bother to
post answers to questions that have already been answered?

And then its platform specific I believe.

You mean you don't know? I suggest you find out, by reading and
understanding instead of looking for any pretext, no matter how
spurious, to criticise those who *do* know.

But I'll tell you. The behaviour on overflow is undefined. The Standard
does *not* require that undefined behaviour must be platform-specific.
For all it cares, the behaviour could depend on the phase of the moon,
or some equally bizarre platform-independent phenomenon.

 

[Jack Klein]

declare
static int var = 0;
as global variable not auto variable.....

No, there is no gain and some loss to changing his already correct
definition of a static object at function scope. While it is
permissible to initialize a static scalar object with 0, it is
unnecessary and redundant.

and
return ( var++ )
now each calling will increment it

for eg.

#include<stdio.h>
static int x = 0;
int ret( void );

int main( void )
{
int i;
for ( i = 0; i < 100; i++ )
{
ret( );
printf( "%d\n", x );
}
_getch( );

There is no such function as "_getch" in C.

return ( 0 );

"return" is a statement, not a function. Remove the parentheses.

}

int ret( void )
{
return( x ++ );

Again, remove the parentheses. They haven't been required for 18
years.

--
Jack Klein
Home: http://JK-Technology.Com
FAQs for
comp.lang.c http://c-faq.com/
comp.lang.c++ http://www.parashift.com/c++-faq-lite/
alt.comp.lang.learn.c-c++
http://www.club.cc.cmu.edu/~ajo/docs/FAQ-acllc.html

 

[CBFalconer]

.... snip ...

Again, remove the parentheses. They haven't been required for
18 years.

Totally harmless. However, since 'return' is not a function, a
space between 'return' and the expression value would be valuable.
I.E. write as:

int ret(void) {
return (x++); /* or 'return x++;' */
}

This sort of emphasis on removing redundant pararentheses can cause
evil errors, especially in macros.

 

[Old Wolf]

While it is permissible to initialize a static scalar
object with 0, it is unnecessary and redundant.

I think it helps the code readability.

 

[Dietmar Schindler]

This sort of emphasis on removing redundant pararentheses can cause
evil errors, especially in macros.

It can't, since the parentheses are redundant. And while we're at it, I
also suggest removing redundant "ar"s.

 

[CBFalconer]

It can't, since the parentheses are redundant. And while we're at it,
I also suggest removing redundant "ar"s.

Then we wouldn't have pararentheses to admire . However, most
macro parentheses are NOT really redundant, they are used to ensure
proper evaluation of the argument in various situations, and
omission can bring forth hidden creatures with multiple legs.