Loading ...
Sorry, an error occurred while loading the content.

Output to stdout should always be binary on Win32

Expand Messages
  • vfun_00
    Currently, ploticus only sets stdout to binary if running in direct CGI mode - from pl.c: // [snip] if( PLS.cgiargs != NULL ) { /* begin parsing QUERY_STRING..
    Message 1 of 4 , Dec 21, 2004
    • 0 Attachment
      Currently, ploticus only sets stdout to binary if running in direct
      CGI mode - from pl.c:

      // [snip]
      if( PLS.cgiargs != NULL ) {
      /* begin parsing QUERY_STRING.. */
      stoparg = 80;
      ci = 0;

      strcpy( PLS.outfile, "stdout" );
      #ifdef WIN32
      /* must set stdin and stdout to binary mode */
      _setmode( _fileno( stdin ), _O_BINARY );
      _setmode( _fileno( stdout ), _O_BINARY );
      #endif /* WIN32 */
      // [endsnip]

      The code shouldn't assume that this only needs to be done when
      invoked as a CGI program; I use stdout to output the resulting image,
      then pipe out to file afterwards. That's when the downloaded Win32
      binary causes newline conversion to occur, which confirms the problem.

      The proposed fix is to either move the #ifdef block out of the above
      conditional, or to add it to grgd.c as follows:

      // [snip]
      /* Open a file for writing. "wb" means "write binary", important
      under MSDOS, harmless under Unix. */
      if( stricmp( filename, "stdout" )==0 ) outfp = stdout;
      else outfp = fopen( filename, "wb");

      #ifdef WIN32
      _setmode( _fileno( stdout ), _O_BINARY );
      #endif /* WIN32 */
      // [endsnip]

      Logically, either approach should work, but I haven't tested them
      since I used Cygwin to build (and run) the original source, which
      (just like Unix) doesn't distinguish between text and binary files.
    • Bjoern Hoehrmann
      ... But the code should not assume that disabling end of line translation is acceptable for (US-ASCII compatible) text output (e.g. ISO-8859-1 SVGs), either.
      Message 2 of 4 , Dec 21, 2004
      • 0 Attachment
        * vfun_00 wrote:
        >The code shouldn't assume that this only needs to be done when
        >invoked as a CGI program; I use stdout to output the resulting image,
        >then pipe out to file afterwards. That's when the downloaded Win32
        >binary causes newline conversion to occur, which confirms the problem.

        But the code should not assume that disabling end of line translation is
        acceptable for (US-ASCII compatible) text output (e.g. ISO-8859-1 SVGs),
        either. If the output is always binary, text output would need to use CR
        LF rather than just "\n" for the end of a line.
        --
        Björn Höhrmann · mailto:bjoern@... · http://bjoern.hoehrmann.de
        Weinh. Str. 22 · Telefon: +49(0)621/4309674 · http://www.bjoernsworld.de
        68309 Mannheim · PGP Pub. KeyID: 0xA4357E78 · http://www.websitedev.de/
      • vfun_00
        ... translation is ... SVGs), ... use CR ... I concur that the fix should be more isolated - if you follow the second approach (modifying grgd.c), this
        Message 3 of 4 , Dec 21, 2004
        • 0 Attachment
          --- In ploticus@yahoogroups.com, Bjoern Hoehrmann <derhoermi@g...>
          wrote:

          > But the code should not assume that disabling end of line
          translation is
          > acceptable for (US-ASCII compatible) text output (e.g. ISO-8859-1
          SVGs),
          > either. If the output is always binary, text output would need to
          use CR
          > LF rather than just "\n" for the end of a line.

          I concur that the fix should be more isolated - if you follow the
          second approach (modifying grgd.c), this inconsistency will not occur
          because the file only seems to contain GD-related graphics code (PNG,
          JPEG, GIF etc - no text output). I think adding another #ifdef
          directive to that file just after "if( stricmp filename, "stdout" )!
          =0 ) {...}" conditional should restore the text mode to stdout (this
          is after the image is written out), which will completely localize
          this change:

          #ifdef WIN32
          else _setmode( _fileno( stdout ), _O_TEXT );
          #endif /* WIN32 */
        • Bjoern Hoehrmann
          ... Be sure to flush the file handle before you do that, otherwise buffered data would be (at least with MSVC++) processed using the new mode which would
          Message 4 of 4 , Dec 21, 2004
          • 0 Attachment
            * vfun_00 wrote:
            >I concur that the fix should be more isolated - if you follow the
            >second approach (modifying grgd.c), this inconsistency will not occur
            >because the file only seems to contain GD-related graphics code (PNG,
            >JPEG, GIF etc - no text output). I think adding another #ifdef
            >directive to that file just after "if( stricmp filename, "stdout" )!
            >=0 ) {...}" conditional should restore the text mode to stdout (this
            >is after the image is written out), which will completely localize
            >this change:
            >
            >#ifdef WIN32
            > else _setmode( _fileno( stdout ), _O_TEXT );
            >#endif /* WIN32 */

            Be sure to flush the file handle before you do that, otherwise buffered
            data would be (at least with MSVC++) processed using the new mode which
            would potentially corrupt the binary data. Calling fflush(stdout) should
            avoid that.
            --
            Björn Höhrmann · mailto:bjoern@... · http://bjoern.hoehrmann.de
            Weinh. Str. 22 · Telefon: +49(0)621/4309674 · http://www.bjoernsworld.de
            68309 Mannheim · PGP Pub. KeyID: 0xA4357E78 · http://www.websitedev.de/
          Your message has been successfully submitted and would be delivered to recipients shortly.