C File read getchar yields random EOF after 32KB

Question

I was tasked to make a file copy over ipc shared memory. The problem is that getc randomly yeilds EOF after 32k char.

FILE* file;
int znak;

file = fopen("./source","r");

if(file != NULL)
{
    while(feof(file) == 0)
    {
        znak = getc(file);

        if(znak != EOF)
        {
            czekaj(0);
            *adres = znak;

            sygnal(1);
        }
    }

    wait(0);        //Wait for your turn
    *adres = EOF;
    signal(1);      //Let other process go
}

Writing part as requested

int znak
FILE *plik;
plik = fopen("./plik_klient", "w");
fclose(plik);

.....



plik = fopen("./result","a");


if(plik != NULL)
{
    while(znak != EOF)
    {

        wait(1);        //Opuszczenie semafora

        znak=*adres;

        if(znak != EOF)
        {
            fputc(znak,plik);

            signal(0);
        }

    }
}

As a result of work other process reads the info and writes it into file.

-rw-r--r--. 1 ficekba inf-17   32769 01-11 21:15 result
-rw-r--r--. 1 ficekba inf-17 1000000 01-11 21:13 source

As you can see result file has exactly 32k

https://stackoverflow.com/questions/5431941/why-is-while-feof-file-always-wrong could be an interesting read for you. — Yunnosch, Jan 11 '18 at 20:24
Possible duplicate of [Why is “while ( !feof (file) )” always wrong?](https://stackoverflow.com/questions/5431941/why-is-while-feof-file-always-wrong) — Yunnosch, Jan 11 '18 at 20:25
"to make a file copy ", open in binary mode. `fopen("./source","rb");` Add b — chux - Reinstate Monica, Jan 11 '18 at 20:27
@EugeneSh. OTOH `while(feof(file) == 0)` can lead to an infinite loop with a hard input error, yet I doubt that is OP's woes. — chux - Reinstate Monica, Jan 11 '18 at 20:28
@EugeneSh. When `char` is signed and `EOF == -1` (this is common) , a `char` can have the value of `EOF`. Still better to use `int znak`. — chux - Reinstate Monica, Jan 11 '18 at 20:29
@chux _Still better to use int._ -> always use `int` would be better — Ed Heal, Jan 11 '18 at 20:30
@chux Well, yeah, incorrectly said. Surely always use, as when `char` equals to `-1` it is indistinguishable from a binary value read `0xFF`. — Eugene Sh., Jan 11 '18 at 20:31
You don't show enough code. For example, where is the result written? — Eugene Sh., Jan 11 '18 at 20:34
You have both `signal` and `sygnal`, `wait` and `czekaj`... OK, [mcve] please, or VTC. — Eugene Sh., Jan 11 '18 at 20:44
@Haito If comments answer to this point do not fix the issue, then it lies elsewhere and a more complete [mcve] with some of the bytes of `result` and `source` are needed. — chux - Reinstate Monica, Jan 11 '18 at 20:50
Problem omited.. I've run that code on my Mac and it works flawlesly. Something is not quite happy with our University Shared server. That's good enough. Thank you very much all for help @EugeneSh. — Haito, Jan 11 '18 at 21:13
the logic for the 'write' operation is a bit convoluted. Also, there is an error. The declaration of `znak` is leaving the variable containing what every value happens to be on the stack at that location. That location might contain `0xFFFFFFFF`. So this statement: `while(znak != EOF)` would immediately exit. This is undefined behavior. Suggest initializing `znak` to `0`. — user3629249, Jan 12 '18 at 00:24
when calling `fopen()`, when the returned value is NULL, then call `perror()` so both the enclosed text AND the text giving the reason the system thinks the function failed are output to `stderr` — user3629249, Jan 12 '18 at 00:25
what is this call: `wait(1)` and this call: `signal(0)` expected to perform. Please post a [mcve] so we can help you debug the code — user3629249, Jan 12 '18 at 00:27

chux - Reinstate Monica · Answer 1 · 2018-01-11T20:41:21.057

1

Code uses char znak when int znak is best.

getc() returns an int in the range of unsigned char and EOF. This is typically 257 different values: [-1 ... 255]. When code read the file source and may return a 255 and assigns that to a char znak, znak has the value of -1 which matches EOF in this case. This fools code into thinking copying is done. and so may end up with a rump result file.

Use int znak.

Also open the file in binary mode is source may be a binary file.

// file = fopen("./source","r");
file = fopen("./source","rb");

edited Jan 11 '18 at 20:41

answered Jan 11 '18 at 20:35

chux - Reinstate Monica

143,097
13
135
256

Done, no effect – Haito Jan 11 '18 at 20:37
1

_Code uses char znak when int znak is best_ -> `int znak` is required – Ed Heal Jan 11 '18 at 20:37
Yeah I've modified it. – Haito Jan 11 '18 at 20:42
@EdHeal `int znak` is not required - even though `int` is most often the best. The value from `getc()` is in the range of `unsigned char` and `EOF`. A type of `int` or `unsigned char/unsigned` should be used. On select platforms where `UCHAR_MAX > INT_MAX`, there is a difficulty distinguishing end-of-file from character `(unsigned char) EOF` and more complex code is needed. Such code often uses `unsigned char/unsigned` for the stored return value of `getc()`. – chux - Reinstate Monica Jan 11 '18 at 20:47
1

Please `getc` returns an `int` - so Store it in an `int`. i.e. over 8 bits. `unsigned char` /`char` is (usually) 8 bits. Please tell me what platform that `UCHAR_MAX > INT_MAX` is true – Ed Heal Jan 11 '18 at 20:51
@EdHeal Do you agree `UCHAR_MAX > INT_MAX` is allowed by the C spec? Else such a search and post would not be convincing. – chux - Reinstate Monica Jan 11 '18 at 20:55
@chux I think it is not allowed by C standard. UCHAR_MAX is required to be `2^CHAR_BITS - 1`, while I am pretty sure `int` is required to be wider than `char`....yet can't find by which clause... – Eugene Sh. Jan 11 '18 at 21:05
@EugeneSh. I do not think C specifies `UCHAR_MAX <= INT_MAX`. Some graphics processors have reported using `signed char, short, int` with the same signed range as well as `unsigned char, unsigned short, unsigned` with a common unsigned range. On such odd platforms `UCHAR_MAX > INT_MAX`. Now if that C compliant - this remains unresolved. IAC, it is rare. – chux - Reinstate Monica Jan 11 '18 at 21:07
@EugeneSh. See [Is it possible to confuse EOF with a normal byte value when using fgetc?](https://stackoverflow.com/a/32641434/2410359) – chux - Reinstate Monica Jan 11 '18 at 21:16
@EugeneSh. This reports a sample of [all the integer types (< `long`) same size](https://www.thecodingforums.com/threads/implementations-with-char_bit-32.440062/#post-2435265). C's very broad embrace of such odd (and now quaint) platforms appears to allow `UCHAR_MAX > INT_MAX`. It is dubious if a future platform would attempt that given the common view that `UCHAR_MAX <= INT_MAX` is a truism. – chux - Reinstate Monica Jan 11 '18 at 21:39

C File read getchar yields random EOF after 32KB

1 Answers1