- Previous message: Karen Pieper: "Minutes of the 2/7/05 Meeting"
- Maybe in reply to: sharp@cadence.com: "errata/549: 17.1.1.7 leading zeros in string format"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ] [ attachment ]
The following reply was made to PR errata/549; it has been noted by GNATS.
From: Shalom.Bresticker@freescale.com
To: etf-bugs@boyd.com
Cc:
Subject: Re: errata/549: 17.1.1.7 leading zeros in string format
Date: Sat, 12 Feb 2005 20:23:23 +0200 (IST)
This is to update the database with the recent discussions.
Date: Wed, 9 Feb 2005 20:13:35 +0530
From: Kausik Datta <kausikd@cal.interrasystems.com>
Subject: Query related to escaped character in verilog
I have one query related to use of escaped character in verilog.
Let's take the following example:
reg [31:0] a;
initial
begin
a = "s\0a";
#5 $display("%s\n", a);
end
Some tool print this one as "s a".
and some tool print as "s"
Which one is the correct output? LRM doesn't say anything about this.
Date: Wed, 09 Feb 2005 17:36:01 +0200
From: Shalom Bresticker <Shalom.Bresticker@freescale.com>
The three simulators I have access to all print " s a", with leading space
before the "s".
Date: Wed, 09 Feb 2005 11:15:14 -0800
From: Neil Korpusik <Neil.Korpusik@Sun.COM>
The results that Shalom is showing appear to be incorrect. The leading space
appears to be inconsistent with what is stated in 17.1.1.7
Even though the LRM doesn't explicitly state what character to print when
a \0 is embedded within a string, it appears from 17.1.1.7 that the NUL
character should not be treated like a string terminator, as shown in one of
the outputs shown by Kausik.
Printing a blank for an embedded NUL character seems to be the most appropriate
thing to do. Ignoring leading NUL characters seems to be the most consistent
with the rules for the comparison and concatenation operators (4.2.3.2).
4.2.3.2 String value padding and potential problems
"When strings are assigned to variables, the values stored shall be padded
on the left with zeros."
"The comparison and cancatenation operators shall not distinguish between
zeros resulting from padding and the original string characters (\0, ASCII
NUL)."
17.1.1.7 String format
"No termination character or value is required at the end of a string, and
leading zeros are never printed."
Date: Wed, 9 Feb 2005 22:10:08 +0200 (IST)
From: Shalom.Bresticker@freescale.com
What 17.1.1.7 says is that leading "zeroes" are not printed.
It does not say anything about spaces.
If you look at parallel language in 17.1.1.3, it says that when printing
decimal values (i.e., numbers in decimal format),
"leading zeroes are suppressed and replaced by spaces.
In other radices, leading zeroes are always displayed."
"Other radices" means other integral numeric formats.
Strings are like decimal formats. The leading zeroes are not printed, but
space is left for them.
Only when you use a %0s format are the leading spaces omitted.
The most basic test, which I should have thought of earlier, is
reg[31:0] r = "" ;
$display ("%s", r, "cucu");
This will always give you " cucu" and never "cucu".
This shows that the zero bytes are printed as spaces.
But it's also true that the LRM does not say explicitly how \0 should be
printed and it should.
A harder question is how should other nonprinting characters be printed?
(a self-contradiction, of course)
And 4.2.3.2 explicitly says that leading NULs are not ignored:
"Padding can affect the results of comparison and concatenation operations".
Date: Wed, 9 Feb 2005 22:26:04 +0200 (IST)
From: Shalom.Bresticker@freescale.com
I take it back, partially.
I just ran a fascinating experiment.
I ran the following simple code:
module m;
integer i;
initial
begin
for (i=0;i<256;i=i+1)
begin
a = i;
$display("s%sa", a);
end
end
endmodule
I urge everyone to try it.
Look at the results on the screen, in your editor, etc.
If you have Unix, try sending the output to cat, vi, textedit, etc.
What appears to happen is simply the obvious:
the Verilog simulator just outputs the required byte (ASCII 0-255) into
the data stream. What it looks like, how it is represented, how it
behaves, that depends on how you view it or process it.
Date: Wed, 9 Feb 2005 17:49:09 -0500 (EST)
From: Steven Sharp <sharp@cadence.com>
>module m;
>integer i;
>
>initial
>begin
>for (i=0;i<256;i=i+1)
>begin
> a = i;
> $display("s%sa", a);
>end
>end
>
>endmodule
I assume you intended to declare "reg [7:0] a;" in there.
>What appears to happen is simply the obvious:
>
>the Verilog simulator just outputs the required byte (ASCII 0-255) into
>the data stream. What it looks like, how it is represented, how it
>behaves, that depends on how you view it or process it.
Well, except for ASCII 0, which gets converted into a space in the output.
Date: Wed, 9 Feb 2005 17:54:07 -0500 (EST)
From: Steven Sharp <sharp@cadence.com>
>Some tool print this one as "s a".
>and some tool print as "s"
The second case sounds like a tool that is not converting the NUL
into a space, and is then mistaking the NUL for a string termination
in C code that is printing it out.
>Which one is the correct output? LRM doesn't say anything about this.
In this situation, it is generally reasonable to go back to Verilog-XL
and find out what the original behavior was. XL appears to convert
NULs into spaces in the output (including any leading zeroes). If
printed with %0s, then the spaces for any leading zeroes are supressed.
Date: Wed, 9 Feb 2005 18:06:54 -0500 (EST)
From: Steven Sharp <sharp@cadence.com>
>17.1.1.7 String format
>
> "No termination character or value is required at the end of a string, and
> leading zeros are never printed."
This text came directly from the Verilog-XL Reference Manual, word for word.
So however the text is interpreted, the intent of the standard was to match
Verilog-XL here.
This may have been an error in the XL documentation, or it may have been
intended to be interpreted as Shalom suggested: like decimal numbers, leading
zeroes are not printed, but are replaced with spaces instead.
Date: Wed, 09 Feb 2005 15:48:39 -0800
From: Clifford E. Cummings <cliffc@sunburst-design.com>
Attached is a uuencoded tar-file with escape-test-code and the outputs from
VCS 7.2 and ModelSim 6.0
Hopefully the uuencoding will preserve all the interesting characters.
Doing a diff (Linux RedHat 7.3) between the tmpout.vcs and tmpout.mti
actually showed a few differences (just a few and none of them are going to
get me upset).
I kind of thought that displaying a null character would not show anything
(VCS did not print a " " but ModelSim did and from this email thread it
sounds like other simulators are doing the same).
The octal-13 character was also different (line feed or ^M), as were a few
other of the obscure-variety characters.
I don't know if I agree that we should match Verilog-XL if we think it is
doing something wrong. Seems like we cleaned up a couple of Verilog-XL-isms
for IEEE Verilog-1995 and if we think printing a space when a
null-character was requested is wrong, I am inclined to say so. I have not
tried this with C yet. Any takers?
I must admit that I would never base a Verilog-simulator-buying decision on
this, but we should probably clean it up.
[ Part 2, Application/OCTET-STREAM (Name: "esc_test.uu") 19KB. ]
[ Unable to print this part. ]
Date: Wed, 9 Feb 2005 19:22:00 -0500 (EST)
From: Steven Sharp <sharp@cadence.com>
>Attached is a uuencoded tar-file with escape-test-code and the outputs from
>VCS 7.2 and ModelSim 6.0
>
>Hopefully the uuencoding will preserve all the interesting characters.
My uudecode won't decode something containing a NUL character, so I
can't read your file.
>The octal-13 character was also different (line feed or ^M), as were a few
>other of the obscure-variety characters.
Were you on a PC? This might be a classic carriage-return/linefeed
versus linefeed issue.
>I don't know if I agree that we should match Verilog-XL if we think it is
>doing something wrong. Seems like we cleaned up a couple of Verilog-XL-isms
>for IEEE Verilog-1995 and if we think printing a space when a
>null-character was requested is wrong, I am inclined to say so.
And do you have any real argument that this is wrong?
Note that NUL characters tend to mess up any application written in C.
And if you tried to specify that NUL characters be printed out,
simulators with I/O libraries written in C might start truncating
outputs in a variety of unexpected ways. Have you ever tried printing
out NUL characters using %c in the middle of a complex format? NC can
do it, but I don't think most other simulators can.
> I have not
>tried this with C yet. Any takers?
You can't print out an embedded NUL with %s in C, because a NUL will
terminate the string.
>I must admit that I would never base a Verilog-simulator-buying decision on
>this, but we should probably clean it up.
The current specification in the LRM is lacking, and should be clarified.
This assumes that we can agree on what to specify. What XL does makes
reasonable sense, and is the de facto standard. I don't see a reason to
specify anything else.
Date: Wed, 09 Feb 2005 17:32:16 -0800
From: Neil Korpusik <Neil.Korpusik@Sun.COM>
I ran a small experiment using two different simulators. Both of them
produced the same results. Both of them are converting a leading zero and
a leading NUL into a space. ASCII 0 is the only ASCII character that
appears to be getting converted into a space (ASCII decimal 32). All of the
other characters are printed out "as-is". All of the ASCII decimal 10's that
are showing up in the output file are from new-line characters.
ascii.file is the output from the simulator.
output is the output from the small c program.
You can't really tell what value is being displayed by the simulator
for many of the ASCII characters just by looking at the results on the screen.
Many of them look just like a space. We are able to see exactly what ASCII
character is being written out by reading them back in with a C program.
VerilogXL was one of the simulators that I ran.
--------------------< Verilog code with $display for strings >-------------
module m;
integer i;
reg [15:0] a,b;
initial
begin
for (i=0;i<127;i=i+1) // ASCII is 0:127
begin
a = i;
b = {"\0",i};
$display("%s%s", a,b); // a has leading 0's and b has a leading NUL
end
end
endmodule
--------------------< c code to read in simulator output >-------------
#include <stdio.h>
main() {
int done;
char *fname = "ascii.file";
char *nc_p;
char buf[2];
FILE *fd;
fd = fopen(fname,"r");
if (!fd) {
printf("unable to open %s\n",fname);
} else {
printf("file %s was opened for reading\n",fname);
for (done=0; !done; done = (nc_p==NULL)) {
nc_p = fgets(buf, 2, fd);
printf("'%c' decimal=%d\n",buf[0],buf[0]);
}
}
}
[ Part 2: "Attached Text" ]
^A ^A
^B ^B
^C ^C
^D ^D
^E ^E
^F ^F
^G ^G
^H ^H
^P ^P
^Q ^Q
^R ^R
^S ^S
^T ^T
^U ^U
^V ^V
^W ^W
^X ^X
^Y ^Y
^Z ^Z
^[ ^[
^\ ^\
^] ^]
^^ ^^
^_ ^_
! !
" "
# #
$ $
% %
& &
' '
( (
) )
* *
+ +
, ,
- -
. .
/ /
0 0
1 1
2 2
3 3
4 4
5 5
6 6
7 7
8 8
9 9
: :
; ;
< <
= =
> >
? ?
@ @
A A
B B
C C
D D
E E
F F
G G
H H
I I
J J
K K
L L
M M
N N
O O
P P
Q Q
R R
S S
T T
U U
V V
W W
X X
Y Y
Z Z
[ [
\ \
] ]
^ ^
_ _
` `
a a
b b
c c
d d
e e
f f
g g
h h
i i
j j
k k
l l
m m
n n
o o
p p
q q
r r
s s
t t
u u
v v
w w
x x
y y
z z
{ {
| |
} }
~ ~
[ Part 3: "Attached Text" ]
file ascii.file was opened for reading
' ' decimal=32
'^A' decimal=1
' ' decimal=32
'^A' decimal=1
'
' decimal=10
' ' decimal=32
'^B' decimal=2
' ' decimal=32
'^B' decimal=2
'
' decimal=10
' ' decimal=32
'^C' decimal=3
' ' decimal=32
'^C' decimal=3
'
' decimal=10
' ' decimal=32
'^D' decimal=4
' ' decimal=32
'^D' decimal=4
'
' decimal=10
' ' decimal=32
'^E' decimal=5
' ' decimal=32
'^E' decimal=5
'
' decimal=10
' ' decimal=32
'^F' decimal=6
' ' decimal=32
'^F' decimal=6
'
' decimal=10
' ' decimal=32
'^G' decimal=7
' ' decimal=32
'^G' decimal=7
'
' decimal=10
' ' decimal=32
'^H' decimal=8
' ' decimal=32
'^H' decimal=8
'
' decimal=10
' ' decimal=32
' ' decimal=9
' ' decimal=32
' ' decimal=9
'
' decimal=10
' ' decimal=32
'
' decimal=10
' ' decimal=32
'
' decimal=10
'
' decimal=10
' ' decimal=32
' ' decimal=11
' ' decimal=32
' ' decimal=11
'
' decimal=10
' ' decimal=32
' ' decimal=12
' ' decimal=32
' ' decimal=12
'
' decimal=10
' ' decimal=32
'
' decimal=13
' ' decimal=32
'
' decimal=13
'
' decimal=10
' ' decimal=32
'' decimal=14
' ' decimal=32
'' decimal=14
'
' decimal=10
' ' decimal=32
'' decimal=15
' ' decimal=32
'' decimal=15
'
' decimal=10
' ' decimal=32
'^P' decimal=16
' ' decimal=32
'^P' decimal=16
'
' decimal=10
' ' decimal=32
'^Q' decimal=17
' ' decimal=32
'^Q' decimal=17
'
' decimal=10
' ' decimal=32
'^R' decimal=18
' ' decimal=32
'^R' decimal=18
'
' decimal=10
' ' decimal=32
'^S' decimal=19
' ' decimal=32
'^S' decimal=19
'
' decimal=10
' ' decimal=32
'^T' decimal=20
' ' decimal=32
'^T' decimal=20
'
' decimal=10
' ' decimal=32
'^U' decimal=21
' ' decimal=32
'^U' decimal=21
'
' decimal=10
' ' decimal=32
'^V' decimal=22
' ' decimal=32
'^V' decimal=22
'
' decimal=10
' ' decimal=32
'^W' decimal=23
' ' decimal=32
'^W' decimal=23
'
' decimal=10
' ' decimal=32
'^X' decimal=24
' ' decimal=32
'^X' decimal=24
'
' decimal=10
' ' decimal=32
'^Y' decimal=25
' ' decimal=32
'^Y' decimal=25
'
' decimal=10
' ' decimal=32
'^Z' decimal=26
' ' decimal=32
'^Z' decimal=26
'
' decimal=10
' ' decimal=32
'^[' decimal=27
' ' decimal=32
'^[' decimal=27
'
' decimal=10
' ' decimal=32
'^\' decimal=28
' ' decimal=32
'^\' decimal=28
'
' decimal=10
' ' decimal=32
'^]' decimal=29
' ' decimal=32
'^]' decimal=29
'
' decimal=10
' ' decimal=32
'^^' decimal=30
' ' decimal=32
'^^' decimal=30
'
' decimal=10
' ' decimal=32
'^_' decimal=31
' ' decimal=32
'^_' decimal=31
'
' decimal=10
' ' decimal=32
' ' decimal=32
' ' decimal=32
' ' decimal=32
'
' decimal=10
' ' decimal=32
'!' decimal=33
' ' decimal=32
'!' decimal=33
'
' decimal=10
' ' decimal=32
'"' decimal=34
' ' decimal=32
'"' decimal=34
'
' decimal=10
' ' decimal=32
'#' decimal=35
' ' decimal=32
'#' decimal=35
'
' decimal=10
' ' decimal=32
'$' decimal=36
' ' decimal=32
'$' decimal=36
'
' decimal=10
' ' decimal=32
'%' decimal=37
' ' decimal=32
'%' decimal=37
'
' decimal=10
' ' decimal=32
'&' decimal=38
' ' decimal=32
'&' decimal=38
'
' decimal=10
' ' decimal=32
''' decimal=39
' ' decimal=32
''' decimal=39
'
' decimal=10
' ' decimal=32
'(' decimal=40
' ' decimal=32
'(' decimal=40
'
' decimal=10
' ' decimal=32
')' decimal=41
' ' decimal=32
')' decimal=41
'
' decimal=10
' ' decimal=32
'*' decimal=42
' ' decimal=32
'*' decimal=42
'
' decimal=10
' ' decimal=32
'+' decimal=43
' ' decimal=32
'+' decimal=43
'
' decimal=10
' ' decimal=32
',' decimal=44
' ' decimal=32
',' decimal=44
'
' decimal=10
' ' decimal=32
'-' decimal=45
' ' decimal=32
'-' decimal=45
'
' decimal=10
' ' decimal=32
'.' decimal=46
' ' decimal=32
'.' decimal=46
'
' decimal=10
' ' decimal=32
'/' decimal=47
' ' decimal=32
'/' decimal=47
'
' decimal=10
' ' decimal=32
'0' decimal=48
' ' decimal=32
'0' decimal=48
'
' decimal=10
' ' decimal=32
'1' decimal=49
' ' decimal=32
'1' decimal=49
'
' decimal=10
' ' decimal=32
'2' decimal=50
' ' decimal=32
'2' decimal=50
'
' decimal=10
' ' decimal=32
'3' decimal=51
' ' decimal=32
'3' decimal=51
'
' decimal=10
' ' decimal=32
'4' decimal=52
' ' decimal=32
'4' decimal=52
'
' decimal=10
' ' decimal=32
'5' decimal=53
' ' decimal=32
'5' decimal=53
'
' decimal=10
' ' decimal=32
'6' decimal=54
' ' decimal=32
'6' decimal=54
'
' decimal=10
' ' decimal=32
'7' decimal=55
' ' decimal=32
'7' decimal=55
'
' decimal=10
' ' decimal=32
'8' decimal=56
' ' decimal=32
'8' decimal=56
'
' decimal=10
' ' decimal=32
'9' decimal=57
' ' decimal=32
'9' decimal=57
'
' decimal=10
' ' decimal=32
':' decimal=58
' ' decimal=32
':' decimal=58
'
' decimal=10
' ' decimal=32
';' decimal=59
' ' decimal=32
';' decimal=59
'
' decimal=10
' ' decimal=32
'<' decimal=60
' ' decimal=32
'<' decimal=60
'
' decimal=10
' ' decimal=32
'=' decimal=61
' ' decimal=32
'=' decimal=61
'
' decimal=10
' ' decimal=32
'>' decimal=62
' ' decimal=32
'>' decimal=62
'
' decimal=10
' ' decimal=32
'?' decimal=63
' ' decimal=32
'?' decimal=63
'
' decimal=10
' ' decimal=32
'@' decimal=64
' ' decimal=32
'@' decimal=64
'
' decimal=10
' ' decimal=32
'A' decimal=65
' ' decimal=32
'A' decimal=65
'
' decimal=10
' ' decimal=32
'B' decimal=66
' ' decimal=32
'B' decimal=66
'
' decimal=10
' ' decimal=32
'C' decimal=67
' ' decimal=32
'C' decimal=67
'
' decimal=10
' ' decimal=32
'D' decimal=68
' ' decimal=32
'D' decimal=68
'
' decimal=10
' ' decimal=32
'E' decimal=69
' ' decimal=32
'E' decimal=69
'
' decimal=10
' ' decimal=32
'F' decimal=70
' ' decimal=32
'F' decimal=70
'
' decimal=10
' ' decimal=32
'G' decimal=71
' ' decimal=32
'G' decimal=71
'
' decimal=10
' ' decimal=32
'H' decimal=72
' ' decimal=32
'H' decimal=72
'
' decimal=10
' ' decimal=32
'I' decimal=73
' ' decimal=32
'I' decimal=73
'
' decimal=10
' ' decimal=32
'J' decimal=74
' ' decimal=32
'J' decimal=74
'
' decimal=10
' ' decimal=32
'K' decimal=75
' ' decimal=32
'K' decimal=75
'
' decimal=10
' ' decimal=32
'L' decimal=76
' ' decimal=32
'L' decimal=76
'
' decimal=10
' ' decimal=32
'M' decimal=77
' ' decimal=32
'M' decimal=77
'
' decimal=10
' ' decimal=32
'N' decimal=78
' ' decimal=32
'N' decimal=78
'
' decimal=10
' ' decimal=32
'O' decimal=79
' ' decimal=32
'O' decimal=79
'
' decimal=10
' ' decimal=32
'P' decimal=80
' ' decimal=32
'P' decimal=80
'
' decimal=10
' ' decimal=32
'Q' decimal=81
' ' decimal=32
'Q' decimal=81
'
' decimal=10
' ' decimal=32
'R' decimal=82
' ' decimal=32
'R' decimal=82
'
' decimal=10
' ' decimal=32
'S' decimal=83
' ' decimal=32
'S' decimal=83
'
' decimal=10
' ' decimal=32
'T' decimal=84
' ' decimal=32
'T' decimal=84
'
' decimal=10
' ' decimal=32
'U' decimal=85
' ' decimal=32
'U' decimal=85
'
' decimal=10
' ' decimal=32
'V' decimal=86
' ' decimal=32
'V' decimal=86
'
' decimal=10
' ' decimal=32
'W' decimal=87
' ' decimal=32
'W' decimal=87
'
' decimal=10
' ' decimal=32
'X' decimal=88
' ' decimal=32
'X' decimal=88
'
' decimal=10
' ' decimal=32
'Y' decimal=89
' ' decimal=32
'Y' decimal=89
'
' decimal=10
' ' decimal=32
'Z' decimal=90
' ' decimal=32
'Z' decimal=90
'
' decimal=10
' ' decimal=32
'[' decimal=91
' ' decimal=32
'[' decimal=91
'
' decimal=10
' ' decimal=32
'\' decimal=92
' ' decimal=32
'\' decimal=92
'
' decimal=10
' ' decimal=32
']' decimal=93
' ' decimal=32
']' decimal=93
'
' decimal=10
' ' decimal=32
'^' decimal=94
' ' decimal=32
'^' decimal=94
'
' decimal=10
' ' decimal=32
'_' decimal=95
' ' decimal=32
'_' decimal=95
'
' decimal=10
' ' decimal=32
'`' decimal=96
' ' decimal=32
'`' decimal=96
'
' decimal=10
' ' decimal=32
'a' decimal=97
' ' decimal=32
'a' decimal=97
'
' decimal=10
' ' decimal=32
'b' decimal=98
' ' decimal=32
'b' decimal=98
'
' decimal=10
' ' decimal=32
'c' decimal=99
' ' decimal=32
'c' decimal=99
'
' decimal=10
' ' decimal=32
'd' decimal=100
' ' decimal=32
'd' decimal=100
'
' decimal=10
' ' decimal=32
'e' decimal=101
' ' decimal=32
'e' decimal=101
'
' decimal=10
' ' decimal=32
'f' decimal=102
' ' decimal=32
'f' decimal=102
'
' decimal=10
' ' decimal=32
'g' decimal=103
' ' decimal=32
'g' decimal=103
'
' decimal=10
' ' decimal=32
'h' decimal=104
' ' decimal=32
'h' decimal=104
'
' decimal=10
' ' decimal=32
'i' decimal=105
' ' decimal=32
'i' decimal=105
'
' decimal=10
' ' decimal=32
'j' decimal=106
' ' decimal=32
'j' decimal=106
'
' decimal=10
' ' decimal=32
'k' decimal=107
' ' decimal=32
'k' decimal=107
'
' decimal=10
' ' decimal=32
'l' decimal=108
' ' decimal=32
'l' decimal=108
'
' decimal=10
' ' decimal=32
'm' decimal=109
' ' decimal=32
'm' decimal=109
'
' decimal=10
' ' decimal=32
'n' decimal=110
' ' decimal=32
'n' decimal=110
'
' decimal=10
' ' decimal=32
'o' decimal=111
' ' decimal=32
'o' decimal=111
'
' decimal=10
' ' decimal=32
'p' decimal=112
' ' decimal=32
'p' decimal=112
'
' decimal=10
' ' decimal=32
'q' decimal=113
' ' decimal=32
'q' decimal=113
'
' decimal=10
' ' decimal=32
'r' decimal=114
' ' decimal=32
'r' decimal=114
'
' decimal=10
' ' decimal=32
's' decimal=115
' ' decimal=32
's' decimal=115
'
' decimal=10
' ' decimal=32
't' decimal=116
' ' decimal=32
't' decimal=116
'
' decimal=10
' ' decimal=32
'u' decimal=117
' ' decimal=32
'u' decimal=117
'
' decimal=10
' ' decimal=32
'v' decimal=118
' ' decimal=32
'v' decimal=118
'
' decimal=10
' ' decimal=32
'w' decimal=119
' ' decimal=32
'w' decimal=119
'
' decimal=10
' ' decimal=32
'x' decimal=120
' ' decimal=32
'x' decimal=120
'
' decimal=10
' ' decimal=32
'y' decimal=121
' ' decimal=32
'y' decimal=121
'
' decimal=10
' ' decimal=32
'z' decimal=122
' ' decimal=32
'z' decimal=122
'
' decimal=10
' ' decimal=32
'{' decimal=123
' ' decimal=32
'{' decimal=123
'
' decimal=10
' ' decimal=32
'|' decimal=124
' ' decimal=32
'|' decimal=124
'
' decimal=10
' ' decimal=32
'}' decimal=125
' ' decimal=32
'}' decimal=125
'
' decimal=10
' ' decimal=32
'~' decimal=126
' ' decimal=32
'~' decimal=126
'
' decimal=10
'
' decimal=10
Date: Wed, 09 Feb 2005 18:06:22 -0800
From: Neil Korpusik <Neil.Korpusik@sun.com>
Steven Sharp wrote:
>
> The current specification in the LRM is lacking, and should be clarified.
> This assumes that we can agree on what to specify. What XL does makes
> reasonable sense, and is the de facto standard. I don't see a reason to
> specify anything else.
I agree with this characterization. The LRM should definitely be
clarified. Since XL is only performing this transformation on an
ASCII 0 it seems reasonable to me as well. Like Shalom said, if
you don't want to see the leading spaces you can always use %0s.
I assume that there are many people out there relying on an
ASCII 0 that is embedded within a string to be displayed as a blank.
Retaining that behavior seems to be the right thing to do. And then
if the embedded ASCII 0's are to be converted into a space any
leading ASCII 0's should be treated in a consistent manner.
Date: Wed, 09 Feb 2005 18:20:51 -0800
From: Clifford E. Cummings <cliffc@sunburst-design.com>
>My uudecode won't decode something containing a NUL character, so I
>can't read your file.
And if I embed the characters, they will probably disappear. Can you use
winzip to read the files to a PC?
> >The octal-13 character was also different (line feed or ^M), as were a few
> >other of the obscure-variety characters.
>
>Were you on a PC? This might be a classic carriage-return/linefeed
>versus linefeed issue.
I was on a PC when I ran the example.
> >I don't know if I agree that we should match Verilog-XL if we think it is
> >doing something wrong. Seems like we cleaned up a couple of Verilog-XL-isms
> >for IEEE Verilog-1995 and if we think printing a space when a
> >null-character was requested is wrong, I am inclined to say so.
>
>And do you have any real argument that this is wrong?
Not really. I just thought that printing a null character was the same as
printing a non-existent character, but I don't do a lot of work with null
characters so my opinion is probably not important :-)
>The current specification in the LRM is lacking, and should be clarified.
>This assumes that we can agree on what to specify. What XL does makes
>reasonable sense, and is the de facto standard. I don't see a reason to
>specify anything else.
If everyone or near-everyone agrees, I see no reason to oppose.
Date: Wed, 9 Feb 2005 21:26:13 -0500 (EST)
From: Steven Sharp <sharp@cadence.com>
I knew this seemed familiar. I already filed this as an erratum. See
http://www.boyd.com/1364_btf/report/full_pr/549.html
Date: Fri, 11 Feb 2005 09:59:52 +0200 (IST)
From: Shalom.Bresticker@freescale.com
Actually, we work with null characters in strings much more than you may think.
Typically, we initialize a string variable (I mean a reg that we intend to use
to hold a string, not what SV defines as a string variable) to be an empty
string or to 0, which is the same thing. Later we assign it a value, often
shorter than the declared length of the string variable. Then we print it.
We do this all the time. So we are printing leading null characters.
Less often, but still common, is concatenation of string variables.
If the 2nd string contains leading nulls, the resulting string will have
embedded nulls.
In both cases, if we don't want the nulls to print as spaces, we will use
the %0s format. If we do, which is common if you want each field to have a
fixed length and print in specified columns, you will use the regular %s
format. This is the behavior we expect from experience and depend on.
So it would be Wrong to change it.
> > >I don't know if I agree that we should match Verilog-XL if we think it is
> > >doing something wrong. Seems like we cleaned up a couple of Verilog-XL-isms
> > >for IEEE Verilog-1995 and if we think printing a space when a
> > >null-character was requested is wrong, I am inclined to say so.
> >
> >And do you have any real argument that this is wrong?
>
> Not really. I just thought that printing a null character was the same as
> printing a non-existent character, but I don't do a lot of work with null
> characters so my opinion is probably not important :-)
Date: Fri, 11 Feb 2005 10:08:54 +0200 (IST)
From: Shalom.Bresticker@freescale.com
But the original issue of 549 dealt only with leading nulls.
I think the following discussion talked about embedded nulls as well.
549 did not talk about other nonprinting characters at all.
But I think we know what we want:
ASCII 0 to be converted to space, all others to print as is.
Date: Fri, 11 Feb 2005 19:22:48 -0500 (EST)
From: Steven Sharp <sharp@cadence.com>
Agreed. And %0s to supress leading ASCII 0 bytes and not print them
as spaces.
- Next message: Shalom Bresticker: "errata/650: 9.7.6 does not explicitly say what happens if "wait" condition is x or z"
- Previous message: Karen Pieper: "Minutes of the 2/7/05 Meeting"
- Maybe in reply to: sharp@cadence.com: "errata/549: 17.1.1.7 leading zeros in string format"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ] [ attachment ]
This archive was generated by hypermail 2.1.4
: Sat Feb 12 2005 - 10:10:23 PST
and
sponsored by Boyd Technology, Inc.