al_save_config_file() ignores Windows-style newline convetions?
Tumlee

I'm working on a game where the game's settings in an INI file via a call to al_save_config_file(). Under Linux, where I do most of development, this works flawlessly. When I compile the game under Windows, the resulting INI file is all on one line, which is highly indicative of saving under binary mode rather than text mode (Many Windows programs require a CR+LF to register a newline).

Is there some sort of parameter that I'm missing, or is this an oversight?

Edgar Reynaldo

It's not binary, it's just missing the CR\LF pair, using LF only (Linux style). You just need a better editor to interpret the LF's properly. Code Blocks works, and Notepad++ too.

I should say, that it may write different config files on different platforms, using the native path separators when saving. Or maybe it only saves in LF form, IDK.

Arthur Kalliokoski

It's not binary, it's just missing the CR\LF pair, using LF only (Linux style).

Actually it is, remember fopen(filename,"wb"); ?

Edgar Reynaldo

You're using al_save_config_file, right? I don't think that would save in binary, because then you couldn't hand edit it (easily).

Arthur Kalliokoski

Leaving out the \r is binary! Well, so is the other way, it's bits.

Edgar Reynaldo
Tumlee said:

When I compile the game under Windows, the resulting INI file is all on one line

Indicating the file on Linux shows multiple lines, using LF. It could be in binary, but then you couldn't read the text! So I'm assuming it is not binary. See my reasoning?

Arthur Kalliokoski

The "binary" comes from Windows C compilers mangling files opened as text that can contain all values ("binary" files). The text is binary either way, look at it with a hex editor, see the bits?

http://www.delorie.com/djgpp/doc/libc/libc_337.html

[EDIT2]

"Text" is simply that range of binary values that our editors have been programmed to map to alphanumeric chars on the screen.

Edgar Reynaldo

I'm confused. How do you know allegro is opening the file in binary mode? Wouldn't that defeat the purpose of an easily configurable config file?

Oh, and yeah, you're right the text is binary. But the rest of the file would be filled with 'garbage'.

torhu

"Binary" in this context just refers to the line ending convention, not how numbers are represented or anything else.

Arthur Kalliokoski

Edgar, you have debug.com somewhere on your disk, right? Try this:

debug.com edgar.txt
-e 100
 48 65 6c 6c 6f 2c 20 45  64 67 61 72 21 0a
ebx 10e
w
q
type edgar.txt

If that doesn't work, it's because my 10+ year old memory of debug.com is rusty.

Edgar Reynaldo

you have debug.com somewhere on your disk, right?

Not here at school. I'm in class. Is it a DOS program?

taronĀ 

debug.com only works on 32 bit versions of windows.

Peter Wang

It should work (and works here with MinGW and Wine). al_save_config_file calls al_fopen with "w" (not "wb") which is passed through to _wfopen (unless you have overridden it). The C library should then translate \n to CRLF.

Edgar Reynaldo

But if you save on Linux and try to open on Windows you'll have a problem? Is that what you're saying?

Tumlee

But if you save on Linux and try to open on Windows you'll have a problem? Is that you're saying?

Nope. The file is being created from scratch under Windows.

I did some further testing and it appears that when I force the configuration file to be saved before physfs has been initialized, the file saves correctly and displays normally under Notepad. Could the problem be physfs?

SiegeLord
Tumlee said:

Could the problem be physfs?

All files are opened in binary mode; there is no endline conversion for textfiles.

Looks like it. I don't think this problem can be fixed in an efficient manner, so perhaps there should be a stern warning about this in the documentation?

Tumlee

Yuck. So I take it that the only way to circumvent this is to call al_set_standard_file_interface(), then save the file, and then call al_set_physfs_file_interface() again to turn it back on?

Elias
SiegeLord said:

so perhaps there should be a stern warning about this in the documentation

The warning should be about files written in Windows sometimes containing extra random 0x13 bytes. That cost me quite a few wasted hours at work, some parser would add the 0x13 byte to every value that happened to come last in a line :P

I think physfs actually made the most sane choice there and I'd wish Allegro would never write those extra bytes :P

Audric

Assuming it's about the Mingw-gcc port (instead of, say, the Visual Studio one), physfs must be setting one of the flags that alters the behavior of all future fopen() calls.
The following page lists several ways to do it:
http://oldwiki.mingw.org/index.php/binary

Now, if al_save_config_file() would call al_fopen() with an explicit "t" mode, and if al_fopen() relayed it to the underlying libc, I think it would work even if a lib (or user code) plays with these settings.

SiegeLord
Audric said:

if al_fopen() relayed it to the underlying libc

al_fopen() relays it to PhysFS in this case.

Thread #613353. Printed from Allegro.cc