Note that there are some explanatory texts on larger screens.

plurals
  1. POstdout redirect changing output
    primarykey
    data
    text
    <p>I have a program called <code>abc</code>.</p> <p>When I run the following command:</p> <pre><code>$ ./abc &lt; infile </code></pre> <p>I get the following output:</p> <pre><code>ijklm </code></pre> <p>However, when I run:</p> <pre><code>$ ./abc &lt; infile &gt; outfile $ cat outfile </code></pre> <p>I am given this output:</p> <pre><code>ijkoo </code></pre> <p>Now, I'm assuming this is a bug with my program. However, regardless of what my program is doing, I do not know how this is possible.</p> <p><strong>EDIT:</strong></p> <p>Now that I know it is possible, I'm curious as to what it is in my program that is causing this.</p> <p>There is a block inside a loop in my program that contains:</p> <pre><code>byte = ascii_to_byte(asciibyte); putchar(byte); </code></pre> <p>byte is of type <code>char</code>.</p> <p>Now if I change <code>putchar(byte)</code> to <code>printf("%c", byte)</code> all the output stays the same.</p> <p>However, if I change it to <code>printf("%d", byte)</code>, then <code>$ ./abc &lt; infile</code> outputs:</p> <pre><code>105106107111111 </code></pre> <p>Which is the decimal representation of those ascii characters as they were in <code>outfile</code>. But it's not the decimal representation of the characters as they actually appeared when they just got sent to stdout. I don't understand why there could be this difference.</p> <p><strong>EDIT #2:</strong></p> <p>If I change the printing line to <code>printf("%c\n", byte)</code>, then <code>$ ./abc &lt; infile</code> outputs:</p> <pre><code>i j k o o </code></pre> <p>This is consistent with what goes into outfile. Again, not sure what the difference is.</p> <p><strong>EDIT #3</strong></p> <p>I just tested this on a 32 bit machine, and the program works: <code>outputfile</code> contains <code>ijklm</code>. Wierd.</p> <p><strong>EDIT #4</strong></p> <p>Here is the main function:</p> <pre><code>int main() { char asciibyte[8]; char byte; int c; //Using int to avoid the EOF pitfall. long charcount = 0; while((c = getchar()) != EOF){ if(c != '0' &amp;&amp; c != '1'){ continue; } asciibyte[charcount % 8] = c; if(charcount % 8 == 7){ /*Testing revealed that at this point asciibyte does contain what it should contain, eight ASCII ones and zeros representing a byte read in from stdin*/ byte = ascii_to_byte(asciibyte); /*Print statements such as: printf("%d", byte); printf("%c\n", byte); reveal that the ascii_to_byte function works incorrectly on my 64 bit machine. However these statements: putchar(byte); printf("%c", byte); make it appear as though the function operates as it should. EXCEPT if i redirect that output to a file.*/ putchar(byte); } charcount++; } return 0; } </code></pre> <p>And here is the ascii_to_byte function:</p> <pre><code>char ascii_to_byte(char *asciibyte){ char byte; int i; for(i = 0; i &lt; 8; ++i){ if(asciibyte[7-i] == '1'){ byte = byte | (1 &lt;&lt; i); } } return byte; } </code></pre> <p><strong>FINAL EDIT</strong></p> <p>I noticed that I should have initialized byte to 0x00. Problem solved. Why am I this retarded? I'll give answer points to whoever can explain specifically how this caused the problem.</p>
    singulars
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    plurals
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    1. This table or related slice is empty.
 

Querying!

 
Guidance

SQuiL has stopped working due to an internal error.

If you are curious you may find further information in the browser console, which is accessible through the devtools (F12).

Reload