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