$ gcc --version
gcc (GCC) 14.2.1 20240912 (Red Hat 14.2.1-3)

$ g++ -O3 -o /tmp/a /tmp/a.cpp
/tmp/a.cpp:4:1: warning: 'int main(int, const char**, const char**, const char**)' takes only zero or two arguments [-Wmain]
4 | main(int argc, const char **argv, const char **envp, const char **auxv)
| ^~~~

So much for backward compatibility and support for the original C++ operating environment (unix).

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 2/2/2025 10:05 AM, Scott Lurndal wrote:

$ gcc --version
gcc (GCC) 14.2.1 20240912 (Red Hat 14.2.1-3)

$ g++ -O3 -o /tmp/a /tmp/a.cpp
/tmp/a.cpp:4:1: warning: 'int main(int, const char**, const char**, const char**)' takes only zero or two arguments [-Wmain]
4 | main(int argc, const char **argv, const char **envp, const char **auxv)
| ^~~~

So much for backward compatibility and support for the original C++ operating environment (unix).

What is auxv? I've used envp, but never auxv.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 2/2/25 13:05, Scott Lurndal wrote:

$ gcc --version
gcc (GCC) 14.2.1 20240912 (Red Hat 14.2.1-3)

$ g++ -O3 -o /tmp/a /tmp/a.cpp /tmp/a.cpp:4:1: warning: 'int main(int,
const char**, const char**, const char**)' takes only zero or two
arguments [-Wmain]
4 | main(int argc, const char **argv, const char **envp, const char
**auxv)
| ^~~~

So much for backward compatibility and support for the original C++
operating
environment (unix).

Does it prevent the code from compiling and executing correctly in a
Unix environment? If not, it has no effect on the backwards
compatibility of the compiler.
Those are the only two forms that all implementations of C and C++ are
required to accept, though they are allowed to accept additional implementation-defined forms. Those statements have been true of both
languages for as long as they've been standardized.
This is only a warning - fully conforming implementations are allowed to
warn about anything they want, such as failing to use taboo words for user-defined identifiers.
The warning is the default for C++, and is turned on by -Wall and
-Wpedantic for C, because it's a reasonable thing to warn about. But if
you disagree with that assessment, it can be turned off by -Wno-main

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

red floyd <no.spam.here@its.invalid> writes:

On 2/2/2025 10:05 AM, Scott Lurndal wrote:

$ gcc --version
gcc (GCC) 14.2.1 20240912 (Red Hat 14.2.1-3)

$ g++ -O3 -o /tmp/a /tmp/a.cpp
/tmp/a.cpp:4:1: warning: 'int main(int, const char**, const char**, const char**)' takes only zero or two arguments [-Wmain]
4 | main(int argc, const char **argv, const char **envp, const char **auxv)
| ^~~~

So much for backward compatibility and support for the original C++ operating
environment (unix).

What is auxv? I've used envp, but never auxv.

It is how the kernel passes parameters to the run-time loader.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Sun, 2 Feb 2025 11:05:44 -0800
red floyd <no.spam.here@its.invalid> wibbled:

On 2/2/2025 10:05 AM, Scott Lurndal wrote:

$ gcc --version
gcc (GCC) 14.2.1 20240912 (Red Hat 14.2.1-3)

$ g++ -O3 -o /tmp/a /tmp/a.cpp
/tmp/a.cpp:4:1: warning: 'int main(int, const char**, const char**, const >char**)' takes only zero or two arguments [-Wmain]
4 | main(int argc, const char **argv, const char **envp, const char >**auxv)
| ^~~~

So much for backward compatibility and support for the original C++ operating

environment (unix).

What is auxv? I've used envp, but never auxv.

Me neither. On Clang + MacOS iterating it seems to gives some exe info:

R8603$ cat t.c
#include <stdio.h>

int main(int arhc, char **argv, char **env, char **aux)
{
for(char **ptr=aux;ptr && *ptr;++ptr) printf("%s\n",*ptr);
return 0;
}
R8603$ ./a.out
executable_path=./a.out



ptr_munge=
main_stack=
executable_file=0x1a0100000e,0x191ca08
dyld_file=0x1a0100000e,0xfffffff0009756e executable_cdhash=2af475e512eee017cd54b8120e4d0c95f32eb523 executable_boothash=d8f37f49eeb78b53a20fa6a5fb2e19a88b444a44
arm64e_abi=os
th_port=
R8603$

However doing the same on LInux causes a segv if you try to decode as a string.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

James Kuyper <jameskuyper@alumni.caltech.edu> writes:

On 2/2/25 13:05, Scott Lurndal wrote:

$ gcc --version
gcc (GCC) 14.2.1 20240912 (Red Hat 14.2.1-3)

$ g++ -O3 -o /tmp/a /tmp/a.cpp /tmp/a.cpp:4:1: warning: 'int main(int,
const char**, const char**, const char**)' takes only zero or two
arguments [-Wmain]
4 | main(int argc, const char **argv, const char **envp, const char
**auxv)
| ^~~~

So much for backward compatibility and support for the original C++
operating
environment (unix).

Does it prevent the code from compiling and executing correctly in a
Unix environment? If not, it has no effect on the backwards
compatibility of the compiler.

Yes, if the programmer had used -Werror, as many do. This is
a recent change to g++.

Those are the only two forms that all implementations of C and C++ are >required to accept, though they are allowed to accept additional >implementation-defined forms. Those statements have been true of both >languages for as long as they've been standardized.
This is only a warning - fully conforming implementations are allowed to
warn about anything they want, such as failing to use taboo words for >user-defined identifiers.
The warning is the default for C++, and is turned on by -Wall and
-Wpedantic for C, because it's a reasonable thing to warn about. But if
you disagree with that assessment, it can be turned off by -Wno-main

