format for declaring variables?

[Daniel Rudy]

Hello Group,

Consider the following code:


/* form 1 */
int main(void)
{
int i;
char *p;

/* do something */

return(0);
}



/* form 2 */
int main(void)
int i;
char *p;
{

/* do something */

return(0);
}

It seems alot of unix code uses the second form for initializing
variables. Alot of my code uses the first form. Is there any
operational difference between the two?




--
Daniel Rudy

Email address has been base64 encoded to reduce spam
Decode email address using b64decode or uudecode -m

Why geeks like computers: look chat date touch grep make unzip
strip view finger mount fcsk more fcsk yes spray umount sleep

[Richard Heathfield]

Re: format for declaring variables?

[code reflowed for vertical compression!]

Daniel Rudy said:

Consider the following code:
>
/* form 1 */
int main(void) { int i; char *p; /* do something */ return(0); }
>
/* form 2 */
int main(void) int i; char *p; { /* do something */ return(0); }
>
It seems alot of unix code uses the second form for initializing
variables. Alot of my code uses the first form. Is there any
operational difference between the two?

The two forms are not equivalent, and indeed the second form is illegal.
What I think you're trying to represent, which *is* legal, is:

int main(i, p) int i; char **p; { return(0); }

and it is basically an archaeological curiosity. It is equivalent to:

int main(int i, char **p) { return(0); }

except that this more up-to-date ("function prototype") version
facilitates the compiler's type-checking - which is why it was
introduced. The older form is still legal for hysterical reasons.

Ignore the older version if you can. Better still, update code that uses
it to adopt the prototype style.

Incidentally, the parentheses around the 0 are redundant and pointless.

--
Richard Heathfield
"Usenet is a strange place" - dmr 29/7/1999

http://www.cpax.org.uk

email: rjh at the above domain, - www.

[Richard Bos]

Re: format for declaring variables?

Daniel Rudy <spamthis@spamt his.netwrote:

/* form 1 */
int main(void)
{
int i;
char *p;

return(0);
}

/* form 2 */
int main(void)
int i;
char *p;
{

return(0);
}
>
It seems alot of unix code uses the second form for initializing
variables.

No, you don't, and if you did it isn't C.

Alot of my code uses the first form. Is there any
operational difference between the two?

Yes. The former is C, the latter is not.

What you _may_ have seen is this:

int main()
int i;
char *p;
{

return(0);
}

Note the lack of a void keyword in the function header. This makes this
an old-style declaration, rather than a prototype. They're obsolescent,
and IMO should have been obsoleted in the 1999 C Standard. Very old code
may still be around which was written like this in 18-something; code
which still has to compile on antediluvial, pre-Standard compilers may
still need to be written like this; but no normal code should be written
like it today.

Richard

[Jens Thoms Toerring]

Re: format for declaring variables?

Daniel Rudy <spamthis@spamt his.netwrote:

/* form 1 */
int main(void)
{
int i;
char *p;

/* do something */

return(0);
}

/* form 2 */
int main(void)
int i;
char *p;
{

/* do something */

return(0);
}

It seems alot of unix code uses the second form for initializing
variables. Alot of my code uses the first form. Is there any
operational difference between the two?

It's not about initializing variables but function parameters. And
the second form is the correct form, the first form is from times
before standardization of C by ANSI/ISO. i.e. from before 1989/90.
It's only still supported for backward compatibility. And, actually,
the way you write it isn't correct, if I remember correctly it would
have to be

int main(i,p)
int i;
char *p;

making main() a function that takes an integer argument 'i' and a char
pointer argument 'p' which would be written nowadays

int main(int i, char *p)

(Both are, of course, not standard-compliant since main() takes
either no arguments or an int and a char** or an array of char*.)

Regards, Jens
--
\ Jens Thoms Toerring ___ jt@toerring.de
\______________ ____________ http://toerring.de

[Daniel Rudy]

Re: format for declaring variables?

At about the time of 2/9/2007 1:25 AM, Daniel Rudy stated the following:

Hello Group,
>

snip

>
It seems alot of unix code uses the second form for initializing
variables. Alot of my code uses the first form. Is there any
operational difference between the two?
>

I was using main as an example to demonstrate the form....and it should
have been declaring and not initializing there too....

Anyways, I know that this IS platform specific, but here's what I saw,
copied verbatim from the source file:

