Visual C++ wrong entry point

[Laurent Schall]

I experience a problem where starting an application compiled with
visual C++ 6 SP5 does not execute the function main(int argc, char
**argv) and exit immediately with code 1 (0x1).

Putting main as an entry point in the section Project -> settings ->
link -> output -> entry-point symbol, makes the program calling main
but my argc and argv arguments are both equal to 0.

Has anyone an idea ?

 

[John Harrison]

I experience a problem where starting an application compiled with
visual C++ 6 SP5 does not execute the function main(int argc, char
**argv) and exit immediately with code 1 (0x1).

Putting main as an entry point in the section Project -> settings ->
link -> output -> entry-point symbol, makes the program calling main
but my argc and argv arguments are both equal to 0.

Has anyone an idea ?

Maybe your program contains global objects whose constructors fail. Does
this sound plausible?

Setting the entry point under project settings sounds like a really bad
idea, you were just messing with something you didn't understand.

john

 

[Alf P. Steinbach]

* (e-mail address removed) (Laurent Schall) schriebt:

I experience a problem where starting an application compiled with
visual C++ 6 SP5 does not execute the function main(int argc, char
**argv) and exit immediately with code 1 (0x1).

As John Harrison responded, perhaps your program contains global objects
whose constructors fail.

Another possibility might be that you have used that compiler's non-standard
feature where instead of 'main' a 'WinMain' or some such (there are actually
several possibilities) is executed; in that case change the project settings
or modify the compiler/linker arguments appropriately; see your documentation.

Putting main as an entry point in the section Project -> settings ->
link -> output -> entry-point symbol, makes the program calling main
but my argc and argv arguments are both equal to 0.

Has anyone an idea?

Yes, that is off-topic in this group, but in order to get you back on
track: the entry point you specify to the linker, almost regardless of
which C++ implementation, is _not_ the 'main' function, but some function
in that C++ implementation's runtime library that in turn calls 'main'.

 

[Julie]

I experience a problem where starting an application compiled with
visual C++ 6 SP5 does not execute the function main(int argc, char
**argv) and exit immediately with code 1 (0x1).

Putting main as an entry point in the section Project -> settings ->
link -> output -> entry-point symbol, makes the program calling main
but my argc and argv arguments are both equal to 0.

Has anyone an idea ?

Main is defined as:

int main(int argc, char * argv[])

I don't know if that will solve your problem or not, but it is a start.

 

[Johannes Bauer]

Main is defined as:

int main(int argc, char * argv[])

Which differs to Laurents definition (char** instead of char*[]) in what
way?

Johannes

 

[Julie]

Main is defined as:

int main(int argc, char * argv[])

Which differs to Laurents definition (char** instead of char*[]) in what
way?

Johannes

Don't ask me -- ask the standards committee or refer to the current C++
standard.

I was simply trying to point out that the OP's implementation of main wasn't
conformant to the standard. My guess is that it might be possible that when
the compiler/linker is resolving the call to main, it doesn't resolve to the
OP's implementation, and thus resulted in their reported problem ???

 

[Artie Gold]

Main is defined as:

int main(int argc, char * argv[])

Which differs to Laurents definition (char** instead of char*[]) in what
way?

Johannes

Don't ask me -- ask the standards committee or refer to the current C++
standard.

I was simply trying to point out that the OP's implementation of main wasn't
conformant to the standard. My guess is that it might be possible that when
the compiler/linker is resolving the call to main, it doesn't resolve to the
OP's implementation, and thus resulted in their reported problem ???

You miss the point.

int main(int argc, char * argv[])

and

int main(int argc, char ** argv)

Are totally equivalent signatures. Indistinguishable to the compiler.

HTH,
--ag

 

[Julie]

You miss the point.

int main(int argc, char * argv[])

and

int main(int argc, char ** argv)

Are totally equivalent signatures. Indistinguishable to the compiler.

I didn't miss the point.

Where in the standard does it say that *var[] is equivalent to **var or that
they mangle the same, or that main can be implemented w/ char **?

 

[Alf P. Steinbach]

Where in the standard does it say that *var[] is equivalent to **var or that
they mangle the same, or that main can be implemented w/ char **?

