Paul Raulerson <paul.rauler...@me.com> wrote on Friday, February 9, 2018 at 9:43 AM
> No, you just asked what if the string “contains” null characters. > The most correct answer to that is that the “string” is not then a string. How does the presence of a valid character, ASCII code Null character, magically cause a string to not be a string? If you'd ever had to deal with start-stop terminals that require delays you'd understand how bizarre the claim is. -- 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: Friday, February 9, 2018 9:43 AM To: ASSEMBLER-LIST@listserv.uga.edu Subject: Re: Strings (was : Fair comparison C vs HLASM) > On Feb 9, 2018, at 7:46 AM, Robin Vowels <robi...@dodo.com.au> wrote: > From: "Paul Raulerson" <paul.rauler...@me.com> > Sent: Friday, February 09, 2018 1:03 PM > > >>> On Feb 8, 2018, at 7:31 PM, Robin Vowels <robi...@dodo.com.au> wrote: >>> From: "Paul Raulerson" <paul.rauler...@me.com> >>> Sent: Friday, February 09, 2018 9:46 AM >> >>>> Because they don’t have any special knowledge of strings, >> >>> The only "special knowledge" of strings that is required is that >>> a string is composed of bytes. > >> Seriously? > > Seriously. > >> Just haven’t to disagree there. From your point of view integers and >> character data and strings and floating point values are the same thing, >> right? > > No they are not. I never said that they were. > >> Because you can move character them all the same way? > >>>> only untyped data. And the lengths of the data they operate on >>>> is fixed and defined at compile time, not at run time. >> >>> Whether the length of a string is known at compile time or at run time >>> is irrelevant. >> >>> The data is a string. And the instruction(s) that operate on them are >>> string instructions. > >> Nope, but you are as welcome to your opinion as I am to mine. :) > > You are being ridiculous. Okay - so you want to pick and choose which data types you will recognize, and yet you think I am being ridiculous? HLASM is not a strongly typed language, which not incidentally, is one of the reasons it is not suited for OOP. The introduction of strong types into HLASM is always resisted, which is the primary reason to not both extending it to be a OOP language. It has not definition of a STRING type. > >> Question - why do you think IBM added string specific instructions if MVC >> is all one ever really needs? > > IBM can add any kind of instruction that it likes. > It didn't need to add specific instructions to deal with null-terminated > strings. > MVC, MVCL are prefectly good for for handling strings. > > IBM used them in all its compilers for handling all kinds of text (i.e., > strings). > >>>> How about taking as a definition of a string any text that SuperC will >>>> search for? Or a text string in ISP? >> >>>> 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. > > Image data consists of arbitrary characters. It may contain null characters, > and plenty of them. This *is* ridiculous - image data, say your average JPEG, is not a string, by any definition I know of. It isn’t even character data. It’s just a byte array, at least on an IBM Mainframe. What is difficult to accept about that? >>>> Just by the way, a NULL as a string terminator seems to make sense. >> >>> And if the string _contains_ null characters? > >> Then it isn’t a string - unless of course, the null marks the end of the >> string. > > I just said that it didn’t. No, you just asked what if the string “contains” null characters. The most correct answer to that is that the “string” is not then a string. -- Shmuel (Seymour J.) Metz http://mason.gmu.edu/~smetz3
