Two different results passing pointer-to-array to a function in C and C++?
up vote
1
down vote
favorite
I have a question regarding to the code snippet appended below. Anyway I ran the snippet on ideone.com and got two different results
C: Succeed.
C++: Error:
prog.cpp: In function ‘int main()’:
prog.cpp:20:13: error: cannot convert ‘int* (*)[2][10]’ to
‘int* (*)[10]’ for argument ‘1’ to ‘void foo(int* (*)[10], size_t)’
foo(&a, LEN);
^
The result in C++ is what I expect, but it runs successfully in C, and it seems like it's compiler dependent because people on the chat helping ran the snippet only got a warning.
So which part I've missed? Is that C automatically did some conversion?
#include <stdio.h>
#include <stddef.h>
#define LEN 2
void foo(int* a[10], size_t len) {
printf("%sn", "successfully called foo.");
}
int main(void) {
// a is an LEN-array of an 10-array of (int *)
int *a[LEN][10] = {{0}};
// but the identifier `a` will decay to be a pointer of type int*[10]
// p1 is a pointer to an 10-array of (int *)
int *(*p1)[10] = 0;
foo(a, LEN);
foo(&a, LEN);
return 0;
}
c++ c
asked Nov 20 at 15:59
ptr_user7813604
523322
|
show 2 more comments
up vote
1
down vote
favorite
I have a question regarding to the code snippet appended below. Anyway I ran the snippet on ideone.com and got two different results
C: Succeed.
C++: Error:
prog.cpp: In function ‘int main()’:
prog.cpp:20:13: error: cannot convert ‘int* (*)[2][10]’ to
‘int* (*)[10]’ for argument ‘1’ to ‘void foo(int* (*)[10], size_t)’
foo(&a, LEN);
^
The result in C++ is what I expect, but it runs successfully in C, and it seems like it's compiler dependent because people on the chat helping ran the snippet only got a warning.
So which part I've missed? Is that C automatically did some conversion?
#include <stdio.h>
#include <stddef.h>
#define LEN 2
void foo(int* a[10], size_t len) {
printf("%sn", "successfully called foo.");
}
int main(void) {
// a is an LEN-array of an 10-array of (int *)
int *a[LEN][10] = {{0}};
// but the identifier `a` will decay to be a pointer of type int*[10]
// p1 is a pointer to an 10-array of (int *)
int *(*p1)[10] = 0;
foo(a, LEN);
foo(&a, LEN);
return 0;
}
c++ c
asked Nov 20 at 15:59
ptr_user7813604
523322
It is not really successful, your compiler should at least give you a warning.
– Osiris
Nov 20 at 16:02
1
Compiling with adequate C flags giveserror: incompatible pointer types passing 'int *(*)[2][10]' to parameter of type 'int *(*)[10]'.
– Quentin
Nov 20 at 16:02
1
ideone.com/iv3MXi gives you the correct error. You should choose C99 instead of C at ideone.
– mch
Nov 20 at 16:03
3
Legacy C is traditionally very lenient when it comes to type conversion. C++ is much more strict about. With adequate level of warnings, C will also warn you.
– SergeyA
Nov 20 at 16:04
3
On a side note, this might be the first time when I see both tags C and C++ correctly used in the single question!
– SergeyA
Nov 20 at 16:05
|
show 2 more comments
up vote
1
down vote
favorite
up vote
1
down vote
favorite
I have a question regarding to the code snippet appended below. Anyway I ran the snippet on ideone.com and got two different results
C: Succeed.
C++: Error:
prog.cpp: In function ‘int main()’:
prog.cpp:20:13: error: cannot convert ‘int* (*)[2][10]’ to
‘int* (*)[10]’ for argument ‘1’ to ‘void foo(int* (*)[10], size_t)’
foo(&a, LEN);
^
The result in C++ is what I expect, but it runs successfully in C, and it seems like it's compiler dependent because people on the chat helping ran the snippet only got a warning.
So which part I've missed? Is that C automatically did some conversion?
#include <stdio.h>
#include <stddef.h>
#define LEN 2
void foo(int* a[10], size_t len) {
printf("%sn", "successfully called foo.");
}
int main(void) {
// a is an LEN-array of an 10-array of (int *)
int *a[LEN][10] = {{0}};
// but the identifier `a` will decay to be a pointer of type int*[10]
// p1 is a pointer to an 10-array of (int *)
int *(*p1)[10] = 0;
foo(a, LEN);
foo(&a, LEN);
return 0;
}
c++ c
asked Nov 20 at 15:59
ptr_user7813604
523322
I have a question regarding to the code snippet appended below. Anyway I ran the snippet on ideone.com and got two different results
C: Succeed.
C++: Error:
prog.cpp: In function ‘int main()’:
prog.cpp:20:13: error: cannot convert ‘int* (*)[2][10]’ to
‘int* (*)[10]’ for argument ‘1’ to ‘void foo(int* (*)[10], size_t)’
foo(&a, LEN);
^
The result in C++ is what I expect, but it runs successfully in C, and it seems like it's compiler dependent because people on the chat helping ran the snippet only got a warning.
So which part I've missed? Is that C automatically did some conversion?
#include <stdio.h>
#include <stddef.h>
#define LEN 2
void foo(int* a[10], size_t len) {
printf("%sn", "successfully called foo.");
}
int main(void) {
// a is an LEN-array of an 10-array of (int *)
int *a[LEN][10] = {{0}};
// but the identifier `a` will decay to be a pointer of type int*[10]
// p1 is a pointer to an 10-array of (int *)
int *(*p1)[10] = 0;
foo(a, LEN);
foo(&a, LEN);
return 0;
}
c++ c
c++ c
asked Nov 20 at 15:59
ptr_user7813604
523322
asked Nov 20 at 15:59
ptr_user7813604
523322
edited Nov 20 at 16:02
asked Nov 20 at 15:59
ptr_user7813604
523322
asked Nov 20 at 15:59
ptr_user7813604
523322
asked Nov 20 at 15:59
ptr_user7813604
523322
523322
It is not really successful, your compiler should at least give you a warning.
– Osiris
Nov 20 at 16:02
1
Compiling with adequate C flags giveserror: incompatible pointer types passing 'int *(*)[2][10]' to parameter of type 'int *(*)[10]'.
– Quentin
Nov 20 at 16:02
1
ideone.com/iv3MXi gives you the correct error. You should choose C99 instead of C at ideone.
– mch
Nov 20 at 16:03
3
Legacy C is traditionally very lenient when it comes to type conversion. C++ is much more strict about. With adequate level of warnings, C will also warn you.
– SergeyA
Nov 20 at 16:04
3
On a side note, this might be the first time when I see both tags C and C++ correctly used in the single question!
– SergeyA
Nov 20 at 16:05
|
show 2 more comments
It is not really successful, your compiler should at least give you a warning.
– Osiris
Nov 20 at 16:02
1
Compiling with adequate C flags giveserror: incompatible pointer types passing 'int *(*)[2][10]' to parameter of type 'int *(*)[10]'.
– Quentin
Nov 20 at 16:02
1
ideone.com/iv3MXi gives you the correct error. You should choose C99 instead of C at ideone.
– mch
Nov 20 at 16:03
3
Legacy C is traditionally very lenient when it comes to type conversion. C++ is much more strict about. With adequate level of warnings, C will also warn you.
– SergeyA
Nov 20 at 16:04
3
On a side note, this might be the first time when I see both tags C and C++ correctly used in the single question!
– SergeyA
Nov 20 at 16:05
It is not really successful, your compiler should at least give you a warning.
– Osiris
Nov 20 at 16:02
It is not really successful, your compiler should at least give you a warning.
– Osiris
Nov 20 at 16:02
1
1
Compiling with adequate C flags gives
error: incompatible pointer types passing 'int *(*)[2][10]' to parameter of type 'int *(*)[10]'.– Quentin
Nov 20 at 16:02
Compiling with adequate C flags gives
error: incompatible pointer types passing 'int *(*)[2][10]' to parameter of type 'int *(*)[10]'.– Quentin
Nov 20 at 16:02
1
1
ideone.com/iv3MXi gives you the correct error. You should choose C99 instead of C at ideone.
– mch
Nov 20 at 16:03
ideone.com/iv3MXi gives you the correct error. You should choose C99 instead of C at ideone.
– mch
Nov 20 at 16:03
3
3
Legacy C is traditionally very lenient when it comes to type conversion. C++ is much more strict about. With adequate level of warnings, C will also warn you.
– SergeyA
Nov 20 at 16:04
Legacy C is traditionally very lenient when it comes to type conversion. C++ is much more strict about. With adequate level of warnings, C will also warn you.
– SergeyA
Nov 20 at 16:04
3
3
On a side note, this might be the first time when I see both tags C and C++ correctly used in the single question!
– SergeyA
Nov 20 at 16:05
On a side note, this might be the first time when I see both tags C and C++ correctly used in the single question!
– SergeyA
Nov 20 at 16:05
|
show 2 more comments
2 Answers
2
active
oldest
votes
up vote
4
down vote
accepted
Drastic edit; previous answer was wrong as pointed out in the comments.
The program is ill-formed in both C and C++. But the standards of the respective languages don't disallow successfully compiling programs that violate the imposed constraints. This allows the implementations to extend the language. Implementations are merely required to issue a diagnostic message. Both a warning and an error are conforming behaviours.
For whatever reason, the compiler that you use (through ideone) has chosen to behave differently when compiling C++.
answered Nov 20 at 16:13
eerorika
76.1k556116
1
The fact that any pointer to an object or incomplete type may be converted to a pointer to a different object or incomplete type does not mean implicit conversions are well-formed or will be performed. C 2018 6.5.2.2 8 says implicit conversions will not be performed for function call arguments other than as previously listed, and 7 says arguments for this function call with a prototype will be converted as if by assignment, and 6.5.16.1 1 (for assignment) says this conversion violates constraints. So, no, it is not a well-formed conversion, regardless of aliasing.
– Eric Postpischil
Nov 20 at 16:35
@EricPostpischil hmm, you're right. I know more of C++ than C. Your argument appears to hold all the way back to C89.
– eerorika
Nov 20 at 16:43
@EricPostpischil I rewrote the answer.
– eerorika
Nov 20 at 16:50
add a comment |
up vote
4
down vote
This is not valid in C. Using gcc with -Wall -Wextra, it outputs the following:
x1.c: In function ‘main’:
x1.c:19:9: warning: passing argument 1 of ‘foo’ from incompatible pointer type [-Wincompatible-pointer-types]
foo(&a, LEN);
^
x1.c:5:6: note: expected ‘int * (*)[10]’ but argument is of type ‘int * (*)[2][10]’
void foo(int* a[10], size_t len) {
^~~
The types are not compatible. It only shows up as a warning because C tends to allow various pointer conversions even though they aren't proper.
You can however do this:
int *(*p1)[10] = a;
foo(a, LEN);
foo(p1, LEN);
answered Nov 20 at 16:03
dbush
91.4k12100131
Just enabling-pedantic-errorswill make it an error, as it should.
– Quentin
Nov 20 at 16:06
if it is a warning then it is not invalid.-Wall -Wextrarejects code that strictly speaking is valid afaik
– user463035818
Nov 20 at 16:11
you are both right. The code is syntactically correct, but semantically incorrect. Warnings usually warn on syntactically correct code that has high probability of being semantically incorrect or have unexpected semantics.
– bolov
Nov 20 at 16:19
@user463035818: “Valid” and “invalid” are not well defined terms in the C standard. For a function call with a prototype, the arguments are converted as if by assignment (C 2018 6.5.2.2 7), and no other conversions are performed implicitly (8). For assignment, this violates the constraints (6.5.16.1 1), as the only acceptable assignment of a non-void pointer to a non-void pointer is for compatible types (with some flexibility on qualifiers).
– Eric Postpischil
Nov 20 at 16:32
@EricPostpischil yes, they are not well defined, though if I read your comment correctly the code is "not ok" according to the C standard. Actually I dont remember what was making me write that comment, maybe i misread the answer as implying getting a warning means the code is invalid, which the answer does actually not claim. Anyhow, thanks for the details
– user463035818
Nov 20 at 17:46
add a comment |
Your Answer
StackExchange.ifUsing("editor", function () {
StackExchange.using("externalEditor", function () {
StackExchange.using("snippets", function () {
StackExchange.snippets.init();
});
});
}, "code-snippets");
StackExchange.ready(function() {
var channelOptions = {
tags: "".split(" "),
id: "1"
};
initTagRenderer("".split(" "), "".split(" "), channelOptions);
StackExchange.using("externalEditor", function() {
// Have to fire editor after snippets, if snippets enabled
if (StackExchange.settings.snippets.snippetsEnabled) {
StackExchange.using("snippets", function() {
createEditor();
});
}
else {
createEditor();
}
});
function createEditor() {
StackExchange.prepareEditor({
heartbeatType: 'answer',
convertImagesToLinks: true,
noModals: true,
showLowRepImageUploadWarning: true,
reputationToPostImages: 10,
bindNavPrevention: true,
postfix: "",
imageUploader: {
brandingHtml: "Powered by u003ca class="icon-imgur-white" href="https://imgur.com/"u003eu003c/au003e",
contentPolicyHtml: "User contributions licensed under u003ca href="https://creativecommons.org/licenses/by-sa/3.0/"u003ecc by-sa 3.0 with attribution requiredu003c/au003e u003ca href="https://stackoverflow.com/legal/content-policy"u003e(content policy)u003c/au003e",
allowUrls: true
},
onDemand: true,
discardSelector: ".discard-answer"
,immediatelyShowMarkdownHelp:true
});
}
});
draft saved
draft discarded
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fstackoverflow.com%2fquestions%2f53396900%2ftwo-different-results-passing-pointer-to-array-to-a-function-in-c-and-c%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
2 Answers
2
active
oldest
votes
2 Answers
2
active
oldest
votes
active
oldest
votes
active
oldest
votes
up vote
4
down vote
accepted
Drastic edit; previous answer was wrong as pointed out in the comments.
The program is ill-formed in both C and C++. But the standards of the respective languages don't disallow successfully compiling programs that violate the imposed constraints. This allows the implementations to extend the language. Implementations are merely required to issue a diagnostic message. Both a warning and an error are conforming behaviours.
For whatever reason, the compiler that you use (through ideone) has chosen to behave differently when compiling C++.
answered Nov 20 at 16:13
eerorika
76.1k556116
1
The fact that any pointer to an object or incomplete type may be converted to a pointer to a different object or incomplete type does not mean implicit conversions are well-formed or will be performed. C 2018 6.5.2.2 8 says implicit conversions will not be performed for function call arguments other than as previously listed, and 7 says arguments for this function call with a prototype will be converted as if by assignment, and 6.5.16.1 1 (for assignment) says this conversion violates constraints. So, no, it is not a well-formed conversion, regardless of aliasing.
– Eric Postpischil
Nov 20 at 16:35
@EricPostpischil hmm, you're right. I know more of C++ than C. Your argument appears to hold all the way back to C89.
– eerorika
Nov 20 at 16:43
@EricPostpischil I rewrote the answer.
– eerorika
Nov 20 at 16:50
add a comment |
up vote
4
down vote
accepted
Drastic edit; previous answer was wrong as pointed out in the comments.
The program is ill-formed in both C and C++. But the standards of the respective languages don't disallow successfully compiling programs that violate the imposed constraints. This allows the implementations to extend the language. Implementations are merely required to issue a diagnostic message. Both a warning and an error are conforming behaviours.
For whatever reason, the compiler that you use (through ideone) has chosen to behave differently when compiling C++.
answered Nov 20 at 16:13
eerorika
76.1k556116
1
The fact that any pointer to an object or incomplete type may be converted to a pointer to a different object or incomplete type does not mean implicit conversions are well-formed or will be performed. C 2018 6.5.2.2 8 says implicit conversions will not be performed for function call arguments other than as previously listed, and 7 says arguments for this function call with a prototype will be converted as if by assignment, and 6.5.16.1 1 (for assignment) says this conversion violates constraints. So, no, it is not a well-formed conversion, regardless of aliasing.
– Eric Postpischil
Nov 20 at 16:35
@EricPostpischil hmm, you're right. I know more of C++ than C. Your argument appears to hold all the way back to C89.
– eerorika
Nov 20 at 16:43
@EricPostpischil I rewrote the answer.
– eerorika
Nov 20 at 16:50
add a comment |
up vote
4
down vote
accepted
up vote
4
down vote
accepted
Drastic edit; previous answer was wrong as pointed out in the comments.
The program is ill-formed in both C and C++. But the standards of the respective languages don't disallow successfully compiling programs that violate the imposed constraints. This allows the implementations to extend the language. Implementations are merely required to issue a diagnostic message. Both a warning and an error are conforming behaviours.
For whatever reason, the compiler that you use (through ideone) has chosen to behave differently when compiling C++.
answered Nov 20 at 16:13
eerorika
76.1k556116
Drastic edit; previous answer was wrong as pointed out in the comments.
The program is ill-formed in both C and C++. But the standards of the respective languages don't disallow successfully compiling programs that violate the imposed constraints. This allows the implementations to extend the language. Implementations are merely required to issue a diagnostic message. Both a warning and an error are conforming behaviours.
For whatever reason, the compiler that you use (through ideone) has chosen to behave differently when compiling C++.
answered Nov 20 at 16:13
eerorika
76.1k556116
edited Nov 20 at 16:49
answered Nov 20 at 16:13
eerorika
76.1k556116
answered Nov 20 at 16:13
eerorika
76.1k556116
answered Nov 20 at 16:13
eerorika
76.1k556116
76.1k556116
1
The fact that any pointer to an object or incomplete type may be converted to a pointer to a different object or incomplete type does not mean implicit conversions are well-formed or will be performed. C 2018 6.5.2.2 8 says implicit conversions will not be performed for function call arguments other than as previously listed, and 7 says arguments for this function call with a prototype will be converted as if by assignment, and 6.5.16.1 1 (for assignment) says this conversion violates constraints. So, no, it is not a well-formed conversion, regardless of aliasing.
– Eric Postpischil
Nov 20 at 16:35
@EricPostpischil hmm, you're right. I know more of C++ than C. Your argument appears to hold all the way back to C89.
– eerorika
Nov 20 at 16:43
@EricPostpischil I rewrote the answer.
– eerorika
Nov 20 at 16:50
add a comment |
1
The fact that any pointer to an object or incomplete type may be converted to a pointer to a different object or incomplete type does not mean implicit conversions are well-formed or will be performed. C 2018 6.5.2.2 8 says implicit conversions will not be performed for function call arguments other than as previously listed, and 7 says arguments for this function call with a prototype will be converted as if by assignment, and 6.5.16.1 1 (for assignment) says this conversion violates constraints. So, no, it is not a well-formed conversion, regardless of aliasing.
– Eric Postpischil
Nov 20 at 16:35
@EricPostpischil hmm, you're right. I know more of C++ than C. Your argument appears to hold all the way back to C89.
– eerorika
Nov 20 at 16:43
@EricPostpischil I rewrote the answer.
– eerorika
Nov 20 at 16:50
1
1
The fact that any pointer to an object or incomplete type may be converted to a pointer to a different object or incomplete type does not mean implicit conversions are well-formed or will be performed. C 2018 6.5.2.2 8 says implicit conversions will not be performed for function call arguments other than as previously listed, and 7 says arguments for this function call with a prototype will be converted as if by assignment, and 6.5.16.1 1 (for assignment) says this conversion violates constraints. So, no, it is not a well-formed conversion, regardless of aliasing.
– Eric Postpischil
Nov 20 at 16:35
The fact that any pointer to an object or incomplete type may be converted to a pointer to a different object or incomplete type does not mean implicit conversions are well-formed or will be performed. C 2018 6.5.2.2 8 says implicit conversions will not be performed for function call arguments other than as previously listed, and 7 says arguments for this function call with a prototype will be converted as if by assignment, and 6.5.16.1 1 (for assignment) says this conversion violates constraints. So, no, it is not a well-formed conversion, regardless of aliasing.
– Eric Postpischil
Nov 20 at 16:35
@EricPostpischil hmm, you're right. I know more of C++ than C. Your argument appears to hold all the way back to C89.
– eerorika
Nov 20 at 16:43
@EricPostpischil hmm, you're right. I know more of C++ than C. Your argument appears to hold all the way back to C89.
– eerorika
Nov 20 at 16:43
@EricPostpischil I rewrote the answer.
– eerorika
Nov 20 at 16:50
@EricPostpischil I rewrote the answer.
– eerorika
Nov 20 at 16:50
add a comment |
up vote
4
down vote
This is not valid in C. Using gcc with -Wall -Wextra, it outputs the following:
x1.c: In function ‘main’:
x1.c:19:9: warning: passing argument 1 of ‘foo’ from incompatible pointer type [-Wincompatible-pointer-types]
foo(&a, LEN);
^
x1.c:5:6: note: expected ‘int * (*)[10]’ but argument is of type ‘int * (*)[2][10]’
void foo(int* a[10], size_t len) {
^~~
The types are not compatible. It only shows up as a warning because C tends to allow various pointer conversions even though they aren't proper.
You can however do this:
int *(*p1)[10] = a;
foo(a, LEN);
foo(p1, LEN);
answered Nov 20 at 16:03
dbush
91.4k12100131
Just enabling-pedantic-errorswill make it an error, as it should.
– Quentin
Nov 20 at 16:06
if it is a warning then it is not invalid.-Wall -Wextrarejects code that strictly speaking is valid afaik
– user463035818
Nov 20 at 16:11
you are both right. The code is syntactically correct, but semantically incorrect. Warnings usually warn on syntactically correct code that has high probability of being semantically incorrect or have unexpected semantics.
– bolov
Nov 20 at 16:19
@user463035818: “Valid” and “invalid” are not well defined terms in the C standard. For a function call with a prototype, the arguments are converted as if by assignment (C 2018 6.5.2.2 7), and no other conversions are performed implicitly (8). For assignment, this violates the constraints (6.5.16.1 1), as the only acceptable assignment of a non-void pointer to a non-void pointer is for compatible types (with some flexibility on qualifiers).
– Eric Postpischil
Nov 20 at 16:32
@EricPostpischil yes, they are not well defined, though if I read your comment correctly the code is "not ok" according to the C standard. Actually I dont remember what was making me write that comment, maybe i misread the answer as implying getting a warning means the code is invalid, which the answer does actually not claim. Anyhow, thanks for the details
– user463035818
Nov 20 at 17:46
add a comment |
up vote
4
down vote
This is not valid in C. Using gcc with -Wall -Wextra, it outputs the following:
x1.c: In function ‘main’:
x1.c:19:9: warning: passing argument 1 of ‘foo’ from incompatible pointer type [-Wincompatible-pointer-types]
foo(&a, LEN);
^
x1.c:5:6: note: expected ‘int * (*)[10]’ but argument is of type ‘int * (*)[2][10]’
void foo(int* a[10], size_t len) {
^~~
The types are not compatible. It only shows up as a warning because C tends to allow various pointer conversions even though they aren't proper.
You can however do this:
int *(*p1)[10] = a;
foo(a, LEN);
foo(p1, LEN);
answered Nov 20 at 16:03
dbush
91.4k12100131
Just enabling-pedantic-errorswill make it an error, as it should.
– Quentin
Nov 20 at 16:06
if it is a warning then it is not invalid.-Wall -Wextrarejects code that strictly speaking is valid afaik
– user463035818
Nov 20 at 16:11
you are both right. The code is syntactically correct, but semantically incorrect. Warnings usually warn on syntactically correct code that has high probability of being semantically incorrect or have unexpected semantics.
– bolov
Nov 20 at 16:19
@user463035818: “Valid” and “invalid” are not well defined terms in the C standard. For a function call with a prototype, the arguments are converted as if by assignment (C 2018 6.5.2.2 7), and no other conversions are performed implicitly (8). For assignment, this violates the constraints (6.5.16.1 1), as the only acceptable assignment of a non-void pointer to a non-void pointer is for compatible types (with some flexibility on qualifiers).
– Eric Postpischil
Nov 20 at 16:32
@EricPostpischil yes, they are not well defined, though if I read your comment correctly the code is "not ok" according to the C standard. Actually I dont remember what was making me write that comment, maybe i misread the answer as implying getting a warning means the code is invalid, which the answer does actually not claim. Anyhow, thanks for the details
– user463035818
Nov 20 at 17:46
add a comment |
up vote
4
down vote
up vote
4
down vote
This is not valid in C. Using gcc with -Wall -Wextra, it outputs the following:
x1.c: In function ‘main’:
x1.c:19:9: warning: passing argument 1 of ‘foo’ from incompatible pointer type [-Wincompatible-pointer-types]
foo(&a, LEN);
^
x1.c:5:6: note: expected ‘int * (*)[10]’ but argument is of type ‘int * (*)[2][10]’
void foo(int* a[10], size_t len) {
^~~
The types are not compatible. It only shows up as a warning because C tends to allow various pointer conversions even though they aren't proper.
You can however do this:
int *(*p1)[10] = a;
foo(a, LEN);
foo(p1, LEN);
answered Nov 20 at 16:03
dbush
91.4k12100131
This is not valid in C. Using gcc with -Wall -Wextra, it outputs the following:
x1.c: In function ‘main’:
x1.c:19:9: warning: passing argument 1 of ‘foo’ from incompatible pointer type [-Wincompatible-pointer-types]
foo(&a, LEN);
^
x1.c:5:6: note: expected ‘int * (*)[10]’ but argument is of type ‘int * (*)[2][10]’
void foo(int* a[10], size_t len) {
^~~
The types are not compatible. It only shows up as a warning because C tends to allow various pointer conversions even though they aren't proper.
You can however do this:
int *(*p1)[10] = a;
foo(a, LEN);
foo(p1, LEN);
answered Nov 20 at 16:03
dbush
91.4k12100131
answered Nov 20 at 16:03
dbush
91.4k12100131
answered Nov 20 at 16:03
dbush
91.4k12100131
answered Nov 20 at 16:03
dbush
91.4k12100131
91.4k12100131
Just enabling-pedantic-errorswill make it an error, as it should.
– Quentin
Nov 20 at 16:06
if it is a warning then it is not invalid.-Wall -Wextrarejects code that strictly speaking is valid afaik
– user463035818
Nov 20 at 16:11
you are both right. The code is syntactically correct, but semantically incorrect. Warnings usually warn on syntactically correct code that has high probability of being semantically incorrect or have unexpected semantics.
– bolov
Nov 20 at 16:19
@user463035818: “Valid” and “invalid” are not well defined terms in the C standard. For a function call with a prototype, the arguments are converted as if by assignment (C 2018 6.5.2.2 7), and no other conversions are performed implicitly (8). For assignment, this violates the constraints (6.5.16.1 1), as the only acceptable assignment of a non-void pointer to a non-void pointer is for compatible types (with some flexibility on qualifiers).
– Eric Postpischil
Nov 20 at 16:32
@EricPostpischil yes, they are not well defined, though if I read your comment correctly the code is "not ok" according to the C standard. Actually I dont remember what was making me write that comment, maybe i misread the answer as implying getting a warning means the code is invalid, which the answer does actually not claim. Anyhow, thanks for the details
– user463035818
Nov 20 at 17:46
add a comment |
Just enabling-pedantic-errorswill make it an error, as it should.
– Quentin
Nov 20 at 16:06
if it is a warning then it is not invalid.-Wall -Wextrarejects code that strictly speaking is valid afaik
– user463035818
Nov 20 at 16:11
you are both right. The code is syntactically correct, but semantically incorrect. Warnings usually warn on syntactically correct code that has high probability of being semantically incorrect or have unexpected semantics.
– bolov
Nov 20 at 16:19
@user463035818: “Valid” and “invalid” are not well defined terms in the C standard. For a function call with a prototype, the arguments are converted as if by assignment (C 2018 6.5.2.2 7), and no other conversions are performed implicitly (8). For assignment, this violates the constraints (6.5.16.1 1), as the only acceptable assignment of a non-void pointer to a non-void pointer is for compatible types (with some flexibility on qualifiers).
– Eric Postpischil
Nov 20 at 16:32
@EricPostpischil yes, they are not well defined, though if I read your comment correctly the code is "not ok" according to the C standard. Actually I dont remember what was making me write that comment, maybe i misread the answer as implying getting a warning means the code is invalid, which the answer does actually not claim. Anyhow, thanks for the details
– user463035818
Nov 20 at 17:46
Just enabling
-pedantic-errors will make it an error, as it should.– Quentin
Nov 20 at 16:06
Just enabling
-pedantic-errors will make it an error, as it should.– Quentin
Nov 20 at 16:06
if it is a warning then it is not invalid.
-Wall -Wextra rejects code that strictly speaking is valid afaik– user463035818
Nov 20 at 16:11
if it is a warning then it is not invalid.
-Wall -Wextra rejects code that strictly speaking is valid afaik– user463035818
Nov 20 at 16:11
you are both right. The code is syntactically correct, but semantically incorrect. Warnings usually warn on syntactically correct code that has high probability of being semantically incorrect or have unexpected semantics.
– bolov
Nov 20 at 16:19
you are both right. The code is syntactically correct, but semantically incorrect. Warnings usually warn on syntactically correct code that has high probability of being semantically incorrect or have unexpected semantics.
– bolov
Nov 20 at 16:19
@user463035818: “Valid” and “invalid” are not well defined terms in the C standard. For a function call with a prototype, the arguments are converted as if by assignment (C 2018 6.5.2.2 7), and no other conversions are performed implicitly (8). For assignment, this violates the constraints (6.5.16.1 1), as the only acceptable assignment of a non-void pointer to a non-void pointer is for compatible types (with some flexibility on qualifiers).
– Eric Postpischil
Nov 20 at 16:32
@user463035818: “Valid” and “invalid” are not well defined terms in the C standard. For a function call with a prototype, the arguments are converted as if by assignment (C 2018 6.5.2.2 7), and no other conversions are performed implicitly (8). For assignment, this violates the constraints (6.5.16.1 1), as the only acceptable assignment of a non-void pointer to a non-void pointer is for compatible types (with some flexibility on qualifiers).
– Eric Postpischil
Nov 20 at 16:32
@EricPostpischil yes, they are not well defined, though if I read your comment correctly the code is "not ok" according to the C standard. Actually I dont remember what was making me write that comment, maybe i misread the answer as implying getting a warning means the code is invalid, which the answer does actually not claim. Anyhow, thanks for the details
– user463035818
Nov 20 at 17:46
@EricPostpischil yes, they are not well defined, though if I read your comment correctly the code is "not ok" according to the C standard. Actually I dont remember what was making me write that comment, maybe i misread the answer as implying getting a warning means the code is invalid, which the answer does actually not claim. Anyhow, thanks for the details
– user463035818
Nov 20 at 17:46
add a comment |
draft saved
draft discarded
Thanks for contributing an answer to Stack Overflow!
- Please be sure to answer the question. Provide details and share your research!
But avoid …
- Asking for help, clarification, or responding to other answers.
- Making statements based on opinion; back them up with references or personal experience.
To learn more, see our tips on writing great answers.
Some of your past answers have not been well-received, and you're in danger of being blocked from answering.
Please pay close attention to the following guidance:
- Please be sure to answer the question. Provide details and share your research!
But avoid …
- Asking for help, clarification, or responding to other answers.
- Making statements based on opinion; back them up with references or personal experience.
To learn more, see our tips on writing great answers.
draft saved
draft discarded
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fstackoverflow.com%2fquestions%2f53396900%2ftwo-different-results-passing-pointer-to-array-to-a-function-in-c-and-c%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
It is not really successful, your compiler should at least give you a warning.
– Osiris
Nov 20 at 16:02
1
Compiling with adequate C flags gives
error: incompatible pointer types passing 'int *(*)[2][10]' to parameter of type 'int *(*)[10]'.– Quentin
Nov 20 at 16:02
1
ideone.com/iv3MXi gives you the correct error. You should choose C99 instead of C at ideone.
– mch
Nov 20 at 16:03
3
Legacy C is traditionally very lenient when it comes to type conversion. C++ is much more strict about. With adequate level of warnings, C will also warn you.
– SergeyA
Nov 20 at 16:04
3
On a side note, this might be the first time when I see both tags C and C++ correctly used in the single question!
– SergeyA
Nov 20 at 16:05