§8.3.5/3. This specifies what information is used to determine a function's
type (otherwise known as its signature), which all declarations of a given
function must agree on. First array parameters are changed to pointers. Then
cv-qualifiers such as 'const' are deleted. Then e.g. 'register' is deleted.
Then what you're left with is the function type.

And that means, if I'm not totally mistaken, that


int main( int const nArgs, char const * const * args )


is perfectly good -- actually a bit better, I'd suggest, than the example
given in the standard...

;-)

 

[Mike Wahler]

You miss the point.

int main(int argc, char * argv[])

and

int main(int argc, char ** argv)

Are totally equivalent signatures. Indistinguishable to the compiler.

I didn't miss the point.

I think you did.

Where in the standard does it say that *var[] is equivalent to **var or that
they mangle the same,

No 'mangling' is occurring.

or that main can be implemented w/ char **?

ISO/IEC 14882:1998(E)

[....]

8.3.5 Functions

[....]

3

[...]

The type of a function is determined using the following rules.
The type of each parameter is determined from its own decl­
specifier­seq and declarator. After determining the type of each
parameter, any parameter of type "array of T" or "function
returning T" is adjusted to be "pointer to T" or "pointer to
function returning T," respectively.

-Mike

 

[Rob Williscroft]

Alf P. Steinbach wrote in

Where in the standard does it say that *var[] is equivalent to **var
or that they mangle the same, or that main can be implemented w/ char
**?

§8.3.5/3. This specifies what information is used to determine a
function's type (otherwise known as its signature), which all
declarations of a given function must agree on. First array
parameters are changed to pointers. Then cv-qualifiers such as
'const' are deleted. Then e.g. 'register' is deleted. Then what
you're left with is the function type.

And that means, if I'm not totally mistaken, that


int main( int const nArgs, char const * const * args )


is perfectly good -- actually a bit better, I'd suggest, than the
example given in the standard...

;-)

Are you sure, I read the standard as saying the cv-qualifier modifying
the paramiter type is removed, this is:

char * const -> char *, not
char const * -> char *.

In essence char * const and char * are different cv-qualifications of
the same type, where as char const * and char * are different types.

So int main( int const, char ** const ); is as much "const" as you
can legaly add to the usual int main( int, char ** );

Rob.

 

[Alf P. Steinbach]

Alf P. Steinbach wrote in

Where in the standard does it say that *var[] is equivalent to **var
or that they mangle the same, or that main can be implemented w/ char
**?

§8.3.5/3. This specifies what information is used to determine a
function's type (otherwise known as its signature), which all
declarations of a given function must agree on. First array
parameters are changed to pointers. Then cv-qualifiers such as
'const' are deleted. Then e.g. 'register' is deleted. Then what
you're left with is the function type.

And that means, if I'm not totally mistaken, that


int main( int const nArgs, char const * const * args )


is perfectly good -- actually a bit better, I'd suggest, than the
example given in the standard...

;-)

Are you sure, I read the standard as saying the cv-qualifier modifying
the paramiter type is removed, this is:

char * const -> char *, not
char const * -> char *.

In essence char * const and char * are different cv-qualifications of
the same type, where as char const * and char * are different types.

So int main( int const, char ** const ); is as much "const" as you
can legaly add to the usual int main( int, char ** );

Your interpretation seems much more reasonable and correct, yes.

After all it's logical that a const at the outermost level doesn't affect
what you can pass as actual arguments, whereas other const's will.

But I _like_ that version of 'main', I _want_ that version of 'main'... ;-)

 

[Default User]

Where in the standard does it say that *var[] is equivalent to **var or that
they mangle the same, or that main can be implemented w/ char **?

The C standard helpfully adds a footnote for those who don't know that *
and [] are completely equivalent in function signatures:


8) Thus, int can be replaced by a typedef name defined as
int, or the type of argv can be written as char ** argv,
and so on.



Brian Rodenborn

 

[Julie]

Where in the standard does it say that *var[] is equivalent to **var or that
they mangle the same, or that main can be implemented w/ char **?

The C standard helpfully adds a footnote for those who don't know that *
and [] are completely equivalent in function signatures:

8) Thus, int can be replaced by a typedef name defined as
int, or the type of argv can be written as char ** argv,
and so on.

Brian Rodenborn

I was not aware -- thanks to all that have pointed me in the right direction in
the standard.

I stand corrected, char ** argv to char * argv[] will most likely *not* solve
the OP's problem.