What happens if I use “&” with string in scanf function?
I just saw some code in a blog.
It used
scanf("%s",&T);
but as we know, we shouldn't use ampersand with a string because it automatically assigns the first address of that string. I did run that code, and surprisingly it is working, so I want to know what happens when I use &
in string?
#include <stdio.h>
int main()
double a=0.0, M[12][12];
char T[2];
int C,x,y;
scanf("%d", &C);
scanf("%s", &T);
for(x=0;x<=11;x++)
for(y=0; y<=11; y++)
scanf("%lf", &M[x][y]);
if(x==C)
a+=M[x][y];
if(T[0]=='S')
printf("%.1lfn",a);
else if(T[0]=='M')
a=a/12.0;
printf("%.1lfn",a);
return 0;
c string scanf
add a comment |
I just saw some code in a blog.
It used
scanf("%s",&T);
but as we know, we shouldn't use ampersand with a string because it automatically assigns the first address of that string. I did run that code, and surprisingly it is working, so I want to know what happens when I use &
in string?
#include <stdio.h>
int main()
double a=0.0, M[12][12];
char T[2];
int C,x,y;
scanf("%d", &C);
scanf("%s", &T);
for(x=0;x<=11;x++)
for(y=0; y<=11; y++)
scanf("%lf", &M[x][y]);
if(x==C)
a+=M[x][y];
if(T[0]=='S')
printf("%.1lfn",a);
else if(T[0]=='M')
a=a/12.0;
printf("%.1lfn",a);
return 0;
c string scanf
1
Add that code sample here please.
– Azeem
Nov 16 '18 at 5:59
scanf("%s", &T);
has a bigger problem: no width limit. Usescanf("%1s", T);
here.
– chux
Nov 16 '18 at 6:25
add a comment |
I just saw some code in a blog.
It used
scanf("%s",&T);
but as we know, we shouldn't use ampersand with a string because it automatically assigns the first address of that string. I did run that code, and surprisingly it is working, so I want to know what happens when I use &
in string?
#include <stdio.h>
int main()
double a=0.0, M[12][12];
char T[2];
int C,x,y;
scanf("%d", &C);
scanf("%s", &T);
for(x=0;x<=11;x++)
for(y=0; y<=11; y++)
scanf("%lf", &M[x][y]);
if(x==C)
a+=M[x][y];
if(T[0]=='S')
printf("%.1lfn",a);
else if(T[0]=='M')
a=a/12.0;
printf("%.1lfn",a);
return 0;
c string scanf
I just saw some code in a blog.
It used
scanf("%s",&T);
but as we know, we shouldn't use ampersand with a string because it automatically assigns the first address of that string. I did run that code, and surprisingly it is working, so I want to know what happens when I use &
in string?
#include <stdio.h>
int main()
double a=0.0, M[12][12];
char T[2];
int C,x,y;
scanf("%d", &C);
scanf("%s", &T);
for(x=0;x<=11;x++)
for(y=0; y<=11; y++)
scanf("%lf", &M[x][y]);
if(x==C)
a+=M[x][y];
if(T[0]=='S')
printf("%.1lfn",a);
else if(T[0]=='M')
a=a/12.0;
printf("%.1lfn",a);
return 0;
c string scanf
c string scanf
edited Nov 16 '18 at 6:40
Sourav Ghosh
111k15132191
111k15132191
asked Nov 16 '18 at 5:54
mahin hossenmahin hossen
958
958
1
Add that code sample here please.
– Azeem
Nov 16 '18 at 5:59
scanf("%s", &T);
has a bigger problem: no width limit. Usescanf("%1s", T);
here.
– chux
Nov 16 '18 at 6:25
add a comment |
1
Add that code sample here please.
– Azeem
Nov 16 '18 at 5:59
scanf("%s", &T);
has a bigger problem: no width limit. Usescanf("%1s", T);
here.
– chux
Nov 16 '18 at 6:25
1
1
Add that code sample here please.
– Azeem
Nov 16 '18 at 5:59
Add that code sample here please.
– Azeem
Nov 16 '18 at 5:59
scanf("%s", &T);
has a bigger problem: no width limit. Use scanf("%1s", T);
here.– chux
Nov 16 '18 at 6:25
scanf("%s", &T);
has a bigger problem: no width limit. Use scanf("%1s", T);
here.– chux
Nov 16 '18 at 6:25
add a comment |
2 Answers
2
active
oldest
votes
The relevant part of the code snippet is:
char T[2];
scanf("%s", &T);
&T
is a pointer to the array of two characters (char (*)[2]
). This is not the type that scanf
needs for a %s
specifier: it needs a pointer to a character (char *
). So the behavior of the program is undefined.
The correct way to write this program, as you know, is
char T[2];
scanf("%s", T);
Since T
is an array, when it is used in most contexts, it “decays” to a pointer to the first character: T
is equivalent to &(T[0])
which has the type char *
. This decay does not happen when you take the address of the array (&T
) or its size (sizeof(T)
).
In practice, almost all platforms use the same representation for all pointers to the same address. So the compiler generates exactly the same code for T
and &T
. There are some rare platforms that may generate different code (I've heard of them but I couldn't name one). Some platforms use different encodings for “byte pointers” and “word pointers”, because their processor natively addresses words, not bytes. On such platforms, an int *
and a char *
that point to the same address have different encodings. A cast between those types converts the value, but misuse in something like a variable argument list would result in the wrong address. I would expect such platforms to use byte addresses for a char array, however. There are also rare platforms where a pointer encodes not only the address of the data, but also some type or size information. However, on such platforms, the type and size information would have to be equivalent: it's a block of 2 bytes, starting at the address of T
, and addressable byte by byte. So this particular mistake is unlikely to have any practical impact.
Note that it would be completely different if you had a pointer instead of an array in the first place:
char *T; // known to point to an array of two characters
scanf("%s", &T); // bad
Here &T
is a pointer to the location in memory that contains the address of the character array. So scanf
would write the characters that it reads at the location where the pointer T
is stored in memory, not at the location that T
points to. Most compilers analyze the format string of functions like printf
and scanf
and so would emit an error message.
Note that char T[2]
only has room for two characters, and this includes the null byte at the end of the string. So scanf("%s", T)
only has room to read a single character. If the input contains more than one non-whitespace character at this point, the program will overflow the buffer. To read a single character and make it a one-character string, use
char T[2];
scanf("%c", T);
T[1] = 0;
Unlike scanf("%s", T)
, this reads any character, even whitespace. To read a string with a length limit, add a limit to the %s
specification. You should never use an unlimited %s
in scanf
since this will read as much input as is available, regardless of how much room there is to store this input in memory.
char T[2];
scanf("%1s", T); // one less than the array size
add a comment |
Technically speaking, this is a type mismatch, leading to undefined behavior. For scanning a string, the expected argument is a pointer to the initial element of a character array.
When you have an array t
of type char[somevalue]
, when you say
scanf("%s",t);
t
decays to a pointer to the first element, so that is OK.
On the other hand, when you say &t
, it is of type char (*)[somevalue]
- pointer to an array, the whole array, not the pointer to the the initial element of the array.
Now, since the address of the array and the address of the first element of the array are same (memory location), so, writing the scanned value to the supplied address may not lead to any problem and work as intended - but this is neither defined nor recommended.
3
While technically a type mismatch, has there ever been a platform or do you think there will likely ever be a platform where the two pointers could differ? Do any of the C standards ever allow them to differ?
– Mad Physicist
Nov 16 '18 at 6:08
3
@MadPhysicist C allows the pointer to achar*
and a pointer tochar
to differ in size, layout, passing conventions, etc. Technically it is UB, but rarely a big issue. Competent compilers will warn.
– chux
Nov 16 '18 at 6:23
1
@chux. Just to clarify (because I never seem to get this right), the pointer to the array is always going to be equivalent to achar *
pointer?
– Mad Physicist
Nov 16 '18 at 6:29
1
@MadPhysicist They differ in type - and they are not compatible. For example, try pointer arithmetic on both the pointers.
– Sourav Ghosh
Nov 16 '18 at 6:30
1
@Mad Physicist: An artificial platform designed specifically for this sort of stress-testing of C code might deliberately adopt different object representations for these two pointer types. This is allowed by the language specification.
– AnT
Nov 16 '18 at 6:54
|
show 2 more comments
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%2f53332187%2fwhat-happens-if-i-use-with-string-in-scanf-function%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
The relevant part of the code snippet is:
char T[2];
scanf("%s", &T);
&T
is a pointer to the array of two characters (char (*)[2]
). This is not the type that scanf
needs for a %s
specifier: it needs a pointer to a character (char *
). So the behavior of the program is undefined.
The correct way to write this program, as you know, is
char T[2];
scanf("%s", T);
Since T
is an array, when it is used in most contexts, it “decays” to a pointer to the first character: T
is equivalent to &(T[0])
which has the type char *
. This decay does not happen when you take the address of the array (&T
) or its size (sizeof(T)
).
In practice, almost all platforms use the same representation for all pointers to the same address. So the compiler generates exactly the same code for T
and &T
. There are some rare platforms that may generate different code (I've heard of them but I couldn't name one). Some platforms use different encodings for “byte pointers” and “word pointers”, because their processor natively addresses words, not bytes. On such platforms, an int *
and a char *
that point to the same address have different encodings. A cast between those types converts the value, but misuse in something like a variable argument list would result in the wrong address. I would expect such platforms to use byte addresses for a char array, however. There are also rare platforms where a pointer encodes not only the address of the data, but also some type or size information. However, on such platforms, the type and size information would have to be equivalent: it's a block of 2 bytes, starting at the address of T
, and addressable byte by byte. So this particular mistake is unlikely to have any practical impact.
Note that it would be completely different if you had a pointer instead of an array in the first place:
char *T; // known to point to an array of two characters
scanf("%s", &T); // bad
Here &T
is a pointer to the location in memory that contains the address of the character array. So scanf
would write the characters that it reads at the location where the pointer T
is stored in memory, not at the location that T
points to. Most compilers analyze the format string of functions like printf
and scanf
and so would emit an error message.
Note that char T[2]
only has room for two characters, and this includes the null byte at the end of the string. So scanf("%s", T)
only has room to read a single character. If the input contains more than one non-whitespace character at this point, the program will overflow the buffer. To read a single character and make it a one-character string, use
char T[2];
scanf("%c", T);
T[1] = 0;
Unlike scanf("%s", T)
, this reads any character, even whitespace. To read a string with a length limit, add a limit to the %s
specification. You should never use an unlimited %s
in scanf
since this will read as much input as is available, regardless of how much room there is to store this input in memory.
char T[2];
scanf("%1s", T); // one less than the array size
add a comment |
The relevant part of the code snippet is:
char T[2];
scanf("%s", &T);
&T
is a pointer to the array of two characters (char (*)[2]
). This is not the type that scanf
needs for a %s
specifier: it needs a pointer to a character (char *
). So the behavior of the program is undefined.
The correct way to write this program, as you know, is
char T[2];
scanf("%s", T);
Since T
is an array, when it is used in most contexts, it “decays” to a pointer to the first character: T
is equivalent to &(T[0])
which has the type char *
. This decay does not happen when you take the address of the array (&T
) or its size (sizeof(T)
).
In practice, almost all platforms use the same representation for all pointers to the same address. So the compiler generates exactly the same code for T
and &T
. There are some rare platforms that may generate different code (I've heard of them but I couldn't name one). Some platforms use different encodings for “byte pointers” and “word pointers”, because their processor natively addresses words, not bytes. On such platforms, an int *
and a char *
that point to the same address have different encodings. A cast between those types converts the value, but misuse in something like a variable argument list would result in the wrong address. I would expect such platforms to use byte addresses for a char array, however. There are also rare platforms where a pointer encodes not only the address of the data, but also some type or size information. However, on such platforms, the type and size information would have to be equivalent: it's a block of 2 bytes, starting at the address of T
, and addressable byte by byte. So this particular mistake is unlikely to have any practical impact.
Note that it would be completely different if you had a pointer instead of an array in the first place:
char *T; // known to point to an array of two characters
scanf("%s", &T); // bad
Here &T
is a pointer to the location in memory that contains the address of the character array. So scanf
would write the characters that it reads at the location where the pointer T
is stored in memory, not at the location that T
points to. Most compilers analyze the format string of functions like printf
and scanf
and so would emit an error message.
Note that char T[2]
only has room for two characters, and this includes the null byte at the end of the string. So scanf("%s", T)
only has room to read a single character. If the input contains more than one non-whitespace character at this point, the program will overflow the buffer. To read a single character and make it a one-character string, use
char T[2];
scanf("%c", T);
T[1] = 0;
Unlike scanf("%s", T)
, this reads any character, even whitespace. To read a string with a length limit, add a limit to the %s
specification. You should never use an unlimited %s
in scanf
since this will read as much input as is available, regardless of how much room there is to store this input in memory.
char T[2];
scanf("%1s", T); // one less than the array size
add a comment |
The relevant part of the code snippet is:
char T[2];
scanf("%s", &T);
&T
is a pointer to the array of two characters (char (*)[2]
). This is not the type that scanf
needs for a %s
specifier: it needs a pointer to a character (char *
). So the behavior of the program is undefined.
The correct way to write this program, as you know, is
char T[2];
scanf("%s", T);
Since T
is an array, when it is used in most contexts, it “decays” to a pointer to the first character: T
is equivalent to &(T[0])
which has the type char *
. This decay does not happen when you take the address of the array (&T
) or its size (sizeof(T)
).
In practice, almost all platforms use the same representation for all pointers to the same address. So the compiler generates exactly the same code for T
and &T
. There are some rare platforms that may generate different code (I've heard of them but I couldn't name one). Some platforms use different encodings for “byte pointers” and “word pointers”, because their processor natively addresses words, not bytes. On such platforms, an int *
and a char *
that point to the same address have different encodings. A cast between those types converts the value, but misuse in something like a variable argument list would result in the wrong address. I would expect such platforms to use byte addresses for a char array, however. There are also rare platforms where a pointer encodes not only the address of the data, but also some type or size information. However, on such platforms, the type and size information would have to be equivalent: it's a block of 2 bytes, starting at the address of T
, and addressable byte by byte. So this particular mistake is unlikely to have any practical impact.
Note that it would be completely different if you had a pointer instead of an array in the first place:
char *T; // known to point to an array of two characters
scanf("%s", &T); // bad
Here &T
is a pointer to the location in memory that contains the address of the character array. So scanf
would write the characters that it reads at the location where the pointer T
is stored in memory, not at the location that T
points to. Most compilers analyze the format string of functions like printf
and scanf
and so would emit an error message.
Note that char T[2]
only has room for two characters, and this includes the null byte at the end of the string. So scanf("%s", T)
only has room to read a single character. If the input contains more than one non-whitespace character at this point, the program will overflow the buffer. To read a single character and make it a one-character string, use
char T[2];
scanf("%c", T);
T[1] = 0;
Unlike scanf("%s", T)
, this reads any character, even whitespace. To read a string with a length limit, add a limit to the %s
specification. You should never use an unlimited %s
in scanf
since this will read as much input as is available, regardless of how much room there is to store this input in memory.
char T[2];
scanf("%1s", T); // one less than the array size
The relevant part of the code snippet is:
char T[2];
scanf("%s", &T);
&T
is a pointer to the array of two characters (char (*)[2]
). This is not the type that scanf
needs for a %s
specifier: it needs a pointer to a character (char *
). So the behavior of the program is undefined.
The correct way to write this program, as you know, is
char T[2];
scanf("%s", T);
Since T
is an array, when it is used in most contexts, it “decays” to a pointer to the first character: T
is equivalent to &(T[0])
which has the type char *
. This decay does not happen when you take the address of the array (&T
) or its size (sizeof(T)
).
In practice, almost all platforms use the same representation for all pointers to the same address. So the compiler generates exactly the same code for T
and &T
. There are some rare platforms that may generate different code (I've heard of them but I couldn't name one). Some platforms use different encodings for “byte pointers” and “word pointers”, because their processor natively addresses words, not bytes. On such platforms, an int *
and a char *
that point to the same address have different encodings. A cast between those types converts the value, but misuse in something like a variable argument list would result in the wrong address. I would expect such platforms to use byte addresses for a char array, however. There are also rare platforms where a pointer encodes not only the address of the data, but also some type or size information. However, on such platforms, the type and size information would have to be equivalent: it's a block of 2 bytes, starting at the address of T
, and addressable byte by byte. So this particular mistake is unlikely to have any practical impact.
Note that it would be completely different if you had a pointer instead of an array in the first place:
char *T; // known to point to an array of two characters
scanf("%s", &T); // bad
Here &T
is a pointer to the location in memory that contains the address of the character array. So scanf
would write the characters that it reads at the location where the pointer T
is stored in memory, not at the location that T
points to. Most compilers analyze the format string of functions like printf
and scanf
and so would emit an error message.
Note that char T[2]
only has room for two characters, and this includes the null byte at the end of the string. So scanf("%s", T)
only has room to read a single character. If the input contains more than one non-whitespace character at this point, the program will overflow the buffer. To read a single character and make it a one-character string, use
char T[2];
scanf("%c", T);
T[1] = 0;
Unlike scanf("%s", T)
, this reads any character, even whitespace. To read a string with a length limit, add a limit to the %s
specification. You should never use an unlimited %s
in scanf
since this will read as much input as is available, regardless of how much room there is to store this input in memory.
char T[2];
scanf("%1s", T); // one less than the array size
answered Nov 16 '18 at 8:08
GillesGilles
76.2k19164206
76.2k19164206
add a comment |
add a comment |
Technically speaking, this is a type mismatch, leading to undefined behavior. For scanning a string, the expected argument is a pointer to the initial element of a character array.
When you have an array t
of type char[somevalue]
, when you say
scanf("%s",t);
t
decays to a pointer to the first element, so that is OK.
On the other hand, when you say &t
, it is of type char (*)[somevalue]
- pointer to an array, the whole array, not the pointer to the the initial element of the array.
Now, since the address of the array and the address of the first element of the array are same (memory location), so, writing the scanned value to the supplied address may not lead to any problem and work as intended - but this is neither defined nor recommended.
3
While technically a type mismatch, has there ever been a platform or do you think there will likely ever be a platform where the two pointers could differ? Do any of the C standards ever allow them to differ?
– Mad Physicist
Nov 16 '18 at 6:08
3
@MadPhysicist C allows the pointer to achar*
and a pointer tochar
to differ in size, layout, passing conventions, etc. Technically it is UB, but rarely a big issue. Competent compilers will warn.
– chux
Nov 16 '18 at 6:23
1
@chux. Just to clarify (because I never seem to get this right), the pointer to the array is always going to be equivalent to achar *
pointer?
– Mad Physicist
Nov 16 '18 at 6:29
1
@MadPhysicist They differ in type - and they are not compatible. For example, try pointer arithmetic on both the pointers.
– Sourav Ghosh
Nov 16 '18 at 6:30
1
@Mad Physicist: An artificial platform designed specifically for this sort of stress-testing of C code might deliberately adopt different object representations for these two pointer types. This is allowed by the language specification.
– AnT
Nov 16 '18 at 6:54
|
show 2 more comments
Technically speaking, this is a type mismatch, leading to undefined behavior. For scanning a string, the expected argument is a pointer to the initial element of a character array.
When you have an array t
of type char[somevalue]
, when you say
scanf("%s",t);
t
decays to a pointer to the first element, so that is OK.
On the other hand, when you say &t
, it is of type char (*)[somevalue]
- pointer to an array, the whole array, not the pointer to the the initial element of the array.
Now, since the address of the array and the address of the first element of the array are same (memory location), so, writing the scanned value to the supplied address may not lead to any problem and work as intended - but this is neither defined nor recommended.
3
While technically a type mismatch, has there ever been a platform or do you think there will likely ever be a platform where the two pointers could differ? Do any of the C standards ever allow them to differ?
– Mad Physicist
Nov 16 '18 at 6:08
3
@MadPhysicist C allows the pointer to achar*
and a pointer tochar
to differ in size, layout, passing conventions, etc. Technically it is UB, but rarely a big issue. Competent compilers will warn.
– chux
Nov 16 '18 at 6:23
1
@chux. Just to clarify (because I never seem to get this right), the pointer to the array is always going to be equivalent to achar *
pointer?
– Mad Physicist
Nov 16 '18 at 6:29
1
@MadPhysicist They differ in type - and they are not compatible. For example, try pointer arithmetic on both the pointers.
– Sourav Ghosh
Nov 16 '18 at 6:30
1
@Mad Physicist: An artificial platform designed specifically for this sort of stress-testing of C code might deliberately adopt different object representations for these two pointer types. This is allowed by the language specification.
– AnT
Nov 16 '18 at 6:54
|
show 2 more comments
Technically speaking, this is a type mismatch, leading to undefined behavior. For scanning a string, the expected argument is a pointer to the initial element of a character array.
When you have an array t
of type char[somevalue]
, when you say
scanf("%s",t);
t
decays to a pointer to the first element, so that is OK.
On the other hand, when you say &t
, it is of type char (*)[somevalue]
- pointer to an array, the whole array, not the pointer to the the initial element of the array.
Now, since the address of the array and the address of the first element of the array are same (memory location), so, writing the scanned value to the supplied address may not lead to any problem and work as intended - but this is neither defined nor recommended.
Technically speaking, this is a type mismatch, leading to undefined behavior. For scanning a string, the expected argument is a pointer to the initial element of a character array.
When you have an array t
of type char[somevalue]
, when you say
scanf("%s",t);
t
decays to a pointer to the first element, so that is OK.
On the other hand, when you say &t
, it is of type char (*)[somevalue]
- pointer to an array, the whole array, not the pointer to the the initial element of the array.
Now, since the address of the array and the address of the first element of the array are same (memory location), so, writing the scanned value to the supplied address may not lead to any problem and work as intended - but this is neither defined nor recommended.
edited Nov 16 '18 at 6:55
answered Nov 16 '18 at 6:01
Sourav GhoshSourav Ghosh
111k15132191
111k15132191
3
While technically a type mismatch, has there ever been a platform or do you think there will likely ever be a platform where the two pointers could differ? Do any of the C standards ever allow them to differ?
– Mad Physicist
Nov 16 '18 at 6:08
3
@MadPhysicist C allows the pointer to achar*
and a pointer tochar
to differ in size, layout, passing conventions, etc. Technically it is UB, but rarely a big issue. Competent compilers will warn.
– chux
Nov 16 '18 at 6:23
1
@chux. Just to clarify (because I never seem to get this right), the pointer to the array is always going to be equivalent to achar *
pointer?
– Mad Physicist
Nov 16 '18 at 6:29
1
@MadPhysicist They differ in type - and they are not compatible. For example, try pointer arithmetic on both the pointers.
– Sourav Ghosh
Nov 16 '18 at 6:30
1
@Mad Physicist: An artificial platform designed specifically for this sort of stress-testing of C code might deliberately adopt different object representations for these two pointer types. This is allowed by the language specification.
– AnT
Nov 16 '18 at 6:54
|
show 2 more comments
3
While technically a type mismatch, has there ever been a platform or do you think there will likely ever be a platform where the two pointers could differ? Do any of the C standards ever allow them to differ?
– Mad Physicist
Nov 16 '18 at 6:08
3
@MadPhysicist C allows the pointer to achar*
and a pointer tochar
to differ in size, layout, passing conventions, etc. Technically it is UB, but rarely a big issue. Competent compilers will warn.
– chux
Nov 16 '18 at 6:23
1
@chux. Just to clarify (because I never seem to get this right), the pointer to the array is always going to be equivalent to achar *
pointer?
– Mad Physicist
Nov 16 '18 at 6:29
1
@MadPhysicist They differ in type - and they are not compatible. For example, try pointer arithmetic on both the pointers.
– Sourav Ghosh
Nov 16 '18 at 6:30
1
@Mad Physicist: An artificial platform designed specifically for this sort of stress-testing of C code might deliberately adopt different object representations for these two pointer types. This is allowed by the language specification.
– AnT
Nov 16 '18 at 6:54
3
3
While technically a type mismatch, has there ever been a platform or do you think there will likely ever be a platform where the two pointers could differ? Do any of the C standards ever allow them to differ?
– Mad Physicist
Nov 16 '18 at 6:08
While technically a type mismatch, has there ever been a platform or do you think there will likely ever be a platform where the two pointers could differ? Do any of the C standards ever allow them to differ?
– Mad Physicist
Nov 16 '18 at 6:08
3
3
@MadPhysicist C allows the pointer to a
char*
and a pointer to char
to differ in size, layout, passing conventions, etc. Technically it is UB, but rarely a big issue. Competent compilers will warn.– chux
Nov 16 '18 at 6:23
@MadPhysicist C allows the pointer to a
char*
and a pointer to char
to differ in size, layout, passing conventions, etc. Technically it is UB, but rarely a big issue. Competent compilers will warn.– chux
Nov 16 '18 at 6:23
1
1
@chux. Just to clarify (because I never seem to get this right), the pointer to the array is always going to be equivalent to a
char *
pointer?– Mad Physicist
Nov 16 '18 at 6:29
@chux. Just to clarify (because I never seem to get this right), the pointer to the array is always going to be equivalent to a
char *
pointer?– Mad Physicist
Nov 16 '18 at 6:29
1
1
@MadPhysicist They differ in type - and they are not compatible. For example, try pointer arithmetic on both the pointers.
– Sourav Ghosh
Nov 16 '18 at 6:30
@MadPhysicist They differ in type - and they are not compatible. For example, try pointer arithmetic on both the pointers.
– Sourav Ghosh
Nov 16 '18 at 6:30
1
1
@Mad Physicist: An artificial platform designed specifically for this sort of stress-testing of C code might deliberately adopt different object representations for these two pointer types. This is allowed by the language specification.
– AnT
Nov 16 '18 at 6:54
@Mad Physicist: An artificial platform designed specifically for this sort of stress-testing of C code might deliberately adopt different object representations for these two pointer types. This is allowed by the language specification.
– AnT
Nov 16 '18 at 6:54
|
show 2 more comments
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.
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%2f53332187%2fwhat-happens-if-i-use-with-string-in-scanf-function%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
1
Add that code sample here please.
– Azeem
Nov 16 '18 at 5:59
scanf("%s", &T);
has a bigger problem: no width limit. Usescanf("%1s", T);
here.– chux
Nov 16 '18 at 6:25