RE: [vhdl-200x] RE: Vote Cancelled: VHDL + VHPI (P1076c-2006-D2.4a)]

Folks,

I've copied Evan's comments to the Bugzilla entry tracking this issue. See
https://bugzilla.mentor.com/show_bug.cgi?id=70.

May I suggest that further comments go directly into the Bugzilla entry?
That way we have a record of correspondence on the issue all in one place.
You can add yourself to the cc list for the issue to get emails of updates.

Many thanks.

Cheers,

PA

--
Dr. Peter J. Ashenden         peter@ashenden.com.au
Ashenden Designs Pty. Ltd.    www.ashenden.com.au
PO Box 640                    VoIP: sip://0871270078@sip.internode.on.net
Stirling, SA 5152             Phone (mobile):  +61 414 70 9106
Australia


> -----Original Message-----
> From: owner-vhdl-200x@server.eda-stds.org 
> [mailto:owner-vhdl-200x@server.eda-stds.org] On Behalf Of Evan Lavelle
> Sent: Tuesday, 11 July 2006 20:04
> To: vhdl-200x@server.eda-stds.org
> Subject: Re: [vhdl-200x] RE: Vote Cancelled: VHDL + VHPI 
> (P1076c-2006-D2.4a)]
> 
> 
> I've just had a quick look through vhpi_user.h on eda.org (I wasn't 
> actually aware it was there). The char and sized-integer 
> handling needs 
> cleaning up. For instance, we have
> 
> > typedef int             PLI_INT32;
> > typedef unsigned int    PLI_UINT32;
> > typedef short           PLI_INT16;
> > typedef unsigned short  PLI_UINT16;
> > typedef char            PLI_BYTE8;
> > typedef unsigned char   PLI_UBYTE8;
> ...
> > typedef char vhpiCharT;
> 
> 
> 1 - 'plain' char is a distinct type (it is neither a 'signed 
> char' nor 
> an 'unsigned char' type), and the standards don't specify 
> whether it is 
> treated as signed or unsigned; this is up to the compiler. For short, 
> int, and long, specifying 'signed' is optional, since objects 
> of these 
> types are signed unless the 'unsigned' keyword is used. This 
> isn't true 
> of char.
> 
> 2 - In C and C++, a char is a byte, and sizeof(char) is 1. However, a 
> "byte" is not necessarily 8 bits; the standard only says that 
> CHAR_BIT 
> is required to be at least 8. This is probably not relevant - I guess 
> nothing actually requires a char to be 8 bits?
> 
> 3 - Most C/C++ coding standards prohibit the use of 'plain 
> char', except 
> when it is required in the API for an existing library
> 
> 4 - The macros in inttypes.h/stdint.h should be used for standardised 
> typedefs for integers of a known size; ie. uint8_t, uint32_t, etc.
> 
> 5 - What's going on in:
> 
> > #define VHPI_GET_PRINTABLE_STRINGCODE( ch )  
> VHPICharCodes[PLI_UBYTE8 
> > ch]
> 
> is '[PLI_UBYTE8 ch]' meant to be a typecast (it isn't)?
> 
> Evan
>