errata/554: Re: errata/554: A.2.6: function_declaration BNF bug for return type declarations

From: Shalom.Bresticker@motorola.com
Date: Thu Mar 04 2004 - 00:20:00 PST

  • Next message: Steven Sharp: "errata/549: Re: errata/549: Re: errata/549: 17.1.1.7 leading zeros in string format"

    The following reply was made to PR errata/554; it has been noted by GNATS.

    From: Shalom.Bresticker@motorola.com
    To: etf-bugs@boyd.com
    Cc:
    Subject: Re: errata/554: A.2.6: function_declaration BNF bug for return type
     declarations
    Date: Thu, 4 Mar 2004 10:29:23 +0200 (IST)

     Brad,
     
     You are clearly correct that the BNF is too lenient here.
     I would guess that it occurs in order not to complicate function_declaration
     too much.
     
     You should also compare it to parameter_declaration and see the discussion
     in 483 as well.
     
     Shalom
     
     
    > In function_declaration, the BNF for the return type does
    > not match the apparent intent. I would have expected the
    > possible function return type declarations to be like
    > those in a tf_output_declaration, which allows
    >
    > [ reg ] [ signed ] [ range ]
    >
    > and
    > task_port_type
    >
    > where a task_port_type is integer, real, realtime or time.
    >
    > The function_declaration BNF, however, also allows the following
    > additional weird function return type declarations
    >
    > signed integer
    > signed real
    > signed realtime
    > signed time
    >
    > (and doesn't allow 'reg' before the implicit declaration).
    > But integer, real and realtime are already signed, so
    > the only return type this actually adds is 'signed time',
    > which was probably not the intent.
    >
    > So, in my opinion, the BNF has a bug and should instead
    > be allowing function return type declarations that are
    > either exactly the same as allowed by tf_output_declaration
    > or exacly those minus the optional 'reg'. (For more on the
    > optional 'reg', see issue 452.) Personally, 'exactly the same'
    > seems like the way to go.
     
     --
     Shalom Bresticker Shalom.Bresticker@motorola.com
     Design & Reuse Methodology Tel: +972 9 9522268
     Motorola Semiconductor Israel, Ltd. Fax: +972 9 9522890
     POB 2208, Herzlia 46120, ISRAEL Cell: +972 50 441478
     
     [x]Motorola General Business Information
     [ ]Motorola Internal Use Only
     [ ]Motorola Confidential Proprietary
     

    This archive was generated by hypermail 2.1.4 : Thu Mar 04 2004 - 00:20:22 PST and
    sponsored by Boyd Technology, Inc.