Re: Inconsistent Program Results

Francine.Neary@xxxxxxxxxxxxxx writes:
The standard headers will contain only declarations;
including one of them might trivially slow down compilation, but it
won't cause any bloat in your executable.

OK, that's interesting, thanks.

I wrote the above (starting with "The standard headers"). Please
don't delete attribution lines.

void rdinpt();

Make this:

void rdinput(char **);

I don't think it's obligatory to list the parameters yet is it?

It's not obligatory, but you should *always* do it anyway; there's no
good reason not to. Using a prototype (i.e., specifying the types of
the parameters) allows the compiler to detect certain errors, and in
many cases to adjust the argument via an implicit conversion, and
costs you nothing.

Surely it makes the code harder to maintain? If I change the parameter
types of rdinpt then I'd have to go back and change it consistently
somewhere else too. As I understand it, the main point of putting in
this declaration is so that I call rdinpt from a function that occurs
before its body in the source file, and leaving the parameters
flexible still achieves this.

If you change the parameter types, you have to change all the calls as
well. Leaving the parameter types out doesn't give you any real
flexibility; it just makes errors more difficult to detect.

Sounds like more typing :(

More typing, and easier reading. How many times to you type the name?
How many times will you and others read it?

Well, with things like strspn, atoi and setjmp in the standard
library, brevity of names seems to have good precedents in C.

Sure, but we know what "atoi" means, and if we don't, we can look it
up in the standard. We don't have that advantage when we encounter
the name "rdinpt".

When the names of the functions in the standard library were chosen,
some linkers limited external identifiers to just 6 significant
characters, and hardware (teletypes) was such that long identifiers
were physically more difficult to type (or so I've heard; it was
before my time). We're no longer subject to those limitations.

Get a better textbook.

main() returns int. Some compilers may allow it to be declared to
return void, but there's no advantage in using that. By declaring
main to return int, you gain portability, and again, it costs you
*nothing*.

This seems quite a basic point, and I doubt a textbook would get it
wrong.

I admit it's surprising, but it happens to be true. "void main()" is
incorrect, and many textbooks really do get it wrong. See questions
11.12a through 11.15 in the comp.lang.c FAQ, <http://www.c-faq.com/>.
And if that doesn't convince you, the latest version of the C standard
is available at
<http://www.open-std.org/jtc1/sc22/wg14/www/docs/n1124.pdf>.

It costs some thought - if you don't have anything useful to return
from main, what int should you return? 0? 1? 19223?

0.

The only portable values you can return from main() are 0,
EXIT_SUCCESS, and EXIT_FAILURE; the latter are macros defined in
<stdlib.h>.

Yes, there are things you have to remember.

malloc(), if it succeeds, returns a pointer (of type void*) to a chunk
of memory that's guaranteed to be properly aligned for any data type.
A void* pointer can be implicitly converted to any pointer-to-object
type. The cast is absolutely unnecessary.

OK then, I'll try to remember not to typecast malloc in future, though
again it seems very common in all the code I've seen.

You see a lot of bad code.

Thanks, I always forget whether to return() or return(0) at the end of
a void function.

"return();" is a syntax error. "return(0);" or "return 0;" is
incorrect in a void function. "return;" is unnecessary unless you're
terminating the function early.

Hah! Now I remember exactly what happened. I started with return(),
got an error, and assumed I had to return(0) instead - this only gave
a warning, but gcc is extremely picky and produces lots of warnings,
so I tend to ignore them. Why is return() a syntax error? That seems
pretty inconsistent with the syntax for calling a non-built-in
function with no arguments.

"return" is *not* a function, it's a keyword. A return statement
isn't a function call; it's a special kind of statement with its own
syntax.

You're cheating yourself by ignoring warning messages. gcc can be
picky, but most of its warnings are valid. If you have a question
about a particular warning message, feel free to ask here.

--
Keith Thompson (The_Other_Keith) kst-u@xxxxxxx <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <*> <http://users.sdsc.edu/~kst>
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"
.

Relevant Pages

  • Re: how to get CVF not to compile when more than 132 characters on a line?
    ... Set Standard-checking to F95 and "Warn on source truncation" ... In the IDE these are in Compilation Diagnostics under Project Settings... ... For some reason the "Standard warning as error" didn't trigger a fatal ...
    (comp.lang.fortran)
  • Re: Trigraphs forever
    ... since a "diagnostic" only needs to be a warning. ... What the standard doesn't have is requirements that compilation shall ... fail at certain times. ...
    (comp.std.c)
  • Re: how to get CVF not to compile when more than 132 characters on a line?
    ... Set Standard-checking to F95 and "Warn on source truncation" ... For some reason the "Standard warning as error" didn't trigger a fatal ... So, didn't _stop_ compilation outright, but does provide a warning. ...
    (comp.lang.fortran)
  • Re: question on main( )
    ... void main ... Is the compiler supposed to generate warning or error according to ... Standard C. ... allows the implementation to define more) but I don't believe that it is in a constraint, so I think it is undefined behaviour rather than requiring a diagnostic. ...
    (comp.lang.c)
  • Re: question on main( )
    ... subramanian100in@xxxxxxxxx, India wrote: ... void main ... Is the compiler supposed to generate warning or error according to ... Standard C. ...
    (comp.lang.c)