Allegro.cc - Online Community

Allegro.cc Forums » Programming Questions » al_fwrite and 26.

This thread is locked; no one can reply to it. rss feed Print
al_fwrite and 26.
jason perkins
Member #10,524
January 2009

#SelectExpand
1#include "allegro5/allegro.h" 2#include <iostream> 3 4int main() 5{ 6 al_init(); 7 ALLEGRO_FILE* file; 8 9 file = al_fopen("test", "w"); 10 al_fwrite32le(file, 26); 11 al_fclose(file); 12 13 file = al_fopen("test", "r"); 14 std::cout << al_fread32le(file) << std::endl; 15 al_fclose(file); 16 17 file = al_fopen("test", "w"); 18 al_fwrite32le(file, 27); 19 al_fclose(file); 20 21 file = al_fopen("test", "r"); 22 std::cout << al_fread32le(file) << std::endl; 23 al_fclose(file); 24 system("pause"); 25 26 27 return 0; 28}

This is what I get from the console:

-1
27
Press any key to continue ...

I don't wana scream bug, but this seems kind of fishy.

Elias
Member #358
May 2000

Try using "wb" and "rb" instead of "w" and "r".

--
"Either help out or stop whining" - Evert

LennyLen
Member #5,313
December 2004
avatar

Elias said:

Try using "wb" and "rb" instead of "w" and "r".

I tested it and yes, that was the problem.

Elias
Member #358
May 2000

I wonder if Allegro should do that for you. I'm never using Windows but still always use "wb" and "rb" since I know that Windows will possibly garble every byte <= ascii 32 otherwise. But for the Allegro file operations we could just specify that they are always in binary mode and fix the windows drivers accordingly. I can't see any problems with that, unless someone knows of an actual use for the standard libc behavior with "w" and "r".

--
"Either help out or stop whining" - Evert

jason perkins
Member #10,524
January 2009

Thanks alot, You wouldn't believe how long I've spent trying to figure out my problem.

LennyLen
Member #5,313
December 2004
avatar

Quote:

But for the Allegro file operations we could just specify that they are always in binary mode and fix the windows drivers accordingly. I can't see any problems with that, unless someone knows of an actual use for the standard libc behavior with "w" and "r".

That would also keep things the same as the File I/O routines in A4, which also doesn't differentiate between text and binary mode.

Audric
Member #907
January 2001

As far as I understand it, it's standard C behaviour : A portable piece of code that writes "ABC\nDEF" as a text file should read back "ABC\nDEF".

(This is an answer to "an actual use for the standard libc behavior with "w" and "r".")

Elias
Member #358
May 2000

Audric said:

As far as I understand it, it's standard C behaviour : A portable piece of code that writes "ABC\nDEF" as a text file should read back "ABC\nDEF".

Unfortunately not. Only if you use "rb" and "wb" in fopen. [edit:] Otherwise it only applies for ASCII files and if you don't care that line endings get mangled on disk.

--
"Either help out or stop whining" - Evert

Audric
Member #907
January 2001

My meaning was for portable C code that reads and writes in text file: The code opens the file in TEXT mode, fwrite() the single '\n' character, and the libc implementation will do whatever is required to produce a Newline character on the platform. Similarly, open back the file in TEXT mode, fread(), and you should get the single '\n' character.
This is straight-from-the-book implementation of the C standard... And it means the same piece of source code will produce similar-behaving programs on platforms that handle text files differently at the byte level.

Elias
Member #358
May 2000

Audric said:

and the libc implementation will do whatever is required to produce a Newline character on the platform

Yes. And Allegro 5 works like that as well now. I think it would be better if it didn't.

--
"Either help out or stop whining" - Evert

Audric
Member #907
January 2001

For future reference, I just remembered: character 26 is ctrl-z, so it marks end-of-file. When you read a file in text mode, encountering this character should stop the reading as if the physical end-of-file was reached, it explains the "-1" returned by al_fread32le().

I remember some file formats used this trick, they started by a human-readable string,then ctrl-z, then the binary data started. Opening such file in a basic text editor should only show the string - though nowadays many programmer's editors can show the hidden content.

Go to: