Menu
▾
▴
[Bacula-bugs] [Bacula Bug Reports 0002089]: warning: private field 'm_link' is not used
|
From: Mantis B. T. <no...@bu...> - 2014-08-06 16:16:37
|
The following issue requires your FEEDBACK. ====================================================================== http://bugs.bacula.org/view.php?id=2089 ====================================================================== Reported By: martin Assigned To: ====================================================================== Project: Bacula Bug Reports Issue ID: 2089 Category: configure/build process Reproducibility: have not tried Severity: minor Priority: normal Status: feedback ====================================================================== Date Submitted: 2014-08-06 13:34 BST Last Modified: 2014-08-06 17:16 BST ====================================================================== Summary: warning: private field 'm_link' is not used Description: Compiling on systems using clang gives this warning for every file: ../lib/dlist.h:195:10: warning: private field 'm_link' is not used [-Wunused-private-field] dlink m_link; ^ It appears to be true. Steps to Reproduce: ./configure --enable-client-only make Additional Information: On FreeBSD 10.0, cc is clang version 3.3. It also occurs on Mac OS X 10.9 where cc is Apple LLVM version 5.1 (clang-503.0.40) (based on LLVM 3.4svn). ====================================================================== ---------------------------------------------------------------------- (0007015) kern (administrator) - 2014-08-06 13:59 http://bugs.bacula.org/view.php?id=2089#c7015 ---------------------------------------------------------------------- dlink is absolutely needed for the dlist routines to work. It is only referenced inside the dlink subroutines themselves. This is a false warning. ---------------------------------------------------------------------- (0007017) kern (administrator) - 2014-08-06 14:07 http://bugs.bacula.org/view.php?id=2089#c7017 ---------------------------------------------------------------------- I am wondering if just changing the definition of the dlink field to be public will fix the problem. Can you try that and report back? ---------------------------------------------------------------------- (0007018) martin (reporter) - 2014-08-06 14:43 http://bugs.bacula.org/view.php?id=2089#c7018 ---------------------------------------------------------------------- This field is in dlistString, not dlist and there is no reference to it anywhere in the source. Removing it doesn't cause any compile-time errors. The class B_DB has it's own unrelated m_link field. ---------------------------------------------------------------------- (0007019) kern (administrator) - 2014-08-06 14:47 http://bugs.bacula.org/view.php?id=2089#c7019 ---------------------------------------------------------------------- If you remove it you will get corrupted memory. It is required. There are lots of references to it in the dlist.c source via a byte offset rather than by a symbol. For the string class the offset is zero, but for other classes it can be non-zero. There is no problem with any other class having its own m_link field. ---------------------------------------------------------------------- (0007024) martin (reporter) - 2014-08-06 16:37 http://bugs.bacula.org/view.php?id=2089#c7024 ---------------------------------------------------------------------- OK, I see what you mean now. This code looks very fragile. I suspect that making m_link public (but keeping m_str private) will be risky because the C++ compiler will no longer be obliged to keep the fields in order. Adding a public getter should be safe though: dlink get_link() { return m_link; }; and is sufficient to remove the warning. ---------------------------------------------------------------------- (0007025) kern (administrator) - 2014-08-06 17:16 http://bugs.bacula.org/view.php?id=2089#c7025 ---------------------------------------------------------------------- The getter sounds like a nice solution. I am 99% sure where it would go, but can you paste a copy of the subroutine with your fix so I can be sure? Issue History Date Modified Username Field Change ====================================================================== 2014-08-06 13:34 martin New Issue 2014-08-06 13:59 kern Note Added: 0007015 2014-08-06 13:59 kern Status new => closed 2014-08-06 13:59 kern Resolution open => no change required 2014-08-06 14:07 kern Note Added: 0007017 2014-08-06 14:07 kern Status closed => feedback 2014-08-06 14:07 kern Resolution no change required => open 2014-08-06 14:43 martin Note Added: 0007018 2014-08-06 14:43 martin Status feedback => new 2014-08-06 14:47 kern Note Added: 0007019 2014-08-06 16:37 martin Note Added: 0007024 2014-08-06 17:16 kern Note Added: 0007025 2014-08-06 17:16 kern Status new => feedback ====================================================================== |