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

I would submit that the most user friendly is to convert the offending item
into something that can be displayed.

So a %v of a non-scalar takes the least significant bit, and displays that;
if it is a two state variable, displays St1 or St0;  a %v of a real converts
the real to a 1 if it is non zero, and 0 if it is zero.

Similarly a %g, %e or %f of a non real displays the closest real value; so
%g of 123 yields 123.0

This is what we did with VCS way back when; I am not sure if that is still
the case, or if with new data types and format characters this concept is
still practical to extend to every format from every type of argument.

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




-- 
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.