Why not auto?

[Vijay Kumar R. Zanvar]

Hello,

Unlike register, auto keyword can not be used to
declare formal parameter(s). Is there any specific
reason for this?

Kind regards,
Vijay Kumar R. Zanvar

[Richard Bos]

"Vijay Kumar R. Zanvar" <vi*****@gmail.com> wrote:

Unlike register, auto keyword can not be used to
declare formal parameter(s). Is there any specific
reason for this?

No storage class specifier except register can be used for function
parameters declarations. Not auto, but not static, extern or typedef
either. The reason, I suppose, is that declaring a function parameter to
be extern or auto makes even less sense than declaring it register.
Consider: whatever would it mean, a static function parameter?

Richard

[Vijay Kumar R. Zanvar]

Richard Bos wrote:

"Vijay Kumar R. Zanvar" <vi*****@gmail.com> wrote:

Unlike register, auto keyword can not be used to
declare formal parameter(s). Is there any specific
reason for this?
No storage class specifier except register can be used for function
parameters declarations. Not auto, but not static, extern or typedef
either. The reason, I suppose, is that declaring a function parameter

to be extern or auto makes even less sense than declaring it register.
Consider: whatever would it mean, a static function parameter?

Richard

But in one context, static is allowed to be used in function
parameters.

Vijay

[Mike Wahler]

"Vijay Kumar R. Zanvar" <vi*****@gmail.com> wrote in message
news:11**********************@o13g2000cwo.googlegr oups.com...

Hello,

Unlike register, auto keyword can not be used to
declare formal parameter(s). Is there any specific
reason for this?

Function parameters are already effectively 'auto'
(they go away when the function exits). What property
do you feel an 'auto' qualification would give a function
parameter?

-Mike

[Richard Bos]

"Vijay Kumar R. Zanvar" <vi*****@gmail.com> wrote:

Richard Bos wrote:

"Vijay Kumar R. Zanvar" <vi*****@gmail.com> wrote:

Unlike register, auto keyword can not be used to
declare formal parameter(s). Is there any specific
reason for this?

No storage class specifier except register can be used for function
parameters declarations. Not auto, but not static, extern or typedef
either.

But in one context, static is allowed to be used in function
parameters.

Inside the size of an array declaration, yes. Not for the parameter
itself, and not as a storage class specifier.

The keyword "static" is the factotum of the C Standard, made to serve
whenever a small job is found that high-quality keywords such as
"register" and "for" consider beneath them. Most of these jobs have
nothing much to do with one another, and from static's presence in one
place you cannot derive any information about other uses of this jack-
of-all-trades. It has been said, quite possibly in comp.lang.c, that "it
[i.e., C99] wouldn't be a proper C Standard if it didn't find a new use
for 'static'".

Richard

[Chris Croughton]

On Mon, 09 May 2005 13:29:27 GMT, Richard Bos
<rl*@hoekstra-uitgeverij.nl> wrote:

No storage class specifier except register can be used for function
parameters declarations. Not auto, but not static, extern or typedef
either. The reason, I suppose, is that declaring a function parameter to
be extern or auto makes even less sense than declaring it register.
Consider: whatever would it mean, a static function parameter?

Treat it as a suggestion (like register) that the value should be held
in 'static' memory rather than stack, for optimisation? For instance,
on a system where stack space is limited declaring all local variables
including parameters as static (knowing that the function wouldn't be
reentrant) might be useful.

Chris C

[Lawrence Kirby]

On Mon, 09 May 2005 20:04:38 +0100, Chris Croughton wrote:

On Mon, 09 May 2005 13:29:27 GMT, Richard Bos
<rl*@hoekstra-uitgeverij.nl> wrote:

No storage class specifier except register can be used for function
parameters declarations. Not auto, but not static, extern or typedef
either. The reason, I suppose, is that declaring a function parameter to
be extern or auto makes even less sense than declaring it register.
Consider: whatever would it mean, a static function parameter?

