Re: [Tinycc-devel] Clarification about log message in commit 48df89e10e
> This is all a bit academic, but anyway:
>
> The difference is in "that is part of a definition" and "that is
> not part of a definition". So:
>
>int main();
>
> declares main as function but not anything about parameters (main has no
> prototype then). While:
>
>int main() { ...; return 0; }
>
> declares (and defines) main to be a function having no parameters. Even
> the first variant (i.e. missing prototype without parameter info) is no
> license to make main (or any other function) accept any number of
> parameters. This is because "any number of params" would be a stdarg
> function, which must be declared and defined with a parameter type list
> that includes an ellipsis at the end. You could call such function with
> arbitrary number and types of arguments, and the compiler wouldn't reject
> this, but at runtime it won't work. The prototype is what is checked, so
> without one no checks are done. But even without prototype the calls need
> to match the implementation of the function at run time (otherwise:
> undefined behaviour).
>
> Additionally the "or in some other implementation-defined manner" gives us
> leeway to accept more declarations than strictly required, which makes us
> okay to accept:
>
>void main(void);
>
> (i.e. without return type). That is good, because in the wild this usage
> of main() happens, so we better accept it as well.
>
> > Was this implemented intentionally or just happened?
>
> I'm not sure what "this" refers to here,
I meant the TCC tests here; my apologies for not making it clearer in the
first place.
> but we basically need to accept
> any of these forms of decls and defs of main:
>
> int main();
> int main() { ... }
> void main();
> void main() { ... }
> int main(int argc, char *argv[]);
> int main(int argc, char *argv[]) { ... }
> void main(int argc, char *argv[]);
> void main(int argc, char *argv[]) { ... }
>
> We need to accept these in such way that the user has to be able to
> write a prototype for main, and has to be able to _not_ have to write a
> prototype for it before definition. If he chooses to write a prototype it
> must be compatible with the given definition as usual.
> We need not accept other forms of main. E.g. GCC warns
> with other forms, but TCC does not. Sometimes it's convenient (when you
> know something about the C libraries implementation) to define main like
> so:
>
>int main(int argc, char *argv[], char *envp[]) { ... }
>
> or even add another one (auxv) on some libc's, so adding more checks for
> validity would have to be done carefully to not disallow valid uses in the
> wild.
>
> The reason why main() is so special-cased in the standard is historic.
>
> I'm not sure if the above answers your question(s), if not, try asking
> more ;-)
>
For the moment I think you gave me enough information to grasp.
Thank you very much.
>
> Ciao,
> Michael.
___
Tinycc-devel mailing list
Tinycc-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/tinycc-devel
Re: [Tinycc-devel] Clarification about log message in commit 48df89e10e
On 2021-04-19 17:57:04 +0200, Michael Matz wrote:
> On Mon, 19 Apr 2021, Michael Matz wrote:
> > I'm not sure what "this" refers to here, but we basically need to accept
> > any of these forms of decls and defs of main:
> >
> > int main();
> > int main() { ... }
> > void main();
> > void main() { ... }
>
> Gah! And of course also the ones with void (which does declare a prototype
> even outside of a function def, then, and hence must match a definition if
> there's a separate one):
>
> int main(void);
> int main(void) { ... }
> void main(void);
> void main(void) { ... }
>
> > int main(int argc, char *argv[]);
> > int main(int argc, char *argv[]) { ... }
> > void main(int argc, char *argv[]);
> > void main(int argc, char *argv[]) { ... }
But I think it should warn on the forms without a prototype,
like "int main();".
--
Vincent Lefèvre - Web:
Re: [Tinycc-devel] Clarification about log message in commit 48df89e10e
Hello,
On Mon, 19 Apr 2021, Michael Matz wrote:
I'm not sure what "this" refers to here, but we basically need to accept any
of these forms of decls and defs of main:
int main();
int main() { ... }
void main();
void main() { ... }
Gah! And of course also the ones with void (which does declare a
prototype even outside of a function def, then, and hence must match a
definition if there's a separate one):
int main(void);
int main(void) { ... }
void main(void);
void main(void) { ... }
int main(int argc, char *argv[]);
int main(int argc, char *argv[]) { ... }
void main(int argc, char *argv[]);
void main(int argc, char *argv[]) { ... }
Ciao,
Michael.
___
Tinycc-devel mailing list
Tinycc-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/tinycc-devel
Re: [Tinycc-devel] Clarification about log message in commit 48df89e10e
Hello,
On Sat, 17 Apr 2021, Stefanos wrote:
No particular reason most probably (except in the case when specifically
the standard mandated behaviour of 'int main()' is tested). If you prefer
the void form for new tests use it. (please don't change existing tests
except for good reasons)
The reason I asked this question is because I was reading the C standard and
found the following parts at 5.1.2.2.1 [1] and at 6.7.5.3/14 [2]:
The function called at program startup is named main. The implementation
declares no prototype for this function. It shall be defined with a return
type of int and with no parameters:
int main(void) { /* ... */ }
or with two parameters (referred to here as argc and argv, though any names
may be used, as they are local to the function in which they are declared):
int main(int argc, char *argv[]) { /* ... */ }
or equivalent; 9) or in some other implementation-defined manner.
and
An identifier list declares only the identifiers of the parameters of
the function. An empty list in a function declarator that is part of
a definition of that function specifies that the function has no parameters.
The empty list in a function declarator that is not part of a definition of
that function specifies that no information about the number or types of
the parameters is supplied.
In other words, all the tests that use `int main()` are open to accept
any number of parameters, correct?
This is all a bit academic, but anyway:
The difference is in "that is part of a definition" and "that is
not part of a definition". So:
int main();
declares main as function but not anything about parameters (main has no
prototype then). While:
int main() { ...; return 0; }
declares (and defines) main to be a function having no parameters. Even
the first variant (i.e. missing prototype without parameter info) is no
license to make main (or any other function) accept any number of
parameters. This is because "any number of params" would be a stdarg
function, which must be declared and defined with a parameter type list
that includes an ellipsis at the end. You could call such function with
arbitrary number and types of arguments, and the compiler wouldn't reject
this, but at runtime it won't work. The prototype is what is checked, so
without one no checks are done. But even without prototype the calls need
to match the implementation of the function at run time (otherwise:
undefined behaviour).
Additionally the "or in some other implementation-defined manner" gives us
leeway to accept more declarations than strictly required, which makes us
okay to accept:
void main(void);
(i.e. without return type). That is good, because in the wild this usage
of main() happens, so we better accept it as well.
Was this implemented intentionally or just happened?
I'm not sure what "this" refers to here, but we basically need to accept
any of these forms of decls and defs of main:
int main();
int main() { ... }
void main();
void main() { ... }
int main(int argc, char *argv[]);
int main(int argc, char *argv[]) { ... }
void main(int argc, char *argv[]);
void main(int argc, char *argv[]) { ... }
We need to accept these in such way that the user has to be able to
write a prototype for main, and has to be able to _not_ have to write a
prototype for it before definition. If he chooses to write a prototype it
must be compatible with the given definition as usual.
We need not accept other forms of main. E.g. GCC warns
with other forms, but TCC does not. Sometimes it's convenient (when you
know something about the C libraries implementation) to define main like
so:
int main(int argc, char *argv[], char *envp[]) { ... }
or even add another one (auxv) on some libc's, so adding more checks for
validity would have to be done carefully to not disallow valid uses in the
wild.
The reason why main() is so special-cased in the standard is historic.
I'm not sure if the above answers your question(s), if not, try asking
more ;-)
Ciao,
Michael.
___
Tinycc-devel mailing list
Tinycc-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/tinycc-devel
Re: [Tinycc-devel] Status of C language support, et al
Also complex and float functions of different types (float, double, long double, float _Complex, double _Complex and long double _Complex) are not supported. -Original Message- From: Tinycc-devel [mailto:tinycc-devel-bounces+eligis=orange...@nongnu.org] On Behalf Of yangrq Sent: Monday, April 19, 2021 11:04 To: tinycc-devel@nongnu.org Subject: Re: [Tinycc-devel] Status of C language support, et al > * Which features are still missing, for example from C99 and C11? I did some tests and found the following features in C11 are missing: * 7.3.9.3 The CMPLX macros * 6.4.5/3 UTF−8 string literal (prefixed by `u8`) ___ Tinycc-devel mailing list Tinycc-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/tinycc-devel ___ Tinycc-devel mailing list Tinycc-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/tinycc-devel
Re: [Tinycc-devel] Status of C language support, et al
> * Which features are still missing, for example from C99 and C11? I did some tests and found the following features in C11 are missing: * 7.3.9.3 The CMPLX macros * 6.4.5/3 UTF−8 string literal (prefixed by `u8`) ___ Tinycc-devel mailing list Tinycc-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/tinycc-devel
Re: [Tinycc-devel] Status of C language support, et al
> * Which features are still missing, for example from C99 and C11? > > We do not want bloated tcc, but winapi section needs to include, by default, the following three much used header files and libraries: commctrl.h comdlg.h mmsystem.h ___ Tinycc-devel mailing list Tinycc-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/tinycc-devel
