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

Reply via email to