Guard against undefined std::string behavior.

[petejohanson]

• Passing NULL char pointer to std::string constructor results
  in undefined behaviour, so guard against that in the generated
  C interface. See:

  http://stackoverflow.com/questions/17464514/initialize-stdstring-from-a-possibly-null-char-pointer

This came out of a discussion of a crash in sound-juicer on FreeBSD 11.0-CURRENT on the GNOME bugzilla: https://bugzilla.gnome.org/show_bug.cgi?id=742019 The current code happens to work on Linux, but this is a coincidence, and not based on defined behaviour, AFAICT.

I think it is fair that libmusicbrainz should guard against this so the C interface can be idiomatic, but libmusicbrainz avoids the undefined behaviour internally.

Thoughts?

[petejohanson]

Any thoughts?

[adhawkins]

I'm happy to merge this, but can't see me releasing a new version simply to fix this.

To be honest, I think it's quite clear that the C interface is expecting a null terminated string here, so ultimately the calling application should be responsible for passing correct data. I'd suggest an update to sound-juicer to ensure that it passes an empty string (or doesn't call the method at all) if no proxy is required.

[petejohanson]

Ok, I've added your comments to the SJ bug (https://bugzilla.gnome.org/show_bug.cgi?id=742019) to get their feedback. I've also created a FreeBSD PR (https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=196959) for this to address this in FreeBSD until a new libmusicbrainz5 version is released.

Thanks.