Only in languages descended from C is there an issue with nulls in strings. Certainly PL/I doesn't treat NULL any differently than any other character.
I'm perfectly aware that NULL is at code point 0. There's nothing magic about that. ANSI (nee ASA) include NULL in ASCII for a good and sufficient reason, and it wasn't as a string terminator. It already is a control character; K&R hijacked it for a different use in C. There are a lot of control characters that I wouldn't use in a document, e.g., BELL. That doesn't mean that they aren't characters. -- Shmuel (Seymour J.) Metz http://mason.gmu.edu/~smetz3 ________________________________________ From: IBM Mainframe Assembler List <ASSEMBLER-LIST@listserv.uga.edu> on behalf of Paul Raulerson <paul.rauler...@me.com> Sent: Saturday, February 10, 2018 12:14 AM To: ASSEMBLER-LIST@listserv.uga.edu Subject: Re: Fair comparison C vs HLASM On Feb 9, 2018, at 11:11 PM, Paul Raulerson <paul.rauler...@me.com> wrote: MM- I think you misread a comment I left, which was a bit unclear, and have rather gone off on a bit of a tangent. When I said ‘unless the null terminates the string” in a previous comment, what I was saying was “unless in this particular instance you choose to use a null to terminate the string.” Very clearly, in most (all) implementations of a string class, object, type, or anything similar I am aware of, a NULL character is not a valid character. Also, I really thought that other fellow was joking, but apparently he was serious. Given that, see comments below. > On Feb 9, 2018, at 4:47 PM, Seymour J Metz <sme...@gmu.edu> wrote: > > "Because they don’t have any special knowledge of strings, only untyped data." > > "special knowledge" is not relevant. The string operations in PL/I have no > special knowledge of strings either; the compare, concatenate and copy > regardless of the language of the text. Nor is the length fixed at compile > time. A formal definition of a string in a computer would be something along the lines of a “a finite sequence of symbols that are chosen from an alphabet.” Finite, because it is definitely a subset of all possible choices, and chosen because somebody had to sit down and make hard choices about what would and what would not be included in it. And yes, it is a bit mathematical, but it is also a much more precise definition. You simply contend that your idea of a string includes a NULL character in it’s alphabet, and not as a reserved character. And - that’s perfectly OK. But, pease do consider that a NULL has a code point of zero in most alphabets - including EBCDIC and UNICODE. When would you ever use it in normal writing or communications? The fact that you would not use it in a document makes it a very good choice to reserve as a control character - if you want to. > > "And the lengths of the data they operate on is fixed and defined at compile > time, not at run time." > > No. EX is not rocker science. You have to compute the lengths and fill in the size of the MVC. You are right that is computing the length of a string (or in this case, an array) at run time. Nope, using EX isn’t rocket science. But it also a poor engineering solution to use in application level code. IMO, YMMV, etc. > > "How about taking as a definition of a string any text that SuperC will > search for? Or a text string in ISP?" > > String processing is older than ISPF. How are purported limitations in. e.g., > SuperC, relevant? Through a few nulls in your source file and see if it is relevant or not… :) > > "Obviously, what a string is and how it is defined varies from language to > language. But usually they are not defined as binary data. Unicode excepted." > > Usually character strings are defined as strings of characters. NULL is a > character. With a code point of zero, meaning it is utterly meaningless in a text document, unless one uses it a it’s designation suggests - as control character zero. See the more precise definition of a string above, but I have already said numerous times the if you want to include nulls in your string handling routines, more power to you. Do NOT expect to find NULLS included in the alphabets most string routines in the world use to define exactly what a string is. To them that is. I would contend strongly that you do not have string manipulation with MVC and it’s brethren, but merely have a way to copy in memory arrays around. MVC does not pay attention at all to the data type, and will happily move any kind of data anywhere, without paying attention to alignment or other usage considerations. That is not string handling in my opinion, but again, YMMV and you are welcome to your own just as valid opinion. > > "Just by the way, a NULL as a string terminator seems to make sense." > > Only to someone who has never had to work with start/stop devices and never > had to work with 3270s. I have spent a great deal of time with old devices, and not only with devices from IBM. Your assumptions are wrong. I also suggest if you are still using ancient teletypewriters or IBM Selectrics as terminals, or using a 3270 terminal emulator that actually needs nulls to operate, you should consider upgrading. Cheap, and that kind of still has not been a commonplace problem in decades. :) :) :) :) :) :) :) :) :) :) (And yes, that was pretty much a joke. If you don’t want to take it that way, well - your choice. But it isn’t my fault if your send of humor is on the fritz. Maybe you need to insert a few more nulls? :) ) > > "MVST (Move String), CLST (Compare String), SRST (Search String) are all > instructs and all work with null terminated strings. " > > And comma delimited strings, and LF delimited strings. > > > -- > Shmuel (Seymour J.) Metz > http://mason.gmu.edu/~smetz3 >
