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 <IBM-MAIN@LISTSERV.UA.EDU> on behalf of Paul Gilmartin <0000042bfe9c879d-dmarc-requ...@listserv.ua.edu> Sent: Monday, November 4, 2024 1:40 PM To: IBM-MAIN@LISTSERV.UA.EDU 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 <sme...@gmu.edu> 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 lists...@listserv.ua.edu with the message: INFO IBM-MAIN ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
