bug#40576: call-process-region does not accept nil as first argument

[Philipp Stephani <p.stephani2@gmail.com>]

Am So., 12. Apr. 2020 um 18:21 Uhr schrieb Eli Zaretskii <eliz@gnu.org>:
>
> > From: Philipp Stephani <p.stephani2@gmail.com>
> > Date: Sun, 12 Apr 2020 18:01:40 +0200
> > Cc: 40576@debbugs.gnu.org
> >
> > > According to the documentation of call-process-region,
> > >   If START is nil, that means to use the entire buffer contents; END is
> > > ignored.
> > >
> > > But when I run:
> > > (call-process-region nil nil "/bin/cat" t (current-buffer))
> > > I get:
> > > Debugger entered--Lisp error: (wrong-type-argument integer-or-marker-p nil)
> > >   call-process-region(nil nil "/bin/cat" t #<buffer *scratch*>)
> > >   eval((call-process-region nil nil "/bin/cat" t (current-buffer)) nil)
> > >   elisp--eval-last-sexp(t)
> > >   eval-last-sexp(t)
> > >   eval-print-last-sexp(nil)
> > >   funcall-interactively(eval-print-last-sexp nil)
> > >   call-interactively(eval-print-last-sexp nil nil)
> > >   command-execute(eval-print-last-sexp)
> > >
> > > If, instead, I run:
> > > (call-process-region (point-min) (point-max) "/bin/cat" t (current-buffer))
> > >
> > > It works.
> > >
> > > Am I interpreting the documentation wrong?
> >
> > Nope, looks like a genuine bug (that happens only if DELETE is non-nil).
>
> Right.  But there's more here than meets the eye, because the change
> after which we started advertising the special meaning of nil for
> START exposed a problem: write_region, called from create_temp_file,
> has special meaning for START = nil: it widens the buffer and writes
> the entire buffer contents to the temp file.  Which isn't right when
> write_region is called from call-process-region, as it allows access
> to inaccessible portion of the buffer, something we shouldn't do.

I think that's pretty much intentional. The documentation says

"If START is nil, that means to use the entire buffer contents"

It specifically doesn't say to only use the accessible portion of the
buffer. Given that this behavior probably has been in place since
commit 561cb8e159e7eff7a6487a45a1cfab47ba456030 from 1994, it would be
rather unwise to introduce such a breaking change.