Register | Login | |||||
Main
| Memberlist
| Active users
| Calendar
| Chat
| Online users Ranks | FAQ | ACS | Stats | Color Chart | Search | Photo album |
| |
0 users currently in Programming. |
Acmlm's Board - I3 Archive - Programming - Memory Buffer/Array Overlays | New poll | | |
Add to favorites | Next newer thread | Next older thread |
User | Post | ||
Guy Perfect Since: 11-18-05 Last post: 6285 days Last view: 6284 days |
| ||
This is nothing special at all, but as a BASIC veteran, I appreciate how flexible C can be when dealing with memory and arrays.
What this program does is allocate a set number of bytes in memory, declares an array and refers it to somewhere inside the allocated memory, modifies some values in the array, then writes the block of memory to a file. Again, stupid simple, but having worked with BASIC for most of my programming life, I find this kind of thing very entertaining. #include <stdio.h> // Needed for FILE, fopen, etc. |
|||
Cellar Dweller + Red Koopa Since: 11-18-05 From: Arkansas Last post: 6293 days Last view: 6283 days |
| ||
Using structs to read or write file or network data is risky. The endianess, padding, size, and perhaps even order of structure members can vary depending on the CPU architecture, compiler, and compiler options. Even reading or writing file data directly into individual variables or casting a pointer from inside a file buffer to another data type is unsafe due to endianess, alighnment, and type size issues.
The safest practical method for handling file data is to use the types from stdint.h and shift individual bytes to or from the file out of or in to the correct position in your program's variables. For example, this a inline function I wrote to read 64 bit big endian integers from a file buffer : static inline uint64_t rbeu64(char *p)If I needed to read a little endian integer, I'd use the same technique. |
|||
Jagori 150 Since: 11-17-05 Last post: 6284 days Last view: 6284 days |
| ||
I've gotten so used to the freedom that C gives with memory that I often have to rethink how I do things when I'm working in a language that doesn't work that way. It can make for some pretty dirty hacks that actually work, but of course you need to be very careful with that.
It just sucks when you do it by accident. Like array++ instead of array[0]++, or stuff like that. I once misused realloc() and ended up with my program trying to use one array squarely inside the memory space of another array, and the only symptom was some weird results of simple operations. Still, I'd rather have to deal with that kind of thing than not have the freedom to do it. |
|||
Guy Perfect Since: 11-18-05 Last post: 6285 days Last view: 6284 days |
| ||
That's very informative, Cellar Dweller, but the purpose of that snippit is to demonstrate various ways of working with a block of memory, not working with file data. | |||
HyperHacker Star Mario Finally being paid to code in VB! If only I still enjoyed that. <_< Wii #7182 6487 4198 1828 Since: 11-18-05 From: Canada, w00t! My computer's specs, if anyone gives a damn. STOP TRUNCATING THIS >8^( Last post: 6284 days Last view: 6284 days |
| ||
Originally posted by Jagori Yes, memory corruption - particularly from misuse of arrays (treating an array of pointers to objects as an array of objects is a fun one) - is annoying because the symptoms tend to be completely bizarre. I find generally the program will just crash at random in some completely unrelated routine. For example fclose()ing an already-closed file is supposed to be safe, but it was crashing because of some place where I'd written an array wrong that had nothing to do with files. |
|||
Cellar Dweller + Red Koopa Since: 11-18-05 From: Arkansas Last post: 6293 days Last view: 6283 days |
| ||
The reason I brought up the file stuff is because structure overlays are a popular but often unwise technique for handling data that originated from or is destined to somewhere outside the program. Also, the example program did write to a file.
I wouldn't think a double fclose() to be safe. The fact that file streams are pointers suggests that they point to data on the heap. The first fclose() free()s the FILE structure, and if an attempt is made to call fclose() again, the program would probably segfault or cause a double free(), which would probably cause a segfault later. Not too long ago, a program I was working on had a wierd segfault bug that was driving me nuts. By using Electric Fence I found out I had a double free() in it. |
|||
HyperHacker Star Mario Finally being paid to code in VB! If only I still enjoyed that. <_< Wii #7182 6487 4198 1828 Since: 11-18-05 From: Canada, w00t! My computer's specs, if anyone gives a damn. STOP TRUNCATING THIS >8^( Last post: 6284 days Last view: 6284 days |
| ||
It might be fclose()ing a NULL pointer I was thinking of, but either way, something that should be safe was instead going boom. I know double free() is a bad thing in any case. |
Add to favorites | Next newer thread | Next older thread |
Acmlm's Board - I3 Archive - Programming - Memory Buffer/Array Overlays | | |