Fix memory leak and other improvements

[mgreter]

This contains one breaking change for implementors (//CC @am11):

We made an error with sass_make_data_context(char* data). We made a copy of that string pointer, which we should not have be doing, since the API indicates that libsass will take ownership of that memory. You may either have leaked memory unintentionally (which would then be fixed by this commit) or you will need to create a copy before passing it to libsass (or tell your GC that it is no longer in control of that memory).

struct Sass_Data_Context* data_ctx = sass_make_data_context(strdup(input_string));

Otherwise it fixes a few memory leaks in cssize.cpp and removes the copy_c_str sources in favor of another small function in util. Addresses #869

[mgreter]

Fixed some left over issues with interpolate parsing:
Added some more spec tests to sass/sass-spec#270

[am11]

👍
I was not sure what to make of this: #869 (comment). Perhaps both fixes will play role in addressing the flaky behavior of uv_closing in higher versions libuv (that io.js uses).

The higher the version is, more sensitive these libraries become (from GC perspective).. (-8

[am11]

(disclaimer I haven't debugged libsass latest code yet)

@mgreter, is it also applicable to file_context?

After upgrading to 3.2.0-beta.1, if I dispose input_string for data context, it starts failing tests, which makes perfect sense, because we are not making copy before sending to libsass. So I removed the free statement to avoid double free and it worked! 🎉

Next, I also removed the free statement for input_path in file context case and tested, it was working. But then I added back the free statement for this input path, it still does not break or fail anything (still working fine), whereas I was expecting it to throw as this is a double free case! So, if libsass is not owning input_path memory for file context, is this by design?

[mgreter]

I hope the following explains your question

struct Sass_File_Context* sass_make_file_context (const char* input_path);
struct Sass_Data_Context* sass_make_data_context (char* source_string);

So we do make a copy of the path, since we expect it to always be a pretty cheap operation.

[am11]

@mgreter, thanks for the comment.
I will then keep the free() statement for input_path.

There are some source_map path related issues I am facing with 3.2.0-beta.1. Some tests are failing because file member (which points to CSS file) is now returning an absolute path, when we are send the abs. path from node-sass. The expected behavior (the one that libsass v3.1.0 possesses and we shipped with node-sass v3.0.0-pre) is to get the file path resolved w.r.t location of outfile. I couldn't find anything related to paths in changelog. Should I open an issue for it? Or Gitter?