Working in MSVC but not in CLANG

[graviton]

How to convert the following MSVC C based code for compatibility with CLANG compiler?
In MSVC 2019 16.7.4 the following code manage to compile but not in CLANG

    if (lpOverlapped)
    {
        bResult    = (lpOverlapped->dwCommand == FILE_READ ? ReadFile : WriteFile)(
            lpOverlapped->hFile->FileHandle,
            lpOverlapped->lpBuffer, lpOverlapped->dwBuffer, &dwResult, (LPOVERLAPPED)lpOverlapped);


        if (! bResult && (dwResult = GetLastError()) != ERROR_IO_PENDING)
        {
            lpOverlapped->Internal    = dwResult;
            PostQueuedCompletionStatus(hCompletionPort, 0, (DWORD)-5, (LPOVERLAPPED)lpOverlapped);
        }
    }

The CLANG error goes as :

error : called object type 'void *' is not a function or function pointer

For this following line :

bResult    = (lpOverlapped->dwCommand == FILE_READ ? ReadFile : WriteFile)(

What does the code doing generally?

[graviton]

Does the following conversion is the right approach?

if (lpOverlapped)
    {
        if (lpOverlapped->dwCommand == FILE_READ)
        {
            ReadFile;
            bResult = TRUE;
        }
        else
        {
            bResult = FALSE;
            WriteFile;
        }(
            lpOverlapped->hFile->FileHandle,
            lpOverlapped->lpBuffer, lpOverlapped->dwBuffer, &dwResult, (LPOVERLAPPED)lpOverlapped);
 
        if (! bResult && (dwResult = GetLastError()) != ERROR_IO_PENDING)
        {
            lpOverlapped->Internal    = dwResult;
            PostQueuedCompletionStatus(hCompletionPort, 0, (DWORD)-5, (LPOVERLAPPED)lpOverlapped);
        }
    }

[john.c]

The original code should work just fine as long as ReadFile and WriteFile have been properly declared. Are you including <windows.h> ?

[graviton]

Yes it did include a header in which containing include <Windows.h>.

Hmm WriteFile and ReadFile is properly parsed in VS 2019 IDE :



Probably a bug in CLANG, i have reported it.

About my 'conversion' above, is it the converted correct code?

About my toolchain, i have installed LLVM-UTILS from here to support CLANG based compilation in VS 2019 IDE.

Thanks for helping me out btw, i have been hopeless about these for a long time.

[john.c]

I doubt it's a bug in clang. It's unlikely that they declared ReadFile and WriteFile to be void*, which seems to be what the error is saying.

No, your conversion is wrong. You can't just mention a function name as a statement and then put the parameters as the following statement. Also, the way you're setting bResult is incorrect. It's supposed to be TRUE if the function call succeeded, FALSE otherwise. The original code is correct.

The original code is constructed from a conditional operator which chooses between ReadFile or WriteFile, and the function arguments between parentheses. A simplified example:

#include <stdio.h>
  
int add(int x, int y) { return x + y; }
int sub(int x, int y) { return x - y; }
 
int main() {
    int choice;
 
    printf("Enter 1 for add or 0 for sub: ");
    scanf("%d", &choice);
 
    // either add or sub will be called with args 1, 2, depending on truth value of choice,
    // i.e., whether choice is non-zero (true) or zero (false).
    int result = (choice ? add : sub)(1, 2);
 
    printf("%d\n", result);
 
    return 0;
}

I don't know anything about using clang in VS, so I can't help you with that

[graviton]

Thanks man for the example but can you please convert the sample code into conditional operator version one?.

Having difficulties to understand it without comparing both of them.

Also just notice in the example the end has only 2 parameters :

intresult = (choice ? add : sub)(1, 2);

While in mine it has 3? parameters :

bResult = (lpOverlapped->dwCommand == FILE_READ ? ReadFile : WriteFile)(lpOverlapped->hFile->FileHandle, lpOverlapped->lpBuffer, lpOverlapped->dwBuffer, &dwResult, (LPOVERLAPPED)lpOverlapped);

About FILE_READ :

#define	FILE_READ			0
#define	FILE_WRITE			1

After re-reading, starting to understand it, current conversion :

	if (lpOverlapped)
	{


		if (lpOverlapped->dwCommand == FILE_READ)
		{
			bResult = WriteFile(lpOverlapped->hFile->FileHandle,
				lpOverlapped->lpBuffer, lpOverlapped->dwBuffer, &dwResult, (LPOVERLAPPED)lpOverlapped);
		}
		else
		{
			bResult = ReadFile(lpOverlapped->hFile->FileHandle,
				lpOverlapped->lpBuffer, lpOverlapped->dwBuffer, &dwResult, (LPOVERLAPPED)lpOverlapped);
		}
		if (!bResult && (dwResult = GetLastError()) != ERROR_IO_PENDING)
		{
			lpOverlapped->Internal = dwResult;
			PostQueuedCompletionStatus(hCompletionPort, 0, (DWORD)-5, (LPOVERLAPPED)lpOverlapped);
		}
	}

What do you think?, what have i did wrong this time?.

[john.c]

can you please convert the sample code into conditional operator version one?.

It would be exactly what you originally posted. The simplified example was supposed to make it easier to see what's going on.

Also just notice in the example the end has only 2 parameters :

So?

While in mine it has 3? parameters :

No. Yours has 5 arguments.

About FILE_READ :

I never asked about FILE_READ.

what have i did wrong this time?

Nothing. But since the original version was also correct and you had an error with it, I assume you're getting an error with this one, too. If it's working, then something else must have changed. If it isn't, then post all the errors.

[graviton]

no. Yours has 5 arguments.

Dohh, you are correct, missed the commas.

I never asked about FILE_READ.

It just to shows the code completeness so you can now if i am either doing it right or no.

Nothing. But since the original version was also correct and you had an error with it, I assume you're getting an error with this one, too. If it's working, then something else must have changed. If it isn't, then post all the errors.

That's why i am confused, because compiling the the exact same original code is working with MSVC 2019, while clang failing. Also compiling with Conditional operators version with clang is compiled without any errors, hence i am suspecting it's should be a bug.

[laserlight]

Also compiling with Conditional operators version with clang is compiled without any errors, hence i am suspecting it's should be a bug.

You mean without conditional operators? The code from post #1 that you said didn't compile on clang is the one that uses a conditional operator.

As john.c mentioned in post #5, your code in post #2 might compile with both compilers, but it is completely different in meaning from the code in post #1, e.g., the code in post #2 neither calls ReadFile nor WriteFile, it just includes their names in statements that have no net effect and hence can be optimised by being removed. So the code in post #2 proves nothing about whether clang has a particular bug.

[graviton]

Yes, sorry what i have meant was without conditional operator.

What i have meant also, this following code is compile-able in MSVC 2019 and not on CLANG. :

if (lpOverlapped)
{
    bResult    = (lpOverlapped->dwCommand == FILE_READ ? ReadFile : WriteFile)(
        lpOverlapped->hFile->FileHandle,
        lpOverlapped->lpBuffer, lpOverlapped->dwBuffer, &dwResult, (LPOVERLAPPED)lpOverlapped);


    if (! bResult && (dwResult = GetLastError()) != ERROR_IO_PENDING)
    {
        lpOverlapped->Internal    = dwResult;
        PostQueuedCompletionStatus(hCompletionPort, 0, (DWORD)-5, (LPOVERLAPPED)lpOverlapped);
    }
}

And the new revised 'conversion' is compile-able on both MSVC 2019 and CLANG :

if (lpOverlapped)
{


    if (lpOverlapped->dwCommand == FILE_READ)
    {
        bResult = WriteFile(lpOverlapped->hFile->FileHandle,
            lpOverlapped->lpBuffer, lpOverlapped->dwBuffer, &dwResult, (LPOVERLAPPED)lpOverlapped);
    }
    else
    {
        bResult = ReadFile(lpOverlapped->hFile->FileHandle,
            lpOverlapped->lpBuffer, lpOverlapped->dwBuffer, &dwResult, (LPOVERLAPPED)lpOverlapped);
    }
    if (!bResult && (dwResult = GetLastError()) != ERROR_IO_PENDING)
    {
        lpOverlapped->Internal = dwResult;
        PostQueuedCompletionStatus(hCompletionPort, 0, (DWORD)-5, (LPOVERLAPPED)lpOverlapped);
    }
}

Hence that's why i came into that conclusion.

@laserlight
What do you think about the logic correctness in the revised conversion above?, is it correct?.

Assuming with the following define :

#define FILE_READ           0
#define FILE_WRITE          1

[laserlight]

What do you think about the logic correctness in the revised conversion above?, is it correct?

Yes, this revised code looks semantically equivalent to the code in post #1.

Of course, this means that you can move on to other things, but if you think you've found a compiler bug and want to report it to clang: take john.c's example from post #5 and compile it using clang. Does it compile successfully? I suspect it will, so the next thing to do is to temporarily save your current code elsewhere, then begin simplifying the code until it is the smallest and simplest program that you expect should compile, but which demonstrates the problem. This way, instead of just posting a code snippet that looks correct, you can post an entire program that other programmers can look over without digging through a mountain of unrelated stuff, and try to compile for themselves. This can help eliminate the issue where you think you've found a compiler bug, but actually it is a bug in your own code that you have not posted.