RE: [vhdl-200x] LRM bugs

Tristan,

Thanks for your comprehensive list of issues. I will generate an Issue
Report for the Issues Screening and Analysis Committee (ISAC) to review.
You should get a response in the near future.

Meanwhile, if you uncover further issues we need to consider, you can report
them using the form at www.eda.org/vasg/bugrep.htm. Many thanks.

Cheers,

PA

--
Dr. Peter J. Ashenden                        peter@ashenden.com.au
Ashenden Designs Pty. Ltd.                   www.ashenden.com.au
PO Box 640                                   Ph:  +61 8 8339 7532
Stirling, SA 5152                            Fax: +61 8 8339 2616
Australia                                    Mobile: +61 414 70 9106
> -----Original Message-----
> From: owner-vhdl-200x@eda.org 
> [mailto:owner-vhdl-200x@eda.org] On Behalf Of tgingold@free.fr
> Sent: Monday, 29 November 2004 04:45
> To: vhdl-200x@eda.org
> Cc: tgingold@free.fr
> Subject: [vhdl-200x] LRM bugs
> 
> 
> During the development of ghdl (http://ghdl.free.fr), I think 
> I have found severals errors in the VHDL LRM.  Here is a 
> priliminary list with some propositions to fix the bugs. I 
> hope these bugs could be clarified or fixed for the next LRM version.
> 
> 1) The return type of a function can be a file type.
>    However, it is of course not possible to write a correct 
> body for such
>    a declaration.
> 
>    Proposition: The return type of a function must denote 
> neither a file type
>    nor a protected type.
> 
> 2) An alias of a physical type is not possible, although 
> described in the LRM.
>    Indeed, a physical type is always an anonymous type.  Only physical
>    subtypes can be aliased.
> 
>    Proposition: Are non-object aliases really used ?  
> Non-object aliases were
>    added to be able to re-export declarations, but they 
> cannot be used for
>    this purpose.
> 
> 3) Character literal can be decorated through an attribute 
> specification,
>    but the 'decoration' cannot be referenced (because the prefix of an
>    attribute cannot be a character).
> 
> 4) It is possible to write pure functions that do not return 
> the same value:
>    type string_acc is access string;
> 
>    pure function alloc (str : string) return string_acc is
>    begin
>       return new string'(str);
>    end alloc;
> 
>    Proposition: forbid allocators in pure functions (directly 
> or indirectly)
>    as well as calls to the implicit deallocate procedures.
> 
> 5) Some trivial expressions are not valid:
>       constant c : integer := -3;
>    The expression is ambiguous, since the "-" can either that 
> of the integer
>    type or that of the universal integer type.
>    For sure, in this example the result is the same, but what about:
>      function "-" (v : integer) return integer is begin return 0; end;
>      constant c : integer := -3;
> 
>    Proposition: Do like Ada: preference for universal operators.
> 
> 6) Does a generate statement have a declarative part ?
>    No, according to grammar from 9.7, but some of the 
> block_declarative_item
>    are specifications which are valid only inside declarative part...
> 
>    Propostion: Replace "{ block_declarative_item }" with
>    "block_declarative_part".
> 
> 7) What is the meaning of:
>    type t is array (boolean) of bit;
>    signal s : t;
>    ...
>    wait on s (time < 10 ns);
> 
>    Suppose the wait statement starts to execute at 9 ns, and 
> there is an
>    event at 11 ns on s (true).  Does the wait statement finish ?
>    This bug is due to the fact that globally static 
> expression are not static.
> 
>    Proposition: why the time function is pure ?
> 
> 8) What is the meaning of 'signature' in 'INSTANCE_NAME and 
> 'PATH_NAME ?
>    What is the signature of function f return natural ?  
> [return natural] or
>    [return integer].  At least, the use of these attributes 
> is nonportable.
> 
> 9) The default entity aspect is ambiguous, because rules a) 
> and c) or b) and c)
>    of 5.2.2 can results in two visible entity declaration.
>    Proposition: Remove rules a) and b), that are neither intuitive
>    nor understandable.
> 
> 10) Constant parameter of access types are implicitly allowed:
>       type line is access string;
>     seems to implicitly define:
>       function "=" (constant <anon> : line; constant <anon> : line)
>         return boolean;
>     These functions (if they really exist) are of course not 
> overloadable.
>     The restriction (constant parameter cannot be of access 
> type) was not
>     well considered (remember the endline function of std.textio).
>     Although this is not explained, I suppose the reason why 
> this restriction
>     exists is because it prevents from defining pure function 
> that returns
>     different values when called with the same parameters.
> 
>     Proposition:
>      1) allow constant parameter of access types for 
> procedures and impure
>         functions.
>      2) Allow constant parameter of access types for pure 
> functions but forbid
>         to dereference such parameters in pure functions.
> 
> Extra bugs:
> 11a) There is a missing ';' in example of E'PATH_NAME after 
> the generic clause
>     of component BComp declared inside architecture top of top.
> 
> 11b) There is a missing ':' before gbottom'path_name.
> 
> 12) Names of protected type examples in 3.5.1 and 3.5.2 do not match:
>   VariableSizedBitArray vs VariableSizeBitArray.
> 
> Tristan.
>