Item 5 is interesting, but I think it might be worthwhile to include the entire function here (including the comments):
BOOL WINAPI DllMain( HINSTANCE hinstDLL, DWORD fdwReason, LPVOID lpvReserved )
{
(void)hinstDLL; /* avoid warning */
(void)lpvReserved; /* avoid warning */
switch (fdwReason)
{
case DLL_PROCESS_ATTACH:
{
TCHAR szBuffer[64];
// This code will attach the process to its parent process
// if the parent process had set the environment variable.
// The corresponding code (setting the environment variable)
// is desktop/win32/source/officeloader.cxx
DWORD dwResult = GetEnvironmentVariable( "ATTACHED_PARENT_PROCESSID", szBuffer, sizeof(szBuffer) );
if ( dwResult && dwResult < sizeof(szBuffer) )
{
DWORD dwThreadId = 0;
DWORD_PTR dwParentProcessId = (DWORD_PTR)atol( szBuffer );
if ( dwParentProcessId && GetParentProcessId() == dwParentProcessId )
{
// No error check, it works or it does not
// Thread should only be started for headless mode, see desktop/win32/source/officeloader.cxx
CreateThread( NULL, 0, ParentMonitorThreadProc, (LPVOID)dwParentProcessId, 0, &dwThreadId );
// Note: calling CreateThread in DllMain is discouraged
// but this is only done in the headless mode and in
// that case no other threads should be running at startup
// when sal3.dll is loaded; also there is no
// synchronization with the spawned thread, so there
// does not appear to be a real risk of deadlock here
}
}
return TRUE;
}
case DLL_THREAD_ATTACH:
break;
case DLL_THREAD_DETACH:
osl_callThreadKeyCallbackOnThreadDetach( );
break;
}
return TRUE;
}
You can find there here: http://opengrok.libreoffice.org/xref/core/sal/osl/w32/dllent...FWIW, he says to use static analyser tools to analyze code. We do that already, and extensively. Seems a bit provocative...