* [9fans] Unexpected 8c warning message @ 2009-08-09 19:33 Adriano Verardo 2009-08-09 19:46 ` Russ Cox 2009-08-10 21:01 ` James Tomaschke 0 siblings, 2 replies; 13+ messages in thread From: Adriano Verardo @ 2009-08-09 19:33 UTC (permalink / raw) To: Fans of the OS Plan 9 from Bell Labs Hi, all. SDes_t *SDList[2], *SD; .... n = ... // 0, 1, 2, ... //SD = SDList[0]; <= uncommenting this one the warning disappear. for (i = 0; i < 2; i++) { SD = SDList[i]; while (n && SD) { SD = SD->next; if (SD) n--; } } if (!SD) { ..... } ---> used and not set SD ??? 8c shouldn't issue the warning message, beeing SD assigned in a loop defined by constants ... unless there is a subtle (my) error that I don't see. Thanks for the help. adriano ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: [9fans] Unexpected 8c warning message 2009-08-09 19:33 [9fans] Unexpected 8c warning message Adriano Verardo @ 2009-08-09 19:46 ` Russ Cox 2009-08-09 21:20 ` Adriano Verardo 2009-08-10 21:01 ` James Tomaschke 1 sibling, 1 reply; 13+ messages in thread From: Russ Cox @ 2009-08-09 19:46 UTC (permalink / raw) To: Fans of the OS Plan 9 from Bell Labs you are smarter than 8c. just put sd = nil above your loop. 8c isn't smart enough to know that the body of for(i=0; i<2; i++) because it does not make two copies of the i<2 test, so it cannot determine that the very first one is guaranteed to succeed. russ ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: [9fans] Unexpected 8c warning message 2009-08-09 19:46 ` Russ Cox @ 2009-08-09 21:20 ` Adriano Verardo 2009-08-09 21:48 ` erik quanstrom 0 siblings, 1 reply; 13+ messages in thread From: Adriano Verardo @ 2009-08-09 21:20 UTC (permalink / raw) To: Fans of the OS Plan 9 from Bell Labs Russ Cox wrote: > 8c isn't smart enough to know that ... > > It's a pity. In other - more complicated - situations I found such warnings appropriate and very helpful. Could that case be recognised during the variable-scope analysis on the intermediate format (tuples ?) ? I don't remember what D.Gries and others said about and I don't know the 8c internals at all. It's just an academic question I do for cultural interest. IMHO 8c is better than gcc even if sometimes it wrongly complains about variables use. adriano ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: [9fans] Unexpected 8c warning message 2009-08-09 21:20 ` Adriano Verardo @ 2009-08-09 21:48 ` erik quanstrom 2009-08-10 16:24 ` Adriano Verardo 0 siblings, 1 reply; 13+ messages in thread From: erik quanstrom @ 2009-08-09 21:48 UTC (permalink / raw) To: 9fans > It's a pity. In other - more complicated - situations I found such > warnings appropriate and very helpful. > Could that case be recognised during the variable-scope analysis on the > intermediate format (tuples ?) ? > I don't remember what D.Gries and others said about and I don't know the > 8c internals at all. > It's just an academic question I do for cultural interest. > IMHO 8c is better than gcc even if sometimes it wrongly complains about > variables use. sure, one could perform all sorts of analysis on the code. but i think that would be beside the point. i find that code that is subtle enough to evoke a warning often needs to be simplified for the benefit of other humans — or even the author in a week. in your case, you can either provide a dummy assignment or use SET(var) to inform 8c that it can forget about that warning. - erik ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: [9fans] Unexpected 8c warning message 2009-08-09 21:48 ` erik quanstrom @ 2009-08-10 16:24 ` Adriano Verardo 2009-08-10 16:43 ` erik quanstrom 0 siblings, 1 reply; 13+ messages in thread From: Adriano Verardo @ 2009-08-10 16:24 UTC (permalink / raw) To: Fans of the OS Plan 9 from Bell Labs erik quanstrom wrote: >> It's a pity. In other - more complicated - situations I found such >> warnings appropriate and very helpful. >> Could that case be recognised during the variable-scope analysis on the >> intermediate format (tuples ?) ? >> I don't remember what D.Gries and others said about and I don't know the >> 8c internals at all. >> It's just an academic question I do for cultural interest. >> IMHO 8c is better than gcc even if sometimes it wrongly complains about >> variables use. >> > > sure, one could perform all sorts of analysis on the code. > but i think that would be beside the point. ? ... sicerely, I don't understand the exact meaning of these sentences in this context. Please, could you express the same concept with different words ? > i find that code that is subtle > enough to evoke a warning often needs to be simplified > for the benefit of other humans — or even the author in > a week. > Absolutely true. But I got a subtle compiler message about a very very simple and short piece of code. > in your case, you can either provide a dummy assignment > or use SET(var) to inform 8c that it can forget about that > warning. > I didn't know SET(var) so I used a dummy assignment, as you can see in my original mail. Both seems to me a medicine worst than the disease. Personal opinion, of course. adriano ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: [9fans] Unexpected 8c warning message 2009-08-10 16:24 ` Adriano Verardo @ 2009-08-10 16:43 ` erik quanstrom 2009-08-10 17:19 ` Russ Cox 2009-08-10 20:33 ` Adriano Verardo 0 siblings, 2 replies; 13+ messages in thread From: erik quanstrom @ 2009-08-10 16:43 UTC (permalink / raw) To: 9fans > Absolutely true. > But I got a subtle compiler message about a very very simple and short > piece of code. how is the compiler supposed to determine if the code in question is short and simple? > > in your case, you can either provide a dummy assignment > > or use SET(var) to inform 8c that it can forget about that > > warning. > > > I didn't know SET(var) so I used a dummy assignment, as you can see in > my original mail. > Both seems to me a medicine worst than the disease. Personal opinion, of > course. on the other hand, if you've been following along at home with linux development, you'll remember that a week or so ago a really smart compiler screwed everybody over by optimizing away a test for null because clearly that couldn't happen. http://lwn.net/Articles/342330/ http://lwn.net/Articles/342420/ (this problem is also demonstrates one reason mixing asignments and declarations is bad practice.) - erik ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: [9fans] Unexpected 8c warning message 2009-08-10 16:43 ` erik quanstrom @ 2009-08-10 17:19 ` Russ Cox 2009-08-10 23:30 ` Adriano Verardo 2009-08-10 20:33 ` Adriano Verardo 1 sibling, 1 reply; 13+ messages in thread From: Russ Cox @ 2009-08-10 17:19 UTC (permalink / raw) To: Fans of the OS Plan 9 from Bell Labs This problem is uncomputable, so trying to handle every case that comes up is problematic. There has to be a line somewhere. Saying that the compiler could figure out does not imply that it must. I think it's perfectly reasonable that a compiler, when presented with a program like int x; for(___; ___; ___) { x = ___; ___; } if(!x) ___; should complain about a possible used-but-not-set of x. As a person reading that code, I can't look at the overall structure of the code and see that x is obviously initialized at the if statement, unless I analyze the various abstracted-away ___ pieces. And if one of those changes, then there is now a real error. SET is hard to use correctly and not portable. You are better off with a simple assignment, simpler than the one you used in your example: just zero the variable before the loop. int x; x = 0; for(___; ___; ___) { x = ___; ___; } if(!x) ___; Now at least the people reading the code can see that x is initialized, for sure. It's very hard for me to see how "x = 0" is a medicine worse than the disease. I do agree that the "SD = SDList[0];" you had is not a good solution, because it makes it look like that value is important, but "SD = nil;" avoids that issue. Alternately, since the if(!x) is really the continuation of the last iteration of the loop, you could move it inside the loop: int x; for(___; ___; ___) { x = ___; ___; if(last iteration && !x) ___; } which makes it clear to both people and compilers that x is set before it is used. It is not the compiler's job to enable you to be as clever as possible. If this really matters to you and you don't want the compiler warnings, you can always turn them off. Russ ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: [9fans] Unexpected 8c warning message 2009-08-10 17:19 ` Russ Cox @ 2009-08-10 23:30 ` Adriano Verardo 2009-08-11 0:19 ` Charles Forsyth 0 siblings, 1 reply; 13+ messages in thread From: Adriano Verardo @ 2009-08-10 23:30 UTC (permalink / raw) To: Fans of the OS Plan 9 from Bell Labs Russ Cox wrote: > This problem is uncomputable, so trying to > handle every case that comes up is problematic. > There has to be a line somewhere. Ok :-( > Saying that > the compiler could figure out does not imply > that it must. > Of course > I think it's perfectly reasonable that a compiler, > when presented with a program like > > int x; > > for(___; ___; ___) { > x = ___; > ___; > } > if(!x) > ___; > > should complain about a possible used-but-not-set > of x. As a person reading that code, I can't look at > the overall structure of the code and see that x is > obviously initialized at the if statement, unless I analyze > the various abstracted-away ___ pieces. And if one of > those changes, then there is now a real error. > I thought it was possible to do some local - topological - considerations. I saw seriously the theory 25+ y ago. The memory can fail, so I asked. > SET is hard to use correctly and not portable. > You are better off with a simple assignment, > simpler than the one you used in your example: > just zero the variable before the loop. > > int x; > > x = 0; > for(___; ___; ___) { > x = ___; > ___; > } > if(!x) > ___; > > Now at least the people reading the code can see > that x is initialized, for sure. It's very hard for me to > see how "x = 0" is a medicine worse than the disease. > I do agree that the "SD = SDList[0];" you had is not > a good solution, because it makes it look like that > value is important, but "SD = nil;" avoids that issue. > > Alternately, since the if(!x) is really the continuation > of the last iteration of the loop, you could move it > inside the loop: > > int x; > > for(___; ___; ___) { > x = ___; > ___; > if(last iteration && !x) > ___; > } > > which makes it clear to both people and compilers > that x is set before it is used. > Yes > It is not the compiler's job to enable you to be as > clever as possible. If this really matters to you and > you don't want the compiler warnings, you can > always turn them off. > What really matters to me is the reliability of the code I do, because in the environment I work a bug can seriously damage - or kill - human beeings. One of the "holy" programming rules is to compile with the maximum warning level, attentively analyse each message and correct the code accordingly ... and blah and blah ... I'm sure you know the situation, it's just to let you understand my point of view. The example I submitted is trivial. I perfectly knew that there were no true bug. I've honestly thought that 8c was designed to issue only "true" warnings and that the message was just due to a small bug. I regret to know that the problem is completely different and not solvable, as you kindly explained. Ok, it's a pity but not a problem. That means only that one cannot say "8c complains, there is **certainly** an algorithm error somewhere" and must pay attention before writing dummy assigments. Only a compiler characteristic to take into account. Thanks for the help, Russ. adriano ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: [9fans] Unexpected 8c warning message 2009-08-10 23:30 ` Adriano Verardo @ 2009-08-11 0:19 ` Charles Forsyth 0 siblings, 0 replies; 13+ messages in thread From: Charles Forsyth @ 2009-08-11 0:19 UTC (permalink / raw) To: 9fans >8c complains, there is **certainly** an algorithm error somewhere for certainties, (such as many type errors) 8c unlike some others generates fatal errors, not warnings. it's a warning because it can't be absolutely sure that you don't know what you're doing, or that you aren't particularly cunning (or obscure). ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: [9fans] Unexpected 8c warning message 2009-08-10 16:43 ` erik quanstrom 2009-08-10 17:19 ` Russ Cox @ 2009-08-10 20:33 ` Adriano Verardo 1 sibling, 0 replies; 13+ messages in thread From: Adriano Verardo @ 2009-08-10 20:33 UTC (permalink / raw) To: Fans of the OS Plan 9 from Bell Labs erik quanstrom wrote: > on the other hand, if you've been following along at home > with linux development, you'll remember that a week or so > ago a really smart compiler screwed everybody over by optimizing > away a test for null because clearly that couldn't happen. > > http://lwn.net/Articles/342330/ > http://lwn.net/Articles/342420/ > > (this problem is also demonstrates one reason mixing > asignments and declarations is bad practice.) > I don't follow Linux ... thanks for the references, I'll read them. adriano ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: [9fans] Unexpected 8c warning message 2009-08-09 19:33 [9fans] Unexpected 8c warning message Adriano Verardo 2009-08-09 19:46 ` Russ Cox @ 2009-08-10 21:01 ` James Tomaschke 2009-08-11 10:30 ` Ethan Grammatikidis 1 sibling, 1 reply; 13+ messages in thread From: James Tomaschke @ 2009-08-10 21:01 UTC (permalink / raw) To: Fans of the OS Plan 9 from Bell Labs What about, i = 0; do { SD = SDList[i++]; ... } while(i<2); Adriano Verardo wrote: > Hi, all. > > SDes_t *SDList[2], *SD; > .... > n = ... // 0, 1, 2, ... > > //SD = SDList[0]; <= uncommenting this one the warning disappear. > > for (i = 0; i < 2; i++) > { > SD = SDList[i]; > while (n && SD) > { > SD = SD->next; > if (SD) n--; > } > } > > if (!SD) { ..... } ---> used and not set SD ??? > > 8c shouldn't issue the warning message, beeing SD assigned in a loop > defined by constants ... unless there is a subtle (my) error that I > don't see. > > Thanks for the help. > > adriano > > > > ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: [9fans] Unexpected 8c warning message 2009-08-10 21:01 ` James Tomaschke @ 2009-08-11 10:30 ` Ethan Grammatikidis 2009-08-11 22:16 ` James Tomaschke 0 siblings, 1 reply; 13+ messages in thread From: Ethan Grammatikidis @ 2009-08-11 10:30 UTC (permalink / raw) To: 9fans On Mon, 10 Aug 2009 14:01:06 -0700 James Tomaschke <james@orcasystems.com> wrote: > What about, > > i = 0; > do { > SD = SDList[i++]; > ... > } while(i<2); > I was about to suggest something similar. I'm actually trying to avoid using for(;;) altogether which may seem odd to some but I just don't like parsing a for statement, it's rarely clear and usually ugly to my eyes. I still often forget to increment the counter, but that error produces a very obvious symptom. When I don't forget I place the increment on a line by itself, the last of the block, for clarity. -- Ethan Grammatikidis Those who are slower at parsing information must necessarily be faster at problem-solving. ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: [9fans] Unexpected 8c warning message 2009-08-11 10:30 ` Ethan Grammatikidis @ 2009-08-11 22:16 ` James Tomaschke 0 siblings, 0 replies; 13+ messages in thread From: James Tomaschke @ 2009-08-11 22:16 UTC (permalink / raw) To: Fans of the OS Plan 9 from Bell Labs -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Ethan Grammatikidis wrote: > I just don't like parsing a for statement, it's rarely clear and usually ugly to my eyes. Writing a parser to parse a for statement is slightly more involved as well. However I was commenting on how the compiler seems to handle a do/while properly so it might be possible to get for- and while-loops to avoid reporting the false warning with some effort. I still use for(;;) instead of while(1) ever since I saw compilers emit machine code that moved $1 into a register followed by a compare. Most modern compilers do no do this anymore but old habits die hard. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkqB7csACgkQl3JZTBu3/9lgjACgsrd39mxz4Ak6x9cY4iUeK0+A gnUAnRwbVd/6nkxLW5dtxeoxJnS+Njf/ =Rkj5 -----END PGP SIGNATURE----- ^ permalink raw reply [flat|nested] 13+ messages in thread
end of thread, other threads:[~2009-08-11 22:16 UTC | newest] Thread overview: 13+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2009-08-09 19:33 [9fans] Unexpected 8c warning message Adriano Verardo 2009-08-09 19:46 ` Russ Cox 2009-08-09 21:20 ` Adriano Verardo 2009-08-09 21:48 ` erik quanstrom 2009-08-10 16:24 ` Adriano Verardo 2009-08-10 16:43 ` erik quanstrom 2009-08-10 17:19 ` Russ Cox 2009-08-10 23:30 ` Adriano Verardo 2009-08-11 0:19 ` Charles Forsyth 2009-08-10 20:33 ` Adriano Verardo 2009-08-10 21:01 ` James Tomaschke 2009-08-11 10:30 ` Ethan Grammatikidis 2009-08-11 22:16 ` James Tomaschke
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for NNTP newsgroup(s).