What happens in any case if “the caller” (or somesuch) fails to add the terminating (null?) character. I’m assuming this technique is length limited or sets some kind of condition code.
Cheers, Martin (who is unfamiliar with this technique – so far) From: IBM Mainframe Discussion List <[email protected]> on behalf of Tony Harminc <[email protected]> Date: Tuesday, 22 October 2024 at 03:09 To: [email protected] <[email protected]> Subject: [EXTERNAL] Re: Bounded string move? On Mon, 21 Oct 2024 at 19:28, Seymour J Metz <[email protected]> wrote: > If I know the lengths of an input string and the length of a buffer, I can > specify a pad character and copy it with MVCL. If I know that it is > delimited by, e.g., a blank, I can use MVST but I run the risk of a buffer > overrun. Is there a quick way to copy a delimited string without > overrunning either the input or output buffer and without resorting to TRT? > If you're willing to limit your string to 256 bytes, you can probably use TROO (TRANSLATE ONE TO ONE), using your data as the table (GR0) and something like DATA DC 256AL1(*-DATA) as the data (R2). The same trick has been used with TR since S/360 days to reverse (or otherwise reorder) a string, but TROO adds the optional test for a terminating "function character" in R0 that's actually going to be checked for in your source string. TROO (vs TR) also doesn't require reinitializing the table for each use, because it doesn't translate in place. This won't do padding, and your two operands have to have the same length, so it doesn't have everything wrapped into one instruction, i.e. strncpy(). Generally though, how often does one encounter a situation where the lengths are both known *and* there may be a delimiter character *and* you want padding? If that's the case you'd probably use SRST followed by MVCL, and unfortunately have two passes over the data. Hmmm... This TROO trick can still check only one length, so you'd have to be sure the source string has a delimiter, and know the length of your target field. Which is probably not so unusual. I'm not seeing a way to use any of the other TRxx instructions to allow for a longer string, but I may be missing it. I also haven't thought hard about what happens upon hitting the CPU-determined number of characters and branching back on CC3, but it's probably fine. Tony H. ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO IBM-MAIN Unless otherwise stated above: IBM United Kingdom Limited Registered in England and Wales with number 741598 Registered office: Building C, IBM Hursley Office, Hursley Park Road, Winchester, Hampshire SO21 2JN ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO IBM-MAIN
