[MDEV-9794] extended C or C++ style comments scattered through the sources Created: 2016-03-26  Updated: 2016-03-29  Resolved: 2016-03-29

Status: Closed
Project: MariaDB Server
Component/s: Compiling
Affects Version/s: 10.1.12, 5.5.48-galera, 10.0.24-galera
Fix Version/s: N/A

Type: Bug Priority: Minor
Reporter: Michael Felt Assignee: Sergei Golubchik
Resolution: Not a Bug Votes: 0
Labels: None
Environment:

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



 Comments   
Comment by Elena Stepanova [ 2016-03-27 ]

Assigned to serg to decide if it's going to be fixed.

Comment by Sergei Golubchik [ 2016-03-29 ]

TokuDB is

  1. all C++
  2. only works on Linux and OSX
  3. can only be compiled with gcc (4.7 or later) or clang

taking all that into account, I'm closing this as "not a bug".

If you have actual compiler failures on AIX with xlc compiler, caused by C++ comments in the C source files — please list them here and I'll reopen the bug report. Thanks!

Generated at Thu Feb 08 07:37:23 UTC 2024 using Jira 8.20.16#820016-sha1:9d11dbea5f4be3d4cc21f03a88dd11d8c8687422.