RE: [sv-bc] BNF too restrictive for macro actual arg

From: Bresticker, Shalom <shalom.bresticker_at_.....>
Date: Tue Jul 08 2008 - 00:41:28 PDT
Hi,

Mantis 1333 was opened on this issue a long time ago. 

I'll add both your comments as bug notes.

There are other restrictions as well. For example, comment delimiters are interpreted as such. So are compiler directives, at least in some cases.

I think I have also seen some additional cases involving special characters where some tools did not like this.

Shalom

> -----Original Message-----
> From: owner-sv-bc@server.eda.org 
> [mailto:owner-sv-bc@server.eda.org] On Behalf Of Gran, Alex
> Sent: Tuesday, July 08, 2008 7:32 AM
> To: Greg Jaxon; SV_BC List
> Subject: RE: [sv-bc] BNF too restrictive for macro actual arg
> 
> Greg,
> 
> Here is Syntax 21-2
> 
> text_macro_definition ::=
> 	`define text_macro_name macro_text
> text_macro_name ::=
> 	text_macro_identifier [ ( list_of_formal_arguments ) ] 
> list_of_formal_arguments ::=
> 	formal_argument { , formal_argument }
> formal_argument ::=
> 	simple_identifier [ = default_text ]
> text_macro_identifier ::=
> 	identifier
>  
> 
> This uses "default_text" as the default argument for the 
> macros, though it doesn't formally define "default_text"  
> Should we make this and definition of "actual_argument" from 
> Syntax 21-3 the same thing?  
> 
> Because both must play by the exact same rules right, 
> whatever is legal/illegal as a macro argument is the same 
> whether its given as the default argument in the macro 
> definition, or as an actual argument in the macro instance.  
> Or do these need to be treated differently somehow?
> 
> But I agree on your point that  actual_argument ::= 
> expression is too restrictive.
> 
> ~Alex
> 
> 
> -----Original Message-----
> From: owner-sv-bc@server.eda.org 
> [mailto:owner-sv-bc@server.eda.org] On Behalf Of Greg Jaxon
> Sent: Monday, July 07, 2008 7:32 PM
> To: SV_BC List
> Subject: [sv-bc] BNF too restrictive for macro actual arg
> 
> Syntax 21-3 says:
> 
> > text_macro_usage ::=
> >         `text_macro_identifier [ ( list_of_actual_arguments ) ] 
> > list_of_actual_arguments ::=
> >         actual_argument { , actual_argument } actual_argument ::=
> >         expression
> 
> But surely the actuals are not required to be expressions.
> 
> Accompanying text says only that:
> > To use a macro defined with arguments, the name of the text macro 
> > shall be followed by a list of actual argu- ments in parentheses, 
> > separated by commas. Actual arguments and defaults shall 
> not contain 
> > comma or right parenthesis characters outside matched pairs 
> of left and right parentheses (), square brackets [], braces 
> {}, double quotes "", or an escaped identifier.
> 
> and further offers this:
> > An actual argument may be empty or white space only, in 
> which case the 
> > formal argument is substituted by the argument default if 
> one is specified or by nothing if no default is specified.
> 
> I think the BNF production should simply say
> 
>          actual_argument ::=  {any_character}¹
> 
> with the footnote containing or referring to the more subtle 
> restrictions I quoted above.
> 
> Greg
> 
> 
> --
> This message has been scanned for viruses and dangerous 
> content by MailScanner, and is believed to be clean.
> 
> 
> -- 
> This message has been scanned for viruses and
> dangerous content by MailScanner, and is
> believed to be clean.
> 
> 
> 
---------------------------------------------------------------------
Intel Israel (74) Limited

This e-mail and any attachments may contain confidential material for
the sole use of the intended recipient(s). Any review or distribution
by others is strictly prohibited. If you are not the intended
recipient, please contact the sender and delete all copies.


-- 
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.
Received on Tue Jul 8 00:46:39 2008

This archive was generated by hypermail 2.1.8 : Tue Jul 08 2008 - 00:47:23 PDT