-
Notifications
You must be signed in to change notification settings - Fork 159
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
With c_str(...) the string length information is lost. #66
Comments
Ah! Most likely the pull request |
Interesting! Mio was not written with string_view in support, that came after it was written. Let me know if #64 fixes it for you, it should be merged soon. |
I am having several issues getting the patch to work:
but then I get This does the job, but I'am totally uncomfortable with the way it does. For your own experiments, my use case:
|
Unfortunatly, I still have two issues with the your last commit 3f86a95 Issue a) Issue b) (after curing a)) I think it's irrelevant, but for the sake of completeness: |
I'm really sorry, it looks like the latest PR that I accepted doesn't compile then. I don't have a windows machine nearby so I couldn't test it, but it seems this was a mistake. There are two options at the moment:
What do you think? |
I am willing and have time to create a proposal/patch. Unfortunately I have not fully understand I suggest I create a patch to the best of my knowledge and we'll see from there. |
Sorry I don't know GitHub working style. I try not to commit this patch for several reasons:
|
Off Topic: The warnings, my compiler throws are (after applying the patch above):
|
Hi @Spammed, thanks for all your work on this so far. I had a patchy start to the year and didn't have time to work on open source. Just wanted to give a life sign, I'll hopefully be able to get back on this in the next weeks. |
Hello, |
I pass a string_view to map_source instead of a null-terminated string.
detail::open_file() or win::open_file_helper() use c_str(...) and c_str(...) is
casting std::string.data() to a char*.
This way the string length is no longer taken into account and an incorrect file name is used.
Obviously I can work around this problem,
but think that this is at least an API-Bug.
The text was updated successfully, but these errors were encountered: