A dozen unused return value warnings

classic Classic list List threaded Threaded
4 messages Options
Reply | Threaded
Open this post in threaded view
|

A dozen unused return value warnings

Daniel J Sebald
On my system, configuration results in the unused return variable flag
being set.  Attached is a diff file with code changes to get rid of
those warnings.

One in particular I have a question about:

diff -u -r1.6 QtGnuplotApplication.cpp
--- src/qtterminal/QtGnuplotApplication.cpp 29 Jan 2014 15:48:51 -0000 1.6
+++ src/qtterminal/QtGnuplotApplication.cpp 29 Mar 2017 18:47:43 -0000
@@ -80,8 +80,8 @@
  // Some programs executing gnuplot -persist may be waiting for all
default
  // handles to be closed before they consider the sub-process finished.
  // Using freopen() ensures that debug fprintf()s won't crash.
- freopen("/dev/null","w",stdout);
- freopen("/dev/null","w",stderr);
+ if (freopen("/dev/null","w",stdout));
+ if (freopen("/dev/null","w",stderr));
  }

Should the above really be included in Qt?  I don't think that Qt C++
files need to use FPRINTF() any more for debugging.  Qt has it's own
messaging system:

http://doc.qt.io/qt-4.8/debug.html

qDebug(), qWarning(), qCritical(), qFatal().

Dan

------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
gnuplot-beta mailing list
[hidden email]
Membership management via: https://lists.sourceforge.net/lists/listinfo/gnuplot-beta

remove_warnings_djs2017mar29.diff (5K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: A dozen unused return value warnings

Hans-Bernhard Bröker-2
Am 29.03.2017 um 21:01 schrieb Daniel J Sebald:
> On my system, configuration results in the unused return variable flag
> being set.  Attached is a diff file with code changes to get rid of
> those warnings.

Doing the change like that is just wrong:

> -    freopen("/dev/null","w",stdout);
> -    freopen("/dev/null","w",stderr);
> +    if (freopen("/dev/null","w",stdout));
> +    if (freopen("/dev/null","w",stderr));

The usual, widely accepted way of doing that is to cast an unused return
value to (void), i.e.:

    (void)freopen("/dev/null","w",stdout);
    (void)freopen("/dev/null","w",stderr);

> Should the above really be included in Qt?  I don't think that Qt C++
> files need to use FPRINTF() any more for debugging.

That doesn't help with debugging non-QT, non-C++ files in gnuplot at
all, though.

> Qt has it's own
> messaging system:

That's nice to know, but doesn't help us much, because we still want to
be able to work _without_ any Qt involved, too.



------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
gnuplot-beta mailing list
[hidden email]
Membership management via: https://lists.sourceforge.net/lists/listinfo/gnuplot-beta
Reply | Threaded
Open this post in threaded view
|

Re: A dozen unused return value warnings

Daniel J Sebald
On 03/30/2017 08:02 AM, Hans-Bernhard Bröker wrote:

> Am 29.03.2017 um 21:01 schrieb Daniel J Sebald:
>> On my system, configuration results in the unused return variable flag
>> being set.  Attached is a diff file with code changes to get rid of
>> those warnings.
>
> Doing the change like that is just wrong:
>
>> -    freopen("/dev/null","w",stdout);
>> -    freopen("/dev/null","w",stderr);
>> +    if (freopen("/dev/null","w",stdout));
>> +    if (freopen("/dev/null","w",stderr));
>
> The usual, widely accepted way of doing that is to cast an unused return
> value to (void), i.e.:
>
>    (void)freopen("/dev/null","w",stdout);
>    (void)freopen("/dev/null","w",stderr);

That was my initial thought, but I had read on a couple discussion lists
that void-cast doesn't work for some compilers any more.


>> Should the above really be included in Qt?  I don't think that Qt C++
>> files need to use FPRINTF() any more for debugging.
>
> That doesn't help with debugging non-QT, non-C++ files in gnuplot at
> all, though.
>
>> Qt has it's own
>> messaging system:
>
> That's nice to know, but doesn't help us much, because we still want to
> be able to work _without_ any Qt involved, too.

The Qt terminal is a separate compilation and process.  I tried Ethan's
idea of simply closing stderr and stdout rather than reopening.  (fclose
doesn't return anything, so no warning.)  I can't see any difference in
behavior of persist mode.  I see a comment online about someone trying
to redirect std::cerr and std::cout, so I would guess they are separate
entities:

http://qtforum.org/article/678/redirecting-cout-cerr-to-qdebug.html

Dan

------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
gnuplot-beta mailing list
[hidden email]
Membership management via: https://lists.sourceforge.net/lists/listinfo/gnuplot-beta
Reply | Threaded
Open this post in threaded view
|

Re: A dozen unused return value warnings

Daniel J Sebald
In reply to this post by Daniel J Sebald
Does anyone have a better understanding of this comment for do_system()?

/* (am, 19980929)
  * OS/2 related note: cmd.exe returns 255 if called w/o argument.
  * i.e. calling a shell by "!" will always end with an error message.
  * A workaround has to include checking for EMX,OS/2, two environment
  *  variables,...
  */

What are the environment variables?  OS/2 isn't an environment variable.
  There is an OS2 pre-compile flag, e.g.,:

#  elif defined(OS2)

so don't we already know if this is OS2 and can adjust accordingly?

Note, when changing do_system() to int, I'm going to drop

     if (!cmd)
        return 0;

because both system() and _wsystem() accept NULL commands in a
meaningful way.  It's a query for which a return value of 0 means no
command-processor available and not-0 means command-processor is
available.  If cmd is non-NULL, then it is the usual 0 means success,
non-zero means error code.

Dan

------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
gnuplot-beta mailing list
[hidden email]
Membership management via: https://lists.sourceforge.net/lists/listinfo/gnuplot-beta