Skip to content
  • Categories
  • Recent
  • Tags
  • Popular
  • Users
  • Groups
  • Search
  • Get Qt Extensions
  • Unsolved
Collapse
Brand Logo
  1. Home
  2. Qt Development
  3. General and Desktop
  4. [SOLVED] Calling QString::toWCharArray causes segmentation fault
Forum Updated to NodeBB v4.3 + New Features

[SOLVED] Calling QString::toWCharArray causes segmentation fault

Scheduled Pinned Locked Moved General and Desktop
12 Posts 3 Posters 3.9k Views 3 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.
  • M Offline
    M Offline
    mcosta
    wrote on 26 Jun 2015, 12:18 last edited by mcosta
    #2

    Hi and welcome to devnet,

    are you sure lbl length is less or equal to 33??

    from Qt docs

    array has to be allocated by the caller and contain enough space to hold the complete string (allocating the array with the same length as the string is always sufficient).

    Once your problem is solved don't forget to:

    • Mark the thread as SOLVED using the Topic Tool menu
    • Vote up the answer(s) that helped you to solve the issue

    You can embed images using (http://imgur.com/) or (http://postimage.org/)

    K 1 Reply Last reply 26 Jun 2015, 12:20
    0
    • M mcosta
      26 Jun 2015, 12:18

      Hi and welcome to devnet,

      are you sure lbl length is less or equal to 33??

      from Qt docs

      array has to be allocated by the caller and contain enough space to hold the complete string (allocating the array with the same length as the string is always sufficient).

      K Offline
      K Offline
      kdev
      wrote on 26 Jun 2015, 12:20 last edited by
      #3

      @mcosta I tried with wchar_t __lbl[255], but the problem is the same.

      1 Reply Last reply
      0
      • M Offline
        M Offline
        mcosta
        wrote on 26 Jun 2015, 12:27 last edited by
        #4

        Whats the length of lbl???

        I tried this program

        #include <QCoreApplication>
        
        #include <QtDebug>
        
        int main(int argc, char *argv[])
        {
            QCoreApplication a(argc, argv);
        
            QString s = "Super Huge Long long long log string";
        
            const int LABEL_SIZE = 100;
            wchar_t myLabel [LABEL_SIZE];
        
            qDebug() << s.toWCharArray(myLabel);
        }
        

        it works, if I change LABEL_SIZE to 20 it crashes.

        Which platform?? I'm on OS X

        Once your problem is solved don't forget to:

        • Mark the thread as SOLVED using the Topic Tool menu
        • Vote up the answer(s) that helped you to solve the issue

        You can embed images using (http://imgur.com/) or (http://postimage.org/)

        K 1 Reply Last reply 26 Jun 2015, 12:42
        1
        • M mcosta
          26 Jun 2015, 12:27

          Whats the length of lbl???

          I tried this program

          #include <QCoreApplication>
          
          #include <QtDebug>
          
          int main(int argc, char *argv[])
          {
              QCoreApplication a(argc, argv);
          
              QString s = "Super Huge Long long long log string";
          
              const int LABEL_SIZE = 100;
              wchar_t myLabel [LABEL_SIZE];
          
              qDebug() << s.toWCharArray(myLabel);
          }
          

          it works, if I change LABEL_SIZE to 20 it crashes.

          Which platform?? I'm on OS X

          K Offline
          K Offline
          kdev
          wrote on 26 Jun 2015, 12:42 last edited by
          #5

          @mcosta Ah, I was misunderstanding .. I was unaware of the length of lbl which was 365: So the cause of the segmentation fault is clear here. It is not an OS problem (I'm on GNU/Linux). Changing the length of __lbl to 399 solved the problem.
          Thanks.

          1 Reply Last reply
          0
          • C Offline
            C Offline
            Chris Kawa
            Lifetime Qt Champion
            wrote on 26 Jun 2015, 17:13 last edited by
            #6

            Why are you hardcoding the length anyway? What if you decide to use 400 characters one day? You're gonna revisit that code? Just check the length of the string before conversion and allocate enough space for it.

            K 1 Reply Last reply 27 Jun 2015, 08:29
            1
            • C Chris Kawa
              26 Jun 2015, 17:13

              Why are you hardcoding the length anyway? What if you decide to use 400 characters one day? You're gonna revisit that code? Just check the length of the string before conversion and allocate enough space for it.

              K Offline
              K Offline
              kdev
              wrote on 27 Jun 2015, 08:29 last edited by kdev
              #7

              @Chris-Kawa Yes, that's true .. using that code instead __lbl = (wchar_t *)calloc(this->ui->label->text().count(), sizeof(wchar_t)); for allocation is the best way. Thank you for this notice.

              1 Reply Last reply
              0
              • C Offline
                C Offline
                Chris Kawa
                Lifetime Qt Champion
                wrote on 27 Jun 2015, 08:34 last edited by Chris Kawa
                #8

                Since you're using c++ I would consider using new/delete instead of calloc/free, or, better yet, a unique_ptr to stay safe of exception problems. Also, according to the standard, names starting with double underscores (and single underscore in global namespace) are reserved for internal compiler/stl implementation. You're stepping on enemy territory using these.

                K 1 Reply Last reply 27 Jun 2015, 08:41
                0
                • C Chris Kawa
                  27 Jun 2015, 08:34

                  Since you're using c++ I would consider using new/delete instead of calloc/free, or, better yet, a unique_ptr to stay safe of exception problems. Also, according to the standard, names starting with double underscores (and single underscore in global namespace) are reserved for internal compiler/stl implementation. You're stepping on enemy territory using these.

                  K Offline
                  K Offline
                  kdev
                  wrote on 27 Jun 2015, 08:41 last edited by
                  #9

                  @Chris-Kawa I'm mainly a C programmer, I don't like using C++ if not for widget programming .. anyway, what does "reserved for internal compiler/stl implementation" mean?

                  1 Reply Last reply
                  0
                  • C Offline
                    C Offline
                    Chris Kawa
                    Lifetime Qt Champion
                    wrote on 27 Jun 2015, 08:48 last edited by Chris Kawa
                    #10

                    anyway, what does "reserved for internal compiler/stl implementation" mean?

                    Means that such names are not to be used by users (us). They are reserved for compilers and STL.
                    For example the standard __LINE__, __FILE__ and __func__ macros, or the vendor specific keywords like MSVC's __super.

                    This restriction is not enforced by any compiler I know, but technically you shouldn't name your stuff this way and implementation is free to do with that code whatever it wants (undefined behavior in user space).

                    K 1 Reply Last reply 27 Jun 2015, 09:01
                    0
                    • C Chris Kawa
                      27 Jun 2015, 08:48

                      anyway, what does "reserved for internal compiler/stl implementation" mean?

                      Means that such names are not to be used by users (us). They are reserved for compilers and STL.
                      For example the standard __LINE__, __FILE__ and __func__ macros, or the vendor specific keywords like MSVC's __super.

                      This restriction is not enforced by any compiler I know, but technically you shouldn't name your stuff this way and implementation is free to do with that code whatever it wants (undefined behavior in user space).

                      K Offline
                      K Offline
                      kdev
                      wrote on 27 Jun 2015, 09:01 last edited by
                      #11

                      @Chris-Kawa Yes, that's true .. but I'm quite careful about that, and I have enough experience in C Programming with GNU development tools such as GCC.

                      1 Reply Last reply
                      0
                      • C Offline
                        C Offline
                        Chris Kawa
                        Lifetime Qt Champion
                        wrote on 27 Jun 2015, 09:04 last edited by
                        #12

                        Yeah, and I'm not saying that it will ever break. I can't imagine any compiler doing anything malicious to such code. I'm just saying it's standard non-conforming code.

                        1 Reply Last reply
                        0

                        11/12

                        27 Jun 2015, 09:01

                        • Login

                        • Login or register to search.
                        11 out of 12
                        • First post
                          11/12
                          Last post
                        0
                        • Categories
                        • Recent
                        • Tags
                        • Popular
                        • Users
                        • Groups
                        • Search
                        • Get Qt Extensions
                        • Unsolved