RE: [sv-cc] Two quick proposals from this week's meeting

Sounds fine to me, Michael.
I will do that.
 
Regards,
Doug

________________________________

        From: Michael Rohleder [mailto:michael.rohleder@freescale.com]
        Sent: Monday, January 10, 2005 6:01 AM
        To: Warmke, Doug
        Cc: Jim Vellenga; sv-cc@eda.org
        Subject: Re: [sv-cc] Two quick proposals from this week's
meeting
        
        
        Hi Doug,
        
        thanks for this improvement to the usability of SV and its
header files. Just one very minor remark
        from my side:
        
        I believe when you intend to help users in writing better code
and providing them the correct function
        and data prototypes, you might want to change the typedefs
        

                typedef __int64 int64_t;
                typedef __int32 int32_t;
                typedef __int16 int16_t;
                typedef __int8 int8_t;
                

        to
        

                typedef signed __int64 int64_t;
                typedef signed __int32 int32_t;
                typedef signed __int16 int16_t;
                typedef signed __int8 int8_t;

        As you says, it is good idea to provide the correct info
completely upfront and not relying on
        something that is implicit. So it might be also a good idea on
not relying on signed being the default type
        (I have seen compilers where this could be changed ..., and one
of them was M$, which is
        the only one affected here...). Of course this was in the past,
but you'll never know ...
        

        Best regards,
        -Michael
        
        
        Warmke, Doug wrote:
        

                Hi Jim,
                
                The reason is the same reason as for leaving in the
DPI_DLLESPEC:
                for user convenience, and to encourage robust coding.
                
                My thinking is that users have to write their own
interface using
                DPI functions (not like PLI where the vendor provides
all functions).
                
                To encourage users to write correct function prototypes,
using sized
                integer types rather than just counting on the fact that
"short is
                16 bits, int is 32 bits, long long is 64 bits, etc.", we
should make
                it trivially easy for them to write correct function
prototypes
                using sized types.
                
                Make sense?
                
                Thanks,
                Doug
                
                  

                        -----Original Message-----
                        From: Jim Vellenga [mailto:vellenga@cadence.com]

                        Sent: Friday, January 07, 2005 8:24 AM
                        To: Warmke, Doug; sv-cc@eda.org
                        Subject: RE: [sv-cc] Two quick proposals from
this week's meeting
                        
                        Doug, in the second proposal (350) you've also
added
                        some 16 bit types and some signed types. Why is
that?
                        
                        Regards,
                        Jim V.
                        
        
---------------------------------------------------------
                        James H. Vellenga
978-262-6381
                        Engineering Director (FAX)
978-262-6636
                        Cadence Design Systems, Inc.
vellenga@cadence.com
                        270 Billerica Rd
                        Chelmsford, MA 01824-4179
                        "We all work with partial information."
        
----------------------------------------------------------
                          
                         
                        
                        ] -----Original Message-----
                        ] From: owner-sv-cc@eda.org
[mailto:owner-sv-cc@eda.org] On
                        ] Behalf Of Warmke, Doug
                        ] Sent: Thursday, January 06, 2005 8:39 PM
                        ] To: sv-cc@eda.org
                        ] Subject: [sv-cc] Two quick proposals from this
week's meeting
                        ]
                        ] Hello SV-CC,
                        ]
                        ] As requested by Charles, I have created two
new Mantis
                        ] items and uploaded proposals.
                        ]
                        ] These changes are intended to maximize user
convenience
                        ] (the svdpi.h changes) and safety (the string
changes).
                        ] They don't introduce any new semantics.
                        ]
                        ] Please review and comment.
                        ]
                        ]
http://www.eda.org/svdb/bug_view_page.php?bug_id=0000349
                        ]
http://www.eda.org/svdb/bug_view_page.php?bug_id=0000350
                        ]
                        ] We don't have much time to get these finalized
and
                        ] into the hands of the LRM editor in time for
deadline.
                        ]
                        ] (I have made these changes in a prototype tree
and
                        ] ensured that they work correctly)
                        ]
                        ] Thanks and regards,
                        ] Doug
                            

        --
        
        NOTE: The content of this message may contain personal views
              which are not neccessarily the views of Freescale, unless
specifically stated.
         
                 ___________________________________________________
                | |
              _ | Michael Rohleder Tel: +49-89-92103-259 | _
             / )| Freescale Semiconductor Fax: +49-89-92103-680 |( \
            / / | Freescale Halbleiter Deutschland GmbH | \
\
          _( (_ | _ Schatzbogen 7, D-81829 Munich, Germany _ | _)
)_
         (((\ \>|_/ > < \_|</
/)))
         (\\\\ \_/ / mailto:Michael.Rohleder@freescale.com \ \_/
////)
          \ /_______________________________________________\
/
           \ _/ \_
/
           / / \
\
        
        The information contained in this email has been classified as:
        General Business Information ( )
        Freescale Internal Use Only ( )
        Freescale Confidential Proprietary ( )
        
        
        *** This note may contain Freescale Confidential Proprietary or
Freescale Internal Use Only Information and is intended to be reviewed
by only the individual or organization named above. If you are not the
intended recipient or an authorized representative of the intended
recipient, you are hereby notified that any review, dissemination or
copying of this email and its attachments, if any, or the information
contained herein is prohibited. If you have received this email in
error, please immediately notify the sender by return email and delete
this email from your system.
            Thank you! ***
        
        
Received on Mon Jan 10 08:23:08 2005