Can it cause problems to pass the address to an array instead of the array?
I ran into this code:
char str[600];
scanf("%s", &str);
Of course, this emits this warning:
a.c:6:17: warning: format specifies type 'char *' but the argument has type
'char (*)[600]' [-Wformat]
scanf("%s", &str);
~~ ^~~~~~~
I know that the correct way is to remove the & and type scanf("%s", str) instead. But it does work, so my question is if this could cause any problems. Is it UB? When I switched str to a pointer instead of an array it (obviously) did not work. But can this cause any problem when using an array?
(I had a discussion about an answer here, where the answerer did not want to change his answer to the correct way)
c arrays
asked Nov 25 at 21:42
Broman
6,252112241
add a comment |
I ran into this code:
char str[600];
scanf("%s", &str);
Of course, this emits this warning:
a.c:6:17: warning: format specifies type 'char *' but the argument has type
'char (*)[600]' [-Wformat]
scanf("%s", &str);
~~ ^~~~~~~
I know that the correct way is to remove the & and type scanf("%s", str) instead. But it does work, so my question is if this could cause any problems. Is it UB? When I switched str to a pointer instead of an array it (obviously) did not work. But can this cause any problem when using an array?
(I had a discussion about an answer here, where the answerer did not want to change his answer to the correct way)
c arrays
asked Nov 25 at 21:42
Broman
6,252112241
add a comment |
I ran into this code:
char str[600];
scanf("%s", &str);
Of course, this emits this warning:
a.c:6:17: warning: format specifies type 'char *' but the argument has type
'char (*)[600]' [-Wformat]
scanf("%s", &str);
~~ ^~~~~~~
I know that the correct way is to remove the & and type scanf("%s", str) instead. But it does work, so my question is if this could cause any problems. Is it UB? When I switched str to a pointer instead of an array it (obviously) did not work. But can this cause any problem when using an array?
(I had a discussion about an answer here, where the answerer did not want to change his answer to the correct way)
c arrays
asked Nov 25 at 21:42
Broman
6,252112241
I ran into this code:
char str[600];
scanf("%s", &str);
Of course, this emits this warning:
a.c:6:17: warning: format specifies type 'char *' but the argument has type
'char (*)[600]' [-Wformat]
scanf("%s", &str);
~~ ^~~~~~~
I know that the correct way is to remove the & and type scanf("%s", str) instead. But it does work, so my question is if this could cause any problems. Is it UB? When I switched str to a pointer instead of an array it (obviously) did not work. But can this cause any problem when using an array?
(I had a discussion about an answer here, where the answerer did not want to change his answer to the correct way)
c arrays
c arrays
asked Nov 25 at 21:42
Broman
6,252112241
asked Nov 25 at 21:42
Broman
6,252112241
asked Nov 25 at 21:42
Broman
6,252112241
asked Nov 25 at 21:42
Broman
6,252112241
asked Nov 25 at 21:42
Broman
6,252112241
6,252112241
add a comment |
add a comment |
3 Answers
3
active
oldest
votes
Yes, the code is undefined behaviour. The argument corresponding to %s must have the type char *. This is described in C17 7.21.6.2/12 under the s specifier:
[...] the corresponding argument shall be a pointer to the initial element of a character array large enough to accept the sequence and a terminating null character, which will be added automatically.
which says fairly clearly that the pointer should have pointer-to-character type, and not point to the whole array.
Undefined behaviour means that anything can happen. It might behave as if you omitted the &, or it might format your hard drive.
Given that it is extremely easy to avoid undefined behaviour in this case, I don't really see any reason to engage in arguments about whether it is OK to rely on the behaviour of undefined behaviour in this situation.
answered Nov 25 at 22:50
M.M
104k11113234
7.19.6.1? Do you mean 7.21.6.1 The fprintf function? And why doesn't 6.2.7 Compatible type and composite type "save" the posted code from UB? The address of the array is the address of the first element, which has to be compatible with the type of a pointer to the same type as an element of the array? I tend to agree with your answer that's it UB because 7.21.6.1 says it's UB, but I can see how an argument via compatible types and array decay can be made. And that's way, way, waaay down the language lawyer rabbit hole...
– Andrew Henle
Nov 25 at 23:18
@AndrewHenle Nice catch. I was to quick there.
– Broman
Nov 25 at 23:30
@AndrewHenle -- "The address of the array is the address of the first element, which has to be compatible with the type of a pointer to the same type as an element of the array?": I am not sure what you are trying to say here, but it sounds like you are saying that a pointer to an array and a pointer to the first element of that array are compatible types. I can't see any way that the Standard supports this, given that two types have compatible type if their types are the same (plus a few rules that don't appear to apply here).
– David Bowling
Nov 25 at 23:57
The standard says this aboutfscanf: If this object does not have an appropriate type, or if the result of the conversion cannot be represented in the object, the behavior is undefined.
– Broman
Nov 26 at 0:01
@AndrewHenle this is the scanf function,, not the printf function.char *andchar (*)[600]are not compatible types (that term is defined by C17 6.2.7)
– M.M
Nov 26 at 0:27
|
show 10 more comments
Using &str instead of str didn't cause any problems in this case because the addresses of those two are the same. See this past question for an explanation. But as you note, the type of &str is different, and the compiler throws up a warning, and the actual behavior will depend on architecture and implementation.
answered Nov 25 at 21:48
Paul
3606
It might not cause problems in common architectures - but strictly speaking, it's not allowed. And one thing that might break it: there's no guarantee that different pointer types all use the same representation for the same address. So here the types in questionchar*andchar (*)[600]might have different sizes or value representations.
– aschepler
Nov 25 at 23:11
@aschepler Fair enough. I suppose any behavior not defined in the spec is going to be implementation- or architecture-specific. Better to write it the correct way to begin with.
– Paul
Nov 25 at 23:14
@Paul -- "any behavior not defined in the spec": It isn't that the behavior is left undefined, so much as that the Standard says explicitly that the behavior is undefined. Passing the wrong types to functions is not a gray area.
– David Bowling
Nov 25 at 23:24
Yes, though the difference between a behavior not being defined and being explicitly undefined doesn't seem that different. I'll update my answer to say that it "didn't" cause any problems in this case rather than it "wouldn't" cause any problems.
– Paul
Nov 25 at 23:32
1
@Paul -- compiler writers may take advantage of the fact that some constructs lead to explicit undefined behavior (and hence should never show up in valid C programs) to make some optimizations. I would say that this is a significant difference compared with undefined-by-omission behaviors, and certainly with the many implementation-defined behaviors given in the Standard.
– David Bowling
Nov 25 at 23:38
|
show 1 more comment
in C the name of an array is also its address (points to the beginning of the array).
answered Nov 25 at 21:47
XsOuLp
314
This isn't true. Arrays are objects in C (in the C sense), and array identifiers refer to array objects. Arrays do decay to pointers to their first elements in most expressions (but not in all expressions). In particular, withchar arr = "abc"; size_t arr_sz = sizeof arr;the identifierarrnot only refers to an array, it does not decay to a pointer in thesizeofexpression.
– David Bowling
Nov 25 at 23:17
you are right. I wanted to say that the "name of an array" can be used as its address, not that an array is (only) the address.
– XsOuLp
Dec 4 at 18:47
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',
autoActivateHeartbeat: false,
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
});
}
});
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%2f53472293%2fcan-it-cause-problems-to-pass-the-address-to-an-array-instead-of-the-array%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
3 Answers
3
active
oldest
votes
3 Answers
3
active
oldest
votes
active
oldest
votes
active
oldest
votes
Yes, the code is undefined behaviour. The argument corresponding to %s must have the type char *. This is described in C17 7.21.6.2/12 under the s specifier:
[...] the corresponding argument shall be a pointer to the initial element of a character array large enough to accept the sequence and a terminating null character, which will be added automatically.
which says fairly clearly that the pointer should have pointer-to-character type, and not point to the whole array.
Undefined behaviour means that anything can happen. It might behave as if you omitted the &, or it might format your hard drive.
Given that it is extremely easy to avoid undefined behaviour in this case, I don't really see any reason to engage in arguments about whether it is OK to rely on the behaviour of undefined behaviour in this situation.
answered Nov 25 at 22:50
M.M
104k11113234
7.19.6.1? Do you mean 7.21.6.1 The fprintf function? And why doesn't 6.2.7 Compatible type and composite type "save" the posted code from UB? The address of the array is the address of the first element, which has to be compatible with the type of a pointer to the same type as an element of the array? I tend to agree with your answer that's it UB because 7.21.6.1 says it's UB, but I can see how an argument via compatible types and array decay can be made. And that's way, way, waaay down the language lawyer rabbit hole...
– Andrew Henle
Nov 25 at 23:18
@AndrewHenle Nice catch. I was to quick there.
– Broman
Nov 25 at 23:30
@AndrewHenle -- "The address of the array is the address of the first element, which has to be compatible with the type of a pointer to the same type as an element of the array?": I am not sure what you are trying to say here, but it sounds like you are saying that a pointer to an array and a pointer to the first element of that array are compatible types. I can't see any way that the Standard supports this, given that two types have compatible type if their types are the same (plus a few rules that don't appear to apply here).
– David Bowling
Nov 25 at 23:57
The standard says this aboutfscanf: If this object does not have an appropriate type, or if the result of the conversion cannot be represented in the object, the behavior is undefined.
– Broman
Nov 26 at 0:01
@AndrewHenle this is the scanf function,, not the printf function.char *andchar (*)[600]are not compatible types (that term is defined by C17 6.2.7)
– M.M
Nov 26 at 0:27
|
show 10 more comments
Yes, the code is undefined behaviour. The argument corresponding to %s must have the type char *. This is described in C17 7.21.6.2/12 under the s specifier:
[...] the corresponding argument shall be a pointer to the initial element of a character array large enough to accept the sequence and a terminating null character, which will be added automatically.
which says fairly clearly that the pointer should have pointer-to-character type, and not point to the whole array.
Undefined behaviour means that anything can happen. It might behave as if you omitted the &, or it might format your hard drive.
Given that it is extremely easy to avoid undefined behaviour in this case, I don't really see any reason to engage in arguments about whether it is OK to rely on the behaviour of undefined behaviour in this situation.
answered Nov 25 at 22:50
M.M
104k11113234
7.19.6.1? Do you mean 7.21.6.1 The fprintf function? And why doesn't 6.2.7 Compatible type and composite type "save" the posted code from UB? The address of the array is the address of the first element, which has to be compatible with the type of a pointer to the same type as an element of the array? I tend to agree with your answer that's it UB because 7.21.6.1 says it's UB, but I can see how an argument via compatible types and array decay can be made. And that's way, way, waaay down the language lawyer rabbit hole...
– Andrew Henle
Nov 25 at 23:18
@AndrewHenle Nice catch. I was to quick there.
– Broman
Nov 25 at 23:30
@AndrewHenle -- "The address of the array is the address of the first element, which has to be compatible with the type of a pointer to the same type as an element of the array?": I am not sure what you are trying to say here, but it sounds like you are saying that a pointer to an array and a pointer to the first element of that array are compatible types. I can't see any way that the Standard supports this, given that two types have compatible type if their types are the same (plus a few rules that don't appear to apply here).
– David Bowling
Nov 25 at 23:57
The standard says this aboutfscanf: If this object does not have an appropriate type, or if the result of the conversion cannot be represented in the object, the behavior is undefined.
– Broman
Nov 26 at 0:01
@AndrewHenle this is the scanf function,, not the printf function.char *andchar (*)[600]are not compatible types (that term is defined by C17 6.2.7)
– M.M
Nov 26 at 0:27
|
show 10 more comments
Yes, the code is undefined behaviour. The argument corresponding to %s must have the type char *. This is described in C17 7.21.6.2/12 under the s specifier:
[...] the corresponding argument shall be a pointer to the initial element of a character array large enough to accept the sequence and a terminating null character, which will be added automatically.
which says fairly clearly that the pointer should have pointer-to-character type, and not point to the whole array.
Undefined behaviour means that anything can happen. It might behave as if you omitted the &, or it might format your hard drive.
Given that it is extremely easy to avoid undefined behaviour in this case, I don't really see any reason to engage in arguments about whether it is OK to rely on the behaviour of undefined behaviour in this situation.
answered Nov 25 at 22:50
M.M
104k11113234
Yes, the code is undefined behaviour. The argument corresponding to %s must have the type char *. This is described in C17 7.21.6.2/12 under the s specifier:
[...] the corresponding argument shall be a pointer to the initial element of a character array large enough to accept the sequence and a terminating null character, which will be added automatically.
which says fairly clearly that the pointer should have pointer-to-character type, and not point to the whole array.
Undefined behaviour means that anything can happen. It might behave as if you omitted the &, or it might format your hard drive.
Given that it is extremely easy to avoid undefined behaviour in this case, I don't really see any reason to engage in arguments about whether it is OK to rely on the behaviour of undefined behaviour in this situation.
answered Nov 25 at 22:50
M.M
104k11113234
edited Nov 26 at 3:32
answered Nov 25 at 22:50
M.M
104k11113234
answered Nov 25 at 22:50
M.M
104k11113234
answered Nov 25 at 22:50
M.M
104k11113234
104k11113234
7.19.6.1? Do you mean 7.21.6.1 The fprintf function? And why doesn't 6.2.7 Compatible type and composite type "save" the posted code from UB? The address of the array is the address of the first element, which has to be compatible with the type of a pointer to the same type as an element of the array? I tend to agree with your answer that's it UB because 7.21.6.1 says it's UB, but I can see how an argument via compatible types and array decay can be made. And that's way, way, waaay down the language lawyer rabbit hole...
– Andrew Henle
Nov 25 at 23:18
@AndrewHenle Nice catch. I was to quick there.
– Broman
Nov 25 at 23:30
@AndrewHenle -- "The address of the array is the address of the first element, which has to be compatible with the type of a pointer to the same type as an element of the array?": I am not sure what you are trying to say here, but it sounds like you are saying that a pointer to an array and a pointer to the first element of that array are compatible types. I can't see any way that the Standard supports this, given that two types have compatible type if their types are the same (plus a few rules that don't appear to apply here).
– David Bowling
Nov 25 at 23:57
The standard says this aboutfscanf: If this object does not have an appropriate type, or if the result of the conversion cannot be represented in the object, the behavior is undefined.
– Broman
Nov 26 at 0:01
@AndrewHenle this is the scanf function,, not the printf function.char *andchar (*)[600]are not compatible types (that term is defined by C17 6.2.7)
– M.M
Nov 26 at 0:27
|
show 10 more comments
7.19.6.1? Do you mean 7.21.6.1 The fprintf function? And why doesn't 6.2.7 Compatible type and composite type "save" the posted code from UB? The address of the array is the address of the first element, which has to be compatible with the type of a pointer to the same type as an element of the array? I tend to agree with your answer that's it UB because 7.21.6.1 says it's UB, but I can see how an argument via compatible types and array decay can be made. And that's way, way, waaay down the language lawyer rabbit hole...
– Andrew Henle
Nov 25 at 23:18
@AndrewHenle Nice catch. I was to quick there.
– Broman
Nov 25 at 23:30
@AndrewHenle -- "The address of the array is the address of the first element, which has to be compatible with the type of a pointer to the same type as an element of the array?": I am not sure what you are trying to say here, but it sounds like you are saying that a pointer to an array and a pointer to the first element of that array are compatible types. I can't see any way that the Standard supports this, given that two types have compatible type if their types are the same (plus a few rules that don't appear to apply here).
– David Bowling
Nov 25 at 23:57
The standard says this aboutfscanf: If this object does not have an appropriate type, or if the result of the conversion cannot be represented in the object, the behavior is undefined.
– Broman
Nov 26 at 0:01
@AndrewHenle this is the scanf function,, not the printf function.char *andchar (*)[600]are not compatible types (that term is defined by C17 6.2.7)
– M.M
Nov 26 at 0:27
7.19.6.1? Do you mean 7.21.6.1 The fprintf function? And why doesn't 6.2.7 Compatible type and composite type "save" the posted code from UB? The address of the array is the address of the first element, which has to be compatible with the type of a pointer to the same type as an element of the array? I tend to agree with your answer that's it UB because 7.21.6.1 says it's UB, but I can see how an argument via compatible types and array decay can be made. And that's way, way, waaay down the language lawyer rabbit hole...
– Andrew Henle
Nov 25 at 23:18
7.19.6.1? Do you mean 7.21.6.1 The fprintf function? And why doesn't 6.2.7 Compatible type and composite type "save" the posted code from UB? The address of the array is the address of the first element, which has to be compatible with the type of a pointer to the same type as an element of the array? I tend to agree with your answer that's it UB because 7.21.6.1 says it's UB, but I can see how an argument via compatible types and array decay can be made. And that's way, way, waaay down the language lawyer rabbit hole...
– Andrew Henle
Nov 25 at 23:18
@AndrewHenle Nice catch. I was to quick there.
– Broman
Nov 25 at 23:30
@AndrewHenle Nice catch. I was to quick there.
– Broman
Nov 25 at 23:30
@AndrewHenle -- "The address of the array is the address of the first element, which has to be compatible with the type of a pointer to the same type as an element of the array?": I am not sure what you are trying to say here, but it sounds like you are saying that a pointer to an array and a pointer to the first element of that array are compatible types. I can't see any way that the Standard supports this, given that two types have compatible type if their types are the same (plus a few rules that don't appear to apply here).
– David Bowling
Nov 25 at 23:57
@AndrewHenle -- "The address of the array is the address of the first element, which has to be compatible with the type of a pointer to the same type as an element of the array?": I am not sure what you are trying to say here, but it sounds like you are saying that a pointer to an array and a pointer to the first element of that array are compatible types. I can't see any way that the Standard supports this, given that two types have compatible type if their types are the same (plus a few rules that don't appear to apply here).
– David Bowling
Nov 25 at 23:57
The standard says this about
fscanf: If this object does not have an appropriate type, or if the result of the conversion cannot be represented in the object, the behavior is undefined.– Broman
Nov 26 at 0:01
The standard says this about
fscanf: If this object does not have an appropriate type, or if the result of the conversion cannot be represented in the object, the behavior is undefined.– Broman
Nov 26 at 0:01
@AndrewHenle this is the scanf function,, not the printf function.
char * and char (*)[600] are not compatible types (that term is defined by C17 6.2.7)– M.M
Nov 26 at 0:27
@AndrewHenle this is the scanf function,, not the printf function.
char * and char (*)[600] are not compatible types (that term is defined by C17 6.2.7)– M.M
Nov 26 at 0:27
|
show 10 more comments
Using &str instead of str didn't cause any problems in this case because the addresses of those two are the same. See this past question for an explanation. But as you note, the type of &str is different, and the compiler throws up a warning, and the actual behavior will depend on architecture and implementation.
answered Nov 25 at 21:48
Paul
3606
It might not cause problems in common architectures - but strictly speaking, it's not allowed. And one thing that might break it: there's no guarantee that different pointer types all use the same representation for the same address. So here the types in questionchar*andchar (*)[600]might have different sizes or value representations.
– aschepler
Nov 25 at 23:11
@aschepler Fair enough. I suppose any behavior not defined in the spec is going to be implementation- or architecture-specific. Better to write it the correct way to begin with.
– Paul
Nov 25 at 23:14
@Paul -- "any behavior not defined in the spec": It isn't that the behavior is left undefined, so much as that the Standard says explicitly that the behavior is undefined. Passing the wrong types to functions is not a gray area.
– David Bowling
Nov 25 at 23:24
Yes, though the difference between a behavior not being defined and being explicitly undefined doesn't seem that different. I'll update my answer to say that it "didn't" cause any problems in this case rather than it "wouldn't" cause any problems.
– Paul
Nov 25 at 23:32
1
@Paul -- compiler writers may take advantage of the fact that some constructs lead to explicit undefined behavior (and hence should never show up in valid C programs) to make some optimizations. I would say that this is a significant difference compared with undefined-by-omission behaviors, and certainly with the many implementation-defined behaviors given in the Standard.
– David Bowling
Nov 25 at 23:38
|
show 1 more comment
Using &str instead of str didn't cause any problems in this case because the addresses of those two are the same. See this past question for an explanation. But as you note, the type of &str is different, and the compiler throws up a warning, and the actual behavior will depend on architecture and implementation.
answered Nov 25 at 21:48
Paul
3606
It might not cause problems in common architectures - but strictly speaking, it's not allowed. And one thing that might break it: there's no guarantee that different pointer types all use the same representation for the same address. So here the types in questionchar*andchar (*)[600]might have different sizes or value representations.
– aschepler
Nov 25 at 23:11
@aschepler Fair enough. I suppose any behavior not defined in the spec is going to be implementation- or architecture-specific. Better to write it the correct way to begin with.
– Paul
Nov 25 at 23:14
@Paul -- "any behavior not defined in the spec": It isn't that the behavior is left undefined, so much as that the Standard says explicitly that the behavior is undefined. Passing the wrong types to functions is not a gray area.
– David Bowling
Nov 25 at 23:24
Yes, though the difference between a behavior not being defined and being explicitly undefined doesn't seem that different. I'll update my answer to say that it "didn't" cause any problems in this case rather than it "wouldn't" cause any problems.
– Paul
Nov 25 at 23:32
1
@Paul -- compiler writers may take advantage of the fact that some constructs lead to explicit undefined behavior (and hence should never show up in valid C programs) to make some optimizations. I would say that this is a significant difference compared with undefined-by-omission behaviors, and certainly with the many implementation-defined behaviors given in the Standard.
– David Bowling
Nov 25 at 23:38
|
show 1 more comment
Using &str instead of str didn't cause any problems in this case because the addresses of those two are the same. See this past question for an explanation. But as you note, the type of &str is different, and the compiler throws up a warning, and the actual behavior will depend on architecture and implementation.
answered Nov 25 at 21:48
Paul
3606
Using &str instead of str didn't cause any problems in this case because the addresses of those two are the same. See this past question for an explanation. But as you note, the type of &str is different, and the compiler throws up a warning, and the actual behavior will depend on architecture and implementation.
answered Nov 25 at 21:48
Paul
3606
edited Nov 25 at 23:33
answered Nov 25 at 21:48
Paul
3606
answered Nov 25 at 21:48
Paul
3606
answered Nov 25 at 21:48
Paul
3606
3606
It might not cause problems in common architectures - but strictly speaking, it's not allowed. And one thing that might break it: there's no guarantee that different pointer types all use the same representation for the same address. So here the types in questionchar*andchar (*)[600]might have different sizes or value representations.
– aschepler
Nov 25 at 23:11
@aschepler Fair enough. I suppose any behavior not defined in the spec is going to be implementation- or architecture-specific. Better to write it the correct way to begin with.
– Paul
Nov 25 at 23:14
@Paul -- "any behavior not defined in the spec": It isn't that the behavior is left undefined, so much as that the Standard says explicitly that the behavior is undefined. Passing the wrong types to functions is not a gray area.
– David Bowling
Nov 25 at 23:24
Yes, though the difference between a behavior not being defined and being explicitly undefined doesn't seem that different. I'll update my answer to say that it "didn't" cause any problems in this case rather than it "wouldn't" cause any problems.
– Paul
Nov 25 at 23:32
1
@Paul -- compiler writers may take advantage of the fact that some constructs lead to explicit undefined behavior (and hence should never show up in valid C programs) to make some optimizations. I would say that this is a significant difference compared with undefined-by-omission behaviors, and certainly with the many implementation-defined behaviors given in the Standard.
– David Bowling
Nov 25 at 23:38
|
show 1 more comment
It might not cause problems in common architectures - but strictly speaking, it's not allowed. And one thing that might break it: there's no guarantee that different pointer types all use the same representation for the same address. So here the types in questionchar*andchar (*)[600]might have different sizes or value representations.
– aschepler
Nov 25 at 23:11
@aschepler Fair enough. I suppose any behavior not defined in the spec is going to be implementation- or architecture-specific. Better to write it the correct way to begin with.
– Paul
Nov 25 at 23:14
@Paul -- "any behavior not defined in the spec": It isn't that the behavior is left undefined, so much as that the Standard says explicitly that the behavior is undefined. Passing the wrong types to functions is not a gray area.
– David Bowling
Nov 25 at 23:24
Yes, though the difference between a behavior not being defined and being explicitly undefined doesn't seem that different. I'll update my answer to say that it "didn't" cause any problems in this case rather than it "wouldn't" cause any problems.
– Paul
Nov 25 at 23:32
1
@Paul -- compiler writers may take advantage of the fact that some constructs lead to explicit undefined behavior (and hence should never show up in valid C programs) to make some optimizations. I would say that this is a significant difference compared with undefined-by-omission behaviors, and certainly with the many implementation-defined behaviors given in the Standard.
– David Bowling
Nov 25 at 23:38
It might not cause problems in common architectures - but strictly speaking, it's not allowed. And one thing that might break it: there's no guarantee that different pointer types all use the same representation for the same address. So here the types in question
char* and char (*)[600] might have different sizes or value representations.– aschepler
Nov 25 at 23:11
It might not cause problems in common architectures - but strictly speaking, it's not allowed. And one thing that might break it: there's no guarantee that different pointer types all use the same representation for the same address. So here the types in question
char* and char (*)[600] might have different sizes or value representations.– aschepler
Nov 25 at 23:11
@aschepler Fair enough. I suppose any behavior not defined in the spec is going to be implementation- or architecture-specific. Better to write it the correct way to begin with.
– Paul
Nov 25 at 23:14
@aschepler Fair enough. I suppose any behavior not defined in the spec is going to be implementation- or architecture-specific. Better to write it the correct way to begin with.
– Paul
Nov 25 at 23:14
@Paul -- "any behavior not defined in the spec": It isn't that the behavior is left undefined, so much as that the Standard says explicitly that the behavior is undefined. Passing the wrong types to functions is not a gray area.
– David Bowling
Nov 25 at 23:24
@Paul -- "any behavior not defined in the spec": It isn't that the behavior is left undefined, so much as that the Standard says explicitly that the behavior is undefined. Passing the wrong types to functions is not a gray area.
– David Bowling
Nov 25 at 23:24
Yes, though the difference between a behavior not being defined and being explicitly undefined doesn't seem that different. I'll update my answer to say that it "didn't" cause any problems in this case rather than it "wouldn't" cause any problems.
– Paul
Nov 25 at 23:32
Yes, though the difference between a behavior not being defined and being explicitly undefined doesn't seem that different. I'll update my answer to say that it "didn't" cause any problems in this case rather than it "wouldn't" cause any problems.
– Paul
Nov 25 at 23:32
1
1
@Paul -- compiler writers may take advantage of the fact that some constructs lead to explicit undefined behavior (and hence should never show up in valid C programs) to make some optimizations. I would say that this is a significant difference compared with undefined-by-omission behaviors, and certainly with the many implementation-defined behaviors given in the Standard.
– David Bowling
Nov 25 at 23:38
@Paul -- compiler writers may take advantage of the fact that some constructs lead to explicit undefined behavior (and hence should never show up in valid C programs) to make some optimizations. I would say that this is a significant difference compared with undefined-by-omission behaviors, and certainly with the many implementation-defined behaviors given in the Standard.
– David Bowling
Nov 25 at 23:38
|
show 1 more comment
in C the name of an array is also its address (points to the beginning of the array).
answered Nov 25 at 21:47
XsOuLp
314
This isn't true. Arrays are objects in C (in the C sense), and array identifiers refer to array objects. Arrays do decay to pointers to their first elements in most expressions (but not in all expressions). In particular, withchar arr = "abc"; size_t arr_sz = sizeof arr;the identifierarrnot only refers to an array, it does not decay to a pointer in thesizeofexpression.
– David Bowling
Nov 25 at 23:17
you are right. I wanted to say that the "name of an array" can be used as its address, not that an array is (only) the address.
– XsOuLp
Dec 4 at 18:47
add a comment |
in C the name of an array is also its address (points to the beginning of the array).
answered Nov 25 at 21:47
XsOuLp
314
This isn't true. Arrays are objects in C (in the C sense), and array identifiers refer to array objects. Arrays do decay to pointers to their first elements in most expressions (but not in all expressions). In particular, withchar arr = "abc"; size_t arr_sz = sizeof arr;the identifierarrnot only refers to an array, it does not decay to a pointer in thesizeofexpression.
– David Bowling
Nov 25 at 23:17
you are right. I wanted to say that the "name of an array" can be used as its address, not that an array is (only) the address.
– XsOuLp
Dec 4 at 18:47
add a comment |
in C the name of an array is also its address (points to the beginning of the array).
answered Nov 25 at 21:47
XsOuLp
314
in C the name of an array is also its address (points to the beginning of the array).
answered Nov 25 at 21:47
XsOuLp
314
edited Nov 25 at 21:51
answered Nov 25 at 21:47
XsOuLp
314
answered Nov 25 at 21:47
XsOuLp
314
answered Nov 25 at 21:47
XsOuLp
314
314
This isn't true. Arrays are objects in C (in the C sense), and array identifiers refer to array objects. Arrays do decay to pointers to their first elements in most expressions (but not in all expressions). In particular, withchar arr = "abc"; size_t arr_sz = sizeof arr;the identifierarrnot only refers to an array, it does not decay to a pointer in thesizeofexpression.
– David Bowling
Nov 25 at 23:17
you are right. I wanted to say that the "name of an array" can be used as its address, not that an array is (only) the address.
– XsOuLp
Dec 4 at 18:47
add a comment |
This isn't true. Arrays are objects in C (in the C sense), and array identifiers refer to array objects. Arrays do decay to pointers to their first elements in most expressions (but not in all expressions). In particular, withchar arr = "abc"; size_t arr_sz = sizeof arr;the identifierarrnot only refers to an array, it does not decay to a pointer in thesizeofexpression.
– David Bowling
Nov 25 at 23:17
you are right. I wanted to say that the "name of an array" can be used as its address, not that an array is (only) the address.
– XsOuLp
Dec 4 at 18:47
This isn't true. Arrays are objects in C (in the C sense), and array identifiers refer to array objects. Arrays do decay to pointers to their first elements in most expressions (but not in all expressions). In particular, with
char arr = "abc"; size_t arr_sz = sizeof arr; the identifier arr not only refers to an array, it does not decay to a pointer in the sizeof expression.– David Bowling
Nov 25 at 23:17
This isn't true. Arrays are objects in C (in the C sense), and array identifiers refer to array objects. Arrays do decay to pointers to their first elements in most expressions (but not in all expressions). In particular, with
char arr = "abc"; size_t arr_sz = sizeof arr; the identifier arr not only refers to an array, it does not decay to a pointer in the sizeof expression.– David Bowling
Nov 25 at 23:17
you are right. I wanted to say that the "name of an array" can be used as its address, not that an array is (only) the address.
– XsOuLp
Dec 4 at 18:47
you are right. I wanted to say that the "name of an array" can be used as its address, not that an array is (only) the address.
– XsOuLp
Dec 4 at 18:47
add a comment |
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.
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%2f53472293%2fcan-it-cause-problems-to-pass-the-address-to-an-array-instead-of-the-array%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
