Re: Clunky C cleanup code

From: Merrill & Michele (beckjensen_at_comcast.net)
Date: 12/01/04 

Date: Tue, 30 Nov 2004 21:01:55 -0600

"Keith Thompson" <kst-u@mib.org> wrote in message
news:lnbrdedf5a.fsf@nuthaus.mib.org...
> "Merrill & Michele" <beckjensen@comcast.net> writes:
> >> "Mike Wahler"
> >> >"Merrill & Michele"
> >> > > "fatted"
> >> > > I've written a function (clean_string) to remove characters from a
> >> string,
> >> > > but it looks clunky to me, and I'm sure there's a more 'C' like way
of
> >> > > doing it (still learning), comments and advice welcome...
> >> > >
> >> > > --
> >> > > #include <stdio.h>
> >> > > #include <stdlib.h>
> >> > > #include <string.h>
> >> > >
> >> > > int main(void)
> >> > > {
> >> > > char * clean_string(const char *, const
> >> > [single point to make, rest of post snipped]
> >> >
> >> > I get routinely chastised for defining functions inside of main().
> >>
> >> OP's code did not contain any function definitions inside of main
> >> or any other function.
> >
> > Let me go through my premises. There are two return statements. This
> > implies .... What if I #defined 'definition' 'prototype declaration' in
my
> > last post? MPJ
>
> If you "#defined 'definition' 'prototype declaration'", your last post
> would have been unreadable. But yes, I know what you meant.
>
> Yes, there are two return statements, one inside the definition of
> main(), and one inside the definition of clean_string(). No problem
> there.
>
> A function definition includes the stuff in curly braces; that can't
> be nested inside another function definition.
>
> The original post has a function *declaration* inside the definition
> of main(). This is legal, but not generally a good idea.
>
> You need to have (or, in C90, should have) a visible declaration in
> order to call the function from within main(). One way to do this
> would be to put the entire definition of clean_string() before the
> definition of main(), but there are good reasons to want to put main()
> at the top -- and this method doesn't work if you have mutually
> recursive functions.
>
> The usual method is to put declarations (prototypes) for functions
> other than main near the top of the source file, outside any function
> definition. (You don't usually need a separate prototype for main
> because main isn't usually called explicitly.) If the functions
> aren't to be called from any other source file, it's best to declare
> them static. If they are, the declarations should be in a separate
> header file.

Thanks all for correcting my correction, in particular Mr. Thompson with
generous detail. OP does one other thing that caught my interest. He
returns EXIT_SUCCESS from main(). My stdlib has the following:

/* Definition of the argument values for the exit() function */

#define EXIT_SUCCESS 0
#define EXIT_FAILURE 1

I know that one possible answer to my following question is
READ_THE_STANDARD, but that's like telling me to climb Everest with only a
windbreaker. Q) Is there any virtue to using EXIT_SUCCESS as opposed to 0
? MPJ

Relevant Pages

  • Re: Newbie: structs in vectors
    ... How/where do I define a constructor function? ... He meant seperate your declarations from your definitions. ... you can define the constructor in it's source file Total.cpp with an ...
    (alt.comp.lang.learn.c-cpp)
  • Re: cout << char*
    ... "Igor Tandetnik" wrote: ... Each source file is ... Including CLib.h in library.cpp is adding the declarations to the definitions. ... int id ...
    (microsoft.public.vc.language)
  • Re: Utility to ensure appropriate headers were included
    ... a header file that's included directly in the source file? ... that utility is called a C compiler. ... He's not talking about missing declarations. ... declarations that depend on a header that is included indirectly by ...
    (comp.lang.c)
  • Re: Ahead of "main"?
    ... The latter style is effectively required when you move to multi-file projects, and the standard practice is to put all of your function declarations in header files so that each source file can simply #include the appropriate header files and then use whatever functions are needed. ... Actually, you should not put *all* your function definitions in header files, since generally there are some which should be local to a given source file and declared static in that source file. ...
    (comp.lang.c)
  • Re: K&R2 1-23
    ... >> The exercise is to remove all comments from a source file. ... >> int main ... >> MPJ ...
    (comp.lang.c)