This is a string declared in a local context, used in only one place and as
the argument TO a %s directive. There is no
printf formatting of the content. Maybe the variable name should be
changed to "headertext" instead of current "formatstring"
as the variable name suggests it is something it is not used for.
The variable goes out of scope immediately after its use in the call to
ncurse library. No risk for any side effects if fixing this in my view.
Hmm! I worry about the behaviour on old compilers, libc and Linux versions.
As the %% becomes just % on screen something is parsing the string.
Also this is a curses library not standout issue.
Status: pending Group: Unstable (example) Created: Tue Nov 08, 2022 04:14 PM UTC by Nils Smeds Last Updated: Tue Nov 08, 2022 04:14 PM UTC Owner: nobody Attachments:
Hmm! I worry about the behaviour on old compilers, libc and Linux versions.
As the %% becomes just % on screen something is parsing the string.
Also this is a curses library not standout issue.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Where do you see it written as just %CPU and not %%CPU?
I don't think I have seen it. If this really is a problem I guess one could keep the %%
and change the call to ncurses?
From
CURSE mvwprintw(padtop, 1, y, "%s", formatstring);
To
CURSE mvwprintw(padtop, 1, y, formatstring, NULL);
Would that work do you think?
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Interesting. Can you share compile line, compiler detailed version and
error message. I had no issues compiling it when I submitted it, but I will
reinvestigate if needed.
The change is trivial so it is a mystery to me why it would fail unless
there has been an error in the merge of the patch.
Status: pending Group: Unstable (example) Created: Tue Nov 08, 2022 04:14 PM UTC by Nils Smeds Last Updated: Mon Nov 14, 2022 09:53 PM UTC Owner: nobody Attachments:
This works on RHEL with GCC 10 and fails on Ubuntu with GCC 11.
As it is largely a cosmetic change, I am going to close the issue.
Thanks for reporting and working a fix but there are higher priorities.
Thanks Nigel
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
It works for me on a number of different platforms. Would take some effort
to find out if it is the compiler or the ncurses library that is the
culprit.
But it is just a minor annoyance in the top processes output so I have no
real issues with it (and I can fix it on the systems I use)
This works on RHEL with GCC 10 and fails on Ubuntu with GCC 11.
As it is largely a cosmetic change, I am going to close the issue.
Thanks for reporting and working a fix but there are higher priorities.
Thanks Nigel
Status: pending Group: Unstable (example) Created: Tue Nov 08, 2022 04:14 PM UTC by Nils Smeds Last Updated: Wed Dec 07, 2022 06:00 PM UTC Owner: nobody Attachments:
This is a string declared in a local context, used in only one place and as
the argument TO a %s directive. There is no
printf formatting of the content. Maybe the variable name should be
changed to "headertext" instead of current "formatstring"
as the variable name suggests it is something it is not used for.
The variable goes out of scope immediately after its use in the call to
ncurse library. No risk for any side effects if fixing this in my view.
On Mon, Nov 14, 2022 at 5:53 AM Nigel Griffiths nigelgriffiths@users.sourceforge.net wrote:
Related
Patches: #17
Hmm! I worry about the behaviour on old compilers, libc and Linux versions.
As the %% becomes just % on screen something is parsing the string.
Also this is a curses library not standout issue.
Where do you see it written as just %CPU and not %%CPU?
I don't think I have seen it. If this really is a problem I guess one could keep the %%
and change the call to ncurses?
From
CURSE mvwprintw(padtop, 1, y, "%s", formatstring);
To
CURSE mvwprintw(padtop, 1, y, formatstring, NULL);
Would that work do you think?
This change fails to clean compile of Ubuntu with gcc 11 installed.
Interesting. Can you share compile line, compiler detailed version and
error message. I had no issues compiling it when I submitted it, but I will
reinvestigate if needed.
The change is trivial so it is a mystery to me why it would fail unless
there has been an error in the merge of the patch.
On Wed, Dec 7, 2022, 19:00 Nigel Griffiths nigelgriffiths@users.sourceforge.net wrote:
Related
Patches: #17
This works on RHEL with GCC 10 and fails on Ubuntu with GCC 11.
As it is largely a cosmetic change, I am going to close the issue.
Thanks for reporting and working a fix but there are higher priorities.
Thanks Nigel
It works for me on a number of different platforms. Would take some effort
to find out if it is the compiler or the ncurses library that is the
culprit.
But it is just a minor annoyance in the top processes output so I have no
real issues with it (and I can fix it on the systems I use)
These work fine for me:
NAME="Ubuntu"
VERSION="20.04.5 LTS (Focal Fossa)"
gcc (Ubuntu 9.4.0-1ubuntu1~20.04.1) 9.4.0
libncurses-dev/focal,now 6.2-0ubuntu2 amd64 [installed]
[nsmeds-x1(nsmeds):nmon] cat /etc/os-release
NAME="Fedora Linux"
VERSION="37 (Thirty Seven)"
gcc (GCC) 12.2.1 20221121 (Red Hat 12.2.1-4)
ncurses-devel-6.3-3.20220501.fc37.x86_64
NAME="CentOS Linux"
VERSION="8"
strings -a [...]nmon/16n/bin/nmon | egrep -i curses|gcc | sort -u
annobin gcc 8.4.1 20200928
GCC: (GNU) 8.4.1 20200928 (Red Hat 8.4.1-1)
libncurses.so.6
running gcc 8.4.1 20200928
The RHEL/CentOS 8 release distributed binary shows the %%CPU header on the
rop processes display unless the patch is applied.
Cheers
/Nils
On Thu, Dec 8, 2022 at 11:04 AM Nigel Griffiths nigelgriffiths@users.sourceforge.net wrote:
Related
Patches: #17