New 'n' Improved comp.lang.c FAQ List
Kevin Grover
grover at big-joe.cs.unlv.edu
Tue Apr 2 06:30:24 AEST 1991
> [misc deleted. . .]
> Q: Why doesn't this function work:
>
> itoa(int i)
> {
> char retbuf[5]; /* biggest int: 32769 */
> sprintf("%d", retbuf, i);
> return retbuf;
> }
>
> A: Heavens, you left out the parentheses in the return statement.
> No wonder it didn't work.
WRONG: The return does NOT need parans. Also, this function should be
declared to return char *, rather then the default int. The
retbuf space is temporary: you can NOT depend on it being there
after the call. It should be declared static. Furthermore, the
sprintf call is wrong: the retbuf should preceed the format statement.
A correct version of this program is:
char *itoa(int i)
{
static char retbuf[5]; /* biggest int: 32769 */
sprintf(retbuf, "%d", i);
return retbuf;
}
Was this program even checked before being submitted? I find the
idea of a FAQ quite nice and feel that it can help people learning
C very much, but blantantly incorrect answers such as this one could
cause someone not familiar with C many problems. (If it was a joke,
it should have been made clear somewhere.)
Another note: since that one buffer space is used to hold the results
of all calls to this function, a call like:
printf ("%s %s\n", itoa(x), itoa(y) );
might, or might not work (most likely not), becuase the C code will
convert x to ascii (in retbuf), and return the pointer, then the
second call will convert y to ascii (in retbuf) and return the same
pointer. Thus, the output will be:
y y
rahter than:
x y
Again, this MIGHT work on some machines (esp. PCs) but, you should NOT
depend on it working anywhere. (I do know that I will NOT work on
a SPARCstation 1 running gcc. I tried it.)
> [misc deleted . . .]
>
> Q: Which is more efficient, i = i + 1 or i = 1 + i ?
>
> A: Neither; both will generate a two- or three-operand add instruction,
> with a wasteful in-line immediate constant operand, while most machines
> have a much more efficient single-operand increment instruction. My
> compiler lets me use the built-in intrinsic function __inc(i) so that
> the inc instruction is emitted in-line, without even using a function
> call! If your compiler doesn't have __inc(), you might have to use an
> asm directive.
Why not just use the ++ operator??? (as in i++, or ++i) Any decent
compiler should use the ML increment function if your machine has one.
> [misc deleted . . .]
>
> Q: What's the best indentation and brace placement style?
>
> A: Don't bother indenting; the compiler ignores whitespace anyway.
> Braces epitomize the cryptic terseness for which C is notorious. Rather
> than trying to place them in such a way as to make grouping more
> obvious, it is better to set up some macro #definitions:
>
> #define begin {
> #define end }
>
> Then you can use the keywords "begin" and "end" to delineate compound
> statements, which will make things much clearer.
>
> Using the preprocessor to provide "syntactic syrup" in this way can
> powerfully affect the readability of a program. I'm sure that many
> readers have come up with other syntax-liberating macros (SLM's) like
> these. Why doesn't everybody post their favorite ones, and we'll
> compile a complete list?
What do you mean, DON'T BOTHER INDENTING???? Is this a joke? Was
this whole post a joke? Proper indentation makes a program MUCH more
readable (just as improper indentation makes a program virtually
unreadable). As to what is proper, that is a matter of opinion,
although that are several defacto standards (such as K&R) which might
not be the best (again opinion), but are certainly better then not
indentation standard (my opinion.)
While we're at it, why not forget about comments as well? After all,
the compiler just ignores them anyway :-) ???
--
+-------------------------------------------------+----------------------+
| Kevin Grover UNLV Computer Science | Home of the |
| grover at cs.unlv.edu Las Vegas, Nevada | Running REBELS |
+-------------------------------------------------+----------------------+
More information about the Comp.lang.c
mailing list