buffer~ read message arguments documentation bug

The third argument to a read message to buffer~ doesn't work as documented here.

It says "If the third argument is 0, buffer~ reads in the number of channels indicated in the header of the audio file."

If my third argument to a read message to buffer~ is not 0 but rather -1, it works exactly as described. If my third argument is 0, it ignores the channel count of the file (I think it sticks to however the buffer was initialized).

The way it does work is more consistent with other arguments used for many contexts including
the same read message's second (duration) argument whereby -1 has buffer~ matching its size to the file size.

(When my read messages weren't working with the 0 third argument, I just went through all the other integers until I found one that worked... But seriously folks, my first bug report for Max in over a decade I'm sure, and it's good to be back)