According to the ISO/IEC 9899:1999 6.7.5 §2,
Each declarator declares one identifier, and asserts that when an operand of the same
form as the declarator appears in an expression, it designates a function or object with the
scope, storage duration, and type indicated by the declaration specifiers.
I have no idea why an expression suddenly shows up in the declarators semantics. Would you give me some examples that can help me understand the meaning?
Say you have the declaration
int foo[42];
The declarator part is foo[42]. Whenever something of same form (ie foo followed by [ followed by an expression followed by ]) appears within an expression (and the delaration is in scope), the type of that sub-expression will be of the declared type int.
To put it another way: As far as syntax goes, a declaration like
int *bar;
does not declare bar to be of type int *, but instead declares *foo to be of type int.
For a more involved example, take the declaration
float (*op[42])(float, float);
In an expression, an operand of same form could look like this
c = (*op[i])(a, b);
According to the quotation, the right-hand side would have type float.
This implies that
*op[i]
must have function type (we ignore the fact that function designators decay to corresponding pointer types and function invocation via postfix () actually works on pointers, not designators).
This in turn implies that
op[i]
must denote a function pointer and we finally arrive at
op
denoting an array of function pointers as that's what we can apply postfix [] on and get back the correct type.
Fun, isn't it ;)
Say you declare:
static int const i, j, k;
That is same as:
static int const i;
static int const j;
static int const k;
The declarator specifer, static int const is applied to all the identifiers.
You can also extend that logic to functions and function pointers.
static int i, (*fun1)(void), fun2(void);
which is same as:
static int i;
static int (*fun1)(void);
static int fun2(void);
As far as the appears in an expression part goes, there is some commentary at http://c0x.coding-guidelines.com/6.7.5.pdf. It says:
Semantics
Each declarator declares one identifier, and asserts that when an operand of the same form as the declarator appears in an expression, it designates a function or object with the scope, storage duration, and type indicated by the declaration specifiers.
Commentary
The form of an identifier in an expression is likely to be the same as that in the declarator. For instance, the declarator * x will have this form in an expression when the value pointed to by x is required and the declarator y[2] will have this form in an expression when an element of the array y is referred to. It is the declarator portion of a declaration that declares the identifier. There is a special kind of declarator, an abstract-declarator, which does not declare an identifier
I interpret the above to mean:
If you declare:
int *x;
and use *x in an expression, the type of *x is int.
If you declare
static int const *x;
and use *x in an expression, the type of *x is static int const.
Additional references
Static Variable Declaration (C)
Is [ ] also a declarator (when used in parameter declaration) in C?
C -- Accessing a non-const through const declaration
All that's saying is, given a declaration like
const int a = 5; // declaration
then the operand a in an expression like
x = a + b
within the same scope has type const int.
Related
In C, a void pointer is declared, usually, like this:
int a = 10;
char b = 'x';
void *p = &a; // void pointer holds address of int 'a'
p = &b; // void pointer holds address of char 'b'
However, the syntax of malloc in C is like this:
ptr = (cast-type*) malloc(byte-size)
What I can't understand is why the "*" symbol in the "cast-type" section of the code above is on the right. I would assume the correct way of writing the same line of code would be like this:
ptr = (*cast-type) malloc(byte-size)
That's because when declaring a pointer the "*" is on the left, not on the right.
What's the problem with my reasoning?
That's because when declaring a pointer the "*" is on the left, not on the right.
The * is on the right of the type name. In void *p = &a; type is void *, a void pointer. It is on the left of the thing it's being applied to, the variable p.
In ptr = (cast-type*) malloc(byte-size) the type is cast-type *, the * is to the right of the type name. The cast is on the left of the thing being cast, the call to malloc, like an adjective.
[I do find it odd that we write type *variable, which makes it seem like the * is part of the variable rather than type* variable which puts the * with the type.]
The * indirection operator is a unary operator, meaning its operand is to the right of the operator, as in *p.
C declarations are broken into two major sections - a sequence of declaration specifiers (type specifiers, storage class specifiers, type qualifiers, etc.) followed by a comma-separated list of declarators. A declarator introduces the name of the thing being declared, along with information about that thing’s array-ness, pointer-ness, and function-ness. In the declaration statement
int a[10], *p, f(void);
the declaration specifier is int and the declarators are a[10], *p, and f(void). Note that the * is bound to the declarator, not the type specifier. Because it’s a unary operator and token on its own, you don’t need whitespace to separate the type specifier from the identifier - all of
int *p;
int* p;
int*p;
int * p;
are equally valid, and all are interpreted as int (*p); - the operand of * is always p, not int or any other type specifier1.
The type of a is "10-element array of int", which is fully specified by the combination of the int type specifier and by the [10] in the declarator. Similarly the type of p is "pointer to int", which again is fully specified by the combination of the type specifier and the * operator in the declarator. And the type of f is "function returning int" by the same reasoning.
This is key - there is no type specifier for pointer, array, or function types - they can only be specified by a combination of one or more declaration specifiers and a declarator.
So how do we specify pointer types (or array or function types) in a cast? Basically, we write a declaration composed of declaration specifiers and a declarator, but with no identifier. If we want to cast something as a pointer to int, we write it as a regular pointer declaration with an unnamed variable - (int *).
This is why I’m not fond of the C++ convention of writing pointer declarations as T* p;; it doesn’t follow the syntax, and it’s inconsistent - a declaration like int* a[N]; is schizophrenic. It also introduces confusion when you write something like T* p, q; because it looks like you intend to declare both p and q as pointers, but only p is.
I am reading about declarators in C99 ISO Standard and I am struggling to understand the following passage:
5 If, in the declaration ”T D1”, D1 has the form
identifier
then the type specified for ident is T.
6 If, in the declaration “T D1”, D1 has the form
( D )
then ident has the type specified by the declaration “T D”. Thus, a declarator in parentheses is identical to the unparenthesized declarator, but the binding of complicated declarators may be altered by parentheses.
You omitted an important previous paragraph:
4 In the following subclauses, consider a declaration
T D1
where T contains the declaration specifiers that specify a type T (such as int) and D1 is a declarator that contains an identifier ident. The type specified for the identifier ident in the various forms of declarator is described inductively using this notation.
So, when we get to paragraphs 5 and 6, we know the declaration we are considering contains within it some identifier which we label ident. E.g., in int foo(void), ident is foo.
Paragraph 5 says that if the declaration “T D1” is just ”T ident”, it declares ident to be of type T.
Paragraph 6 says that if the declaration “T D1” is just ”T (ident)”, it also declares ident to be of type T.
These are just establishing the base cases for a recursive specification of declaration. Clause 6.7.5.1 goes on to say that if the declaration “T D1” is ”T * some-qualifiers D” and the same declaration without the * and the qualifiers, ”T D” would declare ident to be “some-derived-type T” (like “array of T” or “pointer to T”), then the declaration with the * and the qualifiers declares ident* to be “some-derived-type some-qualifiers pointer to T”.
For example, int x[3] declares x to be “array of 3 int”, so this rule in 6.7.5.1 tells us that “int * const x[3] declares x to be “array of 3 const pointer to int”—it takes the “array of 3” that must have been derived previously and appends “const pointer to” to it.
Similarly, clauses 6.7.5.2 and 6.7.5.3 tell us to append array and function types to declarators with brackets (for subscripts) and postfix parentheses.
In the quoted definitions, T is a type (e.g. int or double or struct foo or any typedef name), and D1 is a declarator.
Declarators may be arbitrarily complex, but are constructed from a small number of simple steps. They mention that it is defined inductively, which is another way of saying it has a recursive defintion.
The simplest declarator is just an identifier name, such as x or foo. So T could be int and D1 could be x.
It then goes on to say that a declarator may be parenthesized, e.g. (x) or ((x)) etc. These are degenerate cases, and are both equivalent to just x, but there are times when parentheses are needed to produce the desired grouping. For example, the declarators *x[10] and (*x)[10] mean quite different things. The former is equivalent to *(x[10]) and is an array of pointers, while the latter is a pointer to an array.
There is more to it (arrays, pointers, functions, etc.), but this covers the portion referenced in the question.
In long int *ident[4]; (array (4) of pointer to long int) long int is the specifier list, *ident[4] is the declarator.
You can put the declarator in parentheses without changing semantics:
long int (*ident[4]);, but in a more complex declaration such as
long int (*ident[4])[5]; (array (4) of pointer to array (5) of long int), the parentheses affect binding as without them, long int *ident[4][5]; would be interpreted as array (4) of array (5) of pointer to long int.
It works this way because the declarator part can recursively encompass another declarator and so on.
From the old C manual (it got a bit more indirect in later standardized Cs, but the basic principle is the same):
declarator:
identifier
* declarator
declarator ( )
declarator [ constant-expression opt ]
( declarator )
To put it in another way, C declarators are a way to prefix pointer-to/function-returning/array-of to some specifier list (e.g., long int) and these can be combined to create a chain.
Normally, in the creation of that chain, the suffixes (()=function returning, []=array of) bind tighter than the */pointer-to prefix. You can use parentheses to override this and force * (or several of them) to bind now without it getting overpowered by a []/() suffix.
E.g.:
long int *ident[4][5]; //array (4) of array (5) of pointer to long int
//the suffixes win over the `*` prefix
long int (*ident[4])[5]; //array (4) of pointer to array (5) of long int
//the parens force `pointer to` right after `array (4)`
//without letting the `[]` suffix overpower the pointer-to/`*` declarator prefix
P.S.:
C disallows arrays of functions and functions returning functions or arrays. These are both nicely expressible in the grammar but C's semantic check will want you to but a pointer-to link in there to prevent these.
cdecl.org may be very helpful if you want to play with these, and perhaps even more so because it doesn't do said semantic check, therefore allowing you even things like int foo[]()(); (array of function returning function returning int), which nicely demonstrate how the grammar works, even though a C compiler would reject them.
...binding of complicated declarators
This is a very nice hint in the specs.
The rule itself is really hard to analyze because of it's recursiveness. Also the relation and parts of declaration and declarator are relevant.
The results are:
() and [] are the innermost direct-declarator parts, declaring (directly by symbol) functions and array names to the left
* declares a name as pointer on the right
(...) is needed for...complicated cases, to change the default association.
The grouping parens lead you on your way from inside (identifier) to outside (type specifier on the left, say "int").
In the end it is all about the pointer symbol * and what it refers to. The reformulated (brackets mean optional, not array here!) syntax is:
declarator: [* [qual]] direct-declarator
direct-declarator: (declarator)
foo() is a DD (direct declarator)
*foo is a declarator. ("indirect" by deduction)
*foo() is *(foo()). foo stays a function, () and [] bind strongest. The * is the return type.
(*foo)() makes foo a pointer. One to a function.
BTW this also explains why in a list of declarator.
int const * a, b
both are const int, but only a is a pointer
The const belongs to int and the star only to a. This makes it more clear,
const int x, *pi
But this already is borderline obfuscation. Like modern poetry. Good for certain occasions.
Even without parens there is a slight U-turn in parsing. But this is natural:
3 2 0 1
int *foo()
This standard situation (and similar ones) had to be simple. Also the famous multidim arrays like int a[10][10][10].
3 1 0 2
int (*foo)()
Here the parens force "foo" to be what is on the left side (a pointer).
Complicated Declarations have their own chapter in K&R C book.
This is sort of the simplest complicated declaration:
int (*(*foo)[])()
It debugs to abstract type:
int (*(*)[])()
With (*) replaced:
int (*F[])()
The missing array size gives compiler warning - "assuming one element".
As abstract type:
int (*[])()
But:
int *G[]()
--> error: declaration of 'G' as array of functions
Yes, you can, even recursively, but with the * indirection and parens. This makes an onion of parens with the identifeir in the middle, stars on the left and [] and () on the right.
The C11 specs has this monster. The ... declare variadic args:
int (*fpfi(int (*)(long), int))(int, ...)
With all params removed:
int (*fpfi())()
Simply a function returning a pointer. One to a function returning int.
But the first param of fpfi is a function itself - a pointer to function with return type and its own params:
int (*)(long)
Non-abstractly:
int (*foo)(long)
A pointer to a function that "converts" a long to int, formally.
That is the param. Only. The return value is also a function pointer, and the pointed-to function's params and return type are outermost. Dropping the whole inner function thing (int (*)(long), int):
int (*pfi)(int, ...)
Or more generic/incomplete:
int (*pfi)()
"T (D)" Onion Rule
So this onion-game repeats itself. Inside-out and right-left-right-left between [], () and *. Syntax is not the problem, but semantics.
The void type in C seems to be strange from various different situations. Sometimes it behaves like a normal object type, such as int or char, and sometimes it just means nothing (as it should).
Look at my snippet. First of all, it seems strange that you can declare a void object, meaning you just declare nothing.
Then I created an int variable and casted its result to void, discarding it:
If an expression of any other type is evaluated as a void
expression, its value or designator is discarded. (ISO/IEC 9899:201x, 6.3.2.2 void)
I tried to call my function with a void cast, but my compiler gave me (Clang 10.0):
error: too many arguments to function call, expected 0, have 1
So the void in a prototype means nothing, and not the type void.
But then, I created a pointer to void, dereferenced it, and assigning the “result” to my int variable. I got the “incompatible type” error. That means the void type does exist here.
extern void a; // Why is this authorised ???
void foo(void); // This function takes no argument. Not the 'void' type.
int main(void)
{
int a = 42;
void *p;
// Expression result casted to 'void' which discards it (per the C standard).
(void)a;
// Casting to 'void' should make the argument inexistant too...
foo((void)a);
// Assigning to 'int' from incompatible type 'void': so the 'void' type does exists...
a = *p;
// Am I not passing the 'void' type ?
foo(*p);
return 0;
}
Is void an actual type, or a keyword to means nothing ? Because sometimes it behaves like the instruction “nothing is allowed here”, and sometimes like an actual type.
EDIT: This questions is NOT a duplicate. It is a purely about the semantics of the void type. I do not want any explanation about how to use void, pointers to void or any other things. I want an answer per the C standard.
In C language the void type has been introduced with the meaning of 'don't care' more than 'null' or 'nothing', and it's used for different scopes.
The void keyword can reference a void type, a reference to void, a void expression, a void operand or a void function. It also explicitly defines a function having no parameters.
Let's have a look at some of them.
The void type
First of all void object exists and have some special properties, as stated in ISO/IEC 9899:2017, §6.2.5 Types:
The void type comprises an empty set of values; it is an incomplete object type that cannot be completed.
Pointers
The more useful reference to void, or void *, is a reference to an incomplete type, but itself is well defined, and then is a complete type, have a size, and can be used as any other standard variable as stated in ISO/IEC 9899:2017, §6.2.5 Types:
A pointer to void shall have the same representation and alignment requirements as a pointer to a character type.
Similarly, pointers to qualified or unqualified versions of compatible types shall have the same representation and alignment requirements.
All pointers to structure types shall have the same representation and alignment requirements as each other.
All pointers to union types shall have the same representation and alignment requirements as each other.
Pointers to other types need not have the same representation or alignment requirements.
Casting to void
It can be used as cast to nullify an expression, but allowing the completion of any side effect of such expression. This concept is explained in the standard at ISO/IEC 9899:2017, §6.3 Conversions, §6.3.2.2 void:
The (nonexistent) value of a void expression (an expression that has type void) shall not be used in any way, and implicit or explicit conversions (except to void) shall not be applied to such an expression.
If an expression of any other type is evaluated as a void expression, its value or designator is discarded. (A void expression is evaluated for its side effects.)
A practical example for the casting to void is its use to prevent warning for unused parameters in function definition:
int fn(int a, int b)
{
(void)b; //This will flag the parameter b as used
... //Your code is here
return 0;
}
The snippet above shows the standard practice used to mute compiler warnings. The cast to void of parameter b acts as an effective expression that don't generate code and marks b as used preventing compiler complains.
void Functions
The paragraph §6.3.2.2 void of the standard, covers also some explanation about void functions, that are such functions that don't return any value usable in an expression, but functions are called anyway to implement side effects.
void pointers properties
As we said before, pointers to void are much more useful because they allow to handle objects references in a generic way due to their property explained in ISO/IEC 9899:2017, §6.3.2.3 Pointers:
A pointer to void may be converted to or from a pointer to any object type.
A pointer to any object type may be converted to a pointer to void and back again; the result shall compare equal to the original pointer.
As practical example imagine a function returning a pointer to different objects depending on input parameters:
enum
{
FAMILY, //Software family as integer
VERSION, //Software version as float
NAME //Software release name as char string
} eRelease;
void *GetSoftwareInfo(eRelease par)
{
static const int iFamily = 1;
static const float fVersion = 2.0;
static const *char szName = "Rel2 Toaster";
switch(par)
{
case FAMILY:
return &iFamily;
case VERSION:
return &fVersion;
case NAME:
return szName;
}
return NULL;
}
In this snippet you can return a generic pointer that can be dependent on input par value.
void as functions parameter
The use of void parameter in functions definitions was introduced after the, so called, ANSI-Standard, to effectively disambiguate functions having variable number of arguments from functions having no arguments.
From standard ISO/IEC 9899:2017, 6.7.6.3 Function declarators (including prototypes):
The special case of an unnamed parameter of type void as the only item in the list specifies that the function has no parameters.
Actual compilers still support function declaration with empty parenthesis for backward compatibility, but this is an obsolete feature that will eventually be removed in future release of standard. See Future directions - §6.11.6 Function declarators:
The use of function declarators with empty parentheses (not prototype-format parameter type declarators) is an obsolescent
feature.
Consider the following example:
int foo(); //prototype of variable arguments function (backward compatibility)
int bar(void); //prototype of no arguments function
int a = foo(2); //Allowed
int b = foo(); //Allowed
int c = bar(); //Allowed
int d = bar(1); //Error!
Now resembling your test, if we call the function bar as follows:
int a = 1;
bar((void)a);
Triggers an error, because casting to void an object doesn't null it. So you are still trying to pass a void object as parameter to a function that don't have any.
Side effects
As requested this is a short explain for side effects concept.
A side effect is whichever alteration of objects and values derived from the execution of a statement, and which are not the direct expected effect.
int a = 0;
(void)b = ++a;
In the snippet above the void expression lose the direct effect, assigning b, but as side effect increase the value of a.
The only reference, explaining the meaning, in the standard can be found in 5.1.2.3 Program execution:
Accessing a volatile object, modifying an object, modifying a
file, or calling a function that does any of those operations are all
side effects, which are changes in the state of the execution
environment.
Evaluation of an expression in general includes both value
computations and initiation of side effects.
void is a type. Per C 2018 6.2.5 19, the type has no values (the set of values it can represent is empty), it is incomplete (its size is unknown), and it cannot be completed (its size cannot be known).
Regarding extern void a;, this does not define an object. It declares an identifier. If a were used in an expression (except as part of a sizeof or _Alignof operator), there would have to be a definition for it somewhere in the program. Since there cannot a definition of void object in strictly conforming C, a cannot be used in an expression. So I think this declaration is allowed in strictly conforming C but is not useful. It might be used in C implementations as an extension that allows getting the address of an object whose type is not known. (For example, define an actual object a in one module, then declare it as extern void a; in another module and use &a there to get its address.)
The declaration of functions with (void) as a parameter list is a kludge. Ideally, () might be used to indicate a function takes no parameters, as is the case in C++. However, due to the history of C, () was used to mean an unspecified parameter list, so something else had to be invented to mean no parameters. So (void) was adopted for that. Thus, (void) is an exception to the rules that would say (int) is for a function taking an int, (double) is for a function taking a double, and so on—(void) is a special case meaning that a function takes no parameters, not that it takes a void.
In foo((void) a), the cast does not make the value “not exist.” It converts a to the type void. The result is an expression of type void. That expression “exists,” but it has no value and cannot be used in an expression, so using it in foo((void) a) results in an error message.
From C Standard#6.2.5p19:
19 The void type comprises an empty set of values; it is an incomplete object type that cannot be completed.
This indicate that the void type exists.
Doubt 1:
void foo(void); // This function takes no argument. Not the 'void' type.
Correct.
From C Standard#6.7.6.3p10 [emphasis mine]:
10 The special case of an unnamed parameter of type void as the only item in the list specifies that the function has no parameters.
This is a special case they had to add to the language syntax because void foo(); already meant something different (void foo(); doesn't specify anything about foo's parameters). If it weren't for the old meaning of void foo();, void foo(); would have been the syntax to declare a no-argument function. You can't generalize anything from this. It's just a special case.
Doubt 2:
// Casting to 'void' should make the argument inexistant too...
foo((void)a);
No, it will not because void is also an object type though it is incomplete.
Doubt 3:
// Assigning to 'int' from incompatible type 'void': so the 'void' type does exists...
a = *p;
Yes, it does exist and hence the compiler is reporting error on this statement.
Doubt 4:
// Am I not passing the 'void' type ?
foo(*p);
Declaration of foo() function:
void foo(void);
^^^^
The void in parameter list indicates that function will not take any argument because it has been declared with no parameters.
Just for reference, check this from C Standard#5.1.2.2.1p1 [emphasis mine]:
1 The function called at program startup is named main. The implementation declares no prototype for this function. It shall be defined with a return type of int and with no parameters:
int main(void) { /* ... */ }
^^^^
Doubt 5:
extern void a; // Why is this authorised ???
This is authorized because void is a valid type and it is just a declaration. No storage will allocate to a.
In C, void can't be considered as a data type, it is a keyword used as a placeholder in place of a data type to show that actually there is no data. Hence this
void a;
is not valid.
while here
void foo(void);
void keyword is used to inform to the compiler that foo is not going to take any input argument nor it has return type.
In below case
int a = 42;
void *p;
a = *p; /* this causes error */
a = *p; is wrong because you can't dereference void pointer directly, you need to perform proper type casting first. for e.g
a = *(int*)p; /* first typecast and then do dereference */
Also this
foo(*p);
is wrong because of two reason,
firstly foo() doesn't expects any argument.
secondly you can't do *p as p is void pointer. Correct one is foo(*(int*)p); if foo() declaration is void foo(int);.
Note that this
(void)a;
doesn't do anything so your compiler might not giving any warning but when you do like
int b = (void)a;
compiler won't allow as void is not consider as data type.
Finally this
extern void a; // Why is this authorised ???
this is just a declaration not definition, a doesn't exist until you define it, since a is having extern storage class, you need to define somewhere & when you are going define like
a = 10;
compiler throws a error as
error: ‘a’ has an incomplete type
From C standard 6.2.5 Types
The void type comprises an empty set of values; it is an
incomplete object type that cannot be completed.
6.3.2.2 void
The (nonexistent) value of a void expression (an expression that has
type void) shall not be used in any way, and implicit or explicit
conversions (except to void) shall not be applied to such an
expression. If an expression of any other type is evaluated as a
void expression, its value or designator is discarded. (A void
expression is evaluated for its side effects.)
6.3.2.3 Pointers
A pointer to void may be converted to or from a pointer to any
object type. A pointer to any object type may be converted to a
pointer to void and back again; the result shall compare equal to the
original pointer.
A storage-class specifier or type qualifier modifies the keyword
void as a function parameter type list (6.7.6.3).
An attempt is made to use the value of a void expression, or an
implicit or explicit conversion (except to void) is applied to a
void expression (6.3.2.2).
First of all, it seems strange that you can declare a void object, meaning you just declare nothing.
void is an incomplete object type that cannot be completed. This mostly defines its uses in regular contexts, i.e. contexts that do not provide special treatment for void. Your extern declaration is one of such regular contexts. It is OK to use an incomplete data type in a non-defining declaration.
However, you will never be able to provide a matching definition for that declaration.
So the void in a prototype means nothing, and not the type void.
Correct. The parameter must be unnnamed. And the (void) combination is given special treatment: it is not one parameter of type void, but rather no parameters at all.
But then, I created a pointer to void, dereferenced it, and assigning the “result” to my int variable. I got the “incompatible type” error. That means the void type does exist here.
No. It is illegal to apply unary * operator to a void * pointer. Your code is invalid for that reason already. Your compiler issued a misleading diagnostic message. Formally, diagnostic messages are not required to properly describe the root of the problem. The compiler could've just said "Hi!".
Is void an actual type, or a keyword to means nothing ?
It is a type. It is an incomplete object type that cannot be completed.
With reference to the question Where in a declaration may a storage class specifier be placed? I started analyzing the concept of declaration-specifiers and declarators. Following is the accumulation of my understanding.
Declarations
Generally, the C declarations follow the syntax of declaration-specifiers declarators;
declaration-specifiers comprises of type-specifiers , storage-class-specifiers and type-qualifiers
declarators can be variables,pointers,functions and arrays etc..
Rules that I assume
declaration-specifiers can be specified in any order, as an example
There cannot be more than a single storage-class-specifier
On the other hand there can be multiple type-qualifiers
storage-class-specifier shall not go with the declarator
Questions
Q1: In the declaration of a constant pointer, I see a mix of declarator and type-qualifier as below
const int *const ptr; //Need justification for the mix of declarator and type-specifier
Q2: There can be a pointer to static int. Is there a possibility of providing the pointer a static storage class? Means the pointer being static.
I'm not sure I full understand you first question. In terms of C++03 grammar const is a cv-qualifier. cv-qualifier can be present in decl-specifier-seq (as a specific kind of type-specifier), which is a "common" part of the declaration, as well as in init-declarator-list, which is a comma-separated sequence of individual declarators.
The grammar is specifically formulated that a const specifier belonging to an individual pointer declarator must follow the *. A const specifier that precedes the first * is not considered a part of the individual declarator. This means that in this example
int const *a, *b;
const belongs to the left-hand side: decl-specifier-seq, the "common" part of the declaration. I.e. both a and b are declared as int const *. Meanwhile this
int *a, const *b;
is simply ill-formed and won't compile.
Your second question doesn't look clear to me either. It seems that you got it backwards. You claim that "there can be a pointer to static int"? No, there's no way to declare such thing as "pointer to static int". You can declare a static pointer to int though
static int *p;
In this case the pointer itself is static, as you wanted it to be.
Q2: There can be a pointer to static int. Is there a possibility of providing the pointer a static storage class? Means the pointer being static.
Well, yes:
static T *a;
Declare a a pointer to T. a has static storage duration.
Generally, the C "declarations" is like this declaration-specifiers declarators;
Here, "declaration-specifiers" comprises of type-specifiers , storage-class-specifiers and type-qualifiers .
"declarators" can be variables,pointers,functions and arrays etc..
errors like :- [Error] expected declaration specifiers or '...' before string constant
This type of errors come ,reason for it is problem in declarations.
An array type decays to a pointer type when it is passed to a function
That means in
int func(int x[*p])
*p should not be evaluated as the declaration is equivalent to int func(int *x)
Does the same hold for pointer to arrays?
Here is the code
int *p=0;
void func(int (*ptr)[*p]) //A
{
// code
}
int main()
{
int arr[5][5];
func(arr);
}
Is evaluation of *p at //A guaranteed by the Standard?
I tried with and without optimization on g++4.6. With optimizations enabled I don't get segfault. On clang the code is not giving any segfault even without any optimizations.
From the C99 Standard Section 6.7.5.2 Array declarators, paragraph 1:
In addition to optional type qualifiers and the keyword static, the [
and ] may delimit an expression or *. If they delimit an expression
(which specifies the size of an array), the expression shall have an
integer type. If the expression is a constant expression, it shall
have a value greater than zero. The element type shall not be an
incomplete or function type. The optional type qualifiers and the
keyword static shall appear only in a declaration of a function
parameter with an array type, and then only in the outermost array
type derivation.
The expression *p evaluates to 0 and does not satisfy the requirements of the above paragraph, so the behavior is undefined.