Re: Some encoding trouble via libpq

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<http://www.gnu.org/software/libc/manual/html_node/Block-Input_002fOutput.html#Block-Input_002fOutput>,
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(at)sss(dot)pgh(dot)pa(dot)us> wrote:
>
> "Billy Gray" <billy(dot)zophar(at)gmail(dot)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
>