Treat it as a suggestion (like register) that the value should be held
in 'static' memory rather than stack, for optimisation? For instance,
on a system where stack space is limited declaring all local variables
including parameters as static (knowing that the function wouldn't be
reentrant) might be useful.

This really boils down to a promise that the function won't be called
recursively, or concurrently from a signal handler. This would make more
sense as a attribute for the function as a whole rather than for
particular parameters.

Lawrence

[Chris Croughton]

On Tue, 10 May 2005 14:04:05 +0100, Lawrence Kirby
<lk****@netactive.co.uk> wrote:

On Mon, 09 May 2005 20:04:38 +0100, Chris Croughton wrote:

On Mon, 09 May 2005 13:29:27 GMT, Richard Bos
<rl*@hoekstra-uitgeverij.nl> wrote:

No storage class specifier except register can be used for function
parameters declarations. Not auto, but not static, extern or typedef
either. The reason, I suppose, is that declaring a function parameter to
be extern or auto makes even less sense than declaring it register.
Consider: whatever would it mean, a static function parameter?

Treat it as a suggestion (like register) that the value should be held
in 'static' memory rather than stack, for optimisation? For instance,
on a system where stack space is limited declaring all local variables
including parameters as static (knowing that the function wouldn't be
reentrant) might be useful.

This really boils down to a promise that the function won't be called
recursively, or concurrently from a signal handler. This would make more
sense as a attribute for the function as a whole rather than for
particular parameters.

It might be needed only for certain parameters (long doubles and large
structs for instance) with others being in registers:

int doSomething(register int action, static struct data);

I agree that a function attribute would also be useful. It can't be yet
another use of static, though, how about restrict? That has a similar
meaning (promise the compiler that you aren't going to do something
'clever' and non-optimisable):

restrict int wellBehavedFunction(int x, double y);

(Some compilers used for embedded systems have had their own extensions
to do similar things...)

Chris C

[Lawrence Kirby]

On Tue, 10 May 2005 14:59:22 +0100, Chris Croughton wrote:

On Tue, 10 May 2005 14:04:05 +0100, Lawrence Kirby
<lk****@netactive.co.uk> wrote:

On Mon, 09 May 2005 20:04:38 +0100, Chris Croughton wrote:

On Mon, 09 May 2005 13:29:27 GMT, Richard Bos
<rl*@hoekstra-uitgeverij.nl> wrote:

No storage class specifier except register can be used for function
parameters declarations. Not auto, but not static, extern or typedef
either. The reason, I suppose, is that declaring a function parameter to
be extern or auto makes even less sense than declaring it register.
Consider: whatever would it mean, a static function parameter?

Treat it as a suggestion (like register) that the value should be held
in 'static' memory rather than stack, for optimisation? For instance,
on a system where stack space is limited declaring all local variables
including parameters as static (knowing that the function wouldn't be
reentrant) might be useful.
This really boils down to a promise that the function won't be called
recursively, or concurrently from a signal handler. This would make more
sense as a attribute for the function as a whole rather than for
particular parameters.

It might be needed only for certain parameters (long doubles and large
structs for instance) with others being in registers:

int doSomething(register int action, static struct data);

The compiler is in a perfect position to know which parameters would
benefit from it. It doesn't need input from the programmer to determine
this, except to tell it that such optimisations are valid for the function
at all. It might be able to determine that for itself but in general it is
tricky. The compiler could also apply such optimisations to automatic
variables in the function body. Of course "stack" based allocation may be
more efficient on some implementations anyway, at the very least it is
likely to promote memory reuse and improved caching.
I agree that a function attribute would also be useful. It can't be yet
another use of static, though, how about restrict? That has a similar
meaning (promise the compiler that you aren't going to do something
'clever' and non-optimisable):

restrict int wellBehavedFunction(int x, double y);
Yes, that could work.
(Some compilers used for embedded systems have had their own extensions
to do similar things...)

Yes it can make a lot of sense for the smaller processors out there.

Lawrence

[Michael Mair]

Chris Croughton wrote:

