This is with reference to the question I asked earlier -
What is the correct way to declare and use a FILE * pointer in C/C++?
MyFile.h
char sMsg[712] = "";
#define STD_MSG(string) \
fprintf (stderr, string)
#define ERR_MSG(fp, string) \
fprintf (fp, "%s\n", string);\
fflush (fp)
MyFile.C
#include "PdmTestClnt.h"
//---------------------------------------------------------------
// ** Global variables
//---------------------------------------------------------------
FILE * fpErr = NULL;
funcxyz() {
//FILE * fpErr1 = NULL;
sprintf (sMsg, "************ CHECKING FOR THE CRASH ************. \n");
ERR_MSG (fpErr, sMsg);
//ERR_MSG (fpErr1, sMsg);
}
//========================================================================
// Main
//========================================================================
integer main (integer argc, char ** argv)
{
//FILE * fpErr = NULL;
if (!(fpErr = sysFopen (sErrFileName, "a+")))
{
sprintf (sMsg,"Error in opening file %s", sErrFileName);
STD_MSG (sMsg);
}
// Log in the error file
sprintf (sMsg, "Log into the error file. \n");
ERR_MSG (fpErr, sMsg);
funcxyz();
}
If the File pointer is declared global it works. But if it is declared local it results in Memory fault(coredump).
Ran on:
HP Unix Itanium
aCC compiler (C++ Compiler)
Can somebody explain the behaviour?
Edit: Sorry for not editing the question. I now understand the problem with printf()/fprintf(). I showed the results for printf()/fprintf() with Dev C++ compiler on Windows in my answer. But when I run it on HP Unix with aCC compiler it ignores %s completely and always prints the string correctly. So how do I ask my architect to change it without showing him it memory fault on Unix?
Thanks.
Assuming by local you mean in funcxyz() uncommenting fpErr1, it segfaults because you don't open a file. You can't just use NULL there, where would you expect the data to go?
I would suggest writing funcxyz to take fpErr1 as a parameter, e.g.:
funcxyz(FILE *fpErr1) {
//FILE * fpErr1 = NULL;
sprintf (sMsg, "************ CHECKING FOR THE CRASH ************. \n");
ERR_MSG (fpErr1, sMsg);
//ERR_MSG (fpErr1, sMsg);
}
And then calling it from main like:
...
funcxyz(fpErr);
...
This information is irrelevent to the question. I should read more carefully before I answer. =X
Your problem is that you're shadowing the fpErr on the global scope with the one in the local scope. For example:
int var = 0;
void print_var() {
printf("print_var: %d\n", var);
}
int main() {
int var = 42;
printf("main: %d\n", var);
print_var();
return 0;
}
If you run the code, the output should be:
main: 42
print_var: 0
In your case, fpErr has a value of NULL (0) and thus the file I/O functions try accessing data at NULL, which causes the segmentation fault.
Don't define variables in headers - it is a nasty habit to get into.
Remove the initializer from sMsg[] in the header, and prepend 'extern' - and do define the variable, with initializer, in an appropriate source file (usually MyFile.c if the header is MyFile.h). This really matters when MyFile.h is used by several source files - and if it is used by just one source file, why were you using a header in the first place?
Your code also includes 'PdmTestClnt.h' and not MyFile.h - should we assume that MyFile.h is what you meant to include?
funcxyz() has no return type - it won't compile in C++ or under a strict C99 compiler. Why does the function format into sMsg, and then use fprintf() to copy the string? fprintf() can do the whole job (and then some).
Why you need a global definition
When you have a global variable, the code in main() initializes it by calling fopen(), and the other functions can use the initialized value. That's convenient. When you have a local variable, you have to initialize it. That's a pain because you'd end up opening the file many times which has numerous unwanted side effects - too many file handles in use, you have to close them too, and you probably keep truncating the output already in the file. To avoid that, pass the file pointer to the functions - or accept that a global is OK. Think about it - in some shape or form, the names stdin, stdout and stderr refer to global variables too.
void funcxyz(FILE *fp)
{
sprintf(sMsg, "************ CHECKING FOR THE CRASH ************. \n");
ERR_MSG (fpErr, sMsg);
}
int main(int argc, char **argv)
{
FILE *fpErr = NULL;
if ((fpErr = sysFopen(sErrFileName, "a+")) != 0)
{
sprintf(sMsg,"Error in opening file %s", sErrFileName);
STD_MSG(sMsg);
}
// Log in the error file
sprintf(sMsg, "Log into the error file. \n");
ERR_MSG(fpErr, sMsg);
funcxyz(fpErr);
return(0);
}
Related
I dont understand the mistake I am making.
I tryed alot but I am unable to read my FILE.
Basically I write an structure into a file named 0.txt / 1.txt / 2.txt ... based of account amound.
I realy seached hours to fix my problem but I dont understand how I can fix and why I get the ERROR.
Also I have no problem in complining my code (with dev c++) but when I press on Load Accounts Button I get the ERROR "Segmentation Fault" (using windows 7).
I noticed that the problem is at fread() line in function ladeAccounts().
The name of my Structure is "iAccount".
The variable infoma is as iAccount typed and the "number of accounts existing" typed as int anzahl in newAccount() decides the path.
iAccount looks like this:
struct iAccount
{
string ID;
string password;
int level;
};
This is how I write my STRUCT into the FILE:
void Account::newAccount(int anzahl, string username, string pw, int lvl)
{
iAccount neu;
neu.ID = username;
neu.password = pw;
neu.level = lvl;
ss.str("");
ss<<anzahl;
s = ss.str();
s = "Accounts/"+s+".txt";
f1 = fopen(s.c_str(), "w");
fseek(f1, 0, SEEK_SET);
fwrite(&infoma, sizeof(iAccount), 1, f1);
fclose(f1);
}
This is how I read the File (ERROR APPEARS when I call fread()
void Account::ladeAccount(int nummer)
{
stringstream sa;
iAccount account_geladen;
sa.str("");
sa<<nummer;
s = sa.str();
s = "Accounts/"+s+".txt";
f2 = fopen(s.c_str(), "r");
fseek(f2, 0, SEEK_SET);
fread(&infoma, sizeof(infoma), 1, f2);
fclose(f2);
}
Thank you for your help. I have no clue where my problem is and as I said I am searching for hours.
EDIT:
The file gets opened I tryed it (f2 is true!).
EDIT":
ERRNO = 0 !!!
SEE HERE:
ostringstream Str;
Str << errno;
infoma.ID = Str.str();
Just did this to see the result of errno in my wxtextlabel.
Reason
You are most probably calling fread on a NULL file handle. So you have two problems here:
In your code (you don't check if fread succeeds or returns a NULL value)
Your file can't be opened for some reason (this, you should investigate...)
Explication
fopen (see documentation) can return a NULL handle for different reasons. If you don't check the validity of the handle before calling fread you will have a segmentation fault.
Tips
As you can read in the official documentation I linked above, on most library implementations the errno variable can help you giving the system-specific error code on failure. This could help you debugging your error in opening the file.
Side Issues
Once you solve this bug in our code you will have other issues. As people (notably #Christophe) remarked in other answers, there is a structural problem in your code because you try to serialize/deserialize on your file objects non POD (aka your strings). Since string are complex objects you can't serialize them directly.
The approach of using an array of characters will work correctly, as simple types can be handled the way you coded.
For this reason, you can use the std::string c_str() method to obtain a null terminated array of chars from your string and store it in the file.
The opposite operation is even more straightforward, as you can initialize a std::string simply passing the deserialized array of chars:
std::string str(the_array);
You have a problem because you use fread() to load binary data. But this works only with plain old data (POD) objects.
It uses to give desastrous results with less trivial objects especially if the internals of these manage dynamic memory allocaton and/or pointers like it's the case here with strings.
By the way:
If you read/write binary data, you should really use "rb"/"wb" as mode for fopen(). If you don't you would'nt necessary have a seg.fault, but your data might be incorrect on some systems.
Edit:
Sorry, I didn't read well enough: if it happens right at fread() the reason provided by Alex will certainly help. However I leave this answer because as soon as you've solved your fopen() issue, you might get segmentation errors if you try to work with the object that you've read. If you're not conviced, look at sizeof(iAccount) and compare it to the size your string content.
EDIT
if(f2) is true so I am wrong and file got opened successfull right?
I found out that the file is not opened/the fopen can not handle with the path for example 0.txt .
Also I tryed to enter the path directly without building it (without stringstream and so on). Still I have the problem of the segmentation fault. I checked everything the file exists in the folder Accounts. I have an other file called "Accounts.txt" in the same folder and there I have no problem reading the amound of accounts existing (also using a struct). There I dont even check if the fopen had success but it works anyway I will write the code for the file-open-check later.
The code for the reading/writing into Accounts/Accounts.txt is:
struct init{
int anzahl_1;};
init anzahl;
FILE* f;
static string ss = "Accounts/Accounts.txt";
int account_anzahl1()
{
f = fopen(ss.c_str(), "r");
fread(&anzahl, sizeof(init), 1, f);
fseek(f, 0, SEEK_END);
fclose(f);
return anzahl.anzahl_1;
}
void account_anzahl_plus()
{
anzahl.anzahl_1 = anzahl.anzahl_1 +1;
f = fopen(ss.c_str(), "w");
fwrite(&anzahl, sizeof(init), 1, f);
fclose(f);
}
There I have no problem!
I have a program that writes occasional status updates, but I'm sure some will want it to run silently so I have provided a -s / --silent CLI option. What would be the best way to have my program abide by that parameter?
This method adds a global variable, and still executes the fprintf functions adding to the smell slightly.
FILE *outfile
if (silent) {
*outfile = NULL;}
else {
*outfile = stderr;}
fprintf (outfile, "This program can run silently");
This method also adds a global variable, and if statments littered throughout the code also adding to the smell.
if (!(silent)){
fprintf (stdout, "This program can run silently");
}
Ternary operators with a global variable might be more elegant:
(silent) ? : fprintf(stdout, "This program can run silently");
Are there better practices than any of these methods? Are there shortcomings to any one that I'm not seeing?
As Don Shankin said in his comment, the most maintainable way to do it is by wrapping fprintf() in a function that implements your filtering logic, and then have your code call the wrapper function rather than calling fprintf() directly. That way you only have to implement the filtering logic in a single location and not all over the place. Here's a program that demonstrates the technique:
#include <stdio.h>
#include <stdarg.h>
bool silent = false;
void my_fprintf(FILE * outFile, const char * fmt, ...)
{
if (silent == false)
{
va_list argsList;
va_start(argsList, fmt);
vfprintf(outFile, fmt, argsList);
va_end(argsList);
}
}
int main(int argc, char ** argv)
{
my_fprintf(stdout, "Not silent now...\n");
silent = true;
my_fprintf(stdout, "But now I'm silent, so you won't see this!\n");
silent = false;
my_fprintf(stdout, "Silent is false again!\n");
return 0;
}
... and here is the output from the program:
Not silent now...
Silent is false again!
Since it's also tagged C++, I'd like to point out that you can replace the output buffer of std::cout by calling std::cout.rdbuf(newbuf). A "devnull buff" is trivial to implement.
I am calling a function funcB from funcA.
funcB uses several printf statements to output data.
Is there a way for me to capture that data via funcA?
I can not modify funcB.
funcB(){
printf( "%s", "My Name is" );
printf( "%s", "I like ice cream" );
}
funcA(){
funcB();
}
(This answer is a corrected version based on this answer.)
This answer is POSIX centric. Use open to create a file descriptor for the file you want to redirect to. Then, use dup2 to STDOUT_FILENO to change stdout to write to the file instead. But, you'll want to dup the STDOUT_FILENO before you do that, so you can restore stdout with another dup2.
fflush(stdout);
int stdout_fd = dup(STDOUT_FILENO);
int redir_fd = open(redirected_filename, O_WRONLY);
dup2(redir_fd, STDOUT_FILENO);
close(redir_fd);
funcB();
fflush(stdout);
dup2(stdout_fd, STDOUT_FILENO);
close(stdout_fd);
If funcB is using std::cout, use std::cout.flush() instead of fflush(stdout).
If you want to manipulate C++ streams more directly, you can use Johnathan Wakely's answer.
If nothing else in your program uses printf, you can write your own version and link it explicitly. The linker will not look in the standard library if the function is already defined. You can probably use vsprintf for the implementation, or some safer version with overrun checking if it is supplied by your compiler.
If you're willing to play a dirty game interposing on printf you can 'steal' its output doing something like:
#include <stdio.h>
#include <stdarg.h>
static char buffer[1024];
static char *next = buffer;
static void funcB(){
printf( "%s", "My Name is" );
printf( "%s", "I like ice cream" );
}
static void funcA(){
funcB();
// Do stuff iwth buffer here
fprintf(stderr, "stole: %s\n", buffer);
next=buffer; // reset for later.
}
int main() {
funcA();
}
int printf(const char *fmt, ...) {
va_list argp;
va_start(argp, fmt);
const int ret = vsnprintf(next, sizeof buffer-(next-buffer), fmt, argp);
next += ret;
va_end(argp);
return ret;
}
You could use a flag to indicate how to handle the instances where you want printf to work as normal. (E.g. map it onto fprintf or use dlsym()/similar to find the real call).
You could also use realloc to manage the size of the buffer more sensibly.
Put funcB in a separate program. You can then capture its standard output, e.g. by piping or by redirecting it to a file. How to do that generally depends on the OS and is outside the realm of C++.
Alternatively, maybe you can redirect your funcA process' standard output to a file, then call FuncB, and retrieve the output from the file.
Again, how to do that is outside the realm of C++ and depends on the OS.
What is the correct way to declare and use a FILE * pointer in C/C++? Should it be declared global or local? Can somebody show a good example?
It doesn't matter at all whether it's local or global. The scope of the file pointer has nothing to do with its use.
In general, it's a good idea to avoid global variables as much as possible.
Here's a sample showing how to copy from input.txt to output.txt:
#include <stdio.h>
int main(void) {
FILE *fin, *fout; int c;
// Open both files, fail fast if either no good.
if ((fin = fopen("input.txt", "r")) == NULL) {
fprintf(stderr, "Cannot read from input.txt");
return 1;
}
if ((fout = fopen("output.txt", "w")) == NULL) {
fprintf(stderr, "Cannot write to output.txt");
fclose(fin);
return 1;
}
// Transfer character by character.
while ((c = fgetc(fin)) >= 0) {
fputc (c, fout);
}
// Close both files and exit.
fclose(fin);
fclose(fout);
return 0;
}
It's just an ordinary pointer like any other.
FILE *CreateLogFile()
{
return fopen("logfile.txt","w"); // allocates a FILE object and returns a pointer to it
}
void UsefulFunction()
{
FILE *pLog = CreateLogFile(); // it's safe to return a pointer from a func
int resultsOfWork = DoSomeWork();
fprintf( pLog, "Work did %d\n", resultsOfWork ); // you can pass it to other functions
fclose( pLog ); // just be sure to clean it up when you are done with fclose()
pLog = NULL; // and it's a good idea to overwrite the pointer afterwards
// so it's obvious you deleted what it points to
}
Here is the first hit on google for "file io in c"
http://www.cs.bu.edu/teaching/c/file-io/intro/
Here is the third hit from gamedev with more of a C++ slant
http://www.gamedev.net/reference/articles/article1127.asp
You declare the pointer in the scope that you need it.
int main(void)
{
char c;
FILE *read;
read = fopen("myfile", "r"); // opens "myfile" for reading
if(read == NULL)
{
perror("Error: could not open \"myfile\" for reading.\n");
exit(1);
}
c = fgetc(read);
fclose(read);
printf("The first character of myfile is %c.\n", c);
return 0;
}
You're perfectly allowed to declare global filehandles if you like, just like any other variable, but it may not be recommended.
This is the C way. C++ can use this, but I think there's a more C++ friendly way of doing it. As a note, I hate it when questions are marked C/C++, because C and C++ are not the same language and do not work the same. C++ has a lot of different ways to do things that C doesn't have, and they may be easier for you to do in the context of C++ but are not valid C. So while this will work for either language, it's not what you want if you predominantly use C++.
EDIT: Added some error checking. Always use error checking in your code.
First, keep in mind that a file pointer (and the associated allocated structure) is based on the lower level open() read() write() calls. The associated file descriptor (obtained by fileno(file_pointer) is the least interesting thing, but something you might want to watch your scope with.
If your going to declare a file pointer as global in a module, its usually a very good idea to keep it static (contained within that module / object file). Sometimes this is a little easier than storing it in a structure that is passed from function to function if you need to write something in a hurry.
For instance, (bad)
#include <stdio.h>
#include ...
#define MY_LOG_FILE "file.txt"
FILE *logfile
Better done as:
#include <stdio.h>
#define MY_LOG_FILE "file.txt"
static FILE *logfile;
int main(void)
{
UNLESS, you need several modules to have access to that pointer, in which case you're better off putting it in a structure that can be passed around.
If its needed only in one module, consider declaring it in main() and letting other functions accept a file pointer as an argument. So, unless your functions within the module have so many arguments that another would be unbearable .. there's (usually) no reason to declare a file pointer globally.
Some logging libraries do it, which I don't care for ... especially when dealing with re-entrant functions. Nevermind C's monolithic namespace :)
First of all, i'd to establish that i do have the text file in my Folders directory. Im using visual studio and it is where my source code is compiling.
The code below should demonstate why its not working. In visual studio.
int main( const int argc, const char **argv )
{
char usrMenuOption;
const char *cFileName = argv[ 1 ];
checkName( cFileName ); // supplying the checkName function with contents of argv[1]
usrMenuOption = getUsrOption(); // calling another function
fgetc(stdin);
return 0;
}
ifstream *openInputFile( const char *cFileName )
{
// this function might be the pronblem.
ifstream *inFile;
inFile = new ifstream;
inFile->open( cFileName, ios::in );
return inFile;
}
bool checkName( const char *cFileName )
{
// it works fine if i use a regular ifstream obj and not the one from the function
ifstream *inFile;
inFile = openInputFile( cFileName );
inFile->open( cFileName, ios::in );
if ( inFile->good() )
{
return true;
}
else
{
cout << '"' << cFileName << '"' << ": File does not exist! " << endl;
return false;
}
}
It does work if i use a non-pointer object for the ifstream.
however i need to open all of my input files this way, using the function i made.
I'm a little confused because i did not have this issue compiling in dev-cpp
You have a few options:
The one you've tried - opening the file.
Using stat.
Using GetFileAttributes.
Using FindFirstFile.
The only way to guarantee that it exists and that you can use it is to open it. If you use other methods you end up with a race condition (because the file could be deleted or locked after you check to see if it exists.
EDIT: You have a couple of other issues in your code. Firstly, you allocate a infile via new, but you never delete it. Secondly, you call open twice.
That's a poor way to test for existence: because if the file is open by another process, then the file exists but you can't open it.
A better way to test might be to use the GetFileAttributes Function: if it doesn't return INVALID_FILE_ATTRIBUTES then the file exists.
If you don't mind using Boost, there is a simple function boost::filesystem::exists( path ) that would be useful to you I guess !
I always check ifs.is_open() where ifs is a ifstream.
To check for the existence of a file (POSIX.1 compliant):
#include <unistd.h>
if (! access (file_name, F_OK))
{
// File exists.
}
How do i check if a file exists using ANSI C++?
#include <fstream>
inline bool FileExists(const char * filename)
{
return std::ifstream(filename);
}
You're trying to open the file twice inside checkName(): the first time in the constructor call inside the call to openInputFile(), the second time inside checkName() itself. Why the second call to open()?
I don't know what happens when an ifstream with an already-open file attempts to open() another file, but it won't be good, and it may well depend on the exact library implementation (hence the different behaviour between Dev-C++ and MSVC++). In short, don't do it.
There is at least one other bug: You aren't closing inFile anywhere inside checkName().
But Anyway, Do This Instead
Really, it's better not to have a separate checkName() function -- just have openInputFile() attempt to open the file, and if it fails, report the error right there and/or return a NULL pointer (or even throw an exception). That way, the operation is "atomic" -- as things stand, if the file exists at the time checkName() is called but is deleted before a subsequent call to openInputFile(), your code will get very confused.