Jean-François MORFIN
asked on
FILE closing
for three decades on BCC and other C compiles I used to close files as follows:
Fabcd=(FILE *)fclose(Fabcd);
and prior to open a file to test if (!Fabcd) fopen(Fabcd, ...)
When using it with gcc I have "cast to pointer from integer to of different size (Wint-to-pointer-cast).
Any solution ?
Fabcd=(FILE *)fclose(Fabcd);
and prior to open a file to test if (!Fabcd) fopen(Fabcd, ...)
When using it with gcc I have "cast to pointer from integer to of different size (Wint-to-pointer-cast).
Any solution ?
gcc compiler will be using these api's:
FILE * fopen ( const char * filename, const char * mode );
http://www.cplusplus.com/reference/cstdio/fopen/
"a null pointer is returned" if fails to open.
int fclose ( FILE * stream );
http://www.cplusplus.com/reference/cstdio/fclose/
"If the stream is successfully closed, a zero value is returned.
On failure, EOF is returned."
Here is their fopen/fclose example. It doesn't look at all like your post since the first arg in fopen is:
FILE * fopen ( const char * filename, const char * mode );
http://www.cplusplus.com/reference/cstdio/fopen/
"a null pointer is returned" if fails to open.
int fclose ( FILE * stream );
http://www.cplusplus.com/reference/cstdio/fclose/
"If the stream is successfully closed, a zero value is returned.
On failure, EOF is returned."
Here is their fopen/fclose example. It doesn't look at all like your post since the first arg in fopen is:
const char * filename
/* fclose example */
#include <stdio.h>
int main ()
{
FILE * pFile;
pFile = fopen ("myfile.txt","wt");
fprintf (pFile, "fclose example");
fclose (pFile);
return 0;
}
I am not familiar with BCC. Could you post their APIs for fopen and fclose?
ASKER
Sorry for the typo.
I certainly proceed as indicated, as follows:
I certainly proceed as indicated, as follows:
char pfile [100]; FILE *FpFile =0L; // documentation of the file.
....
sprintf(pfile ,"%s\\...\\..." , ...); // ....
pFile = fopen (pfile, "r");
....
if (pFile) pFile=(FILE *) fclose (pFile);
It works well with BCC, but gcc dislike it.
if( pFile && !fclose (pFile) ){ pFile=NULL; }
>> if (pFile) pFile=(FILE *) fclose (pFile);
here pFile is const char* but you are type casting to FILE* which is not correct.
More over, in fclose() you have to use FILE* but you are using char*
Ex:
fclose(FpFile); // or int retVal = fclose(FpFile); if interested in the status of close operation
here pFile is const char* but you are type casting to FILE* which is not correct.
More over, in fclose() you have to use FILE* but you are using char*
Ex:
fclose(FpFile); // or int retVal = fclose(FpFile); if interested in the status of close operation
It may be another typo, but http:#a40511980 uses pFile, which, unlike pfile and FpFile, is not declared, but the usage only makes sense if it was FILE *pFile;
ASKER CERTIFIED SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
If you just want to suppress that warning (which I don't recommend), then you can use the suppression flag to your gcc command: -Wno-int-to-pointer-cast
Even if you get the compiler to accept it, casting an EOF into a FILE* when the close fails should not be expected to produce anything sensible.
The only int value that can safely be cast into a FILE* is 0 (or a large enough integer type that was created from a cast of a valid FILE*)
The only int value that can safely be cast into a FILE* is 0 (or a large enough integer type that was created from a cast of a valid FILE*)
I agree with ozo that your code should make sense. That's why I was asking these questions above and was hoping to find a more meaningful approach:
Why do you want to take the int value returned from fclose, and force it to be a FILE* type? How are you then using the value of FpFile from the fclose?There are times, however, where the wrong approach is needed for the short-term. If the author's code base has thousands of cases like this and other similar bad code that the BCC compiler accepts, then if the program functionality remains the same when bypassing the compiler warnings, that gives the developers time to make the correct adjustments and remove the warning suppression.
ASKER
Sorry for the delay. This and your other comments give me some things to think about. Actually what I would need is a real refurbishing of the file functions as nI also use for some the MD5 in a parallel table to differentiate the need for update (I produce local sites to be duplicated globally).
Thank you !
Thank you !
means you can only call fopen(0, ...)
how can that work?
How is Fabcd declared?