title: File pointers after returning from a forked child process
body: <p>Is it normal, for a given file descriptor shared between a forked parent and child process, that the file position in the parent process remains the same after a child process reads from the same file descriptor?</p>
  
  <p>This is happening for me.  Here's the setup:</p>
  
  <p>I am writing a C++ CGI program, so it reads http requests from stdin.  When processing a multipart_form, I process stdin with an intermediary object (Multipart_Pull) that has a getc() method that detects the boundary strings and returns EOF at the end of a each field, so I can pretend a field's contents are a file.  When the field is a file upload, I fork twice in order to pipe the results of Multipart_Pull::getc to the stdin of a child process that runs <code>ssconvert</code> to make a CSV file from an Excel file for further processing.  I wrote the child process to leave the file pointer at the position where the parent could pick it up.  The parent process uses wait() to ensure the child processes are done before continuing.</p>
  
  <p>For testing while developing Multipart_Pull, I am faking stdin by opening a disk file that was copied from a real multipart_form request.</p>
  
  <p>When faking stdin, and after the child process returns, the first character read in the parent process is the same first character that the child process read when it started.  That is, the file pointer didn't move in the parent's copy of the file.</p>
  
  <p>I have confirmed that the child process actually reads the data by running gdb and following the appropriate child process by using <code>set follow-fork-mode child</code>, and also confirmed the file position of the parent on return by comparing the characters read against the file from which the data is read.</p>
  
  <p>When I am really reading from stdin, I don't expect that this will be a problem because (correct me if I'm wrong here), when you read a character from stdin, it's gone forever.</p>
  
  <p>I realize that there are workarounds to solve this particular problem, the easiest being to just ignore any fields that follow a file upload on a multipart_form, i.e. the parent doesn't try to continue reading after the fork.  However, I hate to cripple the production code or make unnecessary restrictions, and mainly because I really just want to understand what's happening.</p>
  
  <p>Thanks in advance.</p>