Can it cause problems to pass the address to an array instead of the array?











up vote
6
down vote

favorite












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)










share|improve this question


























    up vote
    6
    down vote

    favorite












    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)










    share|improve this question
























      up vote
      6
      down vote

      favorite









      up vote
      6
      down vote

      favorite











      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)










      share|improve this question













      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






      share|improve this question













      share|improve this question











      share|improve this question




      share|improve this question










      asked 5 hours ago









      Broman

      6,068102241




      6,068102241
























          3 Answers
          3






          active

          oldest

          votes

















          up vote
          4
          down vote













          Yes, the code is undefined behaviour. The argument corresponding to %s must have exactly the type char *.



          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.






          share|improve this answer























          • 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
            4 hours ago












          • @AndrewHenle Nice catch. I was to quick there.
            – Broman
            3 hours ago










          • @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
            3 hours ago










          • 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
            3 hours ago










          • @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
            3 hours ago


















          up vote
          2
          down vote













          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.






          share|improve this answer










          New contributor




          Paul is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
          Check out our Code of Conduct.


















          • 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
            4 hours ago










          • @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
            4 hours ago










          • @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
            4 hours ago










          • 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
            3 hours ago






          • 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
            3 hours ago


















          up vote
          -1
          down vote













          in C the name of an array is also its address (points to the beginning of the array).






          share|improve this answer










          New contributor




          XsOuLp is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
          Check out our Code of Conduct.














          • 1




            In the question, str is char[600] and &str is char (*)[600] (the latter is mentioned in the warning message).
            – anatolyg
            5 hours ago










          • 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
            4 hours ago











          Your Answer






          StackExchange.ifUsing("editor", function () {
          StackExchange.using("externalEditor", function () {
          StackExchange.using("snippets", function () {
          StackExchange.snippets.init();
          });
          });
          }, "code-snippets");

          StackExchange.ready(function() {
          var channelOptions = {
          tags: "".split(" "),
          id: "1"
          };
          initTagRenderer("".split(" "), "".split(" "), channelOptions);

          StackExchange.using("externalEditor", function() {
          // Have to fire editor after snippets, if snippets enabled
          if (StackExchange.settings.snippets.snippetsEnabled) {
          StackExchange.using("snippets", function() {
          createEditor();
          });
          }
          else {
          createEditor();
          }
          });

          function createEditor() {
          StackExchange.prepareEditor({
          heartbeatType: 'answer',
          convertImagesToLinks: true,
          noModals: true,
          showLowRepImageUploadWarning: true,
          reputationToPostImages: 10,
          bindNavPrevention: true,
          postfix: "",
          imageUploader: {
          brandingHtml: "Powered by u003ca class="icon-imgur-white" href="https://imgur.com/"u003eu003c/au003e",
          contentPolicyHtml: "User contributions licensed under u003ca href="https://creativecommons.org/licenses/by-sa/3.0/"u003ecc by-sa 3.0 with attribution requiredu003c/au003e u003ca href="https://stackoverflow.com/legal/content-policy"u003e(content policy)u003c/au003e",
          allowUrls: true
          },
          onDemand: true,
          discardSelector: ".discard-answer"
          ,immediatelyShowMarkdownHelp:true
          });


          }
          });














           

          draft saved


          draft discarded


















          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








          up vote
          4
          down vote













          Yes, the code is undefined behaviour. The argument corresponding to %s must have exactly the type char *.



          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.






          share|improve this answer























          • 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
            4 hours ago












          • @AndrewHenle Nice catch. I was to quick there.
            – Broman
            3 hours ago










          • @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
            3 hours ago










          • 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
            3 hours ago










          • @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
            3 hours ago















          up vote
          4
          down vote













          Yes, the code is undefined behaviour. The argument corresponding to %s must have exactly the type char *.



          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.






          share|improve this answer























          • 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
            4 hours ago












          • @AndrewHenle Nice catch. I was to quick there.
            – Broman
            3 hours ago










          • @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
            3 hours ago










          • 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
            3 hours ago










          • @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
            3 hours ago













          up vote
          4
          down vote










          up vote
          4
          down vote









          Yes, the code is undefined behaviour. The argument corresponding to %s must have exactly the type char *.



          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.






          share|improve this answer














          Yes, the code is undefined behaviour. The argument corresponding to %s must have exactly the type char *.



          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.







          share|improve this answer














          share|improve this answer



          share|improve this answer








          edited 3 hours ago









          Broman

          6,068102241




          6,068102241










          answered 4 hours ago









          M.M

          103k11108229




          103k11108229












          • 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
            4 hours ago












          • @AndrewHenle Nice catch. I was to quick there.
            – Broman
            3 hours ago










          • @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
            3 hours ago










          • 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
            3 hours ago










          • @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
            3 hours ago


















          • 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
            4 hours ago












          • @AndrewHenle Nice catch. I was to quick there.
            – Broman
            3 hours ago










          • @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
            3 hours ago










          • 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
            3 hours ago










          • @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
            3 hours ago
















          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
          4 hours ago






          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
          4 hours ago














          @AndrewHenle Nice catch. I was to quick there.
          – Broman
          3 hours ago




          @AndrewHenle Nice catch. I was to quick there.
          – Broman
          3 hours ago












          @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
          3 hours ago




          @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
          3 hours ago












          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
          3 hours ago




          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
          3 hours ago












          @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
          3 hours ago




          @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
          3 hours ago












          up vote
          2
          down vote













          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.






          share|improve this answer










          New contributor




          Paul is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
          Check out our Code of Conduct.


















          • 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
            4 hours ago










          • @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
            4 hours ago










          • @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
            4 hours ago










          • 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
            3 hours ago






          • 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
            3 hours ago















          up vote
          2
          down vote













          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.






          share|improve this answer










          New contributor




          Paul is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
          Check out our Code of Conduct.


















          • 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
            4 hours ago










          • @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
            4 hours ago










          • @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
            4 hours ago










          • 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
            3 hours ago






          • 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
            3 hours ago













          up vote
          2
          down vote










          up vote
          2
          down vote









          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.






          share|improve this answer










          New contributor




          Paul is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
          Check out our Code of Conduct.









          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.







          share|improve this answer










          New contributor




          Paul is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
          Check out our Code of Conduct.









          share|improve this answer



          share|improve this answer








          edited 3 hours ago





















          New contributor




          Paul is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
          Check out our Code of Conduct.









          answered 5 hours ago









          Paul

          3206




          3206




          New contributor




          Paul is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
          Check out our Code of Conduct.





          New contributor





          Paul is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
          Check out our Code of Conduct.






          Paul is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
          Check out our Code of Conduct.












          • 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
            4 hours ago










          • @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
            4 hours ago










          • @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
            4 hours ago










          • 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
            3 hours ago






          • 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
            3 hours ago


















          • 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
            4 hours ago










          • @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
            4 hours ago










          • @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
            4 hours ago










          • 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
            3 hours ago






          • 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
            3 hours ago
















          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
          4 hours ago




          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
          4 hours ago












          @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
          4 hours ago




          @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
          4 hours ago












          @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
          4 hours ago




          @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
          4 hours ago












          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
          3 hours ago




          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
          3 hours ago




          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
          3 hours ago




          @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
          3 hours ago










          up vote
          -1
          down vote













          in C the name of an array is also its address (points to the beginning of the array).






          share|improve this answer










          New contributor




          XsOuLp is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
          Check out our Code of Conduct.














          • 1




            In the question, str is char[600] and &str is char (*)[600] (the latter is mentioned in the warning message).
            – anatolyg
            5 hours ago










          • 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
            4 hours ago















          up vote
          -1
          down vote













          in C the name of an array is also its address (points to the beginning of the array).






          share|improve this answer










          New contributor




          XsOuLp is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
          Check out our Code of Conduct.














          • 1




            In the question, str is char[600] and &str is char (*)[600] (the latter is mentioned in the warning message).
            – anatolyg
            5 hours ago










          • 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
            4 hours ago













          up vote
          -1
          down vote










          up vote
          -1
          down vote









          in C the name of an array is also its address (points to the beginning of the array).






          share|improve this answer










          New contributor




          XsOuLp is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
          Check out our Code of Conduct.









          in C the name of an array is also its address (points to the beginning of the array).







          share|improve this answer










          New contributor




          XsOuLp is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
          Check out our Code of Conduct.









          share|improve this answer



          share|improve this answer








          edited 5 hours ago





















          New contributor




          XsOuLp is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
          Check out our Code of Conduct.









          answered 5 hours ago









          XsOuLp

          194




          194




          New contributor




          XsOuLp is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
          Check out our Code of Conduct.





          New contributor





          XsOuLp is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
          Check out our Code of Conduct.






          XsOuLp is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
          Check out our Code of Conduct.








          • 1




            In the question, str is char[600] and &str is char (*)[600] (the latter is mentioned in the warning message).
            – anatolyg
            5 hours ago










          • 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
            4 hours ago














          • 1




            In the question, str is char[600] and &str is char (*)[600] (the latter is mentioned in the warning message).
            – anatolyg
            5 hours ago










          • 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
            4 hours ago








          1




          1




          In the question, str is char[600] and &str is char (*)[600] (the latter is mentioned in the warning message).
          – anatolyg
          5 hours ago




          In the question, str is char[600] and &str is char (*)[600] (the latter is mentioned in the warning message).
          – anatolyg
          5 hours ago












          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
          4 hours ago




          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
          4 hours ago


















           

          draft saved


          draft discarded



















































           


          draft saved


          draft discarded














          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





















































          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

          Costa Masnaga

          Fotorealismo

          Sidney Franklin