Date: Wed, 16 Oct 2024 07:25:55 +0000
I'm not going to try and address everything. I think you made some valid points.
But I want to address this:
> it may be wrong because it may not reflect modifications
It's not wrong, it just does not reflect modifications that you have done internally.
Which for certain applications, that's exactly what you would want. To know what the arguments to the application were when the application was spawned, not necessarily how you modified it to hide content from different components in your application.
It's not wrong, it just has a different way of working with these constructions, you may not be able to use the exact patterns you are used to, but you would still be able to the same thing with a different pattern.
For QT case, if you make a copy and replicate it, Qt can still due its pruning of argv and spit out a list of whatever it remains.
Or even better it could allow for a new Qt::ProccesArguments construction that allows you not only to re-order arguments and reduce its size, but also to expand in size and modify the arguments on the list, in a truly well-defined manner, from anywhere, because you now have a standard way to get them from anywhere without it being attached to a main.
Either or not you would want to do that, that's a different story, it's not wrong, it's just different.
> In any case, on Windows, Qt applications require a main() function so they do get argc and argv.
Isn't "main" on Qt GUI applications on Windows an emulated function where it is actually "WinMain" in a library, and that Qt made their own in order to provide a common main() interface?
So this kind of tricks shouldn't be exactly alien to Qt.
-----Original Message-----
From: Thiago Macieira <thiago_at_[hidden]>
Sent: Wednesday, October 16, 2024 8:19 AM
To: std-proposals_at_lists.isocpp.org; Tiago Freire <tmiguelf_at_hotmail.com>
Subject: Re: [std-proposals] A draft for a std::arguments proposal
On Tuesday 15 October 2024 22:34:34 GMT-7 Tiago Freire wrote:
> Well, its not my paper.
> It is a view, so you can make a copy of the view, and do whatever you
> want with it.
There are no mutators in the paper and there's no way to construct another std::arguments_view from another array. So yes one can make a copy, but it's always going to be identical.
> "GetCommandLineW" isn't modifiable, nor would
That's not a problem, just don't use that. It's an OS interface, so not portable. The problem is when it is in the standard and gets documented and recommended.
In any case, on Windows, Qt applications require a main() function so they do get argc and argv.
> "/proc/self/cmdline", but that never was a deal breaker.
Actually, /proc/self/cmdline reflects the top-of-stack area of the application, so if you modify the argv area, /proc will reflect it too. That's how applications implement setproctitle() on Linux.
But just like GetCommandLineW(), most people will not use this OS-specific, non-portable way of getting to the command-line because a) it's cumbersome, b) it may be wrong because it may not reflect modifications and c) on Linux, it may be completely wrong because the argv area was overwritten with other data.
$ ps -o command -C avahi-daemon
COMMAND
avahi-daemon: running [tjmaciei-mobl5-13.local]
You shouldn't try to parse that.
> I think you are missing the point.
> And it is not like this is deprecating stuff that exist, everything
> that works right now will still work.
That's not my argument. Neither is it my argument that Qt has something better that you should use instead.
My argument is that std::argument, as currently described in the paper, is *actively dangerous* in a Qt application. It must never, ever be used if you created a QCoreApplication.
> And if std::arguments were to be just a view, wouldn't its interface
> be const, and wouldn't that stop you from using it in Qt's API which
> expects it to be not const? And it is not like modifying argv from
> main is a particularly well-defined thing either.
It's very, very well-defined if all you're doing is modifying the order of the elements in the argv array. It's how the GNU getopt() and getopt_long() functions implement the non-POSIXLY_CORRECT way of handling options after non-
options:
ls foo -l
On Linux, that is the same as ls -l foo, but on a traditional Unix system not using GNU coreutils, that would produce a short listing of foo and complain that file "./-l" does not exist. getopt() works by reordering the arguments and moving all non-options to after, so when it finishes running, the global optind variable points to the first non-option and that runs until argc.
Reordering the arguments to remove options handled by the library is a very common technique for frameworks. Qt requires this.
> You can make the argument that it is a feature that it is not for you,
> but then again, the same is true for more than half of the things in
> the standard.
Not the same thing. There are lots of things I don't plan on ever using, but I don't have a problem with people using them in the same process. Some features may have implementation bugs that interfere with Qt, but bugs can be fixed (e.g., a badly written SIGCHLD handler), especially if caught early. Some other features may have (IMO) poor implementations in a given C++ Standard Library, which I can do better in Qt (std::latch comes to mind).
This is not that. This one is actively harmful because you may be getting content that your application has no way of processing.
For example, all X11 applications, which include Qt ones when the XCB backend is in use, can take a -display argument with the display address. They also usually accept a -geometry argument to set the initial window geometry (Qt does). Session management-enabled applications can be relaunched by the SM with a -session argument with an ID, which is used to configure QSessionManager. This means every single user of std::arguments would need to know not to handle these parameters and all the others (like -platform and
-platformtheme) because Qt did. More than that, they'd have to know when Qt
doesn't: for example, if QSessionManager support isn't compiled in, then Qt won't handle -session and the application should produce an error due to the unknown argument.
--
Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
Principal Engineer - Intel DCAI Platform & System Engineering
But I want to address this:
> it may be wrong because it may not reflect modifications
It's not wrong, it just does not reflect modifications that you have done internally.
Which for certain applications, that's exactly what you would want. To know what the arguments to the application were when the application was spawned, not necessarily how you modified it to hide content from different components in your application.
It's not wrong, it just has a different way of working with these constructions, you may not be able to use the exact patterns you are used to, but you would still be able to the same thing with a different pattern.
For QT case, if you make a copy and replicate it, Qt can still due its pruning of argv and spit out a list of whatever it remains.
Or even better it could allow for a new Qt::ProccesArguments construction that allows you not only to re-order arguments and reduce its size, but also to expand in size and modify the arguments on the list, in a truly well-defined manner, from anywhere, because you now have a standard way to get them from anywhere without it being attached to a main.
Either or not you would want to do that, that's a different story, it's not wrong, it's just different.
> In any case, on Windows, Qt applications require a main() function so they do get argc and argv.
Isn't "main" on Qt GUI applications on Windows an emulated function where it is actually "WinMain" in a library, and that Qt made their own in order to provide a common main() interface?
So this kind of tricks shouldn't be exactly alien to Qt.
-----Original Message-----
From: Thiago Macieira <thiago_at_[hidden]>
Sent: Wednesday, October 16, 2024 8:19 AM
To: std-proposals_at_lists.isocpp.org; Tiago Freire <tmiguelf_at_hotmail.com>
Subject: Re: [std-proposals] A draft for a std::arguments proposal
On Tuesday 15 October 2024 22:34:34 GMT-7 Tiago Freire wrote:
> Well, its not my paper.
> It is a view, so you can make a copy of the view, and do whatever you
> want with it.
There are no mutators in the paper and there's no way to construct another std::arguments_view from another array. So yes one can make a copy, but it's always going to be identical.
> "GetCommandLineW" isn't modifiable, nor would
That's not a problem, just don't use that. It's an OS interface, so not portable. The problem is when it is in the standard and gets documented and recommended.
In any case, on Windows, Qt applications require a main() function so they do get argc and argv.
> "/proc/self/cmdline", but that never was a deal breaker.
Actually, /proc/self/cmdline reflects the top-of-stack area of the application, so if you modify the argv area, /proc will reflect it too. That's how applications implement setproctitle() on Linux.
But just like GetCommandLineW(), most people will not use this OS-specific, non-portable way of getting to the command-line because a) it's cumbersome, b) it may be wrong because it may not reflect modifications and c) on Linux, it may be completely wrong because the argv area was overwritten with other data.
$ ps -o command -C avahi-daemon
COMMAND
avahi-daemon: running [tjmaciei-mobl5-13.local]
You shouldn't try to parse that.
> I think you are missing the point.
> And it is not like this is deprecating stuff that exist, everything
> that works right now will still work.
That's not my argument. Neither is it my argument that Qt has something better that you should use instead.
My argument is that std::argument, as currently described in the paper, is *actively dangerous* in a Qt application. It must never, ever be used if you created a QCoreApplication.
> And if std::arguments were to be just a view, wouldn't its interface
> be const, and wouldn't that stop you from using it in Qt's API which
> expects it to be not const? And it is not like modifying argv from
> main is a particularly well-defined thing either.
It's very, very well-defined if all you're doing is modifying the order of the elements in the argv array. It's how the GNU getopt() and getopt_long() functions implement the non-POSIXLY_CORRECT way of handling options after non-
options:
ls foo -l
On Linux, that is the same as ls -l foo, but on a traditional Unix system not using GNU coreutils, that would produce a short listing of foo and complain that file "./-l" does not exist. getopt() works by reordering the arguments and moving all non-options to after, so when it finishes running, the global optind variable points to the first non-option and that runs until argc.
Reordering the arguments to remove options handled by the library is a very common technique for frameworks. Qt requires this.
> You can make the argument that it is a feature that it is not for you,
> but then again, the same is true for more than half of the things in
> the standard.
Not the same thing. There are lots of things I don't plan on ever using, but I don't have a problem with people using them in the same process. Some features may have implementation bugs that interfere with Qt, but bugs can be fixed (e.g., a badly written SIGCHLD handler), especially if caught early. Some other features may have (IMO) poor implementations in a given C++ Standard Library, which I can do better in Qt (std::latch comes to mind).
This is not that. This one is actively harmful because you may be getting content that your application has no way of processing.
For example, all X11 applications, which include Qt ones when the XCB backend is in use, can take a -display argument with the display address. They also usually accept a -geometry argument to set the initial window geometry (Qt does). Session management-enabled applications can be relaunched by the SM with a -session argument with an ID, which is used to configure QSessionManager. This means every single user of std::arguments would need to know not to handle these parameters and all the others (like -platform and
-platformtheme) because Qt did. More than that, they'd have to know when Qt
doesn't: for example, if QSessionManager support isn't compiled in, then Qt won't handle -session and the application should produce an error due to the unknown argument.
--
Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
Principal Engineer - Intel DCAI Platform & System Engineering
Received on 2024-10-16 07:26:01