bin/55190: A bogus error message can be reported by kadmin

[duncan%ecs.vuw.ac.nz@localhost]

>Number:         55190
>Category:       bin
>Synopsis:       A bogus error message can be reported by kadmin
>Confidential:   no
>Severity:       non-critical
>Priority:       low
>Responsible:    bin-bug-people
>State:          open
>Class:          sw-bug
>Submitter-Id:   net
>Arrival-Date:   Tue Apr 21 03:45:00 +0000 2020
>Originator:     Duncan McEwan
>Release:        NetBSD 8.1_STABLE
>Organization:
	School of Engineering and Computer Science,
        Victoria University of Wellington
>Environment:
System: NetBSD krb1.ecs.vuw.ac.nz 8.1_STABLE NetBSD 8.1_STABLE (GENERIC) #4: Sun Jan 12 17:21:45 NZDT 2020 mark%turakirae.ecs.vuw.ac.nz@localhost:/local/SAVE/8_64.obj/src/work/8/src/sys/arch/amd64/compile/GENERIC amd64
Architecture: x86_64
Machine: amd64
>Description:
	kadmin sometimes reports the error message "sl_loop: out of memory"
        when the problem has nothing to do with running out of memory.

        This is tangentially related to PR #55145, in that the bug reported
        in that PR can trigger the above misleading error message.  But
        the message can also be produced independently of that bug.
>How-To-Repeat:
        For eg: Attempt to set a password ending with a '"' character.
        kdc# kadmin -l
        kadmin> cpw --password=asdfdf" duncan
        sl_loop: out of memory
>Fix:
        In the above example the problem isn't that kadmin ran out of
        memory.  It just didn't like the unescaped single '"' character.

        The problem is caused by this code in sl.c in the function
        sl_command_loop().

        ret = sl_make_argv(buf, &argc, &argv);
        if(ret) {
            fprintf(stderr, "sl_loop: out of memory\n");
            free(buf);
            return -1;
        }

        But sl_make_argv() doesn't only fail with ENOMEM.  For other parsing
        errors it returns ERANGE ("Result too large or too small").

        This would hardly be an ideal error message either. But if the error
        return from sl_make_argv() is constrained to be a UNIX errno there
        probably isn't an great option.  Perhaps EINVAL might be better?