* Another ammunition @ 2002-12-31 10:23 Jean-Pierre Rosen 2002-12-31 11:43 ` Eric G. Miller 2003-01-01 9:05 ` Michael Erdmann 0 siblings, 2 replies; 23+ messages in thread From: Jean-Pierre Rosen @ 2002-12-31 10:23 UTC (permalink / raw) I know I'm preaching to the choir, but here is another story Ada fans can tell to the other guys who say that "language doesn't matter"... My son was recently doing an assignment in C, which involved lots of floating point computations, and he kept getting inconsistent results. After lots of searching, he discovered that NaNs were generated in various places. There seemed to be no consistency in the appearing of NaNs: changing optimization options, adding intermediate variables in computations, etc. all changed the way NaNs were produced. Here is what happened: A C function was returning a float, but in some place was declared as returning an int. In gcc, a function that returns a float leaves the result on the coprocessor stack, NOT on the regular stack. Therefore, the return value of the function was not popped off the coprocessor stack. And when the coprocessor's stack is full, every floating point operation results in NaN.... It took a week to understand what was happenning. Would not have passed the first compilation in Ada. FWIW... -- --------------------------------------------------------- J-P. Rosen (rosen@adalog.fr) Visit Adalog's web site at http://www.adalog.fr ^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: Another ammunition 2002-12-31 10:23 Another ammunition Jean-Pierre Rosen @ 2002-12-31 11:43 ` Eric G. Miller 2002-12-31 12:57 ` Jean-Pierre Rosen 2003-01-01 9:05 ` Michael Erdmann 1 sibling, 1 reply; 23+ messages in thread From: Eric G. Miller @ 2002-12-31 11:43 UTC (permalink / raw) Jean-Pierre Rosen wrote: > I know I'm preaching to the choir, but here is another story Ada fans can > tell to the other guys who say that "language doesn't matter"... > > My son was recently doing an assignment in C, which involved lots of floating > point computations, and he kept getting inconsistent results. After lots of > searching, he discovered that NaNs were generated in various places. There > seemed to be no consistency in the appearing of NaNs: changing optimization > options, adding intermediate variables in computations, etc. all changed the > way NaNs were produced. > > Here is what happened: A C function was returning a float, but in some place > was declared as returning an int. In gcc, a function that returns a float > leaves the result on the coprocessor stack, NOT on the regular stack. > Therefore, the return value of the function was not popped off the > coprocessor stack. And when the coprocessor's stack is full, every floating > point operation results in NaN.... > > It took a week to understand what was happenning. Would not have passed the > first compilation in Ada. FWIW... You're right, but I'm sure gcc could have immediately diagnosed the problem had you turned up the warnings ("conflicting types for...", "previous declaration of ..."). The fault here is that the C language requires compilers to be very forgiving, so you have to take explicit actions with compilers to turn warnings into errors (-Wall -W -O -Werror, for starters). IME, gcc rarely gives warnings that are spurious with -Wall (i.e. ignore at your peril). ^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: Another ammunition 2002-12-31 11:43 ` Eric G. Miller @ 2002-12-31 12:57 ` Jean-Pierre Rosen 2002-12-31 16:23 ` Alexander Schreiber 2002-12-31 16:40 ` Warren W. Gay VE3WWG 0 siblings, 2 replies; 23+ messages in thread From: Jean-Pierre Rosen @ 2002-12-31 12:57 UTC (permalink / raw) [-- Warning: decoded text below may be mangled, UTF-8 assumed --] [-- Attachment #1: Type: text/plain, Size: 812 bytes --] "Eric G. Miller" <egm2.NOSPAM@jps-NOSPAM.net> a �crit dans le message news: IpfQ9.4953 > > It took a week to understand what was happenning. Would not have passed the > > first compilation in Ada. FWIW... > > You're right, but I'm sure gcc could have immediately diagnosed the > problem had you turned up the warnings ("conflicting types for...", "previous > declaration of ..."). > Warnings were on, he just overlooked them.... That's what makes a huge difference between a warning which is up to the good will of the compiler (and the programmer paying attention to it), and a *required* compile time error! (count that as another moral of the story). -- --------------------------------------------------------- J-P. Rosen (rosen@adalog.fr) Visit Adalog's web site at http://www.adalog.fr ^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: Another ammunition 2002-12-31 12:57 ` Jean-Pierre Rosen @ 2002-12-31 16:23 ` Alexander Schreiber 2003-01-02 6:55 ` AG 2002-12-31 16:40 ` Warren W. Gay VE3WWG 1 sibling, 1 reply; 23+ messages in thread From: Alexander Schreiber @ 2002-12-31 16:23 UTC (permalink / raw) Jean-Pierre Rosen <rosen@adalog.fr> wrote: > >"Eric G. Miller" <egm2.NOSPAM@jps-NOSPAM.net> a �crit dans le message news: IpfQ9.4953 >> > It took a week to understand what was happenning. Would not have passed the >> > first compilation in Ada. FWIW... >> >> You're right, but I'm sure gcc could have immediately diagnosed the >> problem had you turned up the warnings ("conflicting types for...", "previous >> declaration of ..."). >> >Warnings were on, he just overlooked them.... >That's what makes a huge difference between a warning which is up to the good will of the compiler (and the programmer paying >attention to it), and a *required* compile time error! For gcc, there is always the "anal retentive mode": run it with basically _all_ warnings turned on _and_ any warning considered as error (aborting the compile): -ansi -Wall -pedantic -Wtraditional -Wpointer-arith -Wshadow -Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes -Wcast-qual -Waggregate-return -Wmissing-declarations -Wnested-externs -Winline -Werror -W Forces you to fix the simple bugs to even get your code to compile (leaving you to be more creative in creating tricky logic bugs). Regards, Alex. -- "Opportunity is missed by most people because it is dressed in overalls and looks like work." -- Thomas A. Edison ^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: Another ammunition 2002-12-31 16:23 ` Alexander Schreiber @ 2003-01-02 6:55 ` AG 2003-01-01 16:58 ` Alexander Schreiber ` (2 more replies) 0 siblings, 3 replies; 23+ messages in thread From: AG @ 2003-01-02 6:55 UTC (permalink / raw) > Jean-Pierre Rosen <rosen@adalog.fr> wrote: > -ansi -Wall -pedantic -Wtraditional -Wpointer-arith -Wshadow > -Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes -Wcast-qual > -Waggregate-return -Wmissing-declarations -Wnested-externs -Winline > -Werror -W > Forces you to fix the simple bugs to even get your code to compile > (leaving you to be more creative in creating tricky logic bugs). That's an interesting example. All those switches needed to force you to "fix the simple bugs"? How many people would you think would bother with all the switches? And not make a mistake of omitting one? Even more importantly, how do you know *you* haven't missed one or two? Sure, there are manuals (or are there? or are the manuals complete and up to date? etc etc) but even then, setting up all those switches is surely subject to human error. Isn't it better to just have all of that built right into the language which compiler is required to enforce? ^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: Another ammunition 2003-01-02 6:55 ` AG @ 2003-01-01 16:58 ` Alexander Schreiber 2003-01-07 12:54 ` Peter Hermann 2003-01-07 13:21 ` Richard Riehle 2003-01-03 9:50 ` Jean-Pierre Rosen 2003-01-03 15:24 ` Stephen Leake 2 siblings, 2 replies; 23+ messages in thread From: Alexander Schreiber @ 2003-01-01 16:58 UTC (permalink / raw) AG <ang@xtra.co.nz> wrote: >> Jean-Pierre Rosen <rosen@adalog.fr> wrote: > >> -ansi -Wall -pedantic -Wtraditional -Wpointer-arith -Wshadow >> -Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes -Wcast-qual >> -Waggregate-return -Wmissing-declarations -Wnested-externs -Winline >> -Werror -W > >> Forces you to fix the simple bugs to even get your code to compile >> (leaving you to be more creative in creating tricky logic bugs). > >That's an interesting example. All those switches needed >to force you to "fix the simple bugs"? "simple bugs" == stuff the compiler can find, like trying to write into constants, type mismatches (returning ints but expecting floats), tyops (like a forgotten ";") and the like. Still leaves you free to add buffer overruns, off-by-one errors and so on to your hearts content ;-) >How many people >would you think would bother with all the switches? >And not make a mistake of omitting one? Very few. I've seen enough projects that simply dump stdout and stderr of the compiler into /dev/null during the compile stage - probably to keep the user installing this software from seeing gcc complain about the ugly C he is fed. The long list of compiler switches above came from a programming assignment I once did - I tried to force gcc into the most anal retentive mode possible to avoid leaving stupid and simple coding errors in the project. It helped. >Even more importantly, how do you know *you* haven't >missed one or two? Sure, there are manuals (or are there? >or are the manuals complete and up to date? etc etc) but >even then, setting up all those switches is surely subject >to human error. Isn't it better to just have all of that built >right into the language which compiler is required to enforce? I'm not trying to argue that you should drop Ada and use C instead - there are more than enough misguided zealots of this kind already around. IMHO, the digital world would most likely be a slightly safer place if more software were written in Ada instead of C (and some obnoxious software wouldn't be written at all - good riddance). For me, Ada is an interesting and powerful language - but I still need to find the time to do more than write the canonical "Hello world" in Ada. Regards, Alex. -- "Opportunity is missed by most people because it is dressed in overalls and looks like work." -- Thomas A. Edison ^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: Another ammunition 2003-01-01 16:58 ` Alexander Schreiber @ 2003-01-07 12:54 ` Peter Hermann 2003-01-07 13:21 ` Richard Riehle 1 sibling, 0 replies; 23+ messages in thread From: Peter Hermann @ 2003-01-07 12:54 UTC (permalink / raw) Alexander Schreiber <als@usenet.thangorodrim.de> wrote: > For me, Ada is an interesting and powerful language - but I still need > to find the time to do more than write the canonical "Hello world" in > Ada. > > Regards, > Alex. > -- > "Opportunity is missed by most people because it is dressed in overalls and > looks like work." -- Thomas A. Edison What a coincidence! -- --Peter Hermann(49)0711-685-3611 fax3758 ica2ph@csv.ica.uni-stuttgart.de --Pfaffenwaldring 27 Raum 114, D-70569 Stuttgart Uni Computeranwendungen --http://www.csv.ica.uni-stuttgart.de/homes/ph/ --Team Ada: "C'mon people let the world begin" (Paul McCartney) ^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: Another ammunition 2003-01-01 16:58 ` Alexander Schreiber 2003-01-07 12:54 ` Peter Hermann @ 2003-01-07 13:21 ` Richard Riehle 2003-01-11 18:29 ` Alexander Schreiber 1 sibling, 1 reply; 23+ messages in thread From: Richard Riehle @ 2003-01-07 13:21 UTC (permalink / raw) Alexander Schreiber wrote: > For me, Ada is an interesting and powerful language - but I still need > to find the time to do more than write the canonical "Hello world" in > Ada. Complaints of this kind are one reason I wrote "Ada Distilled." It is intended as an easy way for experienced programmers to try out different programs with a minimum of prowling through long textual explanations. You can download it from www.adaic.org or www.adapower.com. Richard Riehle ^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: Another ammunition 2003-01-07 13:21 ` Richard Riehle @ 2003-01-11 18:29 ` Alexander Schreiber 2003-01-13 2:11 ` u.r. faust 0 siblings, 1 reply; 23+ messages in thread From: Alexander Schreiber @ 2003-01-11 18:29 UTC (permalink / raw) Richard Riehle <richard@adaworks.com> wrote: >Alexander Schreiber wrote: > >> For me, Ada is an interesting and powerful language - but I still need >> to find the time to do more than write the canonical "Hello world" in >> Ada. > >Complaints of this kind are one reason I wrote "Ada Distilled." It is >intended as an easy way for experienced programmers to try out >different programs with a minimum of prowling through long textual >explanations. You can download it from www.adaic.org or >www.adapower.com. Downloaded, added to my local digital library and reading it now. Thanks. Regards, Alex. -- "Opportunity is missed by most people because it is dressed in overalls and looks like work." -- Thomas A. Edison ^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: Another ammunition 2003-01-11 18:29 ` Alexander Schreiber @ 2003-01-13 2:11 ` u.r. faust 2003-01-12 12:44 ` Larry Kilgallen 0 siblings, 1 reply; 23+ messages in thread From: u.r. faust @ 2003-01-13 2:11 UTC (permalink / raw) The "ammunition" analogy is pretty offputting to anyone who is not a hard core military enthusiast. All it does is remind people of Ada's link with the DOD. ( Just imagine how you would react if someone used "another aids infected needle used by a junkie" as a synonym for a good point about a language. ) -- natsu-gusa ya / tsuwamono-domo-ga / yume no ato summer grasses / strong ones / dreams site Summer grasses, All that remains Of soldier's dreams (Basho trans. Stryk) ^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: Another ammunition 2003-01-13 2:11 ` u.r. faust @ 2003-01-12 12:44 ` Larry Kilgallen 2003-01-14 1:24 ` Georg Bauhaus 0 siblings, 1 reply; 23+ messages in thread From: Larry Kilgallen @ 2003-01-12 12:44 UTC (permalink / raw) In article <3cnxyf1j.fsf@optushome.com.au>, "u.r. faust" <urfaust@optushome.com.au> writes: > > The "ammunition" analogy is pretty offputting to anyone who is > not a hard core military enthusiast. Pleasee take the politics to a group where it is on-topic. ^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: Another ammunition 2003-01-12 12:44 ` Larry Kilgallen @ 2003-01-14 1:24 ` Georg Bauhaus 0 siblings, 0 replies; 23+ messages in thread From: Georg Bauhaus @ 2003-01-14 1:24 UTC (permalink / raw) Larry Kilgallen <Kilgallen@spamcop.net> wrote: :> The "ammunition" analogy is pretty offputting to anyone who is :> not a hard core military enthusiast. : : Pleasee take the politics to a group where it is on-topic. The metaphor "ammunition" can easily (and totally unrelated to politics) be replaced by the real thing, and it _will_ serve to bring the discussion back to facts. Convincing arguments in this case. Metaphorically speaking, you wouldn't expect the majority of c.l.Ada readers to feel comfortable with: "Here is ammunition to neutralize your kids' shouting...", would you? -- Georg ^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: Another ammunition 2003-01-02 6:55 ` AG 2003-01-01 16:58 ` Alexander Schreiber @ 2003-01-03 9:50 ` Jean-Pierre Rosen 2003-01-03 15:24 ` Stephen Leake 2 siblings, 0 replies; 23+ messages in thread From: Jean-Pierre Rosen @ 2003-01-03 9:50 UTC (permalink / raw) [-- Warning: decoded text below may be mangled, UTF-8 assumed --] [-- Attachment #1: Type: text/plain, Size: 716 bytes --] "AG" <ang@xtra.co.nz> a �crit dans le message news: hVyQ9.4454$F63.96878@news.xtra.co.nz... > Even more importantly, how do you know *you* haven't > missed one or two? Sure, there are manuals (or are there? > or are the manuals complete and up to date? etc etc) but > even then, setting up all those switches is surely subject > to human error. Isn't it better to just have all of that built > right into the language which compiler is required to enforce? > Agreed. And to state it more simply: this is another example that safety is on *by default* in Ada. -- --------------------------------------------------------- J-P. Rosen (rosen@adalog.fr) Visit Adalog's web site at http://www.adalog.fr ^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: Another ammunition 2003-01-02 6:55 ` AG 2003-01-01 16:58 ` Alexander Schreiber 2003-01-03 9:50 ` Jean-Pierre Rosen @ 2003-01-03 15:24 ` Stephen Leake 2 siblings, 0 replies; 23+ messages in thread From: Stephen Leake @ 2003-01-03 15:24 UTC (permalink / raw) "AG" <ang@xtra.co.nz> writes: > > Jean-Pierre Rosen <rosen@adalog.fr> wrote: > > > -ansi -Wall -pedantic -Wtraditional -Wpointer-arith -Wshadow > > -Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes -Wcast-qual > > -Waggregate-return -Wmissing-declarations -Wnested-externs -Winline > > -Werror -W > > > Forces you to fix the simple bugs to even get your code to compile > > (leaving you to be more creative in creating tricky logic bugs). > > That's an interesting example. All those switches needed > to force you to "fix the simple bugs"? How many people > would you think would bother with all the switches? That's what coding standards are for. Nobody should use any compiler with just the default switches, at least not without a lot of thought first. Here's the relevant section from our coding standard: (2) Compilers shall be configured to enforce the ANSI standard. Table 1 gives the compiler switches required (3) All code should compile without warnings. However, it is sometimes impossible to eliminate warnings; such cases should be documented with comments in the code. TABLE 1. Required Compiler switch settings GNU C -Wall -Wstrict-prototypes -pedantic -ansi -Werror > Even more importantly, how do you know *you* haven't > missed one or two? Because I have read the manuals, and I have been using this set of switches for several years. Every time I find a bug that I think should have been caught by the compiler, I check the manual to see if there is a new switch for that. Of course, first I say "we should be using Ada" :). > Isn't it better to just have all of that built right into the > language which compiler is required to enforce? Yes. That is what Ada is for. But even with Ada, you have to read the compiler documentation and set the compiler switches correctly. -- -- Stephe ^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: Another ammunition 2002-12-31 12:57 ` Jean-Pierre Rosen 2002-12-31 16:23 ` Alexander Schreiber @ 2002-12-31 16:40 ` Warren W. Gay VE3WWG 2003-01-04 20:17 ` David Thompson 1 sibling, 1 reply; 23+ messages in thread From: Warren W. Gay VE3WWG @ 2002-12-31 16:40 UTC (permalink / raw) Jean-Pierre Rosen wrote: > "Eric G. Miller" <egm2.NOSPAM@jps-NOSPAM.net> a �crit dans le message news: IpfQ9.4953 >>>It took a week to understand what was happenning. Would not have passed the >>>first compilation in Ada. FWIW... >> >>You're right, but I'm sure gcc could have immediately diagnosed the >>problem had you turned up the warnings ("conflicting types for...", "previous >>declaration of ..."). > > Warnings were on, he just overlooked them.... > That's what makes a huge difference between a warning which is up to the good will of the compiler (and the programmer paying > attention to it), and a *required* compile time error! > > (count that as another moral of the story). Things may be different now, but I once had a long email discussion with one of the folks about whether a missing return "type" should be a warning or not (it should actually be an error). At the time, you had to specify a compile option to make a declaration like: foo() { ... } return a warning. It should be something like: int foo () { ... } if it does indeed return int. Well, he didn't like the idea of the warning being on by default, and so people continue to get burned by this very problem. -- Warren W. Gay VE3WWG http://home.cogeco.ca/~ve3wwg ^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: Another ammunition 2002-12-31 16:40 ` Warren W. Gay VE3WWG @ 2003-01-04 20:17 ` David Thompson 2003-01-06 17:39 ` Warren W. Gay VE3WWG 0 siblings, 1 reply; 23+ messages in thread From: David Thompson @ 2003-01-04 20:17 UTC (permalink / raw) [-- Warning: decoded text below may be mangled, UTF-8 assumed --] [-- Attachment #1: Type: text/plain, Size: 1963 bytes --] Warren W. Gay VE3WWG <ve3wwg@cogeco.ca> wrote : > Jean-Pierre Rosen wrote: > > "Eric G. Miller" <egm2.NOSPAM@jps-NOSPAM.net> a �crit dans le message news: IpfQ9.4953 ... > >>You're right, but I'm sure gcc could have immediately diagnosed the > >>problem had you turned up the warnings ("conflicting types for...", "previous > >>declaration of ..."). > > > > Warnings were on, he just overlooked them.... Could have (and did) *IF* the same declaration is visible at all relevant locations, typically by #include'ing the same .h file. If you just write out a wrong declaration of foo in bar.c, gcc can't catch it (though a good lint can). Also, if you mistakenly #include a wrong .h file (such as from a wrong subtree) gcc can't catch it, although this is unlikely in simple student projects. (A C implementation *could* legally and practially do the kinds of whole-program or at least cross-unit checks Ada requires and GNAT does, but they don't, not even gcc.) ... > Things may be different now, but I once had a long email discussion > with one of the folks about whether a missing return "type" should > be a warning or not (it should actually be an error). At the time, > you had to specify a compile option to make a declaration like: > > foo() { ... } > > return a warning. ... (That's a definition, not just a declaration. /*int*/ foo () ; is a typical "external" declaration.) According to all C standards before C99 (K&R and C89) it *is* legal and so can't conformingly be an error. With C99 it is a required diagnostic and could well be an error, but won't because implementors don't want to break vast masses of existing legal and supported code. I agree it should be a warning, but whether it's on by default doesn't matter much to me, since I always end up with some mechanism (makefile, script, envvar) for setting flags anyway, and if this needs an entry in there it's no real trouble. -- - David.Thompson 1 now at worldnet.att.net ^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: Another ammunition 2003-01-04 20:17 ` David Thompson @ 2003-01-06 17:39 ` Warren W. Gay VE3WWG 2003-01-06 20:50 ` Stephen Leake 0 siblings, 1 reply; 23+ messages in thread From: Warren W. Gay VE3WWG @ 2003-01-06 17:39 UTC (permalink / raw) David Thompson wrote: > Warren W. Gay VE3WWG <ve3wwg@cogeco.ca> wrote : >>Jean-Pierre Rosen wrote: >> >>>"Eric G. Miller" <egm2.NOSPAM@jps-NOSPAM.net> a �crit dans le message news: >> > IpfQ9.4953 > .... > >>>>You're right, but I'm sure gcc could have immediately diagnosed the >>>>problem had you turned up the warnings ("conflicting types for...", >>> > "previous > >>>>declaration of ..."). >>> >>>Warnings were on, he just overlooked them.... > > Could have (and did) *IF* the same declaration is visible at > all relevant locations, typically by #include'ing the same .h file. > If you just write out a wrong declaration of foo in bar.c, gcc can't > catch it (though a good lint can). Also, if you mistakenly #include > a wrong .h file (such as from a wrong subtree) gcc can't catch it, > although this is unlikely in simple student projects. > (A C implementation *could* legally and practially do > the kinds of whole-program or at least cross-unit checks > Ada requires and GNAT does, but they don't, not even gcc.) > .... >>Things may be different now, but I once had a long email discussion >>with one of the folks about whether a missing return "type" should >>be a warning or not (it should actually be an error). At the time, >>you had to specify a compile option to make a declaration like: >> >>foo() { ... } >> >>return a warning. ... > > (That's a definition, not just a declaration. > /*int*/ foo () ; is a typical "external" declaration.) Sigh, yes, everyone knows this. Even pure undefiled Ada programmers know this, I expect. ;-) > According to all C standards before C99 (K&R and C89) it *is* > legal and so can't conformingly be an error. Fine, but it should be a warning. > With C99 it is a > required diagnostic and could well be an error, but won't because > implementors don't want to break vast masses of existing legal > and supported code. I agree it should be a warning, Agreed. It _should_ be at least a warning. > but whether > it's on by default doesn't matter much to me, since I always end up > with some mechanism (makefile, script, envvar) for setting flags > anyway, and if this needs an entry in there it's no real trouble. > > -- > - David.Thompson 1 now at worldnet.att.net The point is, is that a lot of other projects and even team members fail to include the support for this "warning". If it were on by default, there would be uncounted number of hours saved each year by programmers who instead spend the time debugging a problem related to this issue. I've seen this time and again, even though my team members know about it. It is not enough to say "it is not an issue because I do this...". It is an issue, that could be fixed once and for all. Even a warning doesn't guarantee that it will be noticed and fixed -- but it greatly increases the odds! However, the best solution of all is to use Ada instead, and only rely on C like an assembly level layer, when required ;-) -- Warren W. Gay VE3WWG http://home.cogeco.ca/~ve3wwg ^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: Another ammunition 2003-01-06 17:39 ` Warren W. Gay VE3WWG @ 2003-01-06 20:50 ` Stephen Leake 2003-01-06 22:16 ` Warren W. Gay VE3WWG 0 siblings, 1 reply; 23+ messages in thread From: Stephen Leake @ 2003-01-06 20:50 UTC (permalink / raw) "Warren W. Gay VE3WWG" <ve3wwg@cogeco.ca> writes: > The point is, is that a lot of other projects and even team members > fail to include the support for this "warning". If it were on by > default, there would be uncounted number of hours saved each year > by programmers who instead spend the time debugging a problem > related to this issue. I've seen this time and again, even though > my team members know about it. No tool can substitute for good process, and good education. No tool should be used with only the default command line parameters; the project style guide should say what parameters to specify, and it must be enforced. The first step in your debug process should be to make sure the proper warnings are turned on, and fix all warnings. > It is not enough to say "it is not an issue because I do this...". > It is an issue, yes, it is. And the proper solution is good process. > that could be fixed once and for all. Nope. People who don't like to fix warnings will include the option to supress them (that option has to be there, because you do occasionally have a legitmate need for it). > Even a warning doesn't guarantee that it will be noticed and fixed > -- but it greatly increases the odds! Not much. As has been pointed out in this thread, many people ignore warnings all the time. > However, the best solution of all is to use Ada instead, and only > rely on C like an assembly level layer, when required ;-) True. But even for Ada, using the default command line parameters for the compiler and linker is bad practice. -- -- Stephe ^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: Another ammunition 2003-01-06 20:50 ` Stephen Leake @ 2003-01-06 22:16 ` Warren W. Gay VE3WWG 2003-01-07 18:37 ` Stephen Leake 0 siblings, 1 reply; 23+ messages in thread From: Warren W. Gay VE3WWG @ 2003-01-06 22:16 UTC (permalink / raw) Stephen Leake wrote: > "Warren W. Gay VE3WWG" <ve3wwg@cogeco.ca> writes: > >>The point is, is that a lot of other projects and even team members >>fail to include the support for this "warning". If it were on by >>default, there would be uncounted number of hours saved each year >>by programmers who instead spend the time debugging a problem >>related to this issue. I've seen this time and again, even though >>my team members know about it. > > No tool can substitute for good process, and good education. I agree with this to some degree, but I would also suggest that no amount of "good process or education" is a substitute for bad tools or defaults! > No tool should be used with only the default command line parameters; Nobody said that this should be the case. Nobody. So why harp about this? What was said was that there are safer defaults. > the project style guide should say what parameters to specify, and it > must be enforced. So do you lock down every developer's PC too, so they can't mess with their environment? Programmers are a rebellious lot, and strict levels of enforcement may work in some environments for military projects and NASA, but they don't work in many other environments. Or at least _it isn't done_ ;-) > The first step in your debug process should be to make sure the proper > warnings are turned on, and fix all warnings. No one is doubting this, but there are two problems with this: (1) if the developer is working on a large project with a ton of warnings already, he's not likely to fix them all now. However, if he's smart (and that is not necessarily a given ;-), he'd grep for the most important warnings at least. (2) Some developers (particularly the less experienced ones), do not know what to look for, let alone turn on the correct compile options. At least if it was on by default (or with -Wall), then there would be at least a chance that they'd see it and do something about it. Note: For a time (if not currently), -Wall did not include _all_ warnings. I believe the return type warning was not included. >>It is not enough to say "it is not an issue because I do this...". >>It is an issue, > > yes, it is. And the proper solution is good process. I don't buy this. We're going to have to disagree on this point. >>that could be fixed once and for all. > > Nope. People who don't like to fix warnings will include the option to > supress them (that option has to be there, because you do occasionally > have a legitmate need for it). Again, nobody (I repeat nobody) said that the option to remove that warning should be disabled or removed. The statement was, that it should be on by _default_. Read my lips ;-) "Nothing more, nothing less." If you left your house for a vacation, and due to the hustle and bustle of getting your 3 kids, 2 dogs and your wife all in the van to go, wouldn't you want to be warned that you forgot to lock the back door? Your solution is to strickly depend upon process and "education". Human nature is such that you cannot _depend_ soley upon this. This is why Ada does not depend strictly upon process or education. >>Even a warning doesn't guarantee that it will be noticed and fixed >>-- but it greatly increases the odds! > > Not much. As has been pointed out in this thread, many people ignore > warnings all the time. Whether its is much or little, I won't argue. You concede that it is better, and so even that suggests in favour of what I said in the beginning (change the default). >>However, the best solution of all is to use Ada instead, and only >>rely on C like an assembly level layer, when required ;-) > > True. But even for Ada, using the default command line parameters for > the compiler and linker is bad practice. Again, nobody is saying that you should use strictly defaults. Nobody! But having _safer_ defaults is useful and helpful in the general sense, because _some_ people will use them, irregardless of your superior education and process. Its like herding cats ;-) -- Warren W. Gay VE3WWG http://home.cogeco.ca/~ve3wwg ^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: Another ammunition 2003-01-06 22:16 ` Warren W. Gay VE3WWG @ 2003-01-07 18:37 ` Stephen Leake 2003-01-07 21:55 ` Warren W. Gay VE3WWG 0 siblings, 1 reply; 23+ messages in thread From: Stephen Leake @ 2003-01-07 18:37 UTC (permalink / raw) "Warren W. Gay VE3WWG" <ve3wwg@cogeco.ca> writes: > Stephen Leake wrote: > > No tool should be used with only the default command line parameters; > > Nobody said that this should be the case. Nobody. So why harp > about this? Because you and others keep bringing it up :). > What was said was that there are safer defaults. Why do the defaults matter if you are not going to use them? -- -- Stephe ^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: Another ammunition 2003-01-07 18:37 ` Stephen Leake @ 2003-01-07 21:55 ` Warren W. Gay VE3WWG 0 siblings, 0 replies; 23+ messages in thread From: Warren W. Gay VE3WWG @ 2003-01-07 21:55 UTC (permalink / raw) Stephen Leake wrote: > "Warren W. Gay VE3WWG" <ve3wwg@cogeco.ca> writes: >>Stephen Leake wrote: >> >>>No tool should be used with only the default command line parameters; >> >>Nobody said that this should be the case. Nobody. So why harp >>about this? > > Because you and others keep bringing it up :). But I never said this 8-) >>What was said was that there are safer defaults. > > Why do the defaults matter if you are not going to use them? Well this is precisely why I don't understand your resistance to the idea! You say "you never should..." and "I never do..." and yet all of the resistance to changing the default is coming from you, LOL. I am in favour of changing the default for the various reasons I have already stated. -- Warren W. Gay VE3WWG http://home.cogeco.ca/~ve3wwg ^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: Another ammunition 2002-12-31 10:23 Another ammunition Jean-Pierre Rosen 2002-12-31 11:43 ` Eric G. Miller @ 2003-01-01 9:05 ` Michael Erdmann 2003-01-07 13:03 ` Peter Hermann 1 sibling, 1 reply; 23+ messages in thread From: Michael Erdmann @ 2003-01-01 9:05 UTC (permalink / raw) Jean-Pierre Rosen wrote: > I know I'm preaching to the choir, but here is another story Ada fans can > tell to the other guys who say that "language doesn't matter"... > For me this is a good example, that language does not matter since you can achieve everything in any language by spending unlimited ammount of effort in the implementation phase. > My son was recently doing an assignment in C, which involved lots of > floating point computations, and he kept getting inconsistent results. > After lots of searching, he discovered that NaNs were generated in various > places. There seemed to be no consistency in the appearing of NaNs: > changing optimization options, adding intermediate variables in > computations, etc. all changed the way NaNs were produced. > This is the reason why i am using still Fortran for heavy caculcation. I think that this is not a pure technical problem, because i know a lot researchers which are using C for there calculations. The problem seems to me the teacher, which should know, that a lanaguage is simply a tool to achieve the implementation of your requierements. The usage of these tools has to be questioned during design since every tool is has a limited application domain. My personal experience was that teachers are forced by curiculum to teach on basis of a single language, which i think is simply wrong. The teacher should be asked why he has asked to do the job in C. A happy new year Michael. ^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: Another ammunition 2003-01-01 9:05 ` Michael Erdmann @ 2003-01-07 13:03 ` Peter Hermann 0 siblings, 0 replies; 23+ messages in thread From: Peter Hermann @ 2003-01-07 13:03 UTC (permalink / raw) > This is the reason why i am using still Fortran for heavy > caculcation. an appropriate Freudian typo (in German language) ^ permalink raw reply [flat|nested] 23+ messages in thread
end of thread, other threads:[~2003-01-14 1:24 UTC | newest] Thread overview: 23+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2002-12-31 10:23 Another ammunition Jean-Pierre Rosen 2002-12-31 11:43 ` Eric G. Miller 2002-12-31 12:57 ` Jean-Pierre Rosen 2002-12-31 16:23 ` Alexander Schreiber 2003-01-02 6:55 ` AG 2003-01-01 16:58 ` Alexander Schreiber 2003-01-07 12:54 ` Peter Hermann 2003-01-07 13:21 ` Richard Riehle 2003-01-11 18:29 ` Alexander Schreiber 2003-01-13 2:11 ` u.r. faust 2003-01-12 12:44 ` Larry Kilgallen 2003-01-14 1:24 ` Georg Bauhaus 2003-01-03 9:50 ` Jean-Pierre Rosen 2003-01-03 15:24 ` Stephen Leake 2002-12-31 16:40 ` Warren W. Gay VE3WWG 2003-01-04 20:17 ` David Thompson 2003-01-06 17:39 ` Warren W. Gay VE3WWG 2003-01-06 20:50 ` Stephen Leake 2003-01-06 22:16 ` Warren W. Gay VE3WWG 2003-01-07 18:37 ` Stephen Leake 2003-01-07 21:55 ` Warren W. Gay VE3WWG 2003-01-01 9:05 ` Michael Erdmann 2003-01-07 13:03 ` Peter Hermann
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox