Fuzzing SIP parser

[negbie]

Fuzzit was acquired by GitLab, so I think it's not an option anymore? Let's use good old gofuzz.
https://github.com/google/gofuzz

[jart]

Fuzzing is an even smarter way to do it than the RFC torture tests. I'd welcome a change like this.

[negbie]

Did you have considered to move the SIP, SDP parser into a separate repository? This would reduce the scope and mby gain more search hit's? Since I've used Ragel in some projects myself (like fast CSeq parser) I know that it's mby not the fastest way to build a SIP parser BUT it's a good way to build a fast and correct one. Your implementation has a good quality, better than the most others you can find for Go on Github. Just thinking out loud ;)

[jart]

Would that help people only link the parts they need? If so I say let's do that.
What do you think of naming the directories sip/parse/ and sdp/parse/?

[negbie]

I still think there is a lack of a fast and correct general purpose SIP/SDP parser in Go. Probably because of this some of the existing SIP stacks in Go on Github come with their own implementations.

What do you think of naming the directories sip/parse/ and sdp/parse/?

With the current function names this would result in

...parse.Parse() (for SDP)
...parse.ParseMsg (for SIP)

Go also has a parser package https://golang.org/pkg/go/parser

Shadowing that style it could be sip/parser/ and sdp/parser/ like:
parser.ParseSIP()
parser.ParseSDP()

[jart]

Ah yes that's a good point, regarding Go readability. Taking a quick glance at the Effective Go guide, how about sip/sipfsm and sdp/sdpfsm which are succinct, unique, and short for Finite State Machine.

Out of curiosity, does the Go linker do the equivalent of -ffunction-sections? We might want to try building a binary that only references the existing sip.ParseSIP() function and verifying that it doesn't schlep in things like the dialog and socket code.

[negbie]

Taking a quick glance at the Effective Go guide, how about sip/sipfsm and sdp/sdpfsm which are succinct, unique, and short for Finite State Machine.

+1

Out of curiosity, does the Go linker do the equivalent of -ffunction-sections? We might want to try building a binary that only references the existing sip.ParseSIP() function and verifying that it doesn't schlep in things like the dialog and socket code.

Go's nearest equivalent of -ffunction-sections are Build Constraints better known as build tags.
https://golang.org/pkg/go/build/#hdr-Build_Constraints

Currently you don't use any external dependencies and without having a huge codebase I think it's probably not worth the effort.