Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
| From | Eric Sosman <esosman@comcast-dot-net.invalid> |
|---|---|
| Newsgroups | comp.lang.c |
| Subject | Re: disadvantages of using old parameter syntax? |
| Date | 2015-09-04 10:10 -0400 |
| Organization | A noiseless patient Spider |
| Message-ID | <msc8l0$rjd$1@dont-email.me> (permalink) |
| References | <msc3ru$d6a$1@speranza.aioe.org> |
On 9/4/2015 8:46 AM, Anonymous Shadow wrote:
> Are there any important differences I should know about when writing
> code like this:
>
> int
> main(argc, argv)
> int argc;
> char* argv[];
> {
> do_stuff(argc, argv);
> return EXIT_SUCCESS;
> }
>
> as opposed to this:
>
> int
> main(int argc, char *argv[])
> {
> do_stuff(argc, argv);
> return EXIT_SUCCESS;
> }
>
> I know that the first one is used in some old code, like the bsd games,
> but now nobody uses it anymore. If there isn't a big problem with doing
> this, I would like to use it, as it saves a lot of space when dealing
> with multiple arguments with types such as /unsigned short int/, which
> use up a lot of space on an 80-column tty.
Use the newer form, not the older.
The older form does not provide a prototype to "advertise" the
parameters to the rest of the program. When the compiler sees a call
to a non-prototyped function, it will not necessarily check the number
and types of the argument expressions for agreement with the parameters.
Worse, the compiler *will* not convert arguments to the parameters'
types; it will instead apply the "default argument promotions," even
if these are inappropriate for the function being called. Example:
#include <stdio.h>
void new(double a)
{
printf("new says %g!\n", a);
}
void old(a)
double a;
{
printf("old says %g!\n", a);
}
int main(void)
{
new(42); // `int' expression is converted to `double'
old(42); // `int' expression is *not* converted
return 0;
}
Sometimes it is possible to write a prototype for an old-style
function, but there are traps and it cannot always be done correctly.
Here's a fairly obvious trap, based on one of your examples:
// Function definition:
void shortFunc(a)
short a;
{ ... }
// Incorrect declaration:
void shortFunc(short a);
This is wrong, because the actual definition takes an `int' that it
then converts to `short' for internal use. The proper declaration
would be:
// Corrected declaration:
void shortFunc(int a);
That is, the parameter type in the prototype must *not* be the same
as the one seen in the definition! Can you say "maintenance nightmare?"
It gets worse:
// Function definition:
void charFunc(a)
char a;
{ ... }
// Choose the correct declaration:
void charFunc(char a); // (1)
void charFunc(int a); // (2)
void charFunc(unsigned int a); // (3)
We know that (1) is never correct because a `char' argument expression
will promote -- but to what? On most machines nowadays (2) will be
correct, but the C language allows "exotic" architectures where (3)
would be the right choice. You'd need to write something like:
#include <limits.h>
#if INT_MIN <= CHAR_MIN && CHAR_MAX <= INT_MAX
void charFunc(int a);
#else
void charFunc(unsigned int a);
#endif
... and your goal of brevity is, er, somewhat compromised.
It gets even worse than that! There are expressions that promote
in ways the compiler need not document at all. Example:
enum suit { SPADE, HEART, DIAMOND, CLUB };
// Function definition:
void suitFunc(a)
enum suit a;
{ ... }
To the best of my knowledge, there is *no* way to write a prototype
for this function and be sure of getting it right. When the compiler
chooses a "backing type" for the enum, it is free to choose *any*
integer type that supports all the values -- 0 through 3, in this
case. It may choose `int' or `unsigned int' or `unsigned char' or
`long' or ... Furthermore, it does not advertise its choice in any
way you could test, certainly not in any way you could test with
the preprocessor. Note also that without a prototype
enum suit s = ...;
suitFunc(s); // Correct
suitFunc(SPADE); // Quite possibly incorrect
... because an `enum suit' is some unspecified integer type, while
`SPADE' has the type `int', possibly different. The two types may
or may not promote the same way; have fun with that.
Finally, the use of old-form definitions is officially "an
obsolescent feature" according to the current language Standard,
which means "they may be considered for withdrawal in future
revisions of this International Standard ... their use in new
implementations or new programs is discouraged."
Don't do it.
--
esosman@comcast-dot-net.invalid
"Don't be afraid of work. Make work afraid of you." -- TLM
Back to comp.lang.c | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll thread
disadvantages of using old parameter syntax? Anonymous Shadow <rocket.penguin@riseup.net> - 2015-09-04 20:46 +0800
Re: disadvantages of using old parameter syntax? Anonymous Shadow <rocket.penguin@riseup.net> - 2015-09-04 20:49 +0800
Re: disadvantages of using old parameter syntax? raltbos@xs4all.nl (Richard Bos) - 2015-09-04 16:19 +0000
Re: disadvantages of using old parameter syntax? Eric Sosman <esosman@comcast-dot-net.invalid> - 2015-09-04 10:10 -0400
Re: disadvantages of using old parameter syntax? "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-09-04 07:23 -0700
Re: disadvantages of using old parameter syntax? mark.bluemel@gmail.com - 2015-09-04 07:45 -0700
Re: disadvantages of using old parameter syntax? David Brown <david.brown@hesbynett.no> - 2015-09-05 14:59 +0200
Re: disadvantages of using old parameter syntax? Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-09-07 13:26 -0700
Re: disadvantages of using old parameter syntax? David Brown <david.brown@hesbynett.no> - 2015-09-08 08:51 +0200
Re: (Not) discussing C-like toy languages Noob <root@127.0.0.1> - 2015-09-08 13:35 +0200
Re: (Not) discussing C-like toy languages David Brown <david.brown@hesbynett.no> - 2015-09-08 13:59 +0200
Re: (Not) discussing C-like toy languages gazelle@shell.xmission.com (Kenny McCormack) - 2015-09-08 12:35 +0000
Re: (Not) discussing C-like toy languages Noob <root@127.0.0.1> - 2015-09-08 17:55 +0200
Re: (Not) discussing C-like toy languages James Kuyper <jameskuyper@verizon.net> - 2015-09-08 13:11 -0400
Re: (Not) discussing C-like toy languages "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-09-08 10:19 -0700
Re: (Not) discussing C-like toy languages Noob <root@127.0.0.1> - 2015-09-08 21:31 +0200
Re: (Not) discussing C-like toy languages Richard Heathfield <rjh@cpax.org.uk> - 2015-09-08 20:33 +0100
Re: (Not) discussing C-like toy languages David Brown <david.brown@hesbynett.no> - 2015-09-08 22:56 +0200
Re: (Not) discussing C-like toy languages David Brown <david.brown@hesbynett.no> - 2015-09-08 22:52 +0200
Re: (Not) discussing C-like toy languages Richard Heathfield <rjh@cpax.org.uk> - 2015-09-08 21:59 +0100
Re: (Not) discussing C-like toy languages Gareth Owen <gwowen@gmail.com> - 2015-09-08 21:28 +0100
Re: (Not) discussing C-like toy languages James Kuyper <jameskuyper@verizon.net> - 2015-09-08 10:56 -0400
Re: (Not) discussing C-like toy languages Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-09-08 08:33 -0700
Re: (Not) discussing C-like toy languages fir <profesor.fir@gmail.com> - 2015-09-08 09:12 -0700
Re: (Not) discussing C-like toy languages "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-09-08 09:18 -0700
Re: (Not) discussing C-like toy languages fir <profesor.fir@gmail.com> - 2015-09-08 10:15 -0700
Re: (Not) discussing C-like toy languages "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-09-08 08:38 -0700
Re: (Not) discussing C-like toy languages fir <profesor.fir@gmail.com> - 2015-09-08 08:07 -0700
Re: disadvantages of using old parameter syntax? James Kuyper <jameskuyper@verizon.net> - 2015-09-04 10:48 -0400
Re: disadvantages of using old parameter syntax? Paul N <gw7rib@aol.com> - 2015-09-07 12:48 -0700
csiph-web