bug#45595: closed (recvfrom! optional start and end parameter invalid)

[GNU bug Tracking System]

Your message dated Wed, 3 Nov 2021 19:29:03 +0100
with message-id <658A0848-76C3-4ABE-B543-455AFC965623@sarc.name>
and subject line Re: recvfrom! optional start and end parameter invalid
has caused the debbugs.gnu.org bug report #45595,
regarding recvfrom! optional start and end parameter invalid
to be marked as done.

(If you believe you have received this mail in error, please contact
help-debbugs@gnu.org.)


-- 
45595: http://debbugs.gnu.org/cgi/bugreport.cgi?bug=45595
GNU Bug Tracking System
Contact help-debbugs@gnu.org with problems

--- Begin Message --- Subject: recvfrom! optional start and end parameter invalid Date: Fri, 1 Jan 2021 12:34:57 +0100

hi,

the parameter validation for the optional "start" and "end" arguments to
"recvfrom!" are off by one if "end" is passed. From libguile/socket.c
(master commit 64c89458e6):

  ...
  if (SCM_UNBNDP (end))
    cend = SCM_BYTEVECTOR_LENGTH (buf);
  else
    {
      cend = scm_to_size_t (end);
      if (SCM_UNLIKELY (cend >= SCM_BYTEVECTOR_LENGTH (buf)
                        || cend < offset))
        scm_out_of_range (FUNC_NAME, end);
    }
  ...

"end" is the optional end argument, "offset" is 0 or "start" if start
was given. The check must be:

  cend > SCM_BYTEVECTOR_LENGTH (buf) || cend <= offset

to allow filling the last byte in the buffer and verify that start is
not equal to end. A workaround to skip the validation is to not pass
end. But i think a better way would be to always validate start (and
end), if one (or both) of them are passed. A potentional fix is
attached.

If you need any additional information, please let me know.

Thank you for your great work!

-  d4ryus

recvfrom-fix.patch
Description: Text document

--- End Message ---

> --- Begin Message ---
>
>
>
> Subject: 
>
> Re: recvfrom! optional start and end parameter invalid
>
>
>
>
> Date: 
>
> Wed, 3 Nov 2021 19:29:03 +0100
>
>
>
>
> Hi,
>
> Your patch didn't allow for start == end, which is valid as far as I can tell.
>
> With that amended, applied in 1a8294f495cb202f8fcd0f260627c58e7a4c4d10. Thanks!
>
>
>
>
> --- End Message ---