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

Jonathan,

Unfortunately, the LRM has long been silent regarding the outcome of a
particular format when an improper (or illegal) data-type is passed to
the $display calls.

Other examples of incompatible behavior include using %v with non-scalar
data, %g, %e, or %f with non-reals, etc...

If we determine that improper combinations of formats/data-objects are
to be caught by the tools. The LRMS should list all instances of such
improper use.
Making such uses run-time errors at this point will no doubt have an
impact on legacy runs. Perhaps, the best we can do is a run-time warning
- and, even a warning will impact legacy runs.

	Arturo

-----Original Message-----
From: owner-sv-bc@eda.org [mailto:owner-sv-bc@eda.org] On Behalf Of
Bresticker, Shalom
Sent: Friday, June 22, 2007 1:55 AM
To: Jonathan Bromley; sv-bc@eda-stds.org; sv-ec@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.