Skip to content
  • Categories
  • Recent
  • Tags
  • Popular
  • World
  • Users
  • Groups
Skins
  • Light
  • Cerulean
  • Cosmo
  • Flatly
  • Journal
  • Litera
  • Lumen
  • Lux
  • Materia
  • Minty
  • Morph
  • Pulse
  • Sandstone
  • Simplex
  • Sketchy
  • Spacelab
  • United
  • Yeti
  • Zephyr
  • Dark
  • Cyborg
  • Darkly
  • Quartz
  • Slate
  • Solar
  • Superhero
  • Vapor

  • Default (No Skin)
  • No Skin
Collapse
Code Project
  1. Home
  2. General Programming
  3. C / C++ / MFC
  4. Strange chars

Strange chars

Scheduled Pinned Locked Moved C / C++ / MFC
debuggingwindows-adminlinuxquestion
35 Posts 7 Posters 0 Views 1 Watching
  • Oldest to Newest
  • Newest to Oldest
  • Most Votes
Reply
  • Reply as topic
Log in to reply
This topic has been deleted. Only users with topic management privileges can see it.
  • _ _Flaviu

    #define DIR_NAME_LEN 2048

    struct dir_struct
    {
    void* display;
    char directory[DIR_NAME_LEN];
    ...
    ....

    I have followed the way of how this variable is handled:

    dir_struct_t dir_struct;

    TRACE(\_T("Directory - %s\\n"), dir\_struct.directory); -> \_CrtDbgReport: String too long or IO Error
    
    strncpy(dir\_struct->directory, "/", sizeof(dir\_struct->directory));	
    
    TRACE(\_T("Directory - %s\\n"), dir\_struct->directory);	-> /
    
    strcat(dir\_struct->directory, current\_file->name);
    
    TRACE(\_T("Directory - %s\\n"), dir\_struct->directory);	-> \_CrtDbgReport: String too long or IO Error
    

    And if I look into VS debugger when I got "_CrtDbgReport: String too long or IO Error" from TRACE macro, I see the following result: see image.[^] and Untitled2 — Postimage.org[^] The line strcat(dir_struct->directory, current_file->name); is not quite correct ? I mean, correct for Windows, even if is correct for Linux ...

    K Offline
    K Offline
    k5054
    wrote on last edited by
    #11

    You have actually identified your problem, you just haven't realized it.

    strncpy(dir_strut->directory, "/", sizeof(dir_struct_directory)); // here name is good
    strcat(dir_struct->directory, current_file->name); // here name is bad

    It would seem that current_file->name is not a null terminated C string. You have not given us the details of current_file, or how it is instantiated, so we can't further diagnose the problem at the moment. Perhaps current_file has a member that tells you how long the name member is, in which case you should use that and strncat to append the file name to the directory name.

    Keep Calm and Carry On

    _ 1 Reply Last reply
    0
    • L Lost User

      You are making a wrong assumption. The sizeof(dir_struct->directory) operator will return 2048. But what if the string in that table is less than that? You need an actual count of the number of valid characters in the directory field (assuming that it is correctly null terminated). You are also mixing the dot (.) and arrow (->) operators on your struct reference. But all this is largely irrelevant. You need to go back a stage to the code that fills the directory structure in the first place, as that is where the problem is most likely to be found.

      _ Offline
      _ Offline
      _Flaviu
      wrote on last edited by
      #12

      "You are also mixing the dot (.) and arrow (->) operators on your struct reference." Yes, you are right, I taken those lines of codes from different function (in one of them was reference, in other was pointer), that why those mixing are there.

      L 1 Reply Last reply
      0
      • _ _Flaviu

        "You are also mixing the dot (.) and arrow (->) operators on your struct reference." Yes, you are right, I taken those lines of codes from different function (in one of them was reference, in other was pointer), that why those mixing are there.

        L Offline
        L Offline
        Lost User
        wrote on last edited by
        #13

        Well you should not be doing so, since the reference in both cases is a structure, not a pointer. The dot operator is the correct one. But more importantly you have still not shown or explained when and where this structure gets initialised, and the directory name copied in. Until you give us that information anything we pass on is pure guesswork.

        1 Reply Last reply
        0
        • K k5054

          You have actually identified your problem, you just haven't realized it.

          strncpy(dir_strut->directory, "/", sizeof(dir_struct_directory)); // here name is good
          strcat(dir_struct->directory, current_file->name); // here name is bad

          It would seem that current_file->name is not a null terminated C string. You have not given us the details of current_file, or how it is instantiated, so we can't further diagnose the problem at the moment. Perhaps current_file has a member that tells you how long the name member is, in which case you should use that and strncat to append the file name to the directory name.

          Keep Calm and Carry On

          _ Offline
          _ Offline
          _Flaviu
          wrote on last edited by
          #14

          Yes, indeed, from this point strcat(dir_struct->current_directory, current_file->name);, my dir_struct.directory seem to go crazy. current_file->name is coming from:

          const file_info* current_file = AnotherFunction();

          and file_info is a struct defined like this:

          typedef struct
          {
          char* name;
          .....
          unsigned int status;
          }file_info;

          Here is the steps:

          strncpy(dir_struct->directory, "/", sizeof(dir_struct->directory));

          TRACE(_T("Directory - %s\n"), dir_struct->directory); -> Directory - /

          Untitled — Postimage.org[^]

          const file_info* current_file = AnotherFunction();

          TRACE("\n===>>>%s\n", current_file->name); ->===>>>Unbroken

          Untitled2 — Postimage.org[^]

          TRACE(_T("Directory - %s\n"), dir_struct->directory); -> _CrtDbgReport: String too long or IO Error

          Untitled — Postimage.org[^] Untitled — Postimage.org[^]

          V L 2 Replies Last reply
          0
          • _ _Flaviu

            Yes, indeed, from this point strcat(dir_struct->current_directory, current_file->name);, my dir_struct.directory seem to go crazy. current_file->name is coming from:

            const file_info* current_file = AnotherFunction();

            and file_info is a struct defined like this:

            typedef struct
            {
            char* name;
            .....
            unsigned int status;
            }file_info;

            Here is the steps:

            strncpy(dir_struct->directory, "/", sizeof(dir_struct->directory));

            TRACE(_T("Directory - %s\n"), dir_struct->directory); -> Directory - /

            Untitled — Postimage.org[^]

            const file_info* current_file = AnotherFunction();

            TRACE("\n===>>>%s\n", current_file->name); ->===>>>Unbroken

            Untitled2 — Postimage.org[^]

            TRACE(_T("Directory - %s\n"), dir_struct->directory); -> _CrtDbgReport: String too long or IO Error

            Untitled — Postimage.org[^] Untitled — Postimage.org[^]

            V Offline
            V Offline
            Victor Nijegorodov
            wrote on last edited by
            #15

            The AnotherFunction itself or the way you are using it seems to be a reason of your problem... :|

            _ 1 Reply Last reply
            0
            • _ _Flaviu

              Yes, indeed, from this point strcat(dir_struct->current_directory, current_file->name);, my dir_struct.directory seem to go crazy. current_file->name is coming from:

              const file_info* current_file = AnotherFunction();

              and file_info is a struct defined like this:

              typedef struct
              {
              char* name;
              .....
              unsigned int status;
              }file_info;

              Here is the steps:

              strncpy(dir_struct->directory, "/", sizeof(dir_struct->directory));

              TRACE(_T("Directory - %s\n"), dir_struct->directory); -> Directory - /

              Untitled — Postimage.org[^]

              const file_info* current_file = AnotherFunction();

              TRACE("\n===>>>%s\n", current_file->name); ->===>>>Unbroken

              Untitled2 — Postimage.org[^]

              TRACE(_T("Directory - %s\n"), dir_struct->directory); -> _CrtDbgReport: String too long or IO Error

              Untitled — Postimage.org[^] Untitled — Postimage.org[^]

              L Offline
              L Offline
              Lost User
              wrote on last edited by
              #16

              I have just tried to reproduce what you have done and the code works fine. I can only conclude that the code you are showing does not match what you are actually running. But since you have only shown small pieces and not the complete method where this occurs, it is difficult to say more.

              _ 1 Reply Last reply
              0
              • L Lost User

                I have just tried to reproduce what you have done and the code works fine. I can only conclude that the code you are showing does not match what you are actually running. But since you have only shown small pieces and not the complete method where this occurs, it is difficult to say more.

                _ Offline
                _ Offline
                _Flaviu
                wrote on last edited by
                #17

                I really, really would show the entire code because I am struggling of it, but unfortunately I cannot due to confidentiality issue. I'll try to write more code here.

                K L D 3 Replies Last reply
                0
                • _ _Flaviu

                  I really, really would show the entire code because I am struggling of it, but unfortunately I cannot due to confidentiality issue. I'll try to write more code here.

                  K Offline
                  K Offline
                  kalberts
                  wrote on last edited by
                  #18

                  What you need to display is the assignment to dir_struct.directory - nothing more. It may be as simple as a single statement (/line). I guess that confidentiality issues won't preclude that. How did you get hold of that value? Which system call or library function provided it? If you say "None, we built it from pieces ourselves, and that code is confidential", then you have got the answer: In that string building code you forgot to add the terminating nul. Otherwise: Tell us who provided the directory string, in which way.

                  _ 1 Reply Last reply
                  0
                  • _ _Flaviu

                    I really, really would show the entire code because I am struggling of it, but unfortunately I cannot due to confidentiality issue. I'll try to write more code here.

                    L Offline
                    L Offline
                    Lost User
                    wrote on last edited by
                    #19

                    I am sure that you can modify any confidential pieces so they do not reveal anything that they should not.

                    _ 1 Reply Last reply
                    0
                    • K kalberts

                      What you need to display is the assignment to dir_struct.directory - nothing more. It may be as simple as a single statement (/line). I guess that confidentiality issues won't preclude that. How did you get hold of that value? Which system call or library function provided it? If you say "None, we built it from pieces ourselves, and that code is confidential", then you have got the answer: In that string building code you forgot to add the terminating nul. Otherwise: Tell us who provided the directory string, in which way.

                      _ Offline
                      _ Offline
                      _Flaviu
                      wrote on last edited by
                      #20

                      No, this code is not written by us. I'll try to write here as much as I can. P.S. The buggy code is written in C for Linux, and I don't know C (I guess this is visible :D) P.S. I don't pretend to know C++ either :D ... only that I fight in this domain ....

                      1 Reply Last reply
                      0
                      • L Lost User

                        I am sure that you can modify any confidential pieces so they do not reveal anything that they should not.

                        _ Offline
                        _ Offline
                        _Flaviu
                        wrote on last edited by
                        #21

                        info* current = list_entry(walker, const info, list);
                        TRACE(_T("current->name %s\n"), current->name); -> _CrtDbgReport: String too long or IO Error

                        Why I got _CrtDbgReport: String too long or IO Error I wrote in my previous posts ...

                        L 1 Reply Last reply
                        0
                        • _ _Flaviu

                          info* current = list_entry(walker, const info, list);
                          TRACE(_T("current->name %s\n"), current->name); -> _CrtDbgReport: String too long or IO Error

                          Why I got _CrtDbgReport: String too long or IO Error I wrote in my previous posts ...

                          L Offline
                          L Offline
                          Lost User
                          wrote on last edited by
                          #22

                          I have managed to create a sample of all that code, although I find the #define list_entry_const somewhat difficult to deconstruct. However, with a valid name in the file_info entry it works fine. I can only assume that somewhere in the actual code that you are running there is some corruption of your data, or a pointer is not set up correctly. [edit] I also could not find the TRACE macro in Windows. [/edit]

                          D V 2 Replies Last reply
                          0
                          • _ _Flaviu

                            I really, really would show the entire code because I am struggling of it, but unfortunately I cannot due to confidentiality issue. I'll try to write more code here.

                            D Offline
                            D Offline
                            David Crow
                            wrote on last edited by
                            #23

                            Like they say in the movies, the names have been changed to protect the innocent.

                            "One man's wage rise is another man's price increase." - Harold Wilson

                            "Fireproof doesn't mean the fire will never come. It means when the fire comes that you will be able to withstand it." - Michael Simmons

                            "You can easily judge the character of a man by how he treats those who can do nothing for him." - James D. Miles

                            _ 1 Reply Last reply
                            0
                            • L Lost User

                              I have managed to create a sample of all that code, although I find the #define list_entry_const somewhat difficult to deconstruct. However, with a valid name in the file_info entry it works fine. I can only assume that somewhere in the actual code that you are running there is some corruption of your data, or a pointer is not set up correctly. [edit] I also could not find the TRACE macro in Windows. [/edit]

                              D Offline
                              D Offline
                              David Crow
                              wrote on last edited by
                              #24

                              Richard MacCutchan wrote:

                              I also could not find the TRACE macro in Windows.

                              Isn't that an MFC thing?

                              "One man's wage rise is another man's price increase." - Harold Wilson

                              "Fireproof doesn't mean the fire will never come. It means when the fire comes that you will be able to withstand it." - Michael Simmons

                              "You can easily judge the character of a man by how he treats those who can do nothing for him." - James D. Miles

                              L 1 Reply Last reply
                              0
                              • D David Crow

                                Richard MacCutchan wrote:

                                I also could not find the TRACE macro in Windows.

                                Isn't that an MFC thing?

                                "One man's wage rise is another man's price increase." - Harold Wilson

                                "Fireproof doesn't mean the fire will never come. It means when the fire comes that you will be able to withstand it." - Michael Simmons

                                "You can easily judge the character of a man by how he treats those who can do nothing for him." - James D. Miles

                                L Offline
                                L Offline
                                Lost User
                                wrote on last edited by
                                #25

                                Could be, but I haven't used MFC since about 2003, and I don't intend doing so ever again.

                                1 Reply Last reply
                                0
                                • L Lost User

                                  I have managed to create a sample of all that code, although I find the #define list_entry_const somewhat difficult to deconstruct. However, with a valid name in the file_info entry it works fine. I can only assume that somewhere in the actual code that you are running there is some corruption of your data, or a pointer is not set up correctly. [edit] I also could not find the TRACE macro in Windows. [/edit]

                                  V Offline
                                  V Offline
                                  Victor Nijegorodov
                                  wrote on last edited by
                                  #26

                                  Richard MacCutchan wrote:

                                  I also could not find the TRACE macro in Windows.

                                  After a lot of calls... it finishes calling _CrtDbgReportW

                                  L 1 Reply Last reply
                                  0
                                  • V Victor Nijegorodov

                                    Richard MacCutchan wrote:

                                    I also could not find the TRACE macro in Windows.

                                    After a lot of calls... it finishes calling _CrtDbgReportW

                                    L Offline
                                    L Offline
                                    Lost User
                                    wrote on last edited by
                                    #27

                                    It's an MFC* macro (as pointed out by David Crow above). *Yes, I know, that combination of letters should no more pass my lips.

                                    1 Reply Last reply
                                    0
                                    • D David Crow

                                      Like they say in the movies, the names have been changed to protect the innocent.

                                      "One man's wage rise is another man's price increase." - Harold Wilson

                                      "Fireproof doesn't mean the fire will never come. It means when the fire comes that you will be able to withstand it." - Michael Simmons

                                      "You can easily judge the character of a man by how he treats those who can do nothing for him." - James D. Miles

                                      _ Offline
                                      _ Offline
                                      _Flaviu
                                      wrote on last edited by
                                      #28

                                      :D

                                      1 Reply Last reply
                                      0
                                      • _ _Flaviu

                                        #define DIR_NAME_LEN 2048

                                        struct dir_struct
                                        {
                                        void* display;
                                        char directory[DIR_NAME_LEN];
                                        ...
                                        ....

                                        I have followed the way of how this variable is handled:

                                        dir_struct_t dir_struct;

                                        TRACE(\_T("Directory - %s\\n"), dir\_struct.directory); -> \_CrtDbgReport: String too long or IO Error
                                        
                                        strncpy(dir\_struct->directory, "/", sizeof(dir\_struct->directory));	
                                        
                                        TRACE(\_T("Directory - %s\\n"), dir\_struct->directory);	-> /
                                        
                                        strcat(dir\_struct->directory, current\_file->name);
                                        
                                        TRACE(\_T("Directory - %s\\n"), dir\_struct->directory);	-> \_CrtDbgReport: String too long or IO Error
                                        

                                        And if I look into VS debugger when I got "_CrtDbgReport: String too long or IO Error" from TRACE macro, I see the following result: see image.[^] and Untitled2 — Postimage.org[^] The line strcat(dir_struct->directory, current_file->name); is not quite correct ? I mean, correct for Windows, even if is correct for Linux ...

                                        K Offline
                                        K Offline
                                        kalberts
                                        wrote on last edited by
                                        #29

                                        I am really puzzled by how difficult it seem to be to explain how the value of that .directory was initialized. Where its value came from. How it was created. Obviously, whatever created the value did not follow the C convention of terminating it with a nul - most likely because it doesn't have a C origin. Fair enough. But why is it so difficult to show how the .directory value was obtained? As it now stands, it is like complaining "This variable should have av value between 0 and 100, but it is above 100. Why???" If you can't figure that out yourself, you must reveal how you calculate it, you cannot simply tell us how you use it, after it has gotten that out-of-range value- Your directory string is another out-of-range value. How you use it, after it got this illegal value is of no interest. The important thing is how it got that value, not how you later use it. Like if you ask "Why does my value exceed 100?" Noone can tell unless you tell how you got or calculated that value. String values are no different: If they have an illegal value, such as not being nul-terminated in contexts where that is expected, the problem is in the source, not in the use of the value. If it is as difficult as it seems to trace the source, identify where that directory sting came from, then you should not expect others to be able to help you. "I have an illegal value, but I can't tell where it came from - why is it not legal?" - noone can give you a reasonable answer to that. So come on, tell us how the .directory value was obtained/created! Until you do that, you cannot expect any useful help from other forum members

                                        L _ 3 Replies Last reply
                                        0
                                        • K kalberts

                                          I am really puzzled by how difficult it seem to be to explain how the value of that .directory was initialized. Where its value came from. How it was created. Obviously, whatever created the value did not follow the C convention of terminating it with a nul - most likely because it doesn't have a C origin. Fair enough. But why is it so difficult to show how the .directory value was obtained? As it now stands, it is like complaining "This variable should have av value between 0 and 100, but it is above 100. Why???" If you can't figure that out yourself, you must reveal how you calculate it, you cannot simply tell us how you use it, after it has gotten that out-of-range value- Your directory string is another out-of-range value. How you use it, after it got this illegal value is of no interest. The important thing is how it got that value, not how you later use it. Like if you ask "Why does my value exceed 100?" Noone can tell unless you tell how you got or calculated that value. String values are no different: If they have an illegal value, such as not being nul-terminated in contexts where that is expected, the problem is in the source, not in the use of the value. If it is as difficult as it seems to trace the source, identify where that directory sting came from, then you should not expect others to be able to help you. "I have an illegal value, but I can't tell where it came from - why is it not legal?" - noone can give you a reasonable answer to that. So come on, tell us how the .directory value was obtained/created! Until you do that, you cannot expect any useful help from other forum members

                                          L Offline
                                          L Offline
                                          Lost User
                                          wrote on last edited by
                                          #30

                                          I think you may be banging your head against a brick wall. I have tried this approach repeatedly and got nowhere. But well done for trying.

                                          1 Reply Last reply
                                          0
                                          Reply
                                          • Reply as topic
                                          Log in to reply
                                          • Oldest to Newest
                                          • Newest to Oldest
                                          • Most Votes


                                          • Login

                                          • Don't have an account? Register

                                          • Login or register to search.
                                          • First post
                                            Last post
                                          0
                                          • Categories
                                          • Recent
                                          • Tags
                                          • Popular
                                          • World
                                          • Users
                                          • Groups