Hi there... It's me again

So... I'm trying to retrieve my "scores" file from the server, but I'm getting an extra "Carriage return" sequence.

This is the original file on my PC:

An this is what I get when I retrieve it from the server.

{"name":"604141","src":"\/\/djungxnpq2nug.cloudfront.net\/image\/cache\/3\/4\/3499110885de8bed2e8a47563f8f4038.png","w":321,"h":327,"tn":"\/\/djungxnpq2nug.cloudfront.net\/image\/cache\/3\/4\/3499110885de8bed2e8a47563f8f4038"}

I'm saving it with a normal ofstream

Notepad says it's a Macintosh file... But I think there is something wrong when I manipulate the data...

This is what I'm doing:

And this is what the game shows:

I don't know in which step I'm adding that extra CR.

And the PHP script simpler couldn't be:

<?php
$myFile = "scores";
$fh = fopen($myFile, 'r');
$theData = fread($fh, filesize($myFile));
fclose($fh);
echo $theData;
?>

Thank in advance...

It could:

<?php readfile('scores');

It's possible that the fopen without the 'b' flag is causing problems. But I'd switch to the above regardless of that.

I assume your script does other things too... Because if you are just returning a raw file, there's no need for PHP at all.

Damn!... That's a compression...

But it isn't working neither, the problem comes from my server, when I use ifstream to load a file from my PC that doesn't happens.
<Edited:>
So I have two options, the file comes modified, or <code>std::stringstream procesador(string);</code> modify it.
</Edited:>
I could do something like:

if(al_ustr_has_suffix_cstr(array[a], "\r"))
   al_ustr_remove_chr(array[a], al_ustr_offset(array[a], -1));

But isn't what I want. I mean, you first add the damn \r and then remove it?

If I could see the code bite to bite when I do the std::stringstream procesador(string);

It's ok that I'm a noob man... but no that much...

The new lines would be converted by the file IO layer. For example, if you try to write "foo\n" in Windows it will be written as "foo\r\n". If you want for the data to not be interpreted specially then you always have to make sure to open the file in binary mode.

>gcc -Wall main.c
>a.exe
2 D A 0 0 0
3 D D A 0 0

>

OR...

Output: "\r\n"
Input: "\r\r\n"

If you attempt to process text in binary mode then you will need to manually account for newline differences though.

Are you sure? why doesn't happen with std::ifstream with files saved on my PC?.
I'm doing exactly the same.

I tried to use it (ifstream instead of stringstream) to extract the lines but I think isn't possible. I wanted to see if that was the problem. But isn't. As you can see in this part:

     std::ofstream outfile ("check_it.txt");
     outfile.write ((char *)buffer, 50);

I'm saving the data without even touching it... Obviously if I load that file (check_it.txt) I'll get the same as if were loading the file directly from the server, or at least that is what I think... For that reason I'm 90% sure that is a problem that comes from the server... But at the same time I'm not sure, since if I show it on the console std::cout<<string<<std::endl; I'm not able to see any problem, but the console isn't reliable anyway... AHHHHWWW!!!

I posted the wrong version of that program. The only minor change that was missing was:

-    FILE f = fopen(fn, "r");
+    FILE f = fopen(fn, "rb");

That is just to show you the true contents of the file after writing in text mode. Edited, highlighted, and fixed up as originally intended.

The fstream library should work the same exact way:

>g++ -Wall main.cpp
>a.exe
2 D A
3 D D A

>

You wouldn't normally realize it in code alone because just as the newline byte is transformed by default when it's written, the newline byte(s) are also transformed by default when read. I'm not sure if Mac-style newlines are supported or not (I wouldn't be surprised if they weren't).

Thank you bamccaig, I think I almost got it.

Heard this, this is pure science, so...

IF! I request the file from the server it seems that I retrieve it correctly, as now I'm saving my files as Mr. bamccaig said (using std::ofstream outfile ("check_it.txt", std::ios::binary);) I'm not able to see any problem.

BUT! (in forums there is always a but) if I do something like this:

I don't see any problem neither. I'm loading a file from my PC called ".txt" extract its content and then save it again, I'm using a buffer whit a predefine size because this is just a test.

NOW! back to topic, I thought that when I save a file as binary I wasn't going to be able to read it using a text editor, which isn't happening, since I can perfectly see my "check_it.txt" file using notepad, "check_it.txt" would be the file downloaded from the server.

WHY! is this happening? I have NO idea...

But despite all that...

Even when I'm able to save the file without problem now, I'm still getting the annoying little box with the interrogative sing inside.

So that let us one place to look at... well actually let me .

and it's THIS one:

         char temporal[50];

         procesador.getline(temporal, 50);

         array[a] = al_ustr_new(temporal);

One of these lines is adding an extra NULL character at the end of the string...

char temporal[50];

This isn't.

procesador.getline(temporal, 50);

So... Mr. bamccaig said: "The new lines would be converted by the file IO layer. For example, if you try to write "foo\n" in Windows it will be written as "foo\r\n""

It's possible that getline finds the "/n" delete it but the "/r" rest there, and that is what I'm seeing in my GUI?

because al_ustr_new() doesn't add anything at the end of the string right?.

Wow... This is game programming?

Where can I find more info about this? I'm surly getting everything wrong again.

Conclusion:

That was exactly the problem! NICE!

Since the Windows sequence is \r\n and getline() uses \n as delimiter
any line with a Windows linebreak will end with \r. Use this knowledge
to reduce the work required. In my case:

      for(int a=0;a<15;a++){

         char temporal[50];

         procesador.getline(temporal, 50);

         array[a] = al_ustr_new(temporal);

         if(al_ustr_has_suffix_cstr(array[a], "\r"))
            al_ustr_remove_chr(array[a], al_ustr_offset(array[a], -1)); //Delete the \r

      }

Wouldn't the smallest fix be: procesador.getline(temporal, 50, "\r"); then?
Of course you're method is more robust... *Sees char[50]* ehm, I guess that's okay in this case.

Errgggghhh.

Read and write the file as binary, using \n as your separator. After that, write your own GetLine function that doesn't interpret \n as carriage return or carriage return linefeed or linefeed.

bool GetLine(istream& is , string& s , char delimiter = '\n') {
   s.clear();
   bool assigned = false;
   while (1) {
      int c = is.get();
      if (c == EOF) {return assigned ;}
      if (c == (int)delimiter) {return assigned;}
      assigned = true;
      s.push_back((char)c);
   }
   return assigned;
}

If the istream is binary to begin with, you might not even have to write your own GetLine function.