al_fwrite and 26.

jason perkins

#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

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

LennyLen

Elias said:

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

I tested it and yes, that was the problem.

Elias

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".

jason perkins

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

LennyLen

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

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

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.

Audric

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

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.

Audric

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.

Thread #606718. Printed from Allegro.cc