[perl #45359] [TODO] Enumerate all non-C89 assumptions that Parrot depends on
# New Ticket Created by Paul Cochrane
# Please include the string: [perl #45359]
# in the subject line of all future correspondence about this issue.
# URL: http://rt.perl.org/rt3/Ticket/Display.html?id=45359
In the coding standards PDD (pdd07) there is the todo item:
{{ TODO: Enumerate all other non-C89 assumptions that Parrot depends on. }}
For context, the rest of the section where this appears reads:
C code must generally depend on only those language and library features
specified by the ISO C89 standard.
In addition, C code may assume that any pointer value can be coerced to an
integral type (no smaller than typedef CINTVAL in Parrot), then back to its
original type, without loss.
Also C code may assume that there is a single NULL pointer representation
and that it consists of a number, usually 4 or 8, of '\0' chars in memory.
C code that makes assumptions beyond these must depend on the configuration
system, either to not compile an entire non-portable source where it will not
work, or to provide an appropriate #ifdef macro.
Ok, so the question is: what other assumptions does/should the Parrot
C-language source rely on which are C89 nonstandard?
[perl #42615] [PATCH] C89 doesn't allow non-constant initializers
# New Ticket Created by Andy Dougherty
# Please include the string: [perl #42615]
# in the subject line of all future correspondence about this issue.
# URL: http://rt.perl.org/rt3/Ticket/Display.html?id=42615
This patch works around the following error message:
src/inter_call.c, line 1350: non-constant initializer: op U
src/inter_call.c, line 1350: non-constant initializer: op U
src/inter_call.c, line 1351: non-constant initializer: op NAME
src/inter_call.c, line 1351: non-constant initializer: op NAME
diff -ru parrot-current/src/inter_call.c parrot-andy/src/inter_call.c
--- parrot-current/src/inter_call.c Sun Apr 15 03:15:15 2007
+++ parrot-andy/src/inter_call.cThu Apr 19 10:26:02 2007
@@ -1347,8 +1347,8 @@
PMC* save_current_object;
/* temporary state vars for building PCC index and PCC signature arrays. */
-opcode_t *indexes[2] = { arg_indexes, result_indexes };
-PMC *sigs[2] = { args_sig, results_sig };
+opcode_t *indexes[2]; /* = { arg_indexes, result_indexes }; */
+PMC *sigs[2]; /* = { args_sig, results_sig }; */
int arg_ret_cnt[2] = { 0, 0 }; /* # of arg args, # of result args */
int max_regs[8] = { 0, 0, 0, 0, 0, 0, 0, 0 }; /* INSP args, INSP results */
int seen_arrow = 0;
@@ -1359,6 +1359,11 @@
va_list list;
va_start(list, signature);
+
+indexes[0] = arg_indexes;
+indexes[1] = result_indexes;
+sigs[0] = args_sig;
+sigs[1] = results_sig;
/* account for passing invocant in-band */
if (pmc) {
--
Andy Dougherty [EMAIL PROTECTED]
Re: [perl #42615] [PATCH] C89 doesn't allow non-constant initializers
On Thu, Apr 19, 2007 at 11:24:43AM -0700, Andy Dougherty wrote:
# New Ticket Created by Andy Dougherty
# Please include the string: [perl #42615]
# in the subject line of all future correspondence about this issue.
# URL: http://rt.perl.org/rt3/Ticket/Display.html?id=42615
This patch works around the following error message:
src/inter_call.c, line 1350: non-constant initializer: op U
src/inter_call.c, line 1350: non-constant initializer: op U
src/inter_call.c, line 1351: non-constant initializer: op NAME
src/inter_call.c, line 1351: non-constant initializer: op NAME
diff -ru parrot-current/src/inter_call.c parrot-andy/src/inter_call.c
--- parrot-current/src/inter_call.c Sun Apr 15 03:15:15 2007
+++ parrot-andy/src/inter_call.c Thu Apr 19 10:26:02 2007
@@ -1347,8 +1347,8 @@
PMC* save_current_object;
/* temporary state vars for building PCC index and PCC signature arrays.
*/
-opcode_t *indexes[2] = { arg_indexes, result_indexes };
-PMC *sigs[2] = { args_sig, results_sig };
+opcode_t *indexes[2]; /* = { arg_indexes, result_indexes }; */
+PMC *sigs[2]; /* = { args_sig, results_sig }; */
int arg_ret_cnt[2] = { 0, 0 }; /* # of arg args, # of result args */
int max_regs[8] = { 0, 0, 0, 0, 0, 0, 0, 0 }; /* INSP args, INSP results
*/
int seen_arrow = 0;
@@ -1359,6 +1359,11 @@
va_list list;
va_start(list, signature);
+
+indexes[0] = arg_indexes;
+indexes[1] = result_indexes;
+sigs[0] = args_sig;
+sigs[1] = results_sig;
/* account for passing invocant in-band */
if (pmc) {
Cool! I meant to look into this one since it also breaks Borland C++ and
causes warnings under -ansi -pedantic.
Steve Peters
[EMAIL PROTECTED]
Re: [perl #42615] [PATCH] C89 doesn't allow non-constant initializers
On Thursday 19 April 2007 11:24, Andy Dougherty wrote: This patch works around the following error message: src/inter_call.c, line 1350: non-constant initializer: op U src/inter_call.c, line 1350: non-constant initializer: op U src/inter_call.c, line 1351: non-constant initializer: op NAME src/inter_call.c, line 1351: non-constant initializer: op NAME Thanks, applied as r18288, with some minor formatting updates. -- c
Re: C89
Bill Coffman [EMAIL PROTECTED] wrote: Thanks for the info... Apparently, gcc -ansi -pedantic is supposed to be ANSI C '89. Not really. It's pedantic ;) Incidentally, I tried adding -ansi and -pedantic and I got lots of warnings, like long long not supported by ANSI C'89, etc. (how can you do 64 bit ints then?). A C compiler on a 64-bit machine uses long. ... I also got errors that caused outright failure. Perhaps it's best to forget the whole C'89 thing. Not the C'89 thing, but the -ansi thing of gcc. -Bill leo
Re: C89
On Thu, 28 Oct 2004 19:22:02 -0700, Bill Coffman [EMAIL PROTECTED] wrote: Thanks for the info... Apparently, gcc -ansi -pedantic is supposed to be ANSI C '89. Equiv to -std=c89. Also, my Configure.pl generated make file uses neither -ansi nor -pedantic. I do have access to a KR C v2, but it doesn't look like it's going to match the actual practice. Oh well. So long, as my code works, I'm happy. Incidentally, I tried adding -ansi and -pedantic and I got lots of warnings, like long long not supported by ANSI C'89, etc. (how can you do 64 bit ints then?). I also got errors that caused outright failure. Perhaps it's best to forget the whole C'89 thing. But maybe someone should remove that from the documentation? Just a thought. I thought long long was only defined in C99, not C89? -- bd
Re: C89
Thanks for the info... Apparently, gcc -ansi -pedantic is supposed to be ANSI C '89. Equiv to -std=c89. Also, my Configure.pl generated make file uses neither -ansi nor -pedantic. I do have access to a KR C v2, but it doesn't look like it's going to match the actual practice. Oh well. So long, as my code works, I'm happy. Incidentally, I tried adding -ansi and -pedantic and I got lots of warnings, like long long not supported by ANSI C'89, etc. (how can you do 64 bit ints then?). I also got errors that caused outright failure. Perhaps it's best to forget the whole C'89 thing. But maybe someone should remove that from the documentation? Just a thought. -Bill On Thu, 21 Oct 2004 22:41:36 -0700, Jeff Clites [EMAIL PROTECTED] wrote: On Oct 21, 2004, at 11:51 AM, Dan Sugalski wrote: At 11:25 AM -0700 10/21/04, Bill Coffman wrote: I read somewhere that the requirement for parrot code is that it should be compliant with the ANSI C'89 standard. Can someone point me to a description of the C89 spec, so I can make sure my reg_alloc.c patch is C89 compliant? I don't think the ANSI C89 spec is freely available, though I may be wrong. (Google didn't find it easily, but I don't always get along well with Google) If the patch builds without warning with parrot's standard switches then you should be OK. (ANSI C89 was the first big rev of C after the original KR C. If you've got the second edition or later of the KR C book, it uses the C89 spec) Also, if you're compiling with gcc, then you can pass -std=c89 to the compiler to enforce that particular standard. (Apparently--though I haven't tried it.) I believe -ansi does the same thing. JEff
C89
I read somewhere that the requirement for parrot code is that it should be compliant with the ANSI C'89 standard. Can someone point me to a description of the C89 spec, so I can make sure my reg_alloc.c patch is C89 compliant? Thanks, - Bill
Re: C89
On Thu, Oct 21, 2004 at 02:51:15PM -0400, Dan Sugalski wrote: At 11:25 AM -0700 10/21/04, Bill Coffman wrote: I read somewhere that the requirement for parrot code is that it should be compliant with the ANSI C'89 standard. Can someone point me to a description of the C89 spec, so I can make sure my reg_alloc.c patch is C89 compliant? I don't think the ANSI C89 spec is freely available, though I may be wrong. (Google didn't find it easily, but I don't always get along well with Google) If the patch builds without warning with parrot's standard switches then you should be OK. (ANSI C89 was the first big rev of C after the original KR C. If you've got the second edition or later of the KR C book, it uses the C89 spec) Its available for the low, low price of $18. Makes a great stocking stuffer. Or frightening accessory this Halloween! http://webstore.ansi.org/ansidocstore/product.asp?sku=INCITS%2FISO%2FIEC+9899%2D1999 (That's the C99 spec but it should be clear from it what was C89 and what's been introduced with C99). -- Michael G Schwern[EMAIL PROTECTED] http://www.pobox.com/~schwern/ Beef Coronary
Re: C89
On Oct 21, 2004, at 11:51 AM, Dan Sugalski wrote: At 11:25 AM -0700 10/21/04, Bill Coffman wrote: I read somewhere that the requirement for parrot code is that it should be compliant with the ANSI C'89 standard. Can someone point me to a description of the C89 spec, so I can make sure my reg_alloc.c patch is C89 compliant? I don't think the ANSI C89 spec is freely available, though I may be wrong. (Google didn't find it easily, but I don't always get along well with Google) If the patch builds without warning with parrot's standard switches then you should be OK. (ANSI C89 was the first big rev of C after the original KR C. If you've got the second edition or later of the KR C book, it uses the C89 spec) Also, if you're compiling with gcc, then you can pass -std=c89 to the compiler to enforce that particular standard. (Apparently--though I haven't tried it.) I believe -ansi does the same thing. JEff
