[OT] Some bad code I wrote the other day

[Old Wolf]

char *out = dest;
char const *in = src;

while ( out != dest + dest_len && in != src + src_len )
*dest++ = *src++;

Also on the same day: icc_check is a function that returns a
status value, and also 'returns' the previous status value by writing
to the pointer you pass to it.

if ( icc_check(&state) != state )
{
/* note that state has changed */
}

 

[Cong Wang]

char *out = dest;
char const *in = src;

while ( out != dest + dest_len && in != src + src_len )
*dest++ = *src++;

Also on the same day: icc_check is a function that returns a
status value, and also 'returns' the previous status value by writing
to the pointer you pass to it.

if ( icc_check(&state) != state )
{
/* note that state has changed */
}

But what is your question?

 

[Mudit Khetan]

char *out = dest;
char const *in = src;

while ( out != dest + dest_len && in != src + src_len )
*dest++ = *src++;

Also on the same day: icc_check is a function that returns a
status value, and also 'returns' the previous status value by writing
to the pointer you pass to it.

if ( icc_check(&state) != state )
{
/* note that state has changed */
}

1) The loop given above will never come to an end, "infinite loop".
because u do not change (you can't) the in pointer.
2) The condition will always be true, as function calls are resolved
first then the result (return) of this call will be compared against
the "state" var that has been changed by the function.

 

[Eric Sosman]

>
1) The loop given above will never come to an end, "infinite loop".
because u do not change (you can't) the in pointer.

The `in' pointer can be changed (although the code shown
does not change it). The `const' means that `in' cannot be
used to change the characters that it points at.

And a nit-pick: The loop does indeed end if either dest_len
or src_len is zero.

2) The condition will always be true, as function calls are resolved
first then the result (return) of this call will be compared against
the "state" var that has been changed by the function.

C makes no promise that function calls are "resolved first"
in an expression. The outcome of the test is implementation-
dependent.

 

[Christopher Benson-Manica]

char *out = dest;
char const *in = src;

while ( out != dest + dest_len && in != src + src_len )
*dest++ = *src++;

if ( icc_check(&state) != state )
{
/* note that state has changed */
}

Perhaps you can be switched over to HR so you can write your company's
interview questions ;-)

 

[Kenneth Brody]

Old Wolf wrote: [...]

Also on the same day: icc_check is a function that returns a
status value, and also 'returns' the previous status value by writing
to the pointer you pass to it.

if ( icc_check(&state) != state )
{
/* note that state has changed */
}

[...]
2) The condition will always be true, as function calls are resolved
first then the result (return) of this call will be compared against
the "state" var that has been changed by the function.

Untrue. There is no guarantee that the value of the right-hand side
of the "!=" condition isn't evaluated first, as in this pseudo-asm
code:

load R10,state
push &state
call icc_check ; (return value is stored in R0)
compare R0,R10

(ObNitPickerAvoidance: the compiler knows enough to preserve any
registers R10-R31 that it uses, so R10 won't change even if it is
used by icc_check.)

As I recall, the function call is a sequence point, but there is
no guarantee as to the order in which the statement is evaluated.

However, I'm not sure if this example invokes UB or is simply
"implementation defined".

--
+-------------------------+--------------------+-----------------------+
| Kenneth J. Brody | www.hvcomputer.com | #include |
| kenbrody/at\spamcop.net | www.fptech.com | <std_disclaimer.h> |
+-------------------------+--------------------+-----------------------+
Don't e-mail me at: <mailto:[email protected]>

 

[Guest]

[...]
As I recall, the function call is a sequence point, but there is
no guarantee as to the order in which the statement is evaluated.

However, I'm not sure if this example invokes UB or is simply
"implementation defined".

Neither, actually. It's unspecified, which means the implementation
need not document anything, and need not even be consistent if the code
is executed multiple times, but the result of the function call must be
compared with either the value of state before the function call, or
the value afterwards.