FLTK logo

STR #3169

FLTK matrix user chat room
(using Element browser app)   FLTK gitter user chat room   GitHub FLTK Project   FLTK News RSS Feed  
  FLTK Apps      FLTK Library      Forums      Links     Login 
 Home  |  Articles & FAQs  |  Bugs & Features  |  Documentation  |  Download  |  Screenshots  ]
 

Return to Bugs & Features | Roadmap 1.3 | SVN ⇄ GIT ]

STR #3169

Application:FLTK Library
Status:1 - Closed w/Resolution
Priority:2 - Low, e.g. a documentation error or undocumented side-effect
Scope:2 - Specific to an operating system
Subsystem:Core Library
Summary:OSX 10.9.5: default build warnings with svn current (r10486)
Version:1.3-current
Created By:greg.ercolano
Assigned To:greg.ercolano
Fix Version:1.3-current (SVN: v10501)
Update Notification:

Receive EMails Don't Receive EMails

Trouble Report Files:


Name/Time/Date Filename/Size  
 
#1 greg.ercolano
22:49 Dec 17, 2014
v1.patch
5k
 
     

Trouble Report Comments:


Name/Time/Date Text  
 
#1 greg.ercolano
21:28 Dec 17, 2014
8 warnings from the Xcode 6.1.1 / OSX 10.9.5 platform.

Will see if I can offer fixes for these; reporting just for completeness.

[..] # 1
=== making src ===
Compiling Fl_cocoa.mm...
Fl_cocoa.mm:1111:10: warning: unused variable 'previous' [-Wunused-variable]
    bool previous = subx->mapped_to_retina();
         ^
1 warning generated.
[..] # 2
Compiling Fl_Preferences.cxx...
Fl_Preferences.cxx:959:13: warning: function 'makePath' is not needed and will not be emitted
      [-Wunneeded-internal-declaration]
