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]

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]

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]

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]

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]

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]

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]

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]

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]

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

 

[Clark S. Cox III]

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?

 

[Ben Pfaff]

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

No. The keyword is not useful.

 

[Keith Thompson]

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.

 

[Michael Wojcik]

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.

 

[Keith Thompson]

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.

 

[Ben Pfaff]

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).

 

[Keith Thompson]

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.

 

[Ben Pfaff]

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.

 

[Keith Thompson]

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

Right, I was expanding on your citation.

 

[Chris Dollin]

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.