| Add Proposal | Add Analysis | Edit Class, Environment, or Release |
| Number | 549
|
| Notify-List |
|
| Category | errata
|
| Synopsis | 17.1.1.7 leading zeros in string format
|
| State | open
|
| Class | errata-simple
|
| Arrival-Date | Feb 24 2004
|
| Originator | Steven Sharp
|
| Release |
|
| Environment |
|
| Description |
The last sentence in 17.1.1.7 says that in string format, leading zeros are never printed. This text dates back to the original Verilog-XL Reference Manual and has been propagated into the current standard. This does not match the behavior of Verilog-XL, which prints leading zero bytes as blanks. The XL behavior is consistent with the printing of other formats, where leading zeros or blanks are printed. If a %0s format is used, XL supresses the leading blanks, which is again consistent with the description of other formats in 17.1.1.3. I believe that the intent was to document the behavior of Verilog-XL in this situation, but there was an error in the original documentation. The standard should be fixed to match the intent. There is also an example in 2.6.2 that should be changed to match. This could be done by changing the example to use %0s instead of %s, or by adding 3 spaces to the start of the first line of example output. |
| Fix |
Unknown |
| Audit-Trail |
From: Shalom.Bresticker@motorola.com To: etf-bugs@boyd.com Cc: Subject: Re: errata/549: 17.1.1.7 leading zeros in string format Date: Wed, 25 Feb 2004 18:42:32 +0200 (IST) I think the end of 17.1.1.7 (", and leading zeros are never printed") should just be deleted, and a the (correct) description of the behavior should go into 17.1.1.3 ("Size of displayed data"), where the autosizing is described for the numeric formats, including the statement that for decimal formats, "leading zeros are suppressed and replaced by spaces. In other radices, leading zeros are always displayed." This is parallel to what the %s format does. Also note that the example of 2.6.2 is repeated in 4.2.3, except that in 4.2.3 it appears correctly, with leading spaces. The difference between the two sections is that 2.6.2 is talking about string constants, whereas 4.2.3 is talking about string operands. Probably the proper place of 2.6.1 ("String variable declaration") is in Clause 3, and 2.6.2 ("String manipulation") is more or less duplicated by 4.2.3, which is the proper place for it, anyway. Shalom . > The last sentence in 17.1.1.7 says that in string format, > leading zeros are never printed. This text dates back to > the original Verilog-XL Reference Manual and has been > propagated into the current standard. This does not match > the behavior of Verilog-XL, which prints leading zero bytes > as blanks. The XL behavior is consistent with the printing > of other formats, where leading zeros or blanks are printed. > If a %0s format is used, XL supresses the leading blanks, > which is again consistent with the description of other > formats in 17.1.1.3. > > I believe that the intent was to document the behavior of > Verilog-XL in this situation, but there was an error in the > original documentation. The standard should be fixed to > match the intent. > > There is also an example in 2.6.2 that should be changed > to match. This could be done by changing the example to > use %0s instead of %s, or by adding 3 spaces to the start > of the first line of example output. -- Shalom Bresticker Shalom.Bresticker@motorola.com Design & Reuse Methodology Tel: +972 9 9522268 Motorola Semiconductor Israel, Ltd. Fax: +972 9 9522890 POB 2208, Herzlia 46120, ISRAEL Cell: +972 50 441478 [x]Motorola General Business Information [ ]Motorola Internal Use Only [ ]Motorola Confidential Proprietary From: Shalom.Bresticker@motorola.com To: etf-bugs@boyd.com Cc: Subject: Re: errata/549: 17.1.1.7 leading zeros in string format Date: Sun, 29 Feb 2004 17:55:58 +0200 (IST) Continuing the subject of null characters in strings, following a proposal to SV-EC by Dave Rich which shows the following: r = {"H",""}; // yields "H\0" "" is converted to 8'b0 I think 1364 should define this case, as it is relevant even without any extensions. I ran the following on 3 different simulators: module qq ; initial $display("%s",{"H", ""}); endmodule I got the following results from the different simulators: 0100100000000000 0100100000100000 0100100000000000000000000000000000000000 The first of the three does seem the most logical, and also is like the SV proposal. Comments? -- Shalom Bresticker Shalom.Bresticker@motorola.com Design & Reuse Methodology Tel: +972 9 9522268 Motorola Semiconductor Israel, Ltd. Fax: +972 9 9522890 POB 2208, Herzlia 46120, ISRAEL Cell: +972 50 441478 [x]Motorola General Business Information [ ]Motorola Internal Use Only [ ]Motorola Confidential Proprietary From: Steven Sharp <sharp@cadence.com> To: etf-bugs@boyd.com, Shalom.Bresticker@motorola.com Cc: Subject: Re: errata/549: Re: errata/549: 17.1.1.7 leading zeros in string format Date: Tue, 2 Mar 2004 18:39:29 -0500 (EST) > r = {"H",""}; // yields "H\0" "" is converted to 8'b0 > > I think 1364 should define this case, as it is relevant even without any > extensions. It is also relevant without any concatenation operation. The basic question is what constant value does the empty string literal "" represent? Once you know that, it should have that value in all contexts, including concatenation. The suggestion you have made would say that "" is equivalent to a single NUL character, or 8'b0. The other results you mention seeing appear to be a single space character, or 4 NUL characters (which makes very little sense, and was probably unintentional in the tool in question). Of these, I have to agree that the single NUL character makes most sense. Steven Sharp sharp@cadence.com From: Shalom Bresticker <Shalom.Bresticker@motorola.com> To: etf-bugs@boyd.com Cc: Subject: Re: errata/549: 17.1.1.7 leading zeros in string format Date: Wed, 03 Mar 2004 10:12:40 +0200 I also thought that another reasonable way would say that "" is essentially non-existent. So, for example, {"H", ""} could be considered one 8-bit character long. But at least in this particular case, none of the implementations I tested actually did it that way. There might be a good reason for that. Shalom > The suggestion you have made would say that "" is equivalent to a single > NUL character, or 8'b0. > > The other results you mention seeing appear to be a single space character, > or 4 NUL characters (which makes very little sense, and was probably > unintentional in the tool in question). > > Of these, I have to agree that the single NUL character makes most sense. -- Shalom Bresticker Shalom.Bresticker@motorola.com Design & Reuse Methodology Tel: +972 9 9522268 Motorola Semiconductor Israel, Ltd. Fax: +972 9 9522890 POB 2208, Herzlia 46120, ISRAEL Cell: +972 50 441478 [x]Motorola General Business Information [ ]Motorola Internal Use Only [ ]Motorola Confidential Proprietary From: Bruce LaVigne <bruce@hp.com> To: Shalom Bresticker <Shalom.Bresticker@motorola.com> Cc: etf-bugs@boyd.com Subject: Re: errata/549: Re: errata/549: 17.1.1.7 leading zeros in string format Date: Wed, 03 Mar 2004 08:17:18 -0800 This possibility sounds valuable from a user perspective, but only if I could count on it working in all the tools (which it sounds like it doesn't). -bruce Shalom Bresticker wrote: > The following reply was made to PR errata/549; it has been noted by GNATS. > > From: Shalom Bresticker <Shalom.Bresticker@motorola.com> > To: etf-bugs@boyd.com > Cc: > Subject: Re: errata/549: 17.1.1.7 leading zeros in string format > Date: Wed, 03 Mar 2004 10:12:40 +0200 > > I also thought that another reasonable way would say that "" is essentially > non-existent. > So, for example, {"H", ""} could be considered one 8-bit character long. > But at least in this particular case, none of the implementations I tested > actually did it that way. > There might be a good reason for that. > > Shalom > > > > The suggestion you have made would say that "" is equivalent to a single > > NUL character, or 8'b0. > > > > The other results you mention seeing appear to be a single space character, > > or 4 NUL characters (which makes very little sense, and was probably > > unintentional in the tool in question). > > > > Of these, I have to agree that the single NUL character makes most sense. > > -- > Shalom Bresticker Shalom.Bresticker@motorola.com > Design & Reuse Methodology Tel: +972 9 9522268 > Motorola Semiconductor Israel, Ltd. Fax: +972 9 9522890 > POB 2208, Herzlia 46120, ISRAEL Cell: +972 50 441478 > > [x]Motorola General Business Information > [ ]Motorola Internal Use Only > [ ]Motorola Confidential Proprietary > > > > > -- Bruce LaVigne ASIC Design Engineer Hewlett-Packard Company ProCurve Networking Business 8000 Foothills Blvd, m/s 5672 phone: (916) 785-4194 Roseville, CA 95747-5672 email: bruce@hp.com From: Steven Sharp <sharp@cadence.com> To: etf-bugs@boyd.com, Shalom.Bresticker@motorola.com Cc: Subject: Re: errata/549: Re: errata/549: 17.1.1.7 leading zeros in string format Date: Thu, 4 Mar 2004 16:38:08 -0500 (EST) > I also thought that another reasonable way would say that "" is essentially > non-existent. > So, for example, {"H", ""} could be considered one 8-bit character long. > But at least in this particular case, none of the implementations I tested > actually did it that way. > There might be a good reason for that. There are currently no examples in the language of expressions with a zero bit-width. I don't know whether such a thing would create problems with the language or not. It could certainly create problems for an implementation if it were relying in some way on all expressions having a positive width. The reason is probably related to this somehow. Note that if this is a problem, then it would also apply to your proposal that replication operations with zero repeat counts be allowed and produce a zero width result. Steven Sharp sharp@cadence.com 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. |
| Unformatted |
|
Hosted by Boyd Technology