static char makePath( const char *path ) {
            ^
1 warning generated.
[..] # 3
Compiling Fl_Tabs.cxx...
In file included from Fl_Tabs.cxx:28:
../FL/Fl_Tabs.H:202:14: warning: private field 'value_' is not used [-Wunused-private-field]
  Fl_Widget *value_;
             ^
1 warning generated.
[..] # 4
Compiling Fl_Tree.cxx...
Fl_Tree.cxx:68:12: warning: function 'find_total_children' is not needed and will not be emitted
      [-Wunneeded-internal-declaration]
static int find_total_children(Fl_Tree_Item *item, int count=0) {
           ^
1 warning generated.
[..] # 5
=== making fluid ===
Compiling CodeEditor.cxx...
CodeEditor.cxx:182:27: warning: for loop has empty body [-Wempty-body]
             *bufptr++ = *temp++);
                                 ^
CodeEditor.cxx:182:27: note: put the semicolon on a separate line to silence this warning
1 warning generated.
[..] # 6
Compiling file.cxx...
In file included from file.cxx:296:
In file included from ./Fl_Widget_Type.h:23:
./Fl_Type.h:805:48: warning: attribute declaration must precede definition [-Wignored-attributes]
void write_string(const char *,...) __fl_attr((__format__ (__printf__, 1, 2)));
                                               ^
./Fl_Type.h:799:41: note: expanded from macro '__fl_attr'
#    define __fl_attr(x) __attribute__ (x)
                                        ^
file.cxx:89:6: note: previous definition is here
void write_string(const char *format, ...) {
     ^
1 warning generated.
[..] # 7
Compiling editor.cxx...
editor.cxx:209:27: warning: for loop has empty body [-Wempty-body]
             *bufptr++ = *temp++);
                                 ^
editor.cxx:209:27: note: put the semicolon on a separate line to silence this warning
1 warning generated.
[..] # 8
Compiling fracviewer.cxx...
fracviewer.cxx:311:13: warning: explicitly assigning a variable of type 'GLfloat' (aka 'float') to itself [-Wself-assign]
      EyeAz =  EyeAz;
      ~~~~~ ^  ~~~~~
1 warning generated.
[..]
 
 
#2 greg.ercolano
22:49 Dec 17, 2014
For #1: src/Fl_cocoa.mm
        Suggesting complete removal of line; 'previous' is indeed unused,
        and the function it calls [mapped_to_retina()) only returns
        a value, and has no other effect, so functionally its inert.

        However: wondering if 'previous' was /meant/ to be used somehow,

        Wanna leave this one for manolo to look at.
        In v1.patch I'm commenting it out instead of removing just to silence
        the warning.

For #2: src/Fl_Preferences.cxx
        Suggesting #ifdef'ing out the entire static function, as its code
        is (currently) unused. See v1.patch

For #3: FL/Fl_Tabs.H
        Indeed this private member is unused.
        But it would break ABI to remove it.

        Suggesting to add ABI guards that comment it out,
        and ABI guards in the ctor in .cxx to initialize it to prevent
        the warnings. In 1.4.x we can remove all the code added.
        See v1.patch

For #4: src/Fl_Tree.cxx
        Similar to #2, unused static code.
        Suggesting commenting out rather than removal, as per v1.patch

For #5: fluid/CodeEditor.cxx
        Apparently the new compiler doesn't like empty for() loops that are
        closed with a ';'. Suggesting empty braces instead as per v1.patch.

For #6: fluid/file.cxx and fluid/Fl_Type.H
        I'm not immediately familiar with this GNU-specific syntax.
        Reading about it, and will weigh in later.

For #7: test/editor.cxx
        Seems similar to #5, v1.patch.

For #8: test/fractalviewer.cxx
        Suggest commenting out line (rather than remove) to prevent warning.
        See v1.patch
 
 
#3 AlbrechtS
04:50 Dec 18, 2014
[#2] The entire code block - makePath() together with makePathForFile() - should be removed. These functions have been replaced by fl_make_path() and fl_make_path_for_file() in src/fl_utf8.cxx. The new functions are called in lines #1190 and #1227, resp..

There's no need to keep this obsolete code in the source file.
 
 
#4 AlbrechtS
05:09 Dec 18, 2014
#1: I believe this was fixed by Manolo: svn r 10489.

#2: see above.

#3: +1
#4: +1
#5: +1

#6: no idea - maybe Lauri?

#7: +1

#8: +0.5 - maybe remove?

OT (#2) I think it's interesting that the compiler detects that a private member is not used in _one_ source file. It might be used in another source file though. How does it know? Or is it just an assumption that one class will be defined in one source file? This might be a false assumption...
 
 
#5 greg.ercolano
08:09 Dec 18, 2014
@Albrecht OT #2: Perhaps the compiler knows when it sees all
the methods declared in .H actually implemented in the one .cxx file,
and therefore couldn't be implemented elsewhere.

Certainly we have methods for e.g. Fl_Window implemented all over
in other .cxx files, but I imagine the compiler wouldn't complain
in those cases because it would see not all methods were implemented
at the end of compiling Fl_Window.cxx.
 
 
#6 manolo
09:28 Dec 18, 2014
About #6:

The cause of the warning is that the (obscure) definition
#    define __fl_attr(x) __attribute__ (x)
is done in an include cascade beginning at line 296 of fluid/file.cxx:
#include "Fl_Widget_Type.h"

whereas line 89 of this same file already declares a function with
a variable-number of arguments (write_string).

If you add
#  ifdef __GNUC__
#    define __fl_attr(x) __attribute__ (x)
#  else
#    define __fl_attr(x)
#  endif // __GNUC__
beginning at line 30 of file.cxx,
the warning is removed.

However, I wonder whether this obscure definition
applies to other GNU compilers than Apple's.
Wouldn't it be appropriate to remove altogether the use of
this definition on the mac platform as follows

#  if defined(__GNUC__) && !defined(__APPLE__)
#    define __fl_attr(x) __attribute__ (x)
#  else
#    define __fl_attr(x)
#  endif // __GNUC__

in the 2 places where it occurs, that is,
in FL/fl_ask.H and fluid/Fl_Type.H ?

With that, FLTK compiles OK with Apple's recent clang
compiler but also with Apple's older gcc-4.2 compiler.
But I don't understand the purpose of this definition.
 
 
#7 greg.ercolano
16:41 Dec 18, 2014
@manolo: I believe the purpose of the definition is to enable extra
error checking to make sure the format string matches the argument
list in custom 'printf' style functions that use stdargs,
such as our write_string() function.

Example: modern compilers (last 10 yrs or so) will check
'printf("%d %s\n", i, s);' to make sure the format string matches
the argument list, i.e. that 'i' is an 'int', and 's' is 'char*'.

This checking used to be exclusive to e.g. printf/scanf, but the
gnu compiler allows one to enable this checking for custom functions
using this __attribute__ format syntax. Info here:
http://www.unixwiz.net/techtips/gnu-c-attributes.html#format

Also, gnu's own docs on this:
https://gcc.gnu.org/onlinedocs/gcc/Function-Attributes.html#Function-Attributes
..see the section on 'format', which starts with:

---
format (archetype, string-index, first-to-check)

The format attribute specifies that a function takes printf, scanf, strftime
or strfmon style arguments that should be type-checked against a format string.
For example, the declaration:

          extern int
          my_printf (void *my_object, const char *my_format, ...)
                __attribute__ ((format (printf, 2, 3)));

..causes the compiler to check the arguments in calls to my_printf for consistency
with the printf style format string argument my_format.
[..etc..]
---
 
 
#8 greg.ercolano
19:50 Dec 18, 2014
Fixes applied:

    #1: r10490 (manolo)
    #2: r10491 (erco/albrecht)
    #3: r10492 (erco)
    #4: r10493
    #5: r10493
    #6: (still pending)
    #7: r10493
    #8: r10494
 
 
#9 manolo
07:19 Dec 20, 2014
#6 fixed at r10501  
 
#10 greg.ercolano
06:34 Dec 22, 2014
Fixed in Subversion repository.

@manolo: thanks for assist with #1 + #6; confirmed.
 
     

Return to Bugs & Features ]

 
 

Comments are owned by the poster. All other content is copyright 1998-2024 by Bill Spitzak and others. This project is hosted by The FLTK Team. Please report site problems to 'erco@seriss.com'.