octave-bug-tracker
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Octave-bug-tracker] [bug #44186] print command gives incorrect postscri


From: Dan Sebald
Subject: [Octave-bug-tracker] [bug #44186] print command gives incorrect postscript file
Date: Sun, 15 Feb 2015 09:36:10 +0000
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:18.0) Gecko/20100101 Firefox/18.0 SeaMonkey/2.15

Follow-up Comment #34, bug #44186 (project octave):

OK, let me retract my statement about binary write (read) being a red herring,
step back and say not sure, could be.  :-)

If one looks at the garbage data, if it were the case that gp_ftell_64()
(i.e., ultimately ftell) were to indicate a file size larger than the actual
size (or the correct size but data is decoded when processed), there could be
a last pass of this loop:


    while (left > 0) {
        uint copy = min(left, sbuf_size);

        r = fread(buf, 1, copy, file);
        if (r < 1) {
            gs_note_error(gs_error_ioerror);
            return;
        }
        if (ss)
            s_arcfour_process_buffer(ss, buf, copy);
        stream_write(s, buf, copy);
        left -= copy;
    }


which grabs garbage data.  An fread() is used, and if that file pointer is
associated with a non-binary file, ftell may not match the length of the file
if, say, <CR> are tossed in decoding.

I've tried to follow backward through the ghostscript code where the open() is
for "gx_device * dev", but because of the use of function pointers in a
structure it's difficult to search.

Here is one routine I notice (if ultimately it is used, I'm not sure):


/*
 * Open a temporary file, using O_EXCL and S_I*USR to prevent race
 * conditions and symlink attacks.
 */
static FILE *
gp_fopentemp_generic(const char *fname, const char *mode, bool b64)
{
    int flags = O_EXCL;
    /* Scan the mode to construct the flags. */
    const char *p = mode;
    int fildes;
    FILE *file;

#if defined (O_LARGEFILE)
    /* It works for Linux/gcc. */
    if (b64)
        flags |= O_LARGEFILE;
#else
    /* fixme : Not sure what to do. Unimplemented. */
    /* MSVC has no O_LARGEFILE, but MSVC build never calls this function. */
#endif
    while (*p)
        switch (*p++) {
        case 'a':
            flags |= O_CREAT | O_APPEND;
            break;
        case 'r':
            flags |= O_RDONLY;
            break;
        case 'w':
            flags |= O_CREAT | O_WRONLY | O_TRUNC;
            break;
#ifdef O_BINARY
            /* Watcom C insists on this non-ANSI flag being set. */
        case 'b':
            flags |= O_BINARY;
            break;
#endif
        case '+':
            flags = (flags & ~(O_RDONLY | O_WRONLY)) | O_RDWR;
            break;
        default:                /* e.g., 'b' */
            break;
        }
    fildes = open(fname, flags, S_IRUSR | S_IWUSR);
    if (fildes < 0)
        return 0;
    /*
     * The DEC VMS C compiler incorrectly defines the second argument of
     * fdopen as (char *), rather than following the POSIX.1 standard,
     * which defines it as (const char *).  Patch this here.
     */
    file = fdopen(fildes, (char *)mode); /* still really const */
    if (file == 0)
        close(fildes);
    return file;
}


I see in my configuration file


 UFST_CFLAGS="-DGCCx86_64 -DO_BINARY=0 -Dstrcmpi=strcasecmp"


Does -DO_BINARY=0 appear in the MXE build configuration?


    _______________________________________________________

Reply to this item at:

  <http://savannah.gnu.org/bugs/?44186>

_______________________________________________
  Message sent via/by Savannah
  http://savannah.gnu.org/




reply via email to

[Prev in Thread] Current Thread [Next in Thread]