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