What happens if I use “&” with string in scanf function?










4















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;










share|improve this question



















  • 1





    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
















4















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;










share|improve this question



















  • 1





    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














4












4








4








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;










share|improve this question
















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






share|improve this question















share|improve this question













share|improve this question




share|improve this question








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. Use scanf("%1s", T); here.

    – chux
    Nov 16 '18 at 6:25













  • 1





    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








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













2 Answers
2






active

oldest

votes


















3














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





share|improve this answer






























    4














    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.






    share|improve this answer




















    • 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 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





      @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





      @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











    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
    );



    );













    draft saved

    draft discarded


















    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









    3














    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





    share|improve this answer



























      3














      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





      share|improve this answer

























        3












        3








        3







        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





        share|improve this answer













        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






        share|improve this answer












        share|improve this answer



        share|improve this answer










        answered Nov 16 '18 at 8:08









        GillesGilles

        76.2k19164206




        76.2k19164206























            4














            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.






            share|improve this answer




















            • 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 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





              @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





              @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
















            4














            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.






            share|improve this answer




















            • 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 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





              @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





              @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














            4












            4








            4







            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.






            share|improve this answer















            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.







            share|improve this answer














            share|improve this answer



            share|improve this answer








            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 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





              @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





              @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





              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 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





              @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





              @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


















            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.




            draft saved


            draft discarded














            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





















































            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







            Popular posts from this blog

            Top Tejano songwriter Luis Silva dead of heart attack at 64

            政党

            ReactJS Fetched API data displays live - need Data displayed static