The whole point of my question was compact code with no overrun risk. But it might be appropriate to have an error message for truncation.
For a command processor I would use PARSE. -- Shmuel (Seymour J.) Metz http://mason.gmu.edu/~smetz3 עַם יִשְׂרָאֵל חַי נֵ֣צַח יִשְׂרָאֵ֔ל לֹ֥א יְשַׁקֵּ֖ר ________________________________________ From: IBM Mainframe Discussion List <[email protected]> on behalf of Paul Gilmartin <[email protected]> Sent: Monday, November 4, 2024 1:40 PM To: [email protected] Subject: Re: Bounded string move? Caution: This email did not originate from George Mason’s mail system. Do not click links or open attachments unless you recognize the sender and know the content is safe. On Mon, 4 Nov 2024 17:54:20 +0000, Seymour J Metz <[email protected]> wrote: >Free-form input to a program that I am writing. Each parameter statement has >either one or two labels, separated by blanks. I'm only concerned with EBCDDIC. > ... How long should an input buffer be? Suppose you're parsing left-to-right as you receive input? An erstwhile co-worker, a novice programmer was assigned to write a command processor for our product. He began by calculating the maximum valid command string for each command and storing that number in the symbol table for each command. If a user entered a command string exceeding such a length, the program issued an error message, "Option string too long." how should the user recover? Where is the error? Should the input buffer be large enough to issue a useful diagnostic? Use an output buffer long enough that there is no overrun risk. -- gil ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO IBM-MAIN ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO IBM-MAIN
