Re: while (1) vs. for ( ;; )
- From: Tim Rentsch <txr@xxxxxxxxxxxxxxxxxxx>
- Date: 01 Sep 2005 09:42:56 -0700
"Charlie Gordon" <news@xxxxxxxxxxx> writes:
> "Tim Rentsch" <txr@xxxxxxxxxxxxxxxxxxx> wrote in message
> news:kfn7je280uo.fsf@xxxxxxxxxxxxxxxxxxxxxx
> > "Charlie Gordon" <news@xxxxxxxxxxx> writes:
> > > Assume the programmer always uses while(1) { ... }
> > > for his endless loops. You quickly get used to interpreting
> > > these automatically as you read them, without paying much
> > > attention. What if there are some while(l) { ... } loops
> > > as well. Will you always keep a sharp enough eye to catch
> > > these correctly ?
> >
> > This question has to deserve some kind of award for being a
> > strawman argument. If you need to find 'while(l)', it takes
> > only a few seconds to write a command:
> >
> > grep -n 'while[ ]*([ ]*l[ ]*)'
> >
> > to find them. (Add tabs next to the spaces inside brackets
> > if developers are prone to use tabs in the middle of lines.)
>
> My intent was not to find such things, just to point out that there is a
> possibility for misreading code and for miswriting it as well. That stupid
> programmer might have meant while(l) and typed while(1) and then cannot tell the
> difference because of a stupid Courier font. How will he/she find this bug ?
Oh. You know about a class of problems, but you don't want
to use the best tools to try to avoid them?
Pick a side. Either the problem is one that's important to
address, or it isn't. You can't have it both ways. If it's
important that the problem be addressed, I would expect any
competent software developer to try to find the most
cost-effective means of solving or avoiding it.
> To go after poorly named variables, I would want to catch and flag all use of
> variables named 'l' this way :
> grep -nw l **/*.[hc]
>
> To bad grep doesn't know how to ignore C comments and literals.
If grep doesn't solve this problem for you, it's really not
that difficult to write a specialized program that does
token search rather than string search. Assuming of course
that there isn't one already written that could be found
with a short web search.
> > Fixing them might take as long as two or three minutes; so
> > to save you the trouble, here's a command for that:
> >
> > sed 's:\(while[ ]*(\)[ ]*l[ ]*):\1 l /*** L, NOT 1! ***/ ):'
> >
> > Please feel free to use either or both of these aids
> > to help identify or correct such egregious code.
>
> Thank you professor, you are so grand!
> You will note that this sed script will break code where the while(l) appears in
> /* comments */
> or change code behaviour if it appears in C strings.
Yes, that's a shortcoming. Do you expect such things to
actually occur, or is this just a silly objection for the
purpose of scoring debate points?
In either case, both conditions are easily addressed.
1. In cases where 'while(l)' appears inside comments, the
new code will get an error message out of the compiler.
Use an editor and fix the problem. (Does anyone still
use comments rather than '#if 0' to comment out sections
of code?)
2. In cases where 'while(l)' appears inside strings (or
character literals), these can be found easily using
diff and grep. Use an editor and fix them.
When I wrote my earlier response, I assumed that there some
level of legitimate concern for an actual potential problem.
Now it appears that you are objecting solely for the purpose
of raising objections, and not because you have any interest
in solving a problem. If so, please do everyone a favor and
just go away.
.
- Follow-Ups:
- Re: while (1) vs. for ( ;; )
- From: Charlie Gordon
- Re: while (1) vs. for ( ;; )
- References:
- Re: while (1) vs. for ( ;; )
- From: Tim Rentsch
- Re: while (1) vs. for ( ;; )
- From: Charlie Gordon
- Re: while (1) vs. for ( ;; )
- Prev by Date: Utility to read a hexadecimal number as string
- Next by Date: Re: register allocation
- Previous by thread: Re: while (1) vs. for ( ;; )
- Next by thread: Re: while (1) vs. for ( ;; )
- Index(es):
Relevant Pages
|
|
