Please post a small sample of your input file. And show how you are calling this program.
Jim
Please post a small sample of your input file. And show how you are calling this program.
Jim
Hi Jim,
The first line of the output is actually how the program was launched, i.e. "... ./ex17 alloctest4 c". There is no input file as such, it is created by Database_open (or opened if the flag isn't "c" i.e. the file alread exists). The file is then populated by Database_write, which is where the program seems to be choking.
Alex
When you allocate space for C strings (name and email); I fail to see where you set the c-string to a valid ASCII nul terminated string. This would likely cause the write to fail.
I suggest adding this line below the above line and likewise for email.Code:conn->db->rows[i].name = malloc(sizeof(char)*stringsize);
Tim S.Code:conn->db->rows[i].name[0] = '\0';
Last edited by stahta01; 04-03-2013 at 01:29 PM.
"...a computer is a stupid machine with the ability to do incredibly smart things, while computer programmers are smart people with the ability to do incredibly stupid things. They are,in short, a perfect match.." Bill Bryson
Good point, I made the modification but it hasn't fixed the problem. The output is exactly as before. Same error, same mem location.
Ahhhhh, I think I've cracked it. I was using sizeof(char*) instead of sizeof(char). Using sizeof(char) returns no errors except for that very last one about unintialised bytes, which I think is unrelated to my primary concern, and may be because I haven't initialised the other parts of the name/email strings, only the first byte.
FYI: You do realize that writing pointer to memory out to a physical file does not work?
Tim S.
"...a computer is a stupid machine with the ability to do incredibly smart things, while computer programmers are smart people with the ability to do incredibly stupid things. They are,in short, a perfect match.." Bill Bryson
Can you elaborate on what you mean? If you've followed this thread (I don't expect you to have, it's long and there's a lot of tangential debate). You'll know that this task I've set myself is a modification of a Learning C the Hard Way exercise (linked in the OP). This task worked exactly as advertised, and it used a write based on a pointer. Specifically, the Database struct was preallocated (all array sizes were defined), and the write was performed as follows:
This worked perfectly. So I don't understand what you mean?Code:int rc = fwrite(conn->db, sizeof(struct Database), 1, conn->file);
When you read a pointer to memory back in from the file; there will be no reason to assume the saved pointer points to memory you now own in a real system.
It might work some of the time, but, it is not something that ever should be done in a real world programming project.
To sum it up; poor practice makes a poor programmer.
Tim S.
"...a computer is a stupid machine with the ability to do incredibly smart things, while computer programmers are smart people with the ability to do incredibly stupid things. They are,in short, a perfect match.." Bill Bryson
What you say makes sense, but fwrite doesn't actually write the pointer out. From the linux man pages:
As I understand it, those function are writing a block of memory of a certain size to file, which is pointed to by the pointer. In case you missed my post above, I realised that I had incorrectly formatted the size of the write and have since adjusted it, it seems to working alright.DESCRIPTION The function fread() reads nmemb elements of data, each size bytes
long, from the stream pointed to by stream, storing them at the loca‐
tion given by ptr.
The function fwrite() writes nmemb elements of data, each size bytes
long, to the stream pointed to by stream, obtaining them from the loca‐
tion given by ptr.
You have a pointer in your structure that you are trying to write with fwrite(), fwrite() will write this pointer, not the information the pointer is pointing to, to your file. You need to write the actual information the pointer it pointing to, not the pointer.
Right now when you write your Connection structure to your file you will write two pointers. One a pointer to a FILE structure and one pointer to a Database structure, nothing else will be saved to your file.
Jim
Last edited by jimblumberg; 04-03-2013 at 02:38 PM.
Ahhhhhhhhhhh, light bulb!
I had wondered about that, do you have any suggestions for how I should approach the problem then? Re-link the pointers after reading in raw data? Avoid writing the pointer members at all? Maybe only write the row information, as it's the only info I'm interested in anyway?
Not possible. If you write you file during one run of your program, end the program and then restart the program again, the pointers in your file are meaningless you probably were assigned a different block of memory by your operating system so those pointers won't point to valid data.Re-link the pointers after reading in raw data?
Bingo, write the data not the pointers.Avoid writing the pointer members at all?
But don't forget you have pointers in your row information as well.Maybe only write the row information, as it's the only info I'm interested in anyway?
If those variables were statically allocated you would probably be okay.Code:struct Address { int id; int set; char *name; char *email; };
Is there a particular reason you are trying to use binary files for this?
Jim
Nope, purely unfamiliarity with best practices. I just took a stab using the initial program as a base (which did have statically allocated arrays). The problem is simplified if I remove the constraint that the database entry ID's be consistent from one load to the next. Then I can just write the strings, and then reinit the other data members when I reload, but that feels like cheating.
Taking my thoughts on this a little further, I don't know why I didn't see that I could just store the information as text strings and then parse them for the ID information as I reload them.Originally Posted by AAnderson
Anyway, I'd just like to thank everyone for stepping in and helping me across what turned out to be very shallow (but scary looking) waters. I'm sure I'll be back with more questions but hopefully something a little more interesting!
