Tom,
Thanks for your help, I really appreciate it! I'm kinda new to fread (I grew up in the land of Java, so I haven't had to get this close to memory since my assembler class back in college!), so I'm not sure what you mean by a partial buffer load? Since the first read is only for data up to the size of the initial allocation (because offset is zero the first time through), I don't think I could be going out into un-allocated memory. And in the case that fread() pulls in less data than requested, that means the next call to fread() should return zero, right? I've been working off
the GNU manual, but seeing how things can be different depending on the OS vendor, maybe I'm making an assumption that I shouldn't be making? Again, when I print out the contents of the buffer I get good data for large and small sets. I'm going to try pumping it into hexdump and see if I can identify the offending character sequence.
Billy
On 3/29/07, Tom Lane <tgl@sss.pgh.pa.us> wrote: "Billy Gray" <billy.zophar@gmail.com> writes:
> char *buffer = (char *) xmalloc (STDIN_BLOCK); //xmalloc is really
> malloc
> int offset = 0;
> int read = 1;
> int size = STDIN_BLOCK;
> while ( (read > 0) && (offset <= STDIN_MAX) )
> {
> syslog (LOG_DEBUG, "Reading a block...");
> read = fread (buffer + offset, 1, STDIN_BLOCK, stdin);
> offset += read;
> if (read == STDIN_BLOCK)
> {
> size += STDIN_BLOCK;
> buffer = xrealloc (buffer, size);
> }
> } // while
This looks to me like it risks telling fread to read more bytes than
will actually fit in the buffer at the moment. Think about what happens
if fread returns only a partial bufferload on any particular call.
I'm guessing you're clobbering memory ...
regards, tom lane
