Re: [Tinycc-devel] incorrect/missing license files
Thomas Preud'homme wrote: If both of you answer yes, could you commit the change Grischka? Change the FSF header in lib/libtcc1.c? I'm not sure they would agree. However it allows being linked into any program anyway. Why would they have to agree? They are not author of this file. Only the author need to agree to such change, they are the one who decide what license applies. And the author is? libtcc1.c:148: /* most of this code is taken from libgcc2.c from gcc */ However, as Vincent suggested, it would be even better to put both GPL and BSD copyright notice, thus making the file dual licensed. It's not very useful as the BSD could be relicensed to GPL by doing some change but it doesn't hurt and gives more choice. Of course this only applies to old file, new one would just use BSD. Since libtcc1.c is part of a library (and tcc doesn't have LTO) I'd rather suggest to put everything not related to float conversion into its own file each. --- grischka Best regards, Thomas ___ Tinycc-devel mailing list Tinycc-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/tinycc-devel
Re: [Tinycc-devel] Crosscompiling
On Sun, Jun 29, 2014 at 11:17 PM, grischka wrote: > Markus Bergholz wrote: > >> However, both end up with "Mex file entry point it missing". >> > > __declspec(dllexport) > > This works, thank you! > -- gr > > >> Thanks in advanced, >> Markus >> > > > ___ > Tinycc-devel mailing list > Tinycc-devel@nongnu.org > https://lists.nongnu.org/mailman/listinfo/tinycc-devel > -- icq: 167498924 XMPP|Jabber: marku...@jabber.ccc.de ___ Tinycc-devel mailing list Tinycc-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/tinycc-devel
Re: [Tinycc-devel] isxdigit conversion inconsistency with widechar
2014-06-30 10:45 GMT-04:00 Thomas Preud'homme : > Le dimanche 29 juin 2014, 22:10:01 Carlos Montiers a écrit : > > Hello. > > Currently, in the last version (from git) of tiny c, when you use the > > function: > > > > isxdigit it produce this call: isxdigit > > > > but when you use the widechar version: iswxdigit : > > > > iswxdigit produce this call: iswctype(d, _HEX) > > > > Then, when you use isxdigit tiny c would be generate the call to: > > _isctype(d, _HEX) > > Not very consistent I agree but how is that a bug? > > Best regards, > > Thomas > ___ > Tinycc-devel mailing list > Tinycc-devel@nongnu.org > https://lists.nongnu.org/mailman/listinfo/tinycc-devel > > Yes. It is not a bug. But, I post this for the knowledge. I inspect mscvrt.dll and isxdigit internally call to _isctype. Then I think is more speedy call directly to _isctype instead of isxdigit. But the current macro of tiny c not call to it like the counterpart iswxdigit. Because it I post my little fix: #undefisxdigit #undefiswxdigit #defineisxdigit(d) _isctype(d, _HEX) #defineiswxdigit(d)iswctype(d, _HEX) ___ Tinycc-devel mailing list Tinycc-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/tinycc-devel
Re: [Tinycc-devel] Problem using alloca
I think is a bug of tiny c. I use the tiny c for x86. The problem is that the stack overflow exception that generates alloca, is not catched with the function passed to SetUnhandledExceptionFilter. This only happen with the executable created with tiny c. When I compile the executable with mingw. The exception is catched ok. I imitate the behavior with malloc, if the allocation fails, I set the pointer to NULL. I use MAX_INT intentionally for provocate the exception. Executable created with mingw print alloca Failed Executable created with the last tiny c for x86: crash !! I know that the default stack size on windows for the executable is only 1mb. But I want use the method with alloca as a recovery method when malloc fails (improbable but possible). Carlos. 2014-06-30 10:44 GMT-04:00 Thomas Preud'homme : > Le dimanche 29 juin 2014, 21:38:33 Carlos Montiers a écrit : > > Hello. > > I requesting memory from the stack using the function alloca. > > I know that the use of it is discourage, but I want use it anyways. > > > > I write a code for windows that use it and I tested ok, but only when I > > compile with gcc. Compiling it with tiny c fails, the program crash. > > Maybe is a bug of tiny c. > > I assume that your program is compiled on Windows 64 bits, given the alloca > (INT_MAX). The definition of alloca for Windows 64 bits is in > lib/alloca86_64.S. When the parameter is bigger than 4096, then it will do > a > loop that allocates 4096 bytes on the stack, read a value on the stack and > start all over again until all the space asked is allocated. I suppose that > the goal of the read is to make Windows actually allocate the space to > avoid > an error if a big alloca is made. > > I don't know for Windows but on Linux nothing is allocated as long as > nothing > is written. So a big alloca would do nothing and then writing a bit > structure > on the stack would fail as it would make the stack grow too quickly. I > guess > that's what is happening here. Try to reduce the amount given to alloca > (Try > 8192 for instance). > > Best regards, > > Thomas ___ Tinycc-devel mailing list Tinycc-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/tinycc-devel
[Tinycc-devel] 回复: Request push
I'm sorry! Is I am too impatient. Thank you for your remind and Suggestions.
I'll take the time to put a bug in greater detail.
Best regards,
jiang
Thomas Preud'homme 编写：
>Le lundi 30 juin 2014, 16:49:02 jiang a écrit :
>> Struct improved algorithms and add struct warnings and other warnings.
>
>Hi Jiang,
>
>>
>> The following can be compiled:
>> struct st{int a;;;};
>>
>> If you do not have advice, tomorrow pushed into the mob.
>
>No Jiang, that's not how it works. There is several problem with this request:
>
>1) You need to realize that we are all volunteer spending some of our free
>time to improve tcc. We don't necessarily check emails about tcc everyday and
>anyway 1 day is too short to review. Another consequence of this is that we
>don't have to answer within a given delay. We will do our best to answer but
>you just need to wait. Of course if too much time (like 2 weeks) pass without
>answer you can ping to ask if we saw your email. And finally I think in your
>case you should not commit without an approval first. Eventually, when your
>commit will start to improve we might tell you that you don't need to ask for
>a review anymore.
>
>2) I gave you some comments on another patch. Before asking for another review
>you could maybe post a new version that fixes all my comments. It gives the
>feeling that you don't want to address the remarks and discourages people to
>review your patches.
>
>3) Don't bundle several changes in one patch. It makes it more difficult to
>review. So you make one patch that fixes the bug you mentions and others (or
>maybe just one other, it depends how big it is) with the warnings
>
>4) Your patch contains some formatting issues:
>
>+ if (v == 0 && (type1.t & VT_BTYPE) != VT_STRUCT){
>+ tcc_warning("declaration does not declare
>anything");
>+ break;
>+ }if (type_size(&type1, &align) < 0) {
>+ if ((a == TOK_STRUCT) && (type1.t & VT_ARRAY))
>+ flexible = 1;
>+ else
>+ tcc_error("field '%s' has incomplete type",
>get_tok_str(v, NULL));
> }
>
>There should be a space between the closing parenthesis ')' and the opening
>curly brace '{'. The second "if" should be on a new line or should be preceded
>by a "else"
>
>5) The commit message is not very informative. For the commit with the bugfix
>you could say "Allow tcc to parse:" and then the example. See commit
>82969f045c99b4d1ef833de35117c17b326b46c0 for an example. You can also simply
>explain what bug you fix "Fix parsing of arbitrary number of semicolons" or
>something better and that brings me to the next comment.
>
>6) You need to understand how a language is designed.
>
>- parse_btype(&btype, &ad);
>+ if(!parse_btype(&btype, &ad)){
>+ if (tok == ';'){
>+ skip(';');
>+ continue;
>
>Here you are saying that it's ok to have struct st {int a;} but not struct
>st {int a:10}. A better place to add such a check would be near the end of
>the function, around the "skip(';'). You need to understand why this is
>authorized. So as an exercise grab the C99 standard at [1] and tell me why
>this is authorized. Hint: start to read from section 6.7.2.1. Definitions are
>recursive, so you need to browse quite a lot to understand things. Try to tell
>me which lexical elements to follow (sorry, I don't know the proper term,
>shame on me) to create your testcase. Something like:
>
>struct-or-union-specifier
> -> struct-or-union
> -> identifier (no need to detail here)
> -> struct-declaration-list
> -> struct-declaration
>
>etc…
>
>[1] http://www.open-std.org/jtc1/sc22/WG14/www/docs/n1256.pdf
>
>Best regards,
>
>Thomas
___
Tinycc-devel mailing list
Tinycc-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/tinycc-devel
Re: [Tinycc-devel] incorrect/missing license files
Le dimanche 29 juin 2014, 23:57:08 grischka a écrit : > Thomas Preud'homme wrote: > > It should yes. Grischka, Shinichiro, James: do you agree to relicense your > > contributions to lib/libtcc1.c under the BSD variants in RELICENSING file? > > Is not that what people listed in RELICENSING already did agree to? That was the intent but the field File/feature is confusing. It feels as if only the specified file/feature is relicensed. That's how Daniel used this field and I don't see what other purpose would this file have. Therefore I recommend that you replace the value you put in this field by a *. > > > If both of you answer yes, could you commit the change Grischka? > > Change the FSF header in lib/libtcc1.c? I'm not sure they would > agree. However it allows being linked into any program anyway. Why would they have to agree? They are not author of this file. Only the author need to agree to such change, they are the one who decide what license applies. However, as Vincent suggested, it would be even better to put both GPL and BSD copyright notice, thus making the file dual licensed. It's not very useful as the BSD could be relicensed to GPL by doing some change but it doesn't hurt and gives more choice. Of course this only applies to old file, new one would just use BSD. Best regards, Thomas signature.asc Description: This is a digitally signed message part. ___ Tinycc-devel mailing list Tinycc-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/tinycc-devel
Re: [Tinycc-devel] isxdigit conversion inconsistency with widechar
Le dimanche 29 juin 2014, 22:10:01 Carlos Montiers a écrit : > Hello. > Currently, in the last version (from git) of tiny c, when you use the > function: > > isxdigit it produce this call: isxdigit > > but when you use the widechar version: iswxdigit : > > iswxdigit produce this call: iswctype(d, _HEX) > > Then, when you use isxdigit tiny c would be generate the call to: > _isctype(d, _HEX) Not very consistent I agree but how is that a bug? Best regards, Thomas signature.asc Description: This is a digitally signed message part. ___ Tinycc-devel mailing list Tinycc-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/tinycc-devel
Re: [Tinycc-devel] Problem using alloca
Le dimanche 29 juin 2014, 21:38:33 Carlos Montiers a écrit : > Hello. > I requesting memory from the stack using the function alloca. > I know that the use of it is discourage, but I want use it anyways. > > I write a code for windows that use it and I tested ok, but only when I > compile with gcc. Compiling it with tiny c fails, the program crash. > Maybe is a bug of tiny c. I assume that your program is compiled on Windows 64 bits, given the alloca (INT_MAX). The definition of alloca for Windows 64 bits is in lib/alloca86_64.S. When the parameter is bigger than 4096, then it will do a loop that allocates 4096 bytes on the stack, read a value on the stack and start all over again until all the space asked is allocated. I suppose that the goal of the read is to make Windows actually allocate the space to avoid an error if a big alloca is made. I don't know for Windows but on Linux nothing is allocated as long as nothing is written. So a big alloca would do nothing and then writing a bit structure on the stack would fail as it would make the stack grow too quickly. I guess that's what is happening here. Try to reduce the amount given to alloca (Try 8192 for instance). Best regards, Thomas signature.asc Description: This is a digitally signed message part. ___ Tinycc-devel mailing list Tinycc-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/tinycc-devel
Re: [Tinycc-devel] Request push
Le lundi 30 juin 2014, 16:49:02 jiang a écrit :
> Struct improved algorithms and add struct warnings and other warnings.
Hi Jiang,
>
> The following can be compiled:
> struct st{int a;;;};
>
> If you do not have advice, tomorrow pushed into the mob.
No Jiang, that's not how it works. There is several problem with this request:
1) You need to realize that we are all volunteer spending some of our free
time to improve tcc. We don't necessarily check emails about tcc everyday and
anyway 1 day is too short to review. Another consequence of this is that we
don't have to answer within a given delay. We will do our best to answer but
you just need to wait. Of course if too much time (like 2 weeks) pass without
answer you can ping to ask if we saw your email. And finally I think in your
case you should not commit without an approval first. Eventually, when your
commit will start to improve we might tell you that you don't need to ask for
a review anymore.
2) I gave you some comments on another patch. Before asking for another review
you could maybe post a new version that fixes all my comments. It gives the
feeling that you don't want to address the remarks and discourages people to
review your patches.
3) Don't bundle several changes in one patch. It makes it more difficult to
review. So you make one patch that fixes the bug you mentions and others (or
maybe just one other, it depends how big it is) with the warnings
4) Your patch contains some formatting issues:
+if (v == 0 && (type1.t & VT_BTYPE) != VT_STRUCT){
+tcc_warning("declaration does not declare
anything");
+break;
+}if (type_size(&type1, &align) < 0) {
+if ((a == TOK_STRUCT) && (type1.t & VT_ARRAY))
+flexible = 1;
+else
+tcc_error("field '%s' has incomplete type",
get_tok_str(v, NULL));
}
There should be a space between the closing parenthesis ')' and the opening
curly brace '{'. The second "if" should be on a new line or should be preceded
by a "else"
5) The commit message is not very informative. For the commit with the bugfix
you could say "Allow tcc to parse:" and then the example. See commit
82969f045c99b4d1ef833de35117c17b326b46c0 for an example. You can also simply
explain what bug you fix "Fix parsing of arbitrary number of semicolons" or
something better and that brings me to the next comment.
6) You need to understand how a language is designed.
-parse_btype(&btype, &ad);
+if(!parse_btype(&btype, &ad)){
+if (tok == ';'){
+skip(';');
+continue;
Here you are saying that it's ok to have struct st {int a;} but not struct
st {int a:10}. A better place to add such a check would be near the end of
the function, around the "skip(';'). You need to understand why this is
authorized. So as an exercise grab the C99 standard at [1] and tell me why
this is authorized. Hint: start to read from section 6.7.2.1. Definitions are
recursive, so you need to browse quite a lot to understand things. Try to tell
me which lexical elements to follow (sorry, I don't know the proper term,
shame on me) to create your testcase. Something like:
struct-or-union-specifier
-> struct-or-union
-> identifier (no need to detail here)
-> struct-declaration-list
-> struct-declaration
etc…
[1] http://www.open-std.org/jtc1/sc22/WG14/www/docs/n1256.pdf
Best regards,
Thomas
signature.asc
Description: This is a digitally signed message part.
___
Tinycc-devel mailing list
Tinycc-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/tinycc-devel
Re: [Tinycc-devel] Request push
Struct improved algorithms and add struct warnings and other warnings.
The following can be compiled:
struct st{int a;;;};
If you do not have advice, tomorrow pushed into the mob.
jiang
commit 8be2fbd82ef16c8f846fccb46689827ed37997eb
Author: jiang <30155...@qq.com>
Date: Mon Jun 30 16:40:16 2014 +0800
Add warning
diff --git a/libtcc.c b/libtcc.c
index 7caa7c1..79a2d2c 100644
--- a/libtcc.c
+++ b/libtcc.c
@@ -1397,8 +1397,9 @@ static const FlagDef warning_defs[] = {
{ offsetof(TCCState, warn_unsupported), 0, "unsupported" },
{ offsetof(TCCState, warn_write_strings), 0, "write-strings" },
{ offsetof(TCCState, warn_error), 0, "error" },
-{ offsetof(TCCState, warn_implicit_function_declaration), WD_ALL,
- "implicit-function-declaration" },
+{ offsetof(TCCState, warn_implicit_function_declaration), WD_ALL,
"implicit-function-declaration" },
+{ offsetof(TCCState, warn_return_type), WD_ALL, "return-type" },
+{ offsetof(TCCState, warn_char_subscripts), WD_ALL, "char-subscripts" },
};
ST_FUNC int set_flag(TCCState *s, const FlagDef *flags, int nb_flags,
diff --git a/tcc.h b/tcc.h
index c93cedf..596b22f 100644
--- a/tcc.h
+++ b/tcc.h
@@ -594,6 +594,8 @@ struct TCCState {
int warn_error;
int warn_none;
int warn_implicit_function_declaration;
+int warn_return_type;
+int warn_char_subscripts;
/* compile with debug symbol (and use them if error during execution) */
int do_debug;
diff --git a/tccgen.c b/tccgen.c
index 1a89d4a..227864e 100644
--- a/tccgen.c
+++ b/tccgen.c
@@ -2898,42 +2898,47 @@ static void struct_decl(CType *type, int u, int tdef)
offset = 0;
flexible = 0;
while (tok != '}') {
-parse_btype(&btype, &ad);
+if(!parse_btype(&btype, &ad)){
+if (tok == ';'){
+skip(';');
+continue;
+}else if(tok == TOK_EOF || tok == '{')
+expect("specifier-qualifier-list at end of input");
+}
while (1) {
- if (flexible)
- tcc_error("flexible array member '%s' not at the end of
struct",
- get_tok_str(v, NULL));
+if (flexible)
+tcc_error("flexible array member '%s' not at the end
of struct", get_tok_str(v, NULL));
bit_size = -1;
v = 0;
type1 = btype;
if (tok != ':') {
type_decl(&type1, &ad, &v, TYPE_DIRECT |
TYPE_ABSTRACT);
-if (v == 0 && (type1.t & VT_BTYPE) != VT_STRUCT)
-expect("identifier");
-if (type_size(&type1, &align) < 0) {
- if ((a == TOK_STRUCT) && (type1.t & VT_ARRAY) && c)
- flexible = 1;
- else
- tcc_error("field '%s' has incomplete type",
- get_tok_str(v, NULL));
+if (v == 0 && (type1.t & VT_BTYPE) != VT_STRUCT){
+tcc_warning("declaration does not declare
anything");
+break;
+}if (type_size(&type1, &align) < 0) {
+if ((a == TOK_STRUCT) && (type1.t & VT_ARRAY))
+flexible = 1;
+else
+tcc_error("field '%s' has incomplete type",
get_tok_str(v, NULL));
}
if ((type1.t & VT_BTYPE) == VT_FUNC ||
(type1.t & (VT_TYPEDEF | VT_STATIC | VT_EXTERN |
VT_INLINE)))
-tcc_error("invalid type for '%s'",
- get_tok_str(v, NULL));
+tcc_error("invalid type for '%s'", get_tok_str(v,
NULL));
}
if (tok == ':') {
next();
bit_size = expr_const();
/* XXX: handle v = 0 case for messages */
if (bit_size < 0)
-tcc_error("negative width in bit-field '%s'",
- get_tok_str(v, NULL));
+tcc_error("negative width in bit-field '%s'",
get_tok_str(v, NULL));
if (v && bit_size == 0)
-tcc_error("zero width for bit-field '%s'",
- get_tok_str(v, NULL));
+tcc_error("zero width for bit-field '%s'",
get_tok_str(v, NULL));
}
-size = type_size(&type1, &align);
+if(type1.t & VT_VLA)
+size = 0, align = 1;
+
