nil pointer on c.BufferLength()

[jdamick]

Describe the bug

In React callback:

...React(frame []byte, c gnet.Conn) (out []byte, action gnet.Action) {
fmt.Printf("buf len: %d\n", c.BufferLength())

To Reproduce
Steps to reproduce the behavior:

Send UDP packet.

panic: runtime error: invalid memory address or nil pointer dereference
[signal SIGSEGV: segmentation violation code=0x1 addr=0x28 pc=0x8e7ccc]

(scrubbed stack):

github.com/panjf2000/gnet/ringbuffer.(*RingBuffer).Length(...)
github.com/panjf2000/gnet/ringbuffer/ring_buffer.go:260
github.com/panjf2000/gnet.(*conn).BufferLength(0xc00033e000, 0xc000010018)
github.com/panjf2000/gnet/connection_unix.go:220 +0xc

Expected behavior
The length of the Buffer, even if 0.

System Info (please complete the following information):

• OS amazon linux
• Go version (e.g. Go 1.13): 1.14.4
• gnet version (e.g. v1.0.0): 1.3.2

Additional context
Add any other context about the problem here.

[xscode-auto-reply]

Thanks for opening a new issue. The team has been notified and will review it as soon as possible.
For urgent issues and priority support, visit https://xscode.com/panjf2000/gnet

[panjf2000]

The buffer is not available when working with UDP, see https://gnet.host/blog/presenting-gnet/#udp

[panjf2000]

But still, maybe the doc could be a little clearer, I will update the doc for this.

[jdamick]

Even if it wasn’t available for UDP, causing a panic due to a nil is not a good api experience. Returning an error or even just returning 0 would be more user friendly

[panjf2000]

Even if it wasn’t available for UDP, causing a panic due to a nil is not a good api experience. Returning an error or even just returning 0 would be more user friendly

Allowing users to call those invalid functions and get results from them can be misleading, confusing users of gnet, e.g., you get a 0 by calling the c.BufferLength() while the frame []byte contains real data. So I prefer to keep the current pattern to force users not to call those functions under UDP.