From: Corinna Vinschen <corinna-cygwin@cygwin.com>
To: Jon Turney <jon.turney@dronecode.org.uk>
Cc: cygwin-patches@cygwin.com, Brian Inglis <Brian.Inglis@shaw.ca>
Subject: Re: [PATCH] fhandler/proc.cc(format_proc_cpuinfo): Add Linux 6.3 cpuinfo
Date: Mon, 5 Jun 2023 18:55:17 +0200 [thread overview]
Message-ID: <ZH4TdYlr+RAFbOHe@calimero.vinschen.de> (raw)
In-Reply-To: <0a50e9ad-59c8-65e9-95f5-f53843fbf918@dronecode.org.uk>
On May 12 16:36, Jon Turney wrote:
> On 08/05/2023 04:12, Brian Inglis wrote:
> > cpuid 0x00000007:0 ecx:7 shstk Shadow Stack support & Windows [20]20H1/[20]2004+
> > => user_shstk User mode program Shadow Stack support
> > AMD SVM 0x8000000a:0 edx:25 vnmi virtual Non-Maskable Interrrupts
> > Sync AMD 0x80000008:0 ebx flags across two output locations
>
> Thanks. I applied this.
>
> Does this need applying to the 3.4 branch as well?
>
> > ---
> > winsup/cygwin/fhandler/proc.cc | 29 ++++++++++++++++++++++-------
>
> > + /* cpuid 0x00000007 ecx & Windows [20]20H1/[20]2004+ */
> > + if (maxf >= 0x00000007 && wincap.osname () >= "10.0"
> > + && wincap.build_number () >= 19041)
No problems checking for the OS versions, but not like this.
wincap.osname () >= "10.0" ?
That will not do what you expect it to do. wincap.osname() is a char *
and the >= operator will not work as on cstring in C++, but compare the
pointer values of the two strings instead.
While changing this to
strcmp (wincap.osname (), "10.0") >= 0
is possible, it doesn't make sense. For all supported Windows versions,
the build number is unambiguously bumped with each new release. So
there's no older OS version with a build number >= 19041. As a result,
the check for osname() can simply go away.
But then again, this is a windows feature which would best served by
adding a bit flag to the wincaps array, *and* we already have a wincaps
array for windows versions starting with build number 19041
(wincap_10_2004).
So, Brian, would you mind to create a followup patch which rather defines
a new bitflag in the wincaps array, set it to false or true according
to the OS version, and check this flag instead?
Thanks,
Corinna
prev parent reply other threads:[~2023-06-05 16:55 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-05-08 3:12 Brian Inglis
2023-05-12 15:36 ` Jon Turney
2023-05-12 18:09 ` Brian Inglis
2023-05-21 20:32 ` Jon Turney
2023-05-22 15:45 ` Brian Inglis
2023-06-05 16:55 ` Corinna Vinschen [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=ZH4TdYlr+RAFbOHe@calimero.vinschen.de \
--to=corinna-cygwin@cygwin.com \
--cc=Brian.Inglis@shaw.ca \
--cc=cygwin-patches@cygwin.com \
--cc=jon.turney@dronecode.org.uk \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).