Problem reporting fopen / fwrite error

[tra]

How to reproduce?

Version 8.00.19 Release candidate #6

Open the Pelles IDE (not as administrator)

Run this sample:

#include <stdio.h>
#include <stdlib.h>
#include <assert.h>

size_t string_to_file(char* pszFileName, wchar_t* psz, size_t len)
{
    FILE *hFile = fopen(pszFileName, "w");
    if (hFile)
    {
        size_t w = fwrite(psz, sizeof(wchar_t), len, hFile);
        if (w != len)
        {
          assert(0);
        }
       
        if (fclose(hFile) != 0)
        {
          assert(0);
        }

        return w;
    }
    else
    {
        assert(0);
    }
    return 0;
}


int main(void)
{
    string_to_file("c:\\f.txt", L"abc", 3);
    return 0;
}

The problem: **no error is reported** by fopen or fwrite or fclose but the file f.txt is not created.
If you open the Pelles IDE as adminstrator , the sample works.

[czerny]

Has your user the right to write on C:?

[neo313]

Has your user the right to write on C:?

What do rights have to do with it? Error should be reported in that case. tra states that it wasn't.

[aardvajk]

What do rights have to do with it?

Everything. If you don't have the rights the file create gets silently redirected to the VirtualStore, where you do have the rights. Everything succeeds but if you look at C:\ you won't see it, because it's in the VirtualStore.

[neo313]

Well, thank you for informing me. Looks like a design flaw

[tra]

I did the same test using codeblocks and got the same behavior. (no error is reported)

Using Microsoft 2013 Express compiler for desktop, in C mode, the fopen function fails.
The variable errno is set with the number 13 EACCES  Permission denied .

[TimoVJL]

Check if you have that C:\f.txt created with admin and remove it and test again.

BTW:
check this folder that aardvajk mentioned:
C:\users\xxx\AppData\Local\VirtualStore\

[tra]

Yes. The file is there.
C:\Users\xxx\AppData\Local\VirtualStore
But this doesn't help.

I just wanna know what is the correct behavior.
I tried to find out references about fopen but even in the standard (draft) http://www.open-std.org/jtc1/sc22/wg14/www/docs/n1570.pdf the behaviour is not clear.

I expect an error because the function did not save the file at the correct location. 
How to inform the user that the file was not saved?

I was going to use the Pelles C to compile a markdown program that converts txt into html.
My first test, was to see if the pelles fopen suports utf8.
fopen(fileName, "r, ccs=UTF-8");  It works, but it's not documented.

One of the best references I found.

http://en.cppreference.com/w/c/io/fopen

Does Pelles C library conforms with posix?

[frankie]

As explained above the problem is not fopen.
The libc I/O refers to the underlying OS for real access. Windows is not posix compliant, unless you use a different I/O subsystem as cygwin.

My first test, was to see if the pelles fopen suports utf8.
fopen(fileName, "r, ccs=UTF-8");  It works, but it's not documented.

I'm not aware that this is already implemented, in any case linking with MSVCRT.dll (using MS runtime) you'll have all the features of MS libc.