int
kenv(td, uap)
struct thread *td;
struct kenv_args /* {
int what;
const char *name;
char *value;
int len;
} */ *uap;
{
char *name, *value;
size_t len, done, needed;
int error, i;

KASSERT(dynamic _kenv, ("kenv: dynamic_kenv = 0"));

error = 0;
if (uap->what == KENV_DUMP) {
#ifdef MAC
error = mac_check_kenv_ dump(td->td_ucred);
if (error)
return (error);
#endif
done = needed = 0;
sx_slock(&kenv_ lock);
for (i = 0; kenvp[i] != NULL; i++) {


I cut it short because it's pretty long. But if you want to see for
yourself, FreeBSD 6.2-RELEASE /usr/src/sys/kern/kern_environmen t.c is
where this code fragment came from. The CVS tag on the file is dated
2005/10/09 which is pretty recent.


--
Daniel Rudy

Email address has been base64 encoded to reduce spam
Decode email address using b64decode or uudecode -m

Why geeks like computers: look chat date touch grep make unzip
strip view finger mount fcsk more fcsk yes spray umount sleep

[quarkLore]

Re: format for declaring variables?

except that this more up-to-date ("function prototype") version
facilitates the compiler's type-checking - which is why it was
introduced. The older form is still legal for hysterical reasons.
>
Ignore the older version if you can. Better still, update code that uses
it to adopt the prototype style.
>

Following compiles with gcc (version 3.2.2). Even if I use strict
flags like -ansi -Wall -Werror without warning or error. So using this
you can potentially landup in a mess.

int myf(i)
int i;
{
/* do something */
return(0);
}

int main(void)
{
myf(10,10);
return 0;
}

[Richard Heathfield]

Re: format for declaring variables?

Daniel Rudy said:

<snip>

Anyways, I know that this IS platform specific,

Fortunately, that doesn't matter here (and anyway, you tried, right?).

but here's what I saw, copied verbatim from the source file:
>
int
kenv(td, uap)
struct thread *td;
struct kenv_args /* [...] */ *uap;
{

That's legal.

The modern form is:
int
kenv(struct thread *td, struct kenv_args *uap)
{

They have identical semantics for all intents and purposes, except that
the latter form allows stricter type-checking by the compiler.

--
Richard Heathfield
"Usenet is a strange place" - dmr 29/7/1999

http://www.cpax.org.uk

email: rjh at the above domain, - www.

[Daniel Rudy]

Re: format for declaring variables?

At about the time of 2/9/2007 1:43 AM, Jens Thoms Toerring stated the
following:

Daniel Rudy <spamthis@spamt his.netwrote:

>/* form 1 */
>int main(void)
> {
> int i;
> char *p;

>

> /* do something */

>

> return(0);
> }

>

>/* form 2 */
>int main(void)
> int i;
> char *p;
> {

>

> /* do something */

>

> return(0);
> }

>

>It seems alot of unix code uses the second form for initializing
>variables. Alot of my code uses the first form. Is there any
>operational difference between the two?

>
It's not about initializing variables but function parameters. And
the second form is the correct form, the first form is from times
before standardization of C by ANSI/ISO. i.e. from before 1989/90.
It's only still supported for backward compatibility.

And, actually,
the way you write it isn't correct, if I remember correctly it would
have to be
>

That's interesting, because on programs that don't take arguments, I
always do int main(void).

int main(i,p)
int i;
char *p;
>

Hmm...maybe I missed something.

making main() a function that takes an integer argument 'i' and a char
pointer argument 'p' which would be written nowadays
>
int main(int i, char *p)
>
(Both are, of course, not standard-compliant since main() takes
either no arguments or an int and a char** or an array of char*.)
>
Regards, Jens
--
\ Jens Thoms Toerring ___ jt@toerring.de
\______________ ____________ http://toerring.de

--
Daniel Rudy

Email address has been base64 encoded to reduce spam
Decode email address using b64decode or uudecode -m

Why geeks like computers: look chat date touch grep make unzip
strip view finger mount fcsk more fcsk yes spray umount sleep

[Richard Heathfield]

Re: format for declaring variables?

quarkLore said:

>Ignore the older version if you can. Better still, update code that
>uses it to adopt the prototype style.
>>

>
Following compiles with gcc (version 3.2.2). Even if I use strict
flags like -ansi -Wall -Werror without warning or error. So using this
you can potentially landup in a mess.
>
int myf(i)
int i;
{
/* do something */
return(0);
}
>
int main(void)
{
myf(10,10);
return 0;
}

Which is precisely why I suggested updating the code to use the
prototype style.
</confused>

--
Richard Heathfield
"Usenet is a strange place" - dmr 29/7/1999

http://www.cpax.org.uk

email: rjh at the above domain, - www.

[Daniel Rudy]

Re: format for declaring variables?

At about the time of 2/9/2007 2:03 AM, Richard Heathfield stated the
following:

Daniel Rudy said:
>
<snip>
>

>Anyways, I know that this IS platform specific,

>
Fortunately, that doesn't matter here (and anyway, you tried, right?).
>

Tried? Not sure what you mean there...

>but here's what I saw, copied verbatim from the source file:
>>
>int
>kenv(td, uap)
> struct thread *td;
> struct kenv_args /* [...] */ *uap;
>{

>
That's legal.

Ok. That form threw me for a loop. I had no idea what was going on.

The modern form is:
int
kenv(struct thread *td, struct kenv_args *uap)
{
>
They have identical semantics for all intents and purposes, except that
the latter form allows stricter type-checking by the compiler.
>

I've only used the modern form. People using different styles like that
makes the code much harder to read and decipher. But for a project as
complicated as an operating system kernel (that's what that code
fragment is from), you have a bunch of different people working on
different parts and everybody has their own style.


OT: Speaking of style, forms like this bug me:

if ((fc = open(filename)) < 0)
errx("file error %d\n", errno);

How hard is it to sit there and do this instead?

fc = open(filename);
if (fc < 0) errx("file error %d\n", errno);

It's just so much easier to read, less error prone (since there are
fewer nested () ), and it probably generates the exact same code at the
machine level.


--
Daniel Rudy

Email address has been base64 encoded to reduce spam
Decode email address using b64decode or uudecode -m

Why geeks like computers: look chat date touch grep make unzip
strip view finger mount fcsk more fcsk yes spray umount sleep

[Chris Dollin]

Re: format for declaring variables?

Daniel Rudy wrote:

OT: Speaking of style, forms like this bug me:
>
if ((fc = open(filename)) < 0)
errx("file error %d\n", errno);
>
How hard is it to sit there and do this instead?
>
fc = open(filename);
if (fc < 0) errx("file error %d\n", errno);
>
It's just so much easier to read, less error prone (since there are
fewer nested () ), and it probably generates the exact same code at the
machine level.

But doesn't work as part of an else-if without putting up
extra scaffolding.

(Myself, I want to know why I can't put /declarations/ in
the conditions of an if [1,2].)

[1] Because then I don't have to introduce variables before
I know their values.

[2] Yes, it can be done cleanly, although I haven't thought
hard about it /for C/.

--
Chris "electric hedgehog" Dollin
"Our future looks secure, but it's all out of our hands"
- Magenta, /Man and Machine/

[Richard Heathfield]

Re: format for declaring variables?

Daniel Rudy said:

At about the time of 2/9/2007 2:03 AM, Richard Heathfield stated the
following:

>Daniel Rudy said:
>>
><snip>
>>

>>Anyways, I know that this IS platform specific,

>>
>Fortunately, that doesn't matter here (and anyway, you tried,
>right?).
>>

>
Tried? Not sure what you mean there...

I mean that you made an effort in your original article to present the
problem in a platform-independent way - which was good. Okay, it didn't
work out on this occasion, and it turns out it didn't matter anyway,
but you did make the effort.

--
Richard Heathfield
"Usenet is a strange place" - dmr 29/7/1999

http://www.cpax.org.uk

email: rjh at the above domain, - www.

[Keith Thompson]

Re: format for declaring variables?

Daniel Rudy <spamthis@spamt his.netwrites:

At about the time of 2/9/2007 1:43 AM, Jens Thoms Toerring stated the
following:

[...]

>And, actually,
>the way you write it isn't correct, if I remember correctly it would
>have to be
>>

Um, you snipped what Jens said it would have to be. Oh, well.

That's interesting, because on programs that don't take arguments, I
always do int main(void).

Yes, that's valid.

There are two permitted forms for main:

int main(int argc, char *argv[]) { /* ... */ }

int main(void) { /* ... */ }

(or equivalent).

This:

int main(argc, argv)
int argc;
char *argv;
{
/* ... */
}

is an old-style declaration; it's still legal, but it shouldn't be
used in new code.

>int main(i,p)
> int i;
> char *p;
>>

That's equivalent to the above old-style declarations (the parameters
don't have to be named "argc" and "argv", but they are by convention,
and there's no good reason to use different names) -- except that
"char *p;" should be "char **p;" or "char *p[];".

[...]

--
Keith Thompson (The_Other_Keit h) kst-u@mib.org <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.

[CBFalconer]

Re: format for declaring variables?

Daniel Rudy wrote:

>

.... snip ...

>
OT: Speaking of style, forms like this bug me:
>
if ((fc = open(filename)) < 0)
errx("file error %d\n", errno);
>
How hard is it to sit there and do this instead?
>
fc = open(filename);
if (fc < 0) errx("file error %d\n", errno);
>
It's just so much easier to read, less error prone (since there
are fewer nested () ), and it probably generates the exact same
code at the machine level.

While I am annoyed by (not to mention the non-existent open):

fc = fopen(filename, etc);
if (!fc) erroraction();
dowhatever(fc);

when

if (!(fc = fopen(filename, etc)))
erroraction(fil ename);
else (
/* all is well */
dowhatever(fc);
}

will show me precisely what is required to get to dowhatever, or to
erroraction. I also know that I will not fall into dowhatever when
erroraction (somewhere else) returns. I also trivially know that
dowhatever has a valid opened fc value passed to it.

Note that the preferred method above can be wrapped in:

do {
filename = getfcspecificat ion();
if (!(fc = fopen(filename, etc)))
erroraction(fil ename);
else (
/* all is well */
dowhatever(fc);
}
} while (!fc);
fclose(fc); /* knowing that fc is non-NULL */

It is clearer because the thing that is being tested is the success
of fopen, not the value of fc (which is incidental). It also leads
to single entry / single exit modules, and conserves vertical
space, all of which enhances code readability.

Think it over.

--
<http://www.cs.auckland .ac.nz/~pgut001/pubs/vista_cost.txt>
<http://www.securityfoc us.com/columnists/423>

"A man who is right every time is not likely to do very much."
-- Francis Crick, co-discover of DNA
"There is nothing more amazing than stupidity in action."
-- Thomas Matthews

[Daniel Rudy]

Re: format for declaring variables?

At about the time of 2/9/2007 3:09 AM, Keith Thompson stated the following:

Daniel Rudy <spamthis@spamt his.netwrites:

>At about the time of 2/9/2007 1:43 AM, Jens Thoms Toerring stated the
>following:

[...]

>>And, actually,
>>the way you write it isn't correct, if I remember correctly it would
>>have to be
>>>

>
Um, you snipped what Jens said it would have to be. Oh, well.
>

It was snipped because my example was in error. That's what I get for
copying something from memory. :)

>That's interesting, because on programs that don't take arguments, I
>always do int main(void).

>
Yes, that's valid.
>
There are two permitted forms for main:
>
int main(int argc, char *argv[]) { /* ... */ }
>
int main(void) { /* ... */ }
>
(or equivalent).
>
This:
>
int main(argc, argv)
int argc;
char *argv;
{
/* ... */
}
>
is an old-style declaration; it's still legal, but it shouldn't be
used in new code.
>

Which begs the question as to why they did it that way.

>>int main(i,p)
>> int i;
>> char *p;
>>>

>
That's equivalent to the above old-style declarations (the parameters
don't have to be named "argc" and "argv", but they are by convention,
and there's no good reason to use different names) -- except that
"char *p;" should be "char **p;" or "char *p[];".
>
[...]
>

I've never used anything but this for programs that take command line
arguments:

int main(int argc, char **argv)

But you say that you can also do this?

int main(int argc, char *argv[])

Hmmm.... It seems that second form might be better suited for argument
processing then that first one. I've always had problems properly
interpreting what ** meant, although I know it's a pointer to a pointer.



--
Daniel Rudy

Email address has been base64 encoded to reduce spam
Decode email address using b64decode or uudecode -m

Why geeks like computers: look chat date touch grep make unzip
strip view finger mount fcsk more fcsk yes spray umount sleep