Skip to content
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

[runtime] why f90_mset need guard the NULL pointer #1236

Open
vfdff opened this issue Mar 26, 2022 · 2 comments
Open

[runtime] why f90_mset need guard the NULL pointer #1236

vfdff opened this issue Mar 26, 2022 · 2 comments

Comments

@vfdff
Copy link

vfdff commented Mar 26, 2022

we can see the define of f90_mset in file runtime/flang/miscsup_com.c, which has a condition if (d) , the detail snip code as following, I think the user should make sure don't pass a NULL pointer to the runtime API f90_mset ? so this condition can be deleted according performance.

5359 #define _MSET(n, t)                                                            \
5360   void ENTF90(MSET##n, mset##n)(void *d, void *v, SZ_T size)                   \
5361   {                                                                            \
5362     if (d && size > 0)                                                         \
5363       __c_mset##n(d, *((t *)v), size);                                         \
5364   }
@d-parks
Copy link

d-parks commented Mar 26, 2022

I don't believe that the routines you're referencing are user callable - you might want to first double check whether these routines are internal prior to changing the semantics to have the user validate the arguments prior to the call.

Instead of deleting the test, you might want to give consideration to expanding it to also include checking that v != NULL.

@vfdff
Copy link
Author

vfdff commented May 22, 2022

thanks @d-parks very much , so do you mean that the __c_cset##n is not a general API, which don't like the memset in libc ?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants