Uploaded image for project: 'MariaDB Server'
  1. MariaDB Server
  2. MDEV-9794

extended C or C++ style comments scattered through the sources

    XMLWordPrintable

Details

    • Bug
    • Status: Closed (View Workflow)
    • Minor
    • Resolution: Not a Bug
    • 10.1.12, 5.5.48-galera, 10.0.24-galera
    • N/A
    • Compiling
    • None
    • AIX, xlc (vac) compiler

    Description

      After correcting MANY files manually, I went back and reran cmake but prefixed it with

      export CCFLAGS="-qcpluscmt"
      export CFLAGS="-qcpluscmt"
      

      To remove all the

      "...filename..." ...line 4314.9: 1506-046 (S) Syntax error.
      

      Just one example:

      root@x064:[/data/prj/aixtools/mariadb/src/mariadb-5.5.48]egrep "[^*]//" storage/tokudb/ft-index/ft/cursor.h
          DBT key, val;             // The key-value pair that the cursor currently points to
          bool is_snapshot_read; // true if query is read_committed, false otherwise
          // To fix #3522, we need to remember the pivots that we have searched unsuccessfully.
          // For example, when searching right (left), we call search->compare() on the ith pivot key.  If search->compare(0 returns
          //  nonzero, then we search the ith subtree.  If that subsearch returns DB_NOTFOUND then maybe the key isn't present in the
          //  tree.  But maybe we are doing a DB_NEXT (DB_PREV), and everything was deleted.  So we remember the pivot, and later we
          //  will only search subtrees which contain keys that are bigger than (less than) the pivot.
          // The code is a kludge (even before this fix), and interacts strangely with the TOKUDB_FOUND_BUT_REJECTED (which is there
          //  because a failed DB_GET we would keep searching the rest of the tree).  We probably should write the various lookup
          //  codes (NEXT, PREV, CURRENT, etc) more directly, and we should probably use a binary search within a node to search the
          //  pivots so that we can support a larger fanout.
          // These changes (3312+3522) also (probably) introduce an isolation error (#3529).
          //  We must make sure we lock the right range for proper isolation level.
          //  There's probably a bug in which the following could happen.
          //      Thread A:  Searches through deleted keys A,B,D,E and finds nothing, so searches the next leaf, releasing the YDB lock.
          //      Thread B:  Inserts key C, and acquires the write lock, then commits.
          //      Thread A:  Resumes, searching F,G,H and return success.  Thread A then read-locks the range A-H, and doesn't notice
          //        the value C inserted by thread B.  Thus a failure of serialization.
          //     See #3529.
          // There also remains a potential thrashing problem.  When we get a TOKUDB_TRY_AGAIN, we unpin everything.  There's
          //   no guarantee that we will get everything pinned again.  We ought to keep nodes pinned when we retry, except that on the
          //   way out with a DB_NOTFOUND we ought to unpin those nodes.  See #3528.
      

      I say minor - because it can be caught with a compiler flag - BUT - if you have a standard that says to use standard /* and */ for comments - there are several to many places where this has not be followed.

      p.s. to show just one file 10.0.* and 10.1.* issues:

      root@x064:[/data/prj/aixtools/mariadb/src]egrep -c "[^*]//" mariadb-10*/*/*/*/*/*.[ch] | grep -v :0 | grep 14
      mariadb-10.0.24/storage/tokudb/PerconaFT/util/omt.h:14
      mariadb-10.1.13/storage/tokudb/PerconaFT/util/omt.h:14
      

      So, at least 80 files in the 10.* truncks

      root@x064:[/data/prj/aixtools/mariadb/src]egrep -c "[^*]//" mariadb-10*/*/*/*/*/*.[ch] | grep -v :0 | wc -l  
      161
      

      And more than I wanted to edit manually in the 5.5 branch...

      Michael

      Attachments

        Activity

          People

            serg Sergei Golubchik
            MichaelFelt Michael Felt
            Votes:
            0 Vote for this issue
            Watchers:
            3 Start watching this issue

            Dates

              Created:
              Updated:
              Resolved:

              Git Integration

                Error rendering 'com.xiplink.jira.git.jira_git_plugin:git-issue-webpanel'. Please contact your Jira administrators.