| Re: Operator precedence [message #185143 is a reply to message #185141] |
Sat, 01 March 2014 19:29   |
Jerry Stuckle
Messages: 2598
Registered: September 2010
Karma:
|
Senior Member |
|
|
On 3/1/2014 1:39 PM, Richard Damon wrote:
> On 2/24/14, 11:59 PM, Jerry Stuckle wrote:
>> On 2/24/2014 10:41 PM, Richard Damon wrote:
>>> On 2/24/14, 7:00 AM, Jerry Stuckle wrote:
>>>
>>>> What language gives every possible way for you to screw up your
>>>> programming?
>>>>
>>>> If you want to find out how some screwed-up code works in ANY language,
>>>> you try it and find out.
>>>>
>>>
>>> Herein lies the path to madness.
>>>
>>> Take the following C code
>>>
>>> #include <stdio.h>
>>>
>>> int main() {
>>> int i = 4;
>>> i = ++i + i++;
>>> printf("%i\n", i);
>>> return 0;
>>> }
>>>
>>> Question, you want to find out what this is supposed to do. By your
>>> statement, you run it on a system. The problem is that the answer you
>>> get is only valid for THAT system, and possible for that EXACT piece of
>>> code.
>>>
>>
>> No, it shows how it works with THIS compiler. Not even this system - a
>> different compiler may give different results. But then the same is
>> true for ANY compiler.
>>
>> But then all I claimed was to try it and see how it works for THIS system.
>>
>> For instance, what is the output of:
>>
>> int main() {
>> int i = 1;
>> int j = i << 32;
>> printf("%d\n", j);
>> ?>
>>
>
> The C language spec makes this clear.
>
> The result of 1 << 32 will be 4,294,967,206.
> Now, if INT_MAX is defined to be a smaller value, then the program has
> performed "undefined behavior", and the standard provides no constraints
> on what happens after that point.
>
In my compiler, the output is 0. And it is ANSI compliant.
> In common terms, if int is a type of at least 34 bits, (to include the
> sign bit), this program has defined behavior, and the standard defines
> its operation. if int is only a 33 bit type (or smaller), then the
> compiler is not obligated to make this work. Practically, you are apt to
> get either the result 0 or 1, (0 if the machine actually does the
> shifting, 1 if the machine ignores extra shift count bits), but anything
> is allowed.
>
This has nothing to do with the subject - which is the size of an int.
>>> The REAL answer is you compare the code to the formal specification of
>>> the language, and you get the answer.
>>>
>>
>> IF you have the formal specification available, and are able to
>> understand it.
>>
>
> Not understanding the formal specification is a programmer issue. A
> formal language CAN be used without access (or understanding) of the
> formal specification through other documentation, and in fact, most
> programmers can do a lot without needing to refer to the formal
> specifications. The mere existence of them provides a "higher court" to
> take issue that seem to come up, and figure out if the documentation or
> the implementation has a problem when something doesn't seem right.
>
Yes, but when you're dealing with courseware, knowledge and
understanding of the specification is a very good idea.
>>> Too many people use your answer, and then complain because they get a
>>> different answer on another machine, or in different circumstances, and
>>> then complain that the compiler is "broken", when the real answer is
>>> that THEIR program was the one that was broken.
>>>
>>> (For those not familiar with C, the answer in this case is that the
>>> program has performed "undefined behavior" by modifying i twice without
>>> a sequence point, and thus *ANY* resultant behavior is acceptable.
>>>
>>
>> That is true - and you will not find your example in the ANSI C spec -
>> which is why its output is not defined.
>>
>
>
>>> Here is a question, does PHP's documentation promise how the equivalent
>>> PHP statement will execute?
>>>
>>> ...
>>
>> You tell me.
>>
>
> YOU made the claim that PHP is rigorously defined. Person making
> assertion tends to have burden of proof. Lack of definition would be an
> indication that it is NOT so rigorously defined.
>
YOU made the first assertion - that PHP is NOT rigorously defined. So,
according to your "rules", you have to prove it - which you have not.
>>>
>>>
>>>> > The assignment operators in PHP have, in effect, different precedences
>>>> > on the left and the right (a feature that some languages flaunt) but
>>>> > that is not common and certainly not part of what I'd call basic
>>>> > knowledge. The documentation gives one example of this peculiarity,
>>>> > but
>>>> > that does not clear the matter up conclusively. For example, in some
>>>> > languages permit assignment to the result of a conditional expression,
>>>> > but I think it's hard to tell from the documentation what these two do:
>>>> >
>>>> > $bool ? $a : $b = 42;
>>>> > ($bool ? $a : $b) = 42;
>>>> >
>>>>
>>>> Show me what language provides you with examples of every possible
>>>> combination of operators and expressions.
>>>
>>> Read the C Grammer definition. It precisely describes how ANY expression
>>> is to be parsed.
>>>
>>> It does give the compiler freedom to choose the order to execute the
>>> parse tree, so things without inherent order have no promise of order,
>>> but this is made explicit.
>>>
>>
>> I have - many times while working on updating C courses. So much, in
>> fact, that I completely wore out the ANSI spec I had (and which cost me
>> a bunch of $$$).
>>
>> The spec specifies the order that operators are evaluated. It does NOT
>> specify the order in which operands are evaluated. That is why your
>> example has undefined results - the spec does not define what should
>> happen.
>>
>
> Actually, the specification DOES say what happens, the program has
> invoked undefined behavior, and any further actions are beyond the scope
> of the standard. This IS a precise statement, it may not be real useful
> to the programmer figure out predict what will happen, but it does
> provide "rules of engagement" for writing programs. The programmer
> promises to make sure the code doesn't invoke undefined behavior, and
> the standard(s) will define what the program does.
>
Actually, no, the specification does not say specifically what happens
in a case such as j = i++ + ++i; That is why the operation is
"undefined" - because nothing in the spec defines what should happen.
>>>
>>>>
>>>> > The operator precedence table suggests that both mean the same thing,
>>>> > but they don't. I don't think the meaning of either is easily
>>>> > determined from the documentation.
>>>> >
>>>> > <snip>
>>>> >
>>>>
>>>> So you try it out, as you do in any language. But just because you can
>>>> come up with some weird combination of operators which isn't listed in
>>>> the doc does not mean the language is not rigorously defined.
>>>> with
>>>> But it does mean you are trolling.
>>>>
>>>
>>> Rigorously defined would mean "precisely or exactly defined", which,
>>> yes, does say that if you can come up with a "weird" combination, that
>>> is not documented as to what is to happen, the definition is not
>>> rigorous. A Formal definition, will be complete, as that is part of
>>> being formal.
>>>
>>
>> PHP is defined as rigorously as other languages. Just in a more
>> reader-friendly way. (It took me a long time to figure out my way
>> through the ANSI C spec - and even longer for SQL).
>>
>> But then since you seem to hate PHP so much, I suggest you just find
>> another language more to your liking and stop wasting people's time in a
>> PHP newsgroup. More trolls we don't need.
>>
>
> I don't hate PHP, in fact I find it a very useful language for many usages.
>
> IF you want to claim that PHP is as rigorously defined as a language
> like C, then perhaps your problem is you don't understand what rigorous
> really means, and where it is useful in defining things.
>
I understand exactly what rigorous means. But you obviously think it
means "in arcane and hard to understand language". It does not.
> PHP is NOT "rigorously" defined, its documentation is predominately
> "natural language" based, not on formal grammar. This does have
> advantages for the "common" programmer, making it easier to learn the
> basics of the language, but does leave some minor details, which aren't
> normally important poorly defined. Since PHP is predominately a "single
> implementation language", it can get away with this.
>
And how does the language used make it not "rigorously defined". Prove
your statement - according to your rules.
> One other effect of this is that in PHP, it is possible to file a
> "documentation bug" for the documentation differing from how the
> compiler operates. (this might result in a documentation change, or it
> might be determined that it really is a program bug). With a formal
> language, the only "bugs" that could be filed against the standard would
> be a case where the documentation was in conflict with itself, otherwise
> and discrepancy between the documentation and an implementation is, by
> definition, a non-conformity in the implementation.
>
It's also possible to file a "documentation bug" with ANSI
documentation, also. It's handled differently, but ANSI understands
that even its documentation can have errors.
--
==================
Remove the "x" from my email address
Jerry Stuckle
jstucklex(at)attglobal(dot)net
==================
|
|
|
|
Calendar
Search
Help
Members
Register
Login
Home
]