Home > Archive > Cobol > November 2007 > The MOVE problem
You are viewing an archived Text-only version of the thread.
To view this thread in it's original format and/or if you want to reply to
this thread please [click here]
|
|
| Roger While 2007-10-30, 6:55 pm |
| IDENTIFICATION DIVISION.
PROGRAM-ID. MOVEX.
ENVIRONMENT DIVISION.
DATA DIVISION.
WORKING-STORAGE SECTION.
01 AA.
03 A PIC 9 OCCURS 9.
01 CC.
03 C PIC 9 OCCURS 9.
01 B PIC 9.
PROCEDURE DIVISION.
MOVE "987654321" TO AA.
MOVE "123456789" TO CC.
MOVE 3 TO B.
MOVE A(B) TO B C(B).
DISPLAY CC.
DISPLAY B.
GOBACK.
What shouzld be displayed in various compatible modes?
Roger
| |
| Robert 2007-10-30, 6:55 pm |
| On Tue, 30 Oct 2007 17:51:19 +0100, "Roger While" <simrw@sim-basis.de> wrote:
> IDENTIFICATION DIVISION.
> PROGRAM-ID. MOVEX.
> ENVIRONMENT DIVISION.
> DATA DIVISION.
> WORKING-STORAGE SECTION.
> 01 AA.
> 03 A PIC 9 OCCURS 9.
> 01 CC.
> 03 C PIC 9 OCCURS 9.
> 01 B PIC 9.
> PROCEDURE DIVISION.
> MOVE "987654321" TO AA.
> MOVE "123456789" TO CC.
> MOVE 3 TO B.
> MOVE A(B) TO B C(B).
> DISPLAY CC.
> DISPLAY B.
> GOBACK.
>
>What shouzld be displayed in various compatible modes?
123456789
7
| |
| Bill Gunshannon 2007-10-30, 6:55 pm |
| In article <mruei3d4q4qf84dpofamhfbja1n8gsm176@4ax.com>,
Robert <no@e.mail> writes:
> On Tue, 30 Oct 2007 17:51:19 +0100, "Roger While" <simrw@sim-basis.de> wrote:
>
>
> 123456789
> 7
I got:
123456389
7
which is about what I expected, but I am not sure that the correct
answer isn't compiler dependant. Does the standard address actual
order of execution for things like this? Or side effects?
bill
--
Bill Gunshannon | de-moc-ra-cy (di mok' ra see) n. Three wolves
bill@cs.scranton.edu | and a sheep voting on what's for dinner.
University of Scranton |
Scranton, Pennsylvania | #include <std.disclaimer.h>
| |
| Judson McClendon 2007-10-30, 6:55 pm |
| "Bill Gunshannon" <billg999@cs.uofs.edu> wrote:
> Robert <no@e.mail> writes:
>
> I got:
>
> 123456389
> 7
>
> which is about what I expected, but I am not sure that the correct
> answer isn't compiler dependant. Does the standard address actual
> order of execution for things like this? Or side effects?
Net Express 3.1:
123456789
7
I think the subscripts should properly be calculated before the MOVE,
as Net Express apparently does here.
--
Judson McClendon judmc@sunvaley0.com (remove zero)
Sun Valley Systems http://sunvaley.com
"For God so loved the world that He gave His only begotten Son, that
whoever believes in Him should not perish but have everlasting life."
| |
| Bill Gunshannon 2007-10-30, 6:55 pm |
| In article <5dLVi.57745$c9.57091@bignews8.bellsouth.net>,
"Judson McClendon" <judmc@sunvaley0.com> writes:
> "Bill Gunshannon" <billg999@cs.uofs.edu> wrote:
>
> Net Express 3.1:
>
> 123456789
> 7
>
> I think the subscripts should properly be calculated before the MOVE,
> as Net Express apparently does here.
That was what I meant by my question. Does the standard say that all
expressions shold be evaluated before the MOVE? Or shoud expressions
be evaluated as you progress thru the statement? Or, (and not having
read the standard this is what I would have expected based on their
handling of other items) is it un-defined and therefore left up to the
mplementor?
bill
--
Bill Gunshannon | de-moc-ra-cy (di mok' ra see) n. Three wolves
bill@cs.scranton.edu | and a sheep voting on what's for dinner.
University of Scranton |
Scranton, Pennsylvania | #include <std.disclaimer.h>
| |
| William M. Klein 2007-10-30, 6:55 pm |
| The standard requires subscripts of the sending item o be evaluated once at the
beginning of execution of the statement and of the receiving item immediately
before it gets its data. Pages 478-479 of the '02 Standard has:
***
Item identification for identifier-2 is performed immediately before the data is
moved to the respective data tem. If identifier-2 is a zero-length item, the
MOVE statement leaves identifier-2 unchanged.
If identifier-1 is reference modified, subscripted, or is a function-identifier,
the reference modifier, subscript, or function-identifier is evaluated only
once, immediately before data is moved to the first of the receiving operands.
...
The result of the statement
MOVE a (b) TO b, c (b)
is equivalent to:
MOVE a (b) TO temp
MOVE temp TO b
MOVE temp to c (b)
where 'temp' is an intermediate result item provided by the implementor
***
Now having said that, the concept of "item identification" was new in the '02
Standard (as I recall) and although this EXACT same "smple" appears in the '85
Standard (with the "temp" data item), my memory is that many (most?) compilers
use "temp" as the subscript for the receiving item.
Page VI-103 of the '85 Standard had the rule
"Any length evaluation or subscripting associated with identifier-2 is
evaluated immediately before the data is moved to the respective data item."
and then has exaclty the example given above.
--
Bill Klein
wmklein <at> ix.netcom.com
"Roger While" <simrw@sim-basis.de> wrote in message
news:fg7ne4$e4q$01$1@news.t-online.com...
> IDENTIFICATION DIVISION.
> PROGRAM-ID. MOVEX.
> ENVIRONMENT DIVISION.
> DATA DIVISION.
> WORKING-STORAGE SECTION.
> 01 AA.
> 03 A PIC 9 OCCURS 9.
> 01 CC.
> 03 C PIC 9 OCCURS 9.
> 01 B PIC 9.
> PROCEDURE DIVISION.
> MOVE "987654321" TO AA.
> MOVE "123456789" TO CC.
> MOVE 3 TO B.
> MOVE A(B) TO B C(B).
> DISPLAY CC.
> DISPLAY B.
> GOBACK.
>
> What shouzld be displayed in various compatible modes?
>
> Roger
>
>
| |
| Robert 2007-10-30, 6:55 pm |
| On 30 Oct 2007 19:43:50 GMT, billg999@cs.uofs.edu (Bill Gunshannon) wrote:
>In article <5dLVi.57745$c9.57091@bignews8.bellsouth.net>,
> "Judson McClendon" <judmc@sunvaley0.com> writes:
>
>That was what I meant by my question. Does the standard say that all
>expressions shold be evaluated before the MOVE? Or shoud expressions
>be evaluated as you progress thru the statement? Or, (and not having
>read the standard this is what I would have expected based on their
>handling of other items) is it un-defined and therefore left up to the
>mplementor?
The Standard says data is copied to receiving fields "in the order specified."
In other words
MOVE A(B) TO B C(B)
is the same as
MOVE A(B) TO B
MOVE A(B) TO C(B)
The same goes for arithmetics with multiple receiving items. Fujitsu gives this example:
More Than One Arithmetic Result
An arithmetic statement can contain one or more resultant identifiers (data items to
contain results). In this case, the results of an arithmetic statement are computed as
follows:
1. In a statement, all data items to be initially evaluated are computed as required.
The result is stored in a temporary data item.
2. The temporary data item obtained in (1) is computed for each resultant
identifier, and the results are stored. This computation is done in the order in
which the identifiers are specified (from left to right).
An example of obtaining more than one result is shown below. temp indicates a
temporary storage field created by the compiler.
Example 1:
“ADD a b c TO c d(c) e” is computed as follows:
ADD a b c GIVING temp
ADD temp TO c
ADD temp TO d(c)
.... The value of c was changed by the preceding addition.
ADD temp TO e
Example 2:
“MULTIPLY a(i) BY i a(i)” is computed as follows:
MOVE a(i) TO temp
MULTIPLY temp BY i
MULTIPLY temp BY a(i)
| |
| Judson McClendon 2007-10-31, 7:55 am |
| Thanks Bill, I thought you would come back with a definitive response. :-)
> MOVE A(B) TO B C(B).
I would never consider writing such code as in this example. Code should
be written to be as simple and easy to understand as possible, and this
example violates that principle. Using two statements would make the intent
obvious.
--
Judson McClendon judmc@sunvaley0.com (remove zero)
Sun Valley Systems http://sunvaley.com
"For God so loved the world that He gave His only begotten Son, that
whoever believes in Him should not perish but have everlasting life."
"William M. Klein" <wmklein@nospam.netcom.com> wrote:
> The standard requires subscripts of the sending item o be evaluated once at the beginning of execution of the statement and of the
> receiving item immediately before it gets its data. Pages 478-479 of the '02 Standard has:
>
> ***
>
> Item identification for identifier-2 is performed immediately before the data is moved to the respective data tem. If identifier-2
> is a zero-length item, the MOVE statement leaves identifier-2 unchanged.
>
> If identifier-1 is reference modified, subscripted, or is a function-identifier, the reference modifier, subscript, or
> function-identifier is evaluated only once, immediately before data is moved to the first of the receiving operands.
> ...
>
> The result of the statement
>
> MOVE a (b) TO b, c (b)
>
> is equivalent to:
>
> MOVE a (b) TO temp
> MOVE temp TO b
> MOVE temp to c (b)
>
> where 'temp' is an intermediate result item provided by the implementor
>
> ***
>
> Now having said that, the concept of "item identification" was new in the '02 Standard (as I recall) and although this EXACT same
> "smple" appears in the '85 Standard (with the "temp" data item), my memory is that many (most?) compilers use "temp" as the
> subscript for the receiving item.
>
> Page VI-103 of the '85 Standard had the rule
>
> "Any length evaluation or subscripting associated with identifier-2 is evaluated immediately before the data is moved to the
> respective data item."
>
> and then has exaclty the example given above.
> --
> Bill Klein
> wmklein <at> ix.netcom.com
| |
| Doug Miller 2007-10-31, 7:55 am |
| In article <ssZVi.44717$b9.24845@bignews1.bellsouth.net>, "Judson McClendon" <judmc@sunvaley0.com> wrote:
>Thanks Bill, I thought you would come back with a definitive response. :-)
>
>
>I would never consider writing such code as in this example. Code should
>be written to be as simple and easy to understand as possible, and this
>example violates that principle. Using two statements would make the intent
>obvious.
DING DING DING! We have a winner, ladies and gentlemen! *That* is the correct
answer.
--
Regards,
Doug Miller (alphag at milmac dot com)
It's time to throw all their damned tea in the harbor again.
| |
| Bill Gunshannon 2007-10-31, 7:55 am |
| In article <56_Vi.15993$lD6.14460@newssvr27.news.prodigy.net>,
spambait@milmac.com (Doug Miller) writes:
> In article <ssZVi.44717$b9.24845@bignews1.bellsouth.net>, "Judson McClendon" <judmc@sunvaley0.com> wrote:
>
> DING DING DING! We have a winner, ladies and gentlemen! *That* is the correct
> answer.
Undoubtedly!! I have spent many an hour trying to get that point
across to some of the faculty here regarding code they let students
write, in many languages!! You would be amazed (well, for most of
us here, probably not) some of the wierd stuff I see just like that
which leaves a student (and frequently the professor) totally baffled
about how the program generated the answer it did.
bill
--
Bill Gunshannon | de-moc-ra-cy (di mok' ra see) n. Three wolves
bill@cs.scranton.edu | and a sheep voting on what's for dinner.
University of Scranton |
Scranton, Pennsylvania | #include <std.disclaimer.h>
| |
| Sergey Kashyrin 2007-11-01, 3:55 am |
| > Know anything about standards :-)
That actually mean I'm zero :-G
And the original is going to "non-defined" behavior of teh C/C++ statement:
int i;
....
i = i++ + ++i + --i;
| |
| Pete Dashwood 2007-11-01, 3:55 am |
|
<docdwarf@panix.com> wrote in message news:fgb03p$kmc$1@reader1.panix.com...
> In article <56_Vi.15993$lD6.14460@newssvr27.news.prodigy.net>,
> Doug Miller <spambait@milmac.com> wrote:
>
> Never mind that the Original Poster's question was 'What shouzld (sic) be
> displayed in various compatible modes?', of course. I'm sure that would
> go over quite well in a tech interview:
>
> 'Here's one of our Production programs... what should be displayed in
> various compatible modes?'
>
> 'I would never consider writing such code.'
>
> 'Thanks much... next, please.'
>
> DD
LOL! Very true... :-)
Pete.
--
"I used to write COBOL...now I can do anything."
>
| |
| Robert 2007-11-01, 3:55 am |
| On Wed, 31 Oct 2007 23:33:14 -0400, "Sergey Kashyrin" <ska@resqnet.com> wrote:
>
>That actually mean I'm zero :-G
>
>And the original is going to "non-defined" behavior of teh C/C++ statement:
>
>int i;
>...
>i = i++ + ++i + --i;
0 + 1 + 0
1++
The answer is 2
| |
| Sergey Kashyrin 2007-11-01, 3:55 am |
| >>i = i++ + ++i + --i;
> 0 + 1 + 0
> 1++
> The answer is 2
:-)))))))))))))))
ska 29> cat order.c
#include <stdio.h>
int main(int ac, char ** av) {
int i = 0;
i = i++ + ++i + --i;
printf("%d\n", i);
return 0;
}
ska 30> cc order.c
"order.c", line 5: warning #4279-D: the expression depends on order of
evaluation
i = i++ + ++i + --i;
^
ska 31> ./a.out
3
Regards
| |
| Roger While 2007-11-01, 7:55 am |
|
<docdwarf@panix.com> schrieb im Newsbeitrag
news:fgb03p$kmc$1@reader1.panix.com...
> In article <56_Vi.15993$lD6.14460@newssvr27.news.prodigy.net>,
> Doug Miller <spambait@milmac.com> wrote:
:-)[color=darkred]
intent[color=darkred]
correct[color=darkred]
>
> Never mind that the Original Poster's question was 'What shouzld (sic) be
Per dictionary -
so; thus: usually written parenthetically to denote that a word, phrase,
passage, etc., that may appear strange or incorrect has been written
intentionally or has been quoted verbatim: He signed his name as e. e.
cummings (sic).
Not intentinial and not quoted.
Roger
> displayed in various compatible modes?', of course. I'm sure that would
> go over quite well in a tech interview:
>
> 'Here's one of our Production programs... what should be displayed in
> various compatible modes?'
>
> 'I would never consider writing such code.'
>
> 'Thanks much... next, please.'
>
> DD
>
| |
| Roger While 2007-11-01, 6:55 pm |
|
"Roger While" <simrw@sim-basis.de> schrieb im Newsbeitrag
news:fgchvf$tuq$03$1@news.t-online.com...
>
> <docdwarf@panix.com> schrieb im Newsbeitrag
> news:fgb03p$kmc$1@reader1.panix.com...
> :-)
should[color=darkred]
this[color=darkred]
> intent
> correct
be[color=darkred]
>
> Per dictionary -
> so; thus: usually written parenthetically to denote that a word, phrase,
> passage, etc., that may appear strange or incorrect has been written
> intentionally or has been quoted verbatim: He signed his name as e. e.
> cummings (sic).
>
> Not intentinial and not quoted.
>
Or intentnial (sic) ?
> Roger
>
>
>
>
| |
|
| In article <fgchvf$tuq$03$1@news.t-online.com>,
Roger While <simrw@sim-basis.de> wrote:
>
><docdwarf@panix.com> schrieb im Newsbeitrag
>news:fgb03p$kmc$1@reader1.panix.com...
>:-)
>
>Per dictionary -
>so; thus: usually written parenthetically to denote that a word, phrase,
>passage, etc., that may appear strange or incorrect has been written
>intentionally or has been quoted verbatim: He signed his name as e. e.
>cummings (sic).
>
>Not intentinial and not quoted.
'... has been written intentionally OR (emphasis added) has been quoted
verbatim'.
As author you are welcome to have the definitive word on what was
intended; as
<http://groups.google.com/group/comp...4c?dmode=source>
shows the mis-spelling is accurately quoted.
DD
| |
| Judson McClendon 2007-11-01, 6:55 pm |
| "Sergey Kashyrin" <ska@resqnet.com> wrote:
>
> :-)))))))))))))))
>
> ska 29> cat order.c
> #include <stdio.h>
>
> int main(int ac, char ** av) {
> int i = 0;
> i = i++ + ++i + --i;
> printf("%d\n", i);
> return 0;
> }
> ska 30> cc order.c
> "order.c", line 5: warning #4279-D: the expression depends on order of
> evaluation
> i = i++ + ++i + --i;
> ^
>
> ska 31> ./a.out
> 3
I don't see that there should be any ambiguity here (compiler warning).
Evaluation of arithmetic expressions should proceed left to right, within
equal precedence. That expression should always be evaluated as if it
had been written:
step i = ((i++ + ++i) + --i))
1. 0 i = 1
2. 0 + 1 i = 2
3. 1 + 2 i = 1
4. value (1+2) assigned to i i = 3
Weird, but no ambiguity.
--
Judson McClendon judmc@sunvaley0.com (remove zero)
Sun Valley Systems http://sunvaley.com
"For God so loved the world that He gave His only begotten Son, that
whoever believes in Him should not perish but have everlasting life."
| |
| Doug Miller 2007-11-01, 6:55 pm |
| In article <IYqWi.17728$u7.6839@bignews2.bellsouth.net>, "Judson McClendon" <judmc@sunvaley0.com> wrote:
>"Sergey Kashyrin" <ska@resqnet.com> wrote:
>
>I don't see that there should be any ambiguity here (compiler warning).
>Evaluation of arithmetic expressions should proceed left to right, within
>equal precedence. That expression should always be evaluated as if it
>had been written:
>
> step i = ((i++ + ++i) + --i))
> 1. 0 i = 1
> 2. 0 + 1 i = 2
> 3. 1 + 2 i = 1
> 4. value (1+2) assigned to i i = 3
>
>Weird, but no ambiguity.
No?
Borland TurboC produces 1.
--
Regards,
Doug Miller (alphag at milmac dot com)
It's time to throw all their damned tea in the harbor again.
| |
| Frank Swarbrick 2007-11-01, 6:55 pm |
| Doug Miller wrote:
> In article <IYqWi.17728$u7.6839@bignews2.bellsouth.net>, "Judson McClendon" <judmc@sunvaley0.com> wrote:
>
> No?
>
> Borland TurboC produces 1.
As does MS Visual C++.
Digital Mars C++ produces 3.
Interesting...
| |
| Doug Miller 2007-11-01, 9:55 pm |
| In article <5ov6h1Foffe1U1@mid.individual.net>, Frank Swarbrick <infocat@earthlink.net> wrote:
>Doug Miller wrote:
> <judmc@sunvaley0.com> wrote:
>
>As does MS Visual C++.
>
>Digital Mars C++ produces 3.
>
>Interesting...
A little bit more digging confirms what I had initially suspected: that the
compiler's behavior is undefined, and thus permitted to be nearly anything.
http://c.ittoolbox.
com/groups/technical-functional/cpp-l/c-post-increment-operatoe-504401
Note this in particular: "any combination of ++, --, =, +=, -=, etc. in a
single expression which causes the same object either to be modified twice or
modified and then inspected"
--
Regards,
Doug Miller (alphag at milmac dot com)
It's time to throw all their damned tea in the harbor again.
| |
| Robert 2007-11-01, 9:55 pm |
| On Thu, 01 Nov 2007 23:10:36 GMT, spambait@milmac.com (Doug Miller) wrote:
>In article <IYqWi.17728$u7.6839@bignews2.bellsouth.net>, "Judson McClendon" <judmc@sunvaley0.com> wrote:
>
>No?
>
>Borland TurboC produces 1.
Ch produces -1.
http://www.softintegration.com/prod...ndard/download/
| |
| Jeff Campbell 2007-11-01, 9:55 pm |
| Robert wrote:
> On Thu, 01 Nov 2007 23:10:36 GMT, spambait@milmac.com (Doug Miller) wrote:
>
>
> Ch produces -1.
>
> http://www.softintegration.com/prod...ndard/download/
>
Welcome to OpenVMS (TM) Alpha Operating System, Version V7.3-1 on node AS600
Last interactive login on Friday, 2-NOV-2007 01:30:29.42
Last non-interactive login on Wednesday, 31-OCT-2007 17:25:04.82
You have 1 new Mail message.
$ cd [.temp]
$ type a.c
#include <stdio.h>
int main(int ac, char ** av) {
int i = 0;
i = i++ + ++i + --i;
printf("%d\n", i);
return 0;
}
$ cc a
i = i++ + ++i + --i;
.....^
%CC-W-UNDEFVARMOD, In this statement, the expression "i=i+++++i+--i" modifies the variable "i" more
than once without an intervening sequence point. This be
havior is undefined.
at line number 6 in file SYS$SYSDEVICE:[USERS.FROG.TEMP]A.C;1
$ link a
%LINK-W-WRNERS, compilation warnings
in module A file SYS$SYSDEVICE:[USERS.FROG.TEMP]A.OBJ;2
$ run a
2
$ logo
Jeff
----== Posted via Newsfeeds.Com - Unlimited-Unrestricted-Secure Usenet News==----
http://www.newsfeeds.com The #1 Newsgroup Service in the World! 120,000+ Newsgroups
----= East and West-Coast Server Farms - Total Privacy via Encryption =----
| |
| billious 2007-11-02, 3:55 am |
|
"Jeff Campbell" <n8wxs@arrl.net> wrote in message
news:1193967037_217@sp12lax.superfeed.net...[color=darkred]
> Robert wrote:
[snip C]
2, -1, 1, 3
no, no ambiguity anywhere in sight.
I believe that we're now awash with examples of what happens when we have a
sloppily-written standard that leaves us all at er, C.
So what of the original point? Surely the object was to formalise MOVE
something TO destination-list.
What happened? Powerful forces in ANSI that don't want to change their
compilers (with the potential for altering the behaviour of existing
processes) add the "in the order specified" clause - otherwise, it makes no
sense.
Result? A quirk that can be exploited by those with a bent to produce
obscure code and show how smart they are when conducting interviews.
It's disappointing that a simple standard should be manipulated for
commercial reasons - and ANSI is the _only_ standard in my book. I don't see
the need to bring what is to me bad logic into a standard and then insist
that it's corect because that's what's in the rules. That is the province of
lawyers, politicians, accountants and other minions of Evil - not
programmers.
Worked for a mob once that insisted that DG's COBOL was THE one and only
standard. Fifteen years after throwing away their DG machine, they're still
writing to DG's standard - and even insisted on implementing the DG
restrictions on their DG-emulation software. Same mob also insisted that
MOVE SPACES to 9's-field zeroed the field - even when the destination was a
COMP.
Titter ye not (as Frankie Howerd might say) - the "thanks, next!" argument
is very powerful. They're still working, but I'm not....
| |
| Judson McClendon 2007-11-02, 7:55 am |
| "Doug Miller" <spambait@milmac.com> wrote:
> "Judson McClendon" <judmc@sunvaley0.com> wrote:
>
> No?
>
> Borland TurboC produces 1.
So? There still *shouldn't* (active word) be any ambiguity. :-)
--
Judson McClendon judmc@sunvaley0.com (remove zero)
Sun Valley Systems http://sunvaley.com
"For God so loved the world that He gave His only begotten Son, that
whoever believes in Him should not perish but have everlasting life."
| |
| Judson McClendon 2007-11-02, 7:55 am |
| "billious" <billious_1954@hotmail.com> wrote:
> "Jeff Campbell" <n8wxs@arrl.net> wrote:
> [snip C]
>
> 2, -1, 1, 3
>
> no, no ambiguity anywhere in sight.
I didn't say there wasn't ambiguity, I said there should not be any ambiguity,
and I stand by that. Anyone implementing a C compiler that gives any other
result than 3 is a nitwit or has a bug. Compiler writers may be  about
this, but mathematics isn't. What pre and post ++/-- do is clearly defined in
C, and all else in this example is pure mathematics, which should be THE FINAL
standard in evaluating an arithmetic expression. :-)
--
Judson McClendon judmc@sunvaley0.com (remove zero)
Sun Valley Systems http://sunvaley.com
"For God so loved the world that He gave His only begotten Son, that
whoever believes in Him should not perish but have everlasting life."
| |
| Doug Miller 2007-11-02, 7:55 am |
| In article <7WDWi.14133$a9.2577@bignews5.bellsouth.net>, "Judson McClendon" <judmc@sunvaley0.com> wrote:
>there wasn't ambiguity, I said there should not be any ambiguity,
>and I stand by that. Anyone implementing a C compiler that gives any other
>result than 3 is a nitwit or has a bug.
Sorry, but that's just incorrect. C does *not* define how the compiler is
supposed to behave in this instance.
>Compiler writers may be about
>this, but mathematics isn't. What pre and post ++/-- do is clearly defined in
>C,
No, they're not -- when they're applied more than once to the same variable in
the same statement, the resulting behavior is explicitly UNdefined.
>and all else in this example is pure mathematics, which should be THE FINAL
>standard in evaluating an arithmetic expression. :-)
OK, fine:
i = 0;
i = ... let's evaluate this expression one step at a time:
i++ {i incremented to 1}
+ ++i {i incremented to 2, intermediate value so far is 1 + 2 = 3}
+ --i {i decremented to 1}
final value = 3 + 1 = 4
Pure mathematics. :-)
--
Regards,
Doug Miller (alphag at milmac dot com)
It's time to throw all their damned tea in the harbor again.
| |
| Judson McClendon 2007-11-02, 6:55 pm |
| "Doug Miller" <spambait@milmac.com> wrote
> "Judson McClendon" <judmc@sunvaley0.com> wrote:
>
> Sorry, but that's just incorrect. C does *not* define how the compiler is
> supposed to behave in this instance.
>
>
> No, they're not -- when they're applied more than once to the same variable in
> the same statement, the resulting behavior is explicitly UNdefined.
What they do individually is defined, and given that, mathematics is sufficient to
define how they should act collectively. That is my point. There is simply no
reason to have ambiguity here. Use of prefix and postfix ++/-- is common in C,
specifically to address the kinds of thing that's going on here. Only the fact that
the same variable is referenced more than once in the same expression makes
this an issue, and mathematical rules of evaluation order are sufficient to make
it unambiguous. Not realizing and utilizing this is the 'nitwit' aspect.
>
> OK, fine:
>
> i = 0;
> i = ... let's evaluate this expression one step at a time:
> i++ {i incremented to 1}
> + ++i {i incremented to 2, intermediate value so far is 1 + 2 = 3}
> + --i {i decremented to 1}
> final value = 3 + 1 = 4
>
> Pure mathematics. :-)
But wrong C, because C's postfix i++ is clearly defined is presenting a value for
evaluation *before* 'i' is incremented (in fact, that's the only reason to have both
prefix and postfix ++/--). No ambiguity there. :-)
--
Judson McClendon judmc@sunvaley0.com (remove zero)
Sun Valley Systems http://sunvaley.com
"For God so loved the world that He gave His only begotten Son, that
whoever believes in Him should not perish but have everlasting life."
| |
| Michael Mattias 2007-11-02, 6:55 pm |
| "Judson McClendon" <judmc@sunvaley0.com> wrote in message
news:RBFWi.18108$u7.4925@bignews2.bellsouth.net...> "Doug Miller"
<spambait@milmac.com> wrote[color=darkred]
[ removed multiple variations of physically-abused although already-deceased
equines]
I really think those who suggested the correct response is "Don't write like
that!" have already hit the nail on the head.
And for those who don't think so, Mr. McClendon's selection of the word
"nitwit" is a simply outstanding use of the available English-language
nouns.
MCM
| |
| Doug Miller 2007-11-02, 6:55 pm |
| In article <RBFWi.18108$u7.4925@bignews2.bellsouth.net>, "Judson McClendon" <judmc@sunvaley0.com> wrote:
>"Doug Miller" <spambait@milmac.com> wrote
>
>What they do individually is defined, and given that, mathematics is sufficient to
>define how they should act collectively. That is my point. There is simply no
>reason to have ambiguity here.
Of course there is: the C language does not specify the behavior. That lack of
specification produces the ambiguity.
>Use of prefix and postfix ++/-- is common in C,
>specifically to address the kinds of thing that's going on here. Only the fact that
>the same variable is referenced more than once in the same expression makes
>this an issue,
Exactly. Under those circumstances, the behavior is explicitly undefined.
> and mathematical rules of evaluation order are sufficient to make
>it unambiguous. Not realizing and utilizing this is the 'nitwit' aspect.
That may be. However, the behavior of any language compiler is not governed by
mathematical rules of evaluation order, but rather by the standard for that
language -- and in this case, (a) they don't match, and (b) the standard does
not define the expected behavior. Perhaps it should, but it doesn't, and that
results in ambiguity.
>
>But wrong C, because C's postfix i++ is clearly defined is presenting a value for
>evaluation *before* 'i' is incremented (in fact, that's the only reason to have both
>prefix and postfix ++/--). No ambiguity there. :-)
Yes, there *is* an ambiguity, because C's postfix ++ does not define at
exactly which point the increment occurs -- and the behavior is explicitly
undefined when applied more than once to the same variable in the same
statement.
Example:
i = 0;
i = i++ // evaluate i = 0, temp value so far = 0
+ ++i // increment i, evaluate i = 1, temp value so far = 0 + 1 = 1
+ --i // decrement i, evaluate i = 0, temp value so far = 1 + 0 = 1
; // temp value assigned to i (i = 1)
// final postfix increment: i = i + 1 = 2
Point being, the standard does not specify exactly when the postfix is to be
applied, just that it has to be after evaluation.
--
Regards,
Doug Miller (alphag at milmac dot com)
It's time to throw all their damned tea in the harbor again.
| |
| Howard Brazee 2007-11-02, 6:55 pm |
| On Fri, 2 Nov 2007 14:12:44 +0800, "billious"
<billious_1954@hotmail.com> wrote:
>2, -1, 1, 3
>
>no, no ambiguity anywhere in sight.
>
>I believe that we're now awash with examples of what happens when we have a
>sloppily-written standard that leaves us all at er, C.
The evidence supports your statement. But in the absence of a
defined C standard, shouldn't the common standard used everywhere else
apply?
| |
| Judson McClendon 2007-11-02, 6:55 pm |
| "Doug Miller" <spambait@milmac.com> wrote:
> "Judson McClendon" <judmc@sunvaley0.com> wrote:
>
> That may be. However, the behavior of any language compiler is not governed by
> mathematical rules of evaluation order, but rather by the standard for that
> language -- and in this case, (a) they don't match, and (b) the standard does
> not define the expected behavior. Perhaps it should, ...
There we go. What I've been saying all along is that it should, not that it does. :-)
--
Judson McClendon judmc@sunvaley0.com (remove zero)
Sun Valley Systems http://sunvaley.com
"For God so loved the world that He gave His only begotten Son, that
whoever believes in Him should not perish but have everlasting life."
| |
| Doug Miller 2007-11-02, 6:55 pm |
| In article <qRHWi.25446$N7.11330@bignews7.bellsouth.net>, "Judson McClendon" <judmc@sunvaley0.com> wrote:
>"Doug Miller" <spambait@milmac.com> wrote:
>
>There we go. What I've been saying all along is that it should, not that it
> does. :-)
But because it doesn't, the expected behavior, and hence the result of the
operation, is ambiguous. :-)
--
Regards,
Doug Miller (alphag at milmac dot com)
It's time to throw all their damned tea in the harbor again.
| |
| Judson McClendon 2007-11-02, 6:55 pm |
| "Doug Miller" <spambait@milmac.com> wrote:
> "Judson McClendon" <judmc@sunvaley0.com> wrote:
>
> But because it doesn't, the expected behavior, and hence the result of the
> operation, is ambiguous. :-)
Is this a Pete & Repeat scenario? :-)
--
Judson McClendon judmc@sunvaley0.com (remove zero)
Sun Valley Systems http://sunvaley.com
"For God so loved the world that He gave His only begotten Son, that
whoever believes in Him should not perish but have everlasting life."
| |
| Charles Hottel 2007-11-02, 9:55 pm |
|
"Judson McClendon" <judmc@sunvaley0.com> wrote in message
news:IYqWi.17728$u7.6839@bignews2.bellsouth.net...
> "Sergey Kashyrin" <ska@resqnet.com> wrote:
>
> I don't see that there should be any ambiguity here (compiler warning).
> Evaluation of arithmetic expressions should proceed left to right, within
> equal precedence. That expression should always be evaluated as if it
> had been written:
>
I don't think that is true for C, without explicit parentheses the compiler
can do them in any order it chooses.
| |
| Sergey Kashyrin 2007-11-03, 3:55 am |
|
"Charles Hottel" <chottel@earthlink.net> wrote in message
news:13inl3v5i4sqf11@corp.supernews.com...
>
> "Judson McClendon" <judmc@sunvaley0.com> wrote in message
> news:IYqWi.17728$u7.6839@bignews2.bellsouth.net...
> I don't think that is true for C, without explicit parentheses the
> compiler can do them in any order it chooses.
It's already been correctly said that it's a time of postfix "++" operation
which is undefined and parentheses will not help.
The same as undefined
int i = 1;
i = f(++i, ++i);
because the order of parametes calculation is undefined.
--
SK
| |
| Judson McClendon 2007-11-03, 7:55 am |
| "Sergey Kashyrin" <ska@resqnet.com> wrote:
> "Charles Hottel" <chottel@earthlink.net> wrote:
>
> It's already been correctly said that it's a time of postfix "++" operation which is undefined and parentheses will not help.
> The same as undefined
> int i = 1;
> i = f(++i, ++i);
>
> because the order of parametes calculation is undefined.
Which was unnecessary and mind-bogglingly stupid. It *should* have been
defined; that is my point. It is an incredibly sloppy design flaw, one of many
in C (e.g. =/== seems almost purposely designed to be visually ).
And parenthesis *should* help, because they define the order of evaluation
in every mathematical expression written for thousands of years. For what
conceivable reason would the creators of C ignore such a thing? As I said,
it was unnecessary and mind-bogglingly stupid.
--
Judson McClendon judmc@sunvaley0.com (remove zero)
Sun Valley Systems http://sunvaley.com
"For God so loved the world that He gave His only begotten Son, that
whoever believes in Him should not perish but have everlasting life."
| |
| Robert 2007-11-03, 6:55 pm |
| On Sat, 3 Nov 2007 04:28:45 -0500, "Judson McClendon" <judmc@sunvaley0.com> wrote:
>"Sergey Kashyrin" <ska@resqnet.com> wrote:
>
>Which was unnecessary and mind-bogglingly stupid. It *should* have been
>defined; that is my point. It is an incredibly sloppy design flaw, one of many
>in C (e.g. =/== seems almost purposely designed to be visually ).
>
>And parenthesis *should* help, because they define the order of evaluation
>in every mathematical expression written for thousands of years. For what
>conceivable reason would the creators of C ignore such a thing? As I said,
>it was unnecessary and mind-bogglingly stupid.
Programming Standards are written by programmers, not mathematicians.
This reminds me of a conversation I had with the manager of testing at a federal
government department.
rw: How do you determine the number of test cases required?
mt: That's determined by the budget.
rw: Did you ever take Statistics 101?
mt: Yeah. It was irrelevant crap I've never used in the real world.
rw: Do you remember probability of false positive and false negative.
mt: Sure, alpha and beta. How's that related to software testing?
rw: When you run a regression test, you're looking for a negative finding.
Most other tests are positive.
mt: Ah, negative .. positive. It's all the same. You sound like a professor.
rw: It's not all the same. Regression testing requires thousands of test cases; positive
rests require a small number of cases.
mt: All our tests are positive. If they're not, we write 'em up as failures.
rw: What's your confidence interval?
mt: We try for 100%.
rw: Your test design is really sophisticated.
mt: Thank you.
| |
| Charles Hottel 2007-11-03, 6:55 pm |
|
"Sergey Kashyrin" <ska@resqnet.com> wrote in message
news:eBSWi.71$tV1.41001@news.sisna.com...
>
> "Charles Hottel" <chottel@earthlink.net> wrote in message
> news:13inl3v5i4sqf11@corp.supernews.com...
>
> It's already been correctly said that it's a time of postfix "++"
> operation which is undefined and parentheses will not help.
> The same as undefined
> int i = 1;
> i = f(++i, ++i);
>
> because the order of parametes calculation is undefined.
> --
> SK
>
>
Ok. Yes I did not mean that adding parenthesis would help in this case.
| |
| Charles Hottel 2007-11-03, 6:55 pm |
|
"Judson McClendon" <judmc@sunvaley0.com> wrote in message
news:hbXWi.60804$c9.50981@bignews8.bellsouth.net...
> "Sergey Kashyrin" <ska@resqnet.com> wrote:
>
> Which was unnecessary and mind-bogglingly stupid. It *should* have been
> defined; that is my point. It is an incredibly sloppy design flaw, one of
> many
> in C (e.g. =/== seems almost purposely designed to be visually ).
>
> And parenthesis *should* help, because they define the order of evaluation
> in every mathematical expression written for thousands of years. For what
> conceivable reason would the creators of C ignore such a thing? As I said,
> it was unnecessary and mind-bogglingly stupid.
> --
> Judson McClendon judmc@sunvaley0.com (remove zero)
> Sun Valley Systems http://sunvaley.com
> "For God so loved the world that He gave His only begotten Son, that
> whoever believes in Him should not perish but have everlasting life."
>
I think this was one of those things done in the name of efficiency.
| |
| Rick Smith 2007-11-05, 6:55 pm |
|
"Charles Hottel" <chottel@earthlink.net> wrote in message
news:13iplpvatnlda19@corp.supernews.com...
>
> "Judson McClendon" <judmc@sunvaley0.com> wrote in message
> news:hbXWi.60804$c9.50981@bignews8.bellsouth.net...
of[color=darkred]
warning).[color=darkred]
of[color=darkred]
).[color=darkred]
evaluation[color=darkred]
what[color=darkred]
said,[color=darkred]
>
> I think this was one of those things done in the name of efficiency.
Whether for efficiency or to eliminate ambiguity, this is the rule.
ISO/IEC 9899:TC2 - Programming languages -- C
6.5 Expressions
-----
2. Between the previous and next sequence point an object
shall have its stored value modified at most once by the
evaluation of an expression. Furthermore, the prior value
shall be read only to determine the value to be stored.[71]
---
71) This paragraph renders undefined statement expressions
such as
i = ++i + 1;
a[i++] = i;
while allowing
i = i + 1;
a[i] = i;
-----
| |
| Howard Brazee 2007-11-05, 6:55 pm |
| On Fri, 2 Nov 2007 21:53:06 -0400, "Charles Hottel"
<chottel@earthlink.net> wrote:
>I don't think that is true for C, without explicit parentheses the compiler
>can do them in any order it chooses.
I think that *is* true for C - That is the way it *should* work. (Note
the above quote specifically said "should" - twice).
Unfortunately we have to live in the world the way it is instead of
the way it should be.
No computer language should give a compiler to choose what results an
arithmetic expression should resolve to.
| |
| Howard Brazee 2007-11-05, 6:55 pm |
| On Sat, 3 Nov 2007 04:28:45 -0500, "Judson McClendon"
<judmc@sunvaley0.com> wrote:
>And parenthesis *should* help, because they define the order of evaluation
>in every mathematical expression written for thousands of years. For what
>conceivable reason would the creators of C ignore such a thing? As I said,
>it was unnecessary and mind-bogglingly stupid.
It's easy to skip the obvious. After all, anybody with half a brain
will realize that the standards that we have been using for such a
long time are the defaults.
Unfortunately, it appears that some compiler writers don't have half a
brain.
| |
| Howard Brazee 2007-11-05, 6:55 pm |
| On Sat, 03 Nov 2007 11:02:34 -0600, Robert <no@e.mail> wrote:
>rw: How do you determine the number of test cases required?
>mt: That's determined by the budget.
>rw: Did you ever take Statistics 101?
>mt: Yeah. It was irrelevant crap I've never used in the real world.
>rw: Do you remember probability of false positive and false negative.
>mt: Sure, alpha and beta. How's that related to software testing?
>rw: When you run a regression test, you're looking for a negative finding.
> Most other tests are positive.
>mt: Ah, negative .. positive. It's all the same. You sound like a professor.
>rw: It's not all the same. Regression testing requires thousands of test cases; positive
> rests require a small number of cases.
>mt: All our tests are positive. If they're not, we write 'em up as failures.
>rw: What's your confidence interval?
>mt: We try for 100%.
>rw: Your test design is really sophisticated.
>mt: Thank you.
LOL!
Workers have a bit of the fault that we see so often with politicians.
We do what rewards us and avoid what hurts us. It is real hard to
run a company, a country, or a project so that we see what we need to
see instead of what we want to see. Those running them need well
defined criteria - but how many managers even understand statistical
analysis?
| |
| John Reagan 2007-11-05, 6:55 pm |
| As a compiler writer and standards member (X3J9 - Pascal), I want to
point out the difference between order of evaluation and operand precedence.
There has been lots of discussion on whether parens would help or not.
For statements like:
i = (a + b) + (c + d);
the parens tell the compiler how to associate the operands of the
various binary addition operators. It doesn't tell the compiler in what
order to do many of the operations. It could add "c" to "d" before
adding "a" to "b". It could do them all in parallel if the hardware
supported such a concept. I've had customers by this subtly
over the years.
When "a", "b", "c", and "d" are large complex operands, the compiler can
often generate better code evaluating the operands in different orders
than "a" then "b" then "add" then "c" then "d" then "add" then "add".
Might want to do the most complicated first or perhaps there might be
some common sub-expression shared between each operand.
--
John Reagan
OpenVMS Pascal/Macro-32/COBOL Project Leader
Hewlett-Packard Company
| |
| billious 2007-11-06, 3:56 am |
|
"Howard Brazee" <howard@brazee.net> wrote in message
news:h9oui3pmf7063m3egcp4gsogs5tcrqpcmh@
4ax.com...
> On Sat, 3 Nov 2007 04:28:45 -0500, "Judson McClendon"
> <judmc@sunvaley0.com> wrote:
>
>
> It's easy to skip the obvious. After all, anybody with half a brain
> will realize that the standards that we have been using for such a
> long time are the defaults.
>
> Unfortunately, it appears that some compiler writers don't have half a
> brain.
Hmmm... so your first recommendation for a case of tuberculosis would be a
good leeching, no doubt?
Maintaining a standard that was badly implemented in the first instance
simply to maintain the legitimacy of that original implementation would seem
to be the province of said half-brained legions.
My experience is that those that are most incompetent are those that reach
first for the standards documentation.
| |
| Robert 2007-11-06, 3:56 am |
| On Mon, 05 Nov 2007 11:45:22 -0700, Howard Brazee <howard@brazee.net> wrote:
>On Sat, 03 Nov 2007 11:02:34 -0600, Robert <no@e.mail> wrote:
>
>
>LOL!
>
>Workers have a bit of the fault that we see so often with politicians.
>We do what rewards us and avoid what hurts us. It is real hard to
>run a company, a country, or a project so that we see what we need to
>see instead of what we want to see. Those running them need well
>defined criteria - but how many managers even understand statistical
>analysis?
Those who program well think the key to success is code inspection.
Those who program poorly think the key to success is testing.
Managers who don't program think the key to success is process.
Analysts think the key to success is design.
In short, everyone thinks the key to success is what (s)he is good at or likes doing.
Therefore, your priorities reveal how you see yourself.
| |
| Howard Brazee 2007-11-06, 6:55 pm |
| On Tue, 6 Nov 2007 12:04:20 +0800, "billious"
<billious_1954@hotmail.com> wrote:
>
>Hmmm... so your first recommendation for a case of tuberculosis would be a
>good leeching, no doubt?
Talk about leaping to conclusions.
A compiler has to have predictable results. Undefined doesn't cut
it.
>Maintaining a standard that was badly implemented in the first instance
>simply to maintain the legitimacy of that original implementation would seem
>to be the province of said half-brained legions.
So you don't like the default standard that has been used in math and
science. That's fine - as long as there is a new standard to replace
it.
>My experience is that those that are most incompetent are those that reach
>first for the standards documentation.
I haven't had experience writing compilers. On this forum, I have
seen quite a bit of evidence that the most competent are those who
know the standards the best.
|
|
|
|
|