bret = CreateProcess (NULL_CHARACTER,gnam, & ! Application Name, cmdline NULL_SECURITY_ATTRIBUTES, & NULL_SECURITY_ATTRIBUTES, & TRUE, & ! InheritHandles 0, & ! CreationFlags CREATE_NEW_CONSOLE NULL, & ! Environment variables NULL_CHARACTER, & ! Current directory StartupInfo, & ProcessInfo) ! process id etc returned
With 2017 update 1 and /check:pointer set all the NULL_xxx args give a run time error. In IFWINTY they are are declared as pointers to the specifics types. Shouldn't those be initialised with the NULL() instrinsic? I am slightly confused as I think in my mind that compiled OK with 16 and 17 original but I would need to make a test case as the full source will only compile in the latest compiler because of bug fixes only in that one.
There was a post (within 2-3 weeks) where it was found that the Windows interface declarations were in error (Steve may recall this). Perhaps your issue is related. This was 32-bit vs 64-bit oversight.
Interesting. This would have failed in 16.0 as well. Just use NULL for these arguments. Initializing them to NULL() would not change the behavior. Some time ago we change the interface for CreateProcess to take the arguments by reference but with IGNORE_LOC and ALLOW_NULL. This allows you to use a constant zero as an argument even though the type doesn't match. But when you pass a pointer, the compiler thinks you're accessing the value and gives the "null pointer" error if you have enabled pointer checking. I don't think it should here, and I believe I already reported this as an issue, but if not I will do so.
Easy enough to fix in several different ways but:
bret = CreateProcess ( & NULL(NULL_CHARACTER),gnam, & ! Application Name, cmdline NULL(NULL_SECURITY_ATTRIBUTES), & NULL(NULL_SECURITY_ATTRIBUTES), & TRUE, & ! InheritHandles 0, & ! CreationFlags CREATE_NEW_CONSOLE NULL0, & ! Environment variables NULL(NULL_CHARACTER), & ! Current directory StartupInfo, & ! populated attributes T_STARTUPINFO strucure ProcessInfo) ! process id etc returned
Works with no problem as we are passing a pointer of the correct type that is initialised to zero. I think the compiler is complaining about the pointers being uninitialised. In Iwfinty we have:
type(T_SECURITY_ATTRIBUTES), pointer :: null_security_attributes
To to my mind that should be:
type(T_SECURITY_ATTRIBUTES), pointer :: null_security_attributes = null()
What I don't understand is what has changed.......
My experiments show that nothing has changed - I can reproduce the problem going back to 12.0. Initializing the pointer to NULL() didn't change the behavior for me. At most I can theorize that if the pointer was not initialized, it might have some non-zero value that bypassed the check, but then the API call would almost certainly fail.
I have requested, in issue DPD200416141, that the compiler skip doing pointer checking for a dummy argument that has the ALLOW_NULL attribute, as most (but perhaps not all) of the relevant API declarations do. These APIs allow you to just put in NULL and that is the preferred solution. If you find APIs where this doesn't work, then I'd recommend turning off pointer checking (it is not the default, even in a Debug configuration).
>>I have requested, in issue DPD200416141, that the compiler skip doing pointer checking for a dummy argument that has the ALLOW_NULL attribute.
Wouldn't it be better to have the ALLOW_NULL attributed argument to permit NULL .OR. valid pointer?