On Tue, 10 May 2005 14:04:05 +0100, Lawrence Kirby
<lk****@netactive.co.uk> wrote:

On Mon, 09 May 2005 20:04:38 +0100, Chris Croughton wrote:

On Mon, 09 May 2005 13:29:27 GMT, Richard Bos
<rl*@hoekstra-uitgeverij.nl> wrote:

No storage class specifier except register can be used for function
parameters declarations. Not auto, but not static, extern or typedef
either. The reason, I suppose, is that declaring a function parameter to
be extern or auto makes even less sense than declaring it register.
Consider: whatever would it mean, a static function parameter?

Treat it as a suggestion (like register) that the value should be held
in 'static' memory rather than stack, for optimisation? For instance,
on a system where stack space is limited declaring all local variables
including parameters as static (knowing that the function wouldn't be
reentrant) might be useful.
This really boils down to a promise that the function won't be called
recursively, or concurrently from a signal handler. This would make more
sense as a attribute for the function as a whole rather than for
particular parameters.

It might be needed only for certain parameters (long doubles and large
structs for instance) with others being in registers:

int doSomething(register int action, static struct data);

I agree that a function attribute would also be useful. It can't be yet
another use of static, though, how about restrict?

*g* We have still places where we can put static:

int wellBehavedFunction(int x, double y) static;
SCNR
Michael
That has a similar
meaning (promise the compiler that you aren't going to do something
'clever' and non-optimisable):

restrict int wellBehavedFunction(int x, double y);

(Some compilers used for embedded systems have had their own extensions
to do similar things...)

--
E-Mail: Mine is an /at/ gmx /dot/ de address.

[Clark S. Cox III]

On 2005-05-09 10:02:48 -0400, "Mike Wahler" <mk******@mkwahler.net> said:

"Vijay Kumar R. Zanvar" <vi*****@gmail.com> wrote in message
news:11**********************@o13g2000cwo.googlegr oups.com...

Hello,

Unlike register, auto keyword can not be used to
declare formal parameter(s). Is there any specific
reason for this?

Function parameters are already effectively 'auto'
(they go away when the function exits). What property
do you feel an 'auto' qualification would give a function
parameter?

Is there *any* situation where 'auto' is legal, but not default?
--
Clark S. Cox, III
cl*******@gmail.com

[Ben Pfaff]

Clark S. Cox III <cl*******@gmail.com> writes:

Is there *any* situation where 'auto' is legal, but not default?

No. The keyword is not useful.
--
"Welcome to the wonderful world of undefined behavior, where the demons
are nasal and the DeathStation users are nervous." --Daniel Fox

[Keith Thompson]

Ben Pfaff <bl*@cs.stanford.edu> writes:

Clark S. Cox III <cl*******@gmail.com> writes:

Is there *any* situation where 'auto' is legal, but not default?

No. The keyword is not useful.

Which raises the question of why it's in the language in the first
place. The reasons, I think, are historical. In early C, and in its
ancestor languages, a variable could be declared with no explicit
type; the type then defaulted to int. A declaration like
static x;
would declare x as a static object of type int. A declaration like
y;
would be either ambiguous (it could be an expression statement
referring to a previously declared variable y or a declaration of an
int variable y) or illegal; I'm not sure what the rules were at the
time. To avoid the ambiguity, you could declare
auto y;

Since implicit int on variable declarations has been obsolete for
decades, this is no longer an issue.

--
Keith Thompson (The_Other_Keith) ks***@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.

[Michael Wojcik]

In article <87************@benpfaff.org>, Ben Pfaff <bl*@cs.stanford.edu> writes:

Clark S. Cox III <cl*******@gmail.com> writes:

Is there *any* situation where 'auto' is legal, but not default?

No. The keyword is not useful.

And it's high time the committee did something about that, too. Quick,
someone invent a new use for "auto".

Actually, Keith mentioned implicit int, which is still allowed in C89.
Isn't the following a conforming C89 program where the presence of the
auto keyword has an effect?

