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
/GS for release Windows builds #18
Comments
Please submit a pull request if you think you may improve things. I would not want buffer security checks myself. Note that as of Visual Studio 2017, the correct approach would be to provide a CMake file. |
I haven't checked the generated code, but I'll send a pull request if It's nice that VS 2017 has CMake support, although I haven't checked it. |
Why wouldn't you have buffer security check? It's a good way to know, whether your stack is corrupted, and if so, it will shut down the program. |
@PeterBocan It doesn't look like I submitted this because I was looking into integrating |
Ah, I see. It doesn't have to be a only stack buffer overflow, but any stack frame manipulation. The purpose of It's a (another) good layer of security measure against executing malicious code on the stack. I think it's worth to have enabled it. |
Sure, but look at the code: https://github.com/lemire/simdcomp/blob/master/src/simdfor.c I don't think there's much potential for stack overflows there. For comparison, here are the things |
@lnicola probably a more convenient way were to introduce a config flag, like passing DISABLE_SECURITY_FLAGS=1 to makefile. Then you'd be easy to integrate the build elsewhere. Passing security flags is a common good practice, especially on Windows, you know. Indeed, some security cflags are even missing, that are available in newer VS versions. @lemire maybe a step further could be to even move to cmake completely? Probably no big diff for autotools, as there are no deps to check. But we could fe automate dso name creation, etc. Otherwise, vs2017 is fine as editor by simply moving the folder into the project pane. Otherwise, as a vim user, i'd probably not care much :) Thanks. |
Okay, so I checked. As I suspected,
4 bytes of difference can be explained by the |
Yes. But given that we already have something that works well, it is not urgent. |
Any impact on the performance? |
@lemire I haven't tried, but I suspect it makes no difference to the generated code. |
@lnicola So you recommend closing this issue, then? |
I am for closing that. The performance hit is negligible. As I said, it's only a few assembly instructions. |
Please disregard my comment about the object size, it's not valid since I was using |
To be honest, the run to run variation seemed far too large for these numbers to mean anything. In any case, I'm fine with closing this.
|
Closing per request of the OP. |
The Windows
makefile
enables/GS
(buffer security checks) for release builds. I won't argue in favor of security over performance or the other way around, but is this intentional or should it be/GS-
?The text was updated successfully, but these errors were encountered: