Topics

1

Ideas / Make increment operators statements, not expressions

« on: August 26, 2013, 03:13:08 PM »

http://stackoverflow.com/questions/4176328/undefined-behavior-and-sequence-points

Increment operators used as subexpressions (++x; x++; --x; x--) can easily produce undefined behaviour (see examples in link).

To remove this possibility, I suggest making these only appear as entire statements, not subexpressions.
This could be done by making the return type of the operators void, or by only allowing these operators as statements in the grammar.

Examples from the stackoverflow link:

Code: [Select]

i = i++ * ++i ;  //invalid

i = v[i++];   //invalid
You can argue for making these sort of issues well defined, but I think it is clearest and simplest to require the negligibly longer and perfectly explicit alternative:

Code: [Select]

i = (i+1) * (i+2); // or whatever the actual intention was

i = v[i];
i++;
They should still be valid in the third part of a for loop, including multiple increments:

Code: [Select]

for (int a=1; a<10; a++, i++)


2

Implementation Details / C2 Grammar?

« on: August 25, 2013, 02:54:25 PM »

Is there a grammer for c2lang?

I couldn't see one anywhere on the site (wiki is 403?).
C2Parser.cpp comments have some productions, but it doesn't look like there is a complete grammar in the comments.


I grepped them out (on '::=' so I probably missed a few),
then I started completing it using productions from (or based on) the
C1X draft (see Annex A.2).

Code: [Select]

start ::=  package_declaration  top_level_list
// Should package need to be declared first?
// Should an emtpy file be allowed to compile, or does it need a package_declaration?
package_declaration ::= PACKAGE IDENTIFIER SEMICOLON
top_level_list ::=
top_level_list ::= top_level top_level_list
top_level ::= visibility_qualifier type_def
top_level ::= visibility_qualifier func_def
top_level ::= visibility_qualifier use_declaration
top_level ::= visibility_qualifier var_def
// Can variables be public? Alternative; require accessor/settor public function.
visibility_qualifier ::=
visibility_qualifier ::= PUBLIC
type_def ::= TYPE IDENTIFIER type_qualifier type_specifier
type_def ::= TYPE IDENTIFIER func_type
type_def ::= TYPE IDENTIFIER STRUCT LBRACE struct_block RBRACE
type_def ::= TYPE IDENTIFIER UNION LBRACE struct_block RBRACE
type_def ::= TYPE IDENTIFIER ENUM LBRACE enum_block RBRACE
struct_block ::=
struct_block ::= struct_member struct_block
struct_member ::= type_qualifier type_specifier IDENTIFIER SEMICOLON
struct_member ::= UNION LBRACE struct_block RBRACE IDENTIFIER SEMICOLON
type_def ::= access_specifier TYPE IDENTIFIER ENUM LBRACE enum_block RBRACE SEMICOLON
enum_block   ::= enum_block COMMA enum_member
enum_block   ::= enum_block COMMA
enum_block   ::= enum_member
enum_member ::= IDENTIFIER
enum_member ::= IDENTIFIER EQUALS constant_expression
func_type ::= FUNC type_qualifier single_type_specifier LPAREN full_param_list RPAREN
full_param_list ::=
full_param_list ::= param_list
full_param_list ::= param_list COMMA ELLIPSIS
param_list ::= param_declaration
param_list ::= param_list COMMA param_declaration
param_declaration ::= type_qualifier type_specifier IDENTIFIER param_default
param_default ::= EQUALS constant_expression
type_specifier ::= single_type_specifier
type_specifier ::= type_specifier array_specifier
func_def ::= FUNC type_qualifier single_type_specifier IDENTIFIER LPAREN full_param_list RPAREN compound_statement SEMICOLON
statement ::= labeled_statement
statement ::= compound_statement
statement ::= expression_statement
statement ::= selection_statement
statement ::= iteration_statement
statement ::= jump_statement
labeled_statement ::= IDENTIFIER COLON statement
labeled_statement ::= CASE constant_expression COLON statement
labeled_statement ::= DEFAULT COLON statement
compound_statement ::= LBRACE RBRACE
compound_statement ::= LBRACE block_item_list RBRACE
block_item_list ::= block_item
block_item_list ::= block_item_list block_item
block_item ::= statement
block_item ::= declaration
expression_statement ::= expression SEMICOLON
expression_statement ::= SEMICOLON
// compound_statement instead of statement for IF (C 6.8.4).
// This prevents ambiguous: if(a) if(b) X; else Y;
//  if(a) { if(b) X; else Y; }
//  if(a) { if(b) X; } else Y;
selection_statement ::= IF LPAREN expression RPAREN compound_statement
selection_statement ::= IF LPAREN expression RPAREN compound_statement ELSE compound_statement
iteration_statement ::= FOR LPAREN expression_statement expression_statement expression RPAREN statement
iteration_statement ::= FOR LPAREN expression_statement expression_statement RPAREN statement
jump_statement ::= GOTO identifier SEMICOLON
jump_statement ::= CONTINUE SEMICOLON
jump_statement ::= BREAK SEMICOLON
jump_statement ::= RETURN SEMICOLON
jump_statement ::= RETURN expression SEMICOLON
declaration ::= type_qualifier type_specifier IDENTIFIER var_initialization
var_def ::= type_qualifier type_specifier IDENTIFIER var_initialization SEMICOLON
init_value ::= constant_expression
init_value ::= LBRACE init_values RBRACE
init_values ::= init_values COMMA init_value
init_values ::= init_values COMMA
init_values ::= init_value

That is incomplete, but missing productions are probably mostly the same as the C spec.

Imo it is easiest to implement a parser from a grammar,  so I wonder if you already have one.

3

Ideas / Preprocessor and Macros

« on: July 24, 2013, 02:12:44 PM »

http://stackoverflow.com/questions/14041453/why-preprocessor-macros-are-evil-and-what-is-the-real-alternative-c11
In general, I agree macros are evil.

Remove the preprocessor? Modules address the main problem

Or at least remove macro expansions to source tokens, so #define only effects other preprocessor directives?