#include <stdio.h>
int main(void)
{
int i;

i = 1;
{
/* Because auto makes this an implicit-int declaration, this is
a no-op. */
auto i = 0;
}

printf("auto did%s have an effect\n", i? "" : " not");
return EXIT_SUCCESS;
}

Without the "auto", "i = 0" would have changed the value of i rather
than declaring a new variable in the inner scope. However, I realize
that's not exactly a case of auto being "legal, but not default" -
it's just auto being used as shorthand for "auto int", in which the
"auto" is still redundant. Whether this makes "auto" "useful" is a
matter of definition (it does something, but not anything that
wouldn't be achieved with "int"). Certainly it's not very useful;
it's just a contrived case where removing all instances of the auto
keyword from the source would change the program's semantics.

--
Michael Wojcik mi************@microfocus.com

Cooperation is just like two pagodas, one hardware and one software.
-- Wen Jiabao

[Keith Thompson]

mw*****@newsguy.com (Michael Wojcik) writes:

In article <87************@benpfaff.org>, Ben Pfaff
<bl*@cs.stanford.edu> writes:

Clark S. Cox III <cl*******@gmail.com> writes:

> Is there *any* situation where 'auto' is legal, but not default?

No. The keyword is not useful.

And it's high time the committee did something about that, too. Quick,
someone invent a new use for "auto".

Actually, Keith mentioned implicit int, which is still allowed in C89.
Isn't the following a conforming C89 program where the presence of the
auto keyword has an effect?

#include <stdio.h>
int main(void)
{
int i;

i = 1;
{
/* Because auto makes this an implicit-int declaration, this is
a no-op. */
auto i = 0;
}

printf("auto did%s have an effect\n", i? "" : " not");
return EXIT_SUCCESS;
}

Apart from EXIT_SUCCESS being undeclared (it's in <stdlib.h>, not
<stdio.h>), I'm not sure. I had thought that C89/C90 allows implicit
int only for functions, not for objects, but I might be mistaken. (I
just took a quick look through the C90 standard and didn't find
anything definitive.)

I'm sure someone here can provide the appropriate chapter and verse.

--
Keith Thompson (The_Other_Keith) ks***@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.

[Ben Pfaff]

Keith Thompson <ks***@mib.org> writes:

Apart from EXIT_SUCCESS being undeclared (it's in <stdlib.h>, not
<stdio.h>), I'm not sure. I had thought that C89/C90 allows implicit
int only for functions, not for objects, but I might be mistaken. (I
just took a quick look through the C90 standard and didn't find
anything definitive.)

I'm sure someone here can provide the appropriate chapter and verse.

It's hard to provide exact C&V that prohibits something that's
not prohibited. My C standard notes say the following:

In C90, a declaration without a type specifier had `int'
supplied by default, called "implicit `int'" (C89 6.5.2#3).
C99 disallows this practice, requiring that a type specifier
be explicitly supplied (C99 6.7.2#2).
--
"Given that computing power increases exponentially with time,
algorithms with exponential or better O-notations
are actually linear with a large constant."
--Mike Lee

[Keith Thompson]

Ben Pfaff <bl*@cs.stanford.edu> writes:

Keith Thompson <ks***@mib.org> writes:

Apart from EXIT_SUCCESS being undeclared (it's in <stdlib.h>, not
<stdio.h>), I'm not sure. I had thought that C89/C90 allows implicit
int only for functions, not for objects, but I might be mistaken. (I
just took a quick look through the C90 standard and didn't find
anything definitive.)

I'm sure someone here can provide the appropriate chapter and verse.

It's hard to provide exact C&V that prohibits something that's
not prohibited. My C standard notes say the following:

In C90, a declaration without a type specifier had `int'
supplied by default, called "implicit `int'" (C89 6.5.2#3).
C99 disallows this practice, requiring that a type specifier
be explicitly supplied (C99 6.7.2#2).

It's not just not prohibited; there's an explicit rule that says that
a declaration with no type specifier is implicitly of type int. I
missed it because it's fairly well hidden in C90 6.5.2:

Constraints

Each list of type specifiers shall be one of the following sets
(delimited by commas, when there is more than one set on a line);
the type specifiers may occur in any order, possibly intermixed
with the other declaration specifiers.

-- void
-- char
[snip]
-- int, signed, signed int, or no type specifiers
[snip]

Semantics

[snip]

Each of the above comma-separated sets designates the same type,
except that for bit-fields, the type signed int (or signed) may
differ from int (or no type specifiers).

So it looks like I was correct to think that I might be mistaken.

--
Keith Thompson (The_Other_Keith) ks***@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.

[Ben Pfaff]

Keith Thompson <ks***@mib.org> writes:

Ben Pfaff <bl*@cs.stanford.edu> writes:

It's hard to provide exact C&V that prohibits something that's
not prohibited. My C standard notes say the following:

In C90, a declaration without a type specifier had `int'
supplied by default, called "implicit `int'" (C89 6.5.2#3).
C99 disallows this practice, requiring that a type specifier
be explicitly supplied (C99 6.7.2#2).

It's not just not prohibited; there's an explicit rule that says that
a declaration with no type specifier is implicitly of type int. I
missed it because it's fairly well hidden in C90 6.5.2:

Indeed. That's why I, above, cited the paragraph containing this
very list.
--
"The lusers I know are so clueless, that if they were dipped in clue
musk and dropped in the middle of pack of horny clues, on clue prom
night during clue happy hour, they still couldn't get a clue."
--Michael Girdwood, in the monastery

[Keith Thompson]

Ben Pfaff <bl*@cs.stanford.edu> writes:

Keith Thompson <ks***@mib.org> writes:

Ben Pfaff <bl*@cs.stanford.edu> writes:

It's hard to provide exact C&V that prohibits something that's
not prohibited. My C standard notes say the following:

In C90, a declaration without a type specifier had `int'
supplied by default, called "implicit `int'" (C89 6.5.2#3).
C99 disallows this practice, requiring that a type specifier
be explicitly supplied (C99 6.7.2#2).

It's not just not prohibited; there's an explicit rule that says that
a declaration with no type specifier is implicitly of type int. I
missed it because it's fairly well hidden in C90 6.5.2:

Indeed. That's why I, above, cited the paragraph containing this
very list.

Right, I was expanding on your citation.

--
Keith Thompson (The_Other_Keith) ks***@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.

[Chris Dollin]

Michael Wojcik wrote:

In article <87************@benpfaff.org>, Ben Pfaff <bl*@cs.stanford.edu>
writes:

Clark S. Cox III <cl*******@gmail.com> writes:

> Is there *any* situation where 'auto' is legal, but not default?

No. The keyword is not useful.

And it's high time the committee did something about that, too. Quick,
someone invent a new use for "auto".

Using `auto` on a declaration outside a function allows its initialising
expression to be non-static; the value is computed no later than the
first dynamic reference to the variable, and no sooner than all other
variables referenced in that expression.

Delightfully, this allows you to have `auto static` (or, of course,
`static auto`) variables.

An obvious extension is to allow `auto static` inside a function. Naturally
the initialisation expression can here refer to in-scope auto variables.

--
Chris "bad ideas at the drop of a hat" Dollin
"The compiler is free to insert padding because it makes the struct
look bigger and scares away predators." [Keith Thompson, comp.lang.c]

[Dave Thompson]

On 16 May 2005 23:33:16 GMT, mw*****@newsguy.com (Michael Wojcik)
wrote:
<snip>

And it's high time the committee did something about that, too. Quick,
someone invent a new use for "auto".

There was a half-serious proposal maybe a year ago or so for 'auto' to
declare a variable with the same type as an expression without having
to (be able to) state that type, for things like the GNUC classic
#define SWAP(x,y) { typeof(x) _temp = x; x = y; y = _temp; }
/* or probably better the do...while(0) hack or the GNUC ({ }) hack */
which would now be something like { auto _temp = x; etc. }

C++ templates can already do this in (all?) useful cases.

- David.Thompson1 at worldnet.att.net