Allegro.cc - Online Community

Allegro.cc Forums » Programming Questions » al_save_config_file() ignores Windows-style newline convetions?

This thread is locked; no one can reply to it. rss feed Print
al_save_config_file() ignores Windows-style newline convetions?
Tumlee
Member #15,061
April 2013

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
Member #8,592
May 2007
avatar

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
Second in Command
February 2005
avatar

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

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

“Throughout history, poverty is the normal condition of man. Advances which permit this norm to be exceeded — here and there, now and then — are the work of an extremely small minority, frequently despised, often condemned, and almost always opposed by all right-thinking people. Whenever this tiny minority is kept from creating, or (as sometimes happens) is driven out of a society, the people then slip back into abject poverty. This is known as "bad luck.”

― Robert A. Heinlein

Edgar Reynaldo
Member #8,592
May 2007
avatar

Arthur Kalliokoski
Second in Command
February 2005
avatar

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

“Throughout history, poverty is the normal condition of man. Advances which permit this norm to be exceeded — here and there, now and then — are the work of an extremely small minority, frequently despised, often condemned, and almost always opposed by all right-thinking people. Whenever this tiny minority is kept from creating, or (as sometimes happens) is driven out of a society, the people then slip back into abject poverty. This is known as "bad luck.”

― Robert A. Heinlein

Edgar Reynaldo
Member #8,592
May 2007
avatar

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
Second in Command
February 2005
avatar

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.

“Throughout history, poverty is the normal condition of man. Advances which permit this norm to be exceeded — here and there, now and then — are the work of an extremely small minority, frequently despised, often condemned, and almost always opposed by all right-thinking people. Whenever this tiny minority is kept from creating, or (as sometimes happens) is driven out of a society, the people then slip back into abject poverty. This is known as "bad luck.”

― Robert A. Heinlein

Edgar Reynaldo
Member #8,592
May 2007
avatar

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
Member #2,727
September 2002
avatar

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

Arthur Kalliokoski
Second in Command
February 2005
avatar

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.

“Throughout history, poverty is the normal condition of man. Advances which permit this norm to be exceeded — here and there, now and then — are the work of an extremely small minority, frequently despised, often condemned, and almost always opposed by all right-thinking people. Whenever this tiny minority is kept from creating, or (as sometimes happens) is driven out of a society, the people then slip back into abject poverty. This is known as "bad luck.”

― Robert A. Heinlein

Edgar Reynaldo
Member #8,592
May 2007
avatar

taron 
Member #10,584
January 2009
avatar

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

Peter Wang
Member #23
April 2000

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
Member #8,592
May 2007
avatar

Tumlee
Member #15,061
April 2013

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
Member #7,827
October 2006
avatar

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?

"For in much wisdom is much grief: and he that increases knowledge increases sorrow."-Ecclesiastes 1:18
[SiegeLord's Abode][Codes]:[DAllegro5]:[RustAllegro]

Tumlee
Member #15,061
April 2013

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
Member #358
May 2000

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

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

Audric
Member #907
January 2001

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
Member #7,827
October 2006
avatar

Audric said:

if al_fopen() relayed it to the underlying libc

al_fopen() relays it to PhysFS in this case.

"For in much wisdom is much grief: and he that increases knowledge increases sorrow."-Ecclesiastes 1:18
[SiegeLord's Abode][Codes]:[DAllegro5]:[RustAllegro]

Go to: