RE: [sv-bc] RE: [sv-ec] Formatting strings using %b ???

Even though it never used the word "unpacked", a string is defined to
behave with all the same semantics of a single dimensional unpacked
array. An aggregate is either packed or unpacked, and a string is
definitely not packed.

Since $display is a system task, there is no coercion of an arguments
value. The PLI requires that its arguments be read in by a mechanism
defined by the arguments type. So a string variable will always be
interpreted as a string and mantis 1789 does not apply.

So I think the current LRM implies that it should be an error. But it
would be more friendly to allow formatting a string as an integral value
for $display.

Dave


> -----Original Message-----
> From: owner-sv-bc@server.eda.org [mailto:owner-sv-bc@server.eda.org]
On
> Behalf Of Bresticker, Shalom
> Sent: Friday, June 22, 2007 1:55 AM
> To: Jonathan Bromley; sv-bc@server.eda-stds.org;
sv-ec@server.eda-stds.org
> Subject: [sv-bc] RE: [sv-ec] Formatting strings using %b ???
> 
> Actually, I think the LRM never quite defines the string type as an
> unpacked aggregate. I don't think it ever uses the term 'unpacked'
with
> respect to string types. It just says that a string is an ordered
> collection of characters.
> 
> Shalom
> 
> > -----Original Message-----
> > From: owner-sv-ec@server.eda.org [mailto:owner-sv-ec@server.eda.org]
> > On Behalf Of Jonathan Bromley
> > Sent: Friday, June 22, 2007 11:45 AM
> > To: sv-bc@server.eda-stds.org; sv-ec@server.eda-stds.org
> > Subject: RE: [sv-ec] Formatting strings using %b ???
> >
> > When a data object of string type is fed to a %b format specifier...
> >
> > [Shalom Bresticker]
> >
> > 	%b in normal context prints 0s and 1s. I don't see any
> > justification to
> > 	display a string type as a string if %b is specified.
> >
> >
> > [Dave Rich]
> >
> > 	The string data type is an unpacked aggregate. To convert to an
> > integral
> > 	type requires a cast, and under any other circumstance, this
> > should be
> > 	an error. However, an argument to a system task does not create
> an
> > 	assignment context, so we are free to choose the behavior we
> want.
> >
> > I don't think you are free so to choose.  See the paragraph
> > in P1800 draft 3a that immediately follows Table 20-2:
> >
> > 	These [integer] format specifiers [...] shall not be used
> > 	with any unpacked aggregate type.
> >
> > So, on more careful reflection I conclude that *both* simulators
> > I tried are non-conforming.
> >
> > Is this OK with everyone?  Or do we need a further change to 1789
> > to permit automatic coercion of strings to packed arrays of bit by
> > this set of system tasks?  From a user's viewpoint I would have been
> > much happier if my programming slip-up had been reported as an
> > error, as indicated by the LRM text I quote above.
> >
> > --
> >
> > Jonathan Bromley
> >
> >
> > -- This message has been scanned for viruses anddangerous content by
> > MailScanner, and isbelieved to be clean.
> 
> --
> 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.