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.goo glegroups.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****@netacti ve.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(reg ister 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 wellBehavedFunc tion(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****@netacti ve.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(reg ister 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 wellBehavedFunc tion(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****@netacti ve.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
parameter s 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(reg ister 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 wellBehavedFunc tion(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 wellBehavedFunc tion(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.