My problem is that g++ never warned until recently, so it broke a build
that used -Werror.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Keith Thompson <Keith.S.Thompson+u@gmail.com> writes:

scott@slp53.sl.home (Scott Lurndal) writes:

$ gcc --version
gcc (GCC) 14.2.1 20240912 (Red Hat 14.2.1-3)

$ g++ -O3 -o /tmp/a /tmp/a.cpp
/tmp/a.cpp:4:1: warning: 'int main(int, const char**, const char**, const char**)' takes only zero or two arguments [-Wmain]
4 | main(int argc, const char **argv, const char **envp, const char **auxv)
| ^~~~

So much for backward compatibility and support for the original C++ operating
environment (unix).

Backward compatibility is exactly what you're seeing here.

I would disagree. The application is perfectly legal on unix
and unix-like systems. That it wasn't codified in the C standard
doesn't matter to the programmer who has been using it for decades
and suddenly, the C compiler starts warning on it (esp. if the
programmer uses -Werror). -Wall wasn't specified on that
command line.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Mon, 03 Feb 2025 14:06:27 GMT
scott@slp53.sl.home (Scott Lurndal) wibbled:

James Kuyper <jameskuyper@alumni.caltech.edu> writes:

Those are the only two forms that all implementations of C and C++ are >>required to accept, though they are allowed to accept additional >>implementation-defined forms. Those statements have been true of both >>languages for as long as they've been standardized.
This is only a warning - fully conforming implementations are allowed to >>warn about anything they want, such as failing to use taboo words for >>user-defined identifiers.
The warning is the default for C++, and is turned on by -Wall and >>-Wpedantic for C, because it's a reasonable thing to warn about. But if
you disagree with that assessment, it can be turned off by -Wno-main

My problem is that g++ never warned until recently, so it broke a build
that used -Werror.

Flip flopping between whether something should be an error or not has been a "feature" of gcc ever since I can remember. I used to test compile C programs on a v4 release of gcc because it would error on just about everything if
you set -Wall -pedantic and would spot problems that newer versions missed though thats not the case any more thankfully.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Bonita Montero <Bonita.Montero@gmail.com> writes:

Am 02.02.2025 um 19:05 schrieb Scott Lurndal:

$ gcc --version
gcc (GCC) 14.2.1 20240912 (Red Hat 14.2.1-3)

$ g++ -O3 -o /tmp/a /tmp/a.cpp
/tmp/a.cpp:4:1: warning: 'int main(int, const char**, const char**, const char**)' takes only zero or two arguments [-Wmain]
4 | main(int argc, const char **argv, const char **envp, const char **auxv)
| ^~~~

So much for backward compatibility and support for the original C++ operating
environment (unix).

Use getenv() - you don't need environment-variables you don't know.

There are a number of use cases where your blanket statement is false.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Keith Thompson <Keith.S.Thompson+u@gmail.com> writes:

scott@slp53.sl.home (Scott Lurndal) writes:

James Kuyper <jameskuyper@alumni.caltech.edu> writes:

On 2/2/25 13:05, Scott Lurndal wrote:

$ gcc --version
gcc (GCC) 14.2.1 20240912 (Red Hat 14.2.1-3)

$ g++ -O3 -o /tmp/a /tmp/a.cpp /tmp/a.cpp:4:1: warning: 'int main(int, >>>> const char**, const char**, const char**)' takes only zero or two
arguments [-Wmain]
4 | main(int argc, const char **argv, const char **envp, const char
**auxv)
| ^~~~

So much for backward compatibility and support for the original C++
operating
environment (unix).

Does it prevent the code from compiling and executing correctly in a
Unix environment? If not, it has no effect on the backwards
compatibility of the compiler.

Yes, if the programmer had used -Werror, as many do. This is
a recent change to g++.

That appears not to be the case. I see the same warning by default with >every version of g++ going back to 5.3.0, from 2015.

Thanks for checking.

I see it now on 4.8.3 with g++; I guess I've always compiled code that used auxv with C.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Bonita Montero <Bonita.Montero@gmail.com> writes:

Am 03.02.2025 um 18:46 schrieb Scott Lurndal:

Use getenv() - you don't need environment-variables you don't know.

There are a number of use cases where your blanket statement is false.

extern char **environ;

So what? Every version of unix or unix-like operating
system has provided the environment vector as an
argument to main. They will continue to do that
ad infinitum.

Some applications actually use it.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Bonita Montero <Bonita.Montero@gmail.com> writes:

Am 04.02.2025 um 15:30 schrieb Scott Lurndal:

So what? Every version of unix or unix-like operating
system has provided the environment vector as an
argument to main. They will continue to do that
ad infinitum.

environ is even portable across Windows.a

Windows? Portability? You shouldn't use those
two words in the same sentence.

I don't need, nor care to use Windows for any purpose
whatsoever, professionally or personally.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Bonita Montero <Bonita.Montero@gmail.com> writes:

Am 04.02.2025 um 15:30 schrieb Scott Lurndal:

Bonita Montero <Bonita.Montero@gmail.com> writes:

Am 03.02.2025 um 18:46 schrieb Scott Lurndal:

Use getenv() - you don't need environment-variables you don't know.

There are a number of use cases where your blanket statement is false.

extern char **environ;

So what? Every version of unix or unix-like operating
system has provided the environment vector as an
argument to main. They will continue to do that
ad infinitum.

Polling is inacceptable.

Auf english, das is nicht richtig. "unacceptable" ist besser als "inacceptable".

In either case wtf does 'polling' have to do with the third argument
to main?

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)