Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.c++ > #121480 > unrolled thread

Now this is just annoying.

Back to article view | Back to comp.lang.c++

Contents

  Now this is just annoying. scott@slp53.sl.home (Scott Lurndal) - 2025-02-02 18:05 +0000
    Re: Now this is just annoying. red floyd <no.spam.here@its.invalid> - 2025-02-02 11:05 -0800
      Re: Now this is just annoying. Muttley@DastardlyHQ.org - 2025-02-03 08:55 +0000
      Re: Now this is just annoying. scott@slp53.sl.home (Scott Lurndal) - 2025-02-03 14:02 +0000
        Re: Now this is just annoying. Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2025-02-03 15:34 -0800
    Re: Now this is just annoying. Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2025-02-02 15:22 -0800
      Re: Now this is just annoying. scott@slp53.sl.home (Scott Lurndal) - 2025-02-03 14:05 +0000
    Re: Now this is just annoying. James Kuyper <jameskuyper@alumni.caltech.edu> - 2025-02-02 18:43 -0500
      Re: Now this is just annoying. scott@slp53.sl.home (Scott Lurndal) - 2025-02-03 14:06 +0000
        Re: Now this is just annoying. Muttley@DastardlyHQ.org - 2025-02-03 14:10 +0000
        Re: Now this is just annoying. Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2025-02-03 15:21 -0800
          Re: Now this is just annoying. scott@slp53.sl.home (Scott Lurndal) - 2025-02-03 23:54 +0000
    Re: Now this is just annoying. Bonita Montero <Bonita.Montero@gmail.com> - 2025-02-03 15:16 +0100
      Re: Now this is just annoying. scott@slp53.sl.home (Scott Lurndal) - 2025-02-03 17:46 +0000
        Re: Now this is just annoying. Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2025-02-03 15:33 -0800
        Re: Now this is just annoying. Bonita Montero <Bonita.Montero@gmail.com> - 2025-02-04 07:20 +0100
          Re: Now this is just annoying. scott@slp53.sl.home (Scott Lurndal) - 2025-02-04 14:30 +0000
            Re: Now this is just annoying. Bonita Montero <Bonita.Montero@gmail.com> - 2025-02-04 17:25 +0100
              Re: Now this is just annoying. scott@slp53.sl.home (Scott Lurndal) - 2025-02-04 20:20 +0000
            Re: Now this is just annoying. Bonita Montero <Bonita.Montero@gmail.com> - 2025-02-05 08:53 +0100
              Re: Now this is just annoying. scott@slp53.sl.home (Scott Lurndal) - 2025-02-05 15:09 +0000
                Re: Now this is just annoying. Bonita Montero <Bonita.Montero@gmail.com> - 2025-02-05 16:11 +0100
                  Re: Now this is just annoying. "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2025-02-05 11:46 -0800

Page 1 of 2  [1] 2  Next page →

#121480 — Now this is just annoying.

$ 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).

[toc] | [next] | [standalone]

#121481

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.

[toc] | [prev] | [next] | [standalone]

#121485

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.

[toc] | [prev] | [next] | [standalone]

#121487

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.

[toc] | [prev] | [next] | [standalone]

#121495

scott@slp53.sl.home (Scott Lurndal) writes:
> 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.

See also the getauxval() function (apparently specific to ELF executables).

-- 
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
void Void(void) { Void(); } /* The recursive call of the void */

[toc] | [prev] | [next] | [standalone]

#121483

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.

g++ is warning you that your main function doesn't have one of the two
forms required by the C++ standard, but it's still compiling it.
You can even disable the warning with "-Wno-main".

BTW, the warning is slightly misleading.  It's not emitted if main is
defined with 3 parameters (argc, argv, envp).

-- 
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
void Void(void) { Void(); } /* The recursive call of the void */

[toc] | [prev] | [next] | [standalone]

#121488

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.

[toc] | [prev] | [next] | [standalone]

#121484

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

[toc] | [prev] | [next] | [standalone]

#121489

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.

[toc] | [prev] | [next] | [standalone]

#121490

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.

[toc] | [prev] | [next] | [standalone]

#121493

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.

gcc (the C compiler) does not produce this warning by default, but it
can be enabled by "-Wmain", which is included in "-Wall".  I just tried
30 versions of g++ from 5.3.0 up to 14.2.0; they all produced the warning.

>>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.

See above.

Is it possible that you've been using a *very* old version
of g++, or that you've had some kind of configuration that dissables
the warning, or that you've confused the C++ and C compilers?

See if you can confirm that some version of g++ does not produce this
warning by default.  If so, the details could be interesting.

-- 
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
void Void(void) { Void(); } /* The recursive call of the void */

[toc] | [prev] | [next] | [standalone]

#121496

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.

[toc] | [prev] | [next] | [standalone]

#121491

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.

[toc] | [prev] | [next] | [standalone]

#121492

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.

[toc] | [prev] | [next] | [standalone]

#121494

scott@slp53.sl.home (Scott Lurndal) writes:
> 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.

It's both false (try implementing the printenv command with just
getenv()) and irrelevant.  It's the 4th parameter to main, auxv, that
triggers the warning.  And the environment vector can be accessed either
by defining
    char **envp
as a parameter to main, or by declaring
    extern char **environ;
(The envp parameter is a common extension, but it's not specified by
POSIX.  environ is.)

And the information provided by the auxv parameter can be accessed via
the getauxval() function *if* your implementation provides it.
Apparently it's specific to ELF executables.

-- 
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
void Void(void) { Void(); } /* The recursive call of the void */

[toc] | [prev] | [next] | [standalone]

#121499

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;

[toc] | [prev] | [next] | [standalone]

#121501

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.

[toc] | [prev] | [next] | [standalone]

#121502

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.

[toc] | [prev] | [next] | [standalone]

#121504

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.

[toc] | [prev] | [next] | [standalone]

#121509

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.

> Some applications actually use it.
> 

[toc] | [prev] | [next] | [standalone]

Page 1 of 2  [1] 2  Next page →

Back to top | Article view | comp.lang.c++

csiph-web