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

[Hans-Bernhard Bröker]

Post by 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.
- 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);

Post by Daniel J Sebald
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.

Post by Daniel J Sebald
Qt has it's own

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.

[Daniel J Sebald]

Post by Hans-Bernhard Bröker

Post by 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.
- 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
(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.

Post by Hans-Bernhard Bröker

Post by Daniel J Sebald
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.

Post by Daniel J Sebald
Qt has it's own

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

[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