Right. There are two things here:

1. Resolving the immediate problem (and understanding exactly why it fails
might be a good first step).

2. The quality of the code. You are right; it is poor code. I try to write
pretty good code. I take no pride in avoiding the use of unnecessary
parentheses. I confess, I (a.) failed to consider that testWord =
valueToTest >> 32 would not reliably operate as intended; and (b.) I was
completely satisfied when the function passed basic unit tests and though no
more of it. Lesson learned, hopefully. Not certain exactly what the lesson
is, but I will be more careful in the future. I have learned to be cautious
about integer type conversions, but obviously not cautious enough. I guess
the lesson is just like for sequences of logical operators: use parentheses
to force what you expect.

Charles

-----Original Message-----
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
Behalf Of Harry Wahl
Sent: Sunday, July 21, 2013 11:21 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Looking for help with an obscure C integer problem

Charles,
Hi, here is my opinion (and this definitely falls under the category of
"obscure C"):
You are not considering the implications of "sequence points" in your C/C++.
"Sequence points" should not be confused with "operator precedence."
Operator precedence is determinate, sequence points are not.
I believe IBM XLC is at the C++11 level of C/C++. The C/C++ level is
relevant here because there are sometimes subtle, and sometimes not so
subtle, differences in how sequence points apply between various levels of
C++. 
While C++11 (the most recent level of C/C++) seems to a have only tiny,
mostly irrelevant and evolutionary changes from prior levels of C/C++; there
are significant differences in how "sequence points" are defined and effect
execution. 
Still, C++11 and the level of the C/C++ compiler that is compiling your
program is only tangential to the situation you describe. Your code will
execute with undefined behavior regardless of what compiler you use. But,
knowing the level of the C/C++  compiler may be important if you wish to
reconcile why it behaves one way sometimes and other ways other times (e.g.
on a different z/OS).
To me, your failure to consider the subtle impact of sequence points renders
your code ambiguous and subject to undefined behavior. This manifests
itself, for example, by executing differently when optimized. It is at the
compiler's and optimizer's discretion to decide the order of execution for
code that the C++ standard does not specifically define. This includes
overlapping execution.
I think the C/C++ compiler and optimizer are working exactly as specified by
applicable ISO/IEC standards.
"The fault, dear Brutus, it not in our stars,But, in ourselves, that we are
underlings"
Cassius in Shakespeare's Julius Caesar

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Reply via email to