Describe the bug

The LPOP documentation says that when a count is given the result is "Array reply: list of popped elements, or nil when key does not exist." However, this fast path writes a nil reply when count is 0, rather than an empty list.

It's also exiting before even checking the type of the key, so instead of getting a WRONGTYPE error, it can "successfully" do an LPOP on non-lists. This differs from SPOP key 0 which return a WRONGTYPE error.

To reproduce

With redis-cli (note, I'm using server version 6.2.6, but only have redis-cli 5.0.7 handy, so this is presumably all RESP2):

127.0.0.1:6379> rpush foo a
(integer) 1
127.0.0.1:6379> lpop foo 0
(nil)

Expected behavior

Expected to get (empty list or set).

Additional information

It seems a bit odd that SPOP returns an empty array if the key does not exist while LPOP/RPOP returns nil.