Re: File output truncated

Discussion in 'C Programming' started by Default User, May 29, 2010.

  1. Default User

    Default User Guest

    Here's the message again without attachment. Sorry for the mess. Some
    days you should stay in bed.

    ========= original message follows =========

    Perhaps someone can spot what I'm doing wrong here. I have a function
    that reads in line-oriented text (socket stuff OT, but I believe
    that's irrelevant). It can send the extracted lines to the console or
    to a file as desired. When output to the console, it works normally,
    getting several thousand lines from the remote system and ending with
    the proper termination line. When sent to a file, it stops after a few
    hundred lines.

    #define BUFFERSIZE 1024

    void extract_lines(SOCKET socket, const char *cmd, char *filename)
    {
    int done = 0;
    char buffer[BUFFERSIZE];
    char linebuf[BUFFERSIZE];
    int res;
    int bufpos = 0;
    int linepos = 0;
    int lc = 0;
    FILE *out;
    int mode = 0;

    /* see whether it should output to console or a file */
    if (strcmp(filename, "stdout") == 0)
    {
    mode = 1;
    out = stdout;
    }
    else
    {
    out = fopen(filename, "w");
    if (out == 0)
    {
    fprintf(stderr, "Failed to open: %s", filename);
    return;
    }
    }
    res = send(socket, cmd, strlen(cmd), 0);
    while (!done)
    {
    res = recv(socket, buffer, sizeof buffer, 0);
    if (res <= 0)
    done = 1;
    else
    {
    if (res < sizeof buffer)
    done = 1;
    for (bufpos = 0; bufpos < res; bufpos++)
    {
    if (buffer[bufpos] == '\r')
    continue; /* just skip that */
    else if (buffer[bufpos] == '\n')
    {
    linebuf[linepos] = 0;
    fputs(linebuf, out);
    fputs("\n", out);
    linepos = 0;
    lc++;
    }
    else
    {
    linebuf[linepos++] = buffer[bufpos];
    }
    }
    }
    }
    printf("Line count: %d\n\n", lc);
    if (mode == 0)
    {
    puts("Closing file");
    fclose(out);
    }
    return;
    }

    I'll skip the rest of the program, as it's mostly setting up the
    socket and initializing communication with the remote system. All
    that seems to be ok. The only relevant lines there are the calls to
    this function:

    puts("Output to console");
    extract_lines(m_socket, cmds, "stdout");
    puts("\nOutput to file");
    extract_lines(m_socket, cmds, "line.txt");

    Results from running:

    Output to console
    [many lines of output deleted]
    Line count: 8681


    Output to file
    Line count: 195

    Closing file


    Only difference in the calls is the output target. Makes no difference
    which is called first.



    Brian
     
    Default User, May 29, 2010
    #1
    1. Advertising

  2. Default User

    bart.c Guest

    "Default User" <> wrote in message
    news:...

    > Perhaps someone can spot what I'm doing wrong here. I have a function
    > that reads in line-oriented text (socket stuff OT, but I believe
    > that's irrelevant). It can send the extracted lines to the console or
    > to a file as desired. When output to the console, it works normally,
    > getting several thousand lines from the remote system and ending with
    > the proper termination line. When sent to a file, it stops after a few
    > hundred lines.


    So the first few hundred lines are identical?

    First thing might be to display the set of res values during the loop, and
    seeing how these differ between file and stdout output. (Might be necessary
    to remove the fputs() calls to see the output.)

    If this sequence is the same, then check out the logic surrounding the lc++
    line; this must differ somehow between file and console mode; if might be
    necessary to look at buffer contents in detail (comparing between the two
    modes).

    If the sequence is different, then eliminate surrounding code until the
    results are consistent

    (BTW I can't see how linepos is prevented from overflowing linebuf when the
    input contains no recognised newline characters.)

    --
    Bartc
     
    bart.c, May 29, 2010
    #2
    1. Advertising

  3. "Default User" <> writes:

    > Here's the message again without attachment. Sorry for the mess. Some
    > days you should stay in bed.
    >
    > ========= original message follows =========
    >
    > Perhaps someone can spot what I'm doing wrong here. I have a function
    > that reads in line-oriented text (socket stuff OT, but I believe
    > that's irrelevant).


    I'm not so sure...

    > It can send the extracted lines to the console or
    > to a file as desired. When output to the console, it works normally,
    > getting several thousand lines from the remote system and ending with
    > the proper termination line. When sent to a file, it stops after a few
    > hundred lines.
    >
    > #define BUFFERSIZE 1024
    >
    > void extract_lines(SOCKET socket, const char *cmd, char *filename)
    > {
    > int done = 0;
    > char buffer[BUFFERSIZE];
    > char linebuf[BUFFERSIZE];
    > int res;
    > int bufpos = 0;
    > int linepos = 0;
    > int lc = 0;
    > FILE *out;
    > int mode = 0;
    >
    > /* see whether it should output to console or a file */
    > if (strcmp(filename, "stdout") == 0)
    > {
    > mode = 1;
    > out = stdout;
    > }
    > else
    > {
    > out = fopen(filename, "w");
    > if (out == 0)
    > {
    > fprintf(stderr, "Failed to open: %s", filename);
    > return;
    > }
    > }
    > res = send(socket, cmd, strlen(cmd), 0);
    > while (!done)
    > {
    > res = recv(socket, buffer, sizeof buffer, 0);
    > if (res <= 0)
    > done = 1;


    Why do you set done = 1 here since a short return is usually considered a
    success? No don't answer that. It's off topic and you won't get proper
    scrutiny of any relies.

    Start by treating a short reply like a full one (but don't process more
    that the received bytes) and if it starts to work, post in
    comp.unix.programmer about why.

    > else
    > {
    > if (res < sizeof buffer)
    > done = 1;
    > for (bufpos = 0; bufpos < res; bufpos++)
    > {
    > if (buffer[bufpos] == '\r')
    > continue; /* just skip that */
    > else if (buffer[bufpos] == '\n')
    > {
    > linebuf[linepos] = 0;
    > fputs(linebuf, out);
    > fputs("\n", out);
    > linepos = 0;
    > lc++;
    > }
    > else
    > {
    > linebuf[linepos++] = buffer[bufpos];


    C issue: Long lines will overflow the line buffer. Either check or do
    the output some either way. There is no need print one line at a time.
    I'd juts print data as I get it. Of course, this might be a framework
    for something that needs whole lines, in which case, just check the
    bounds.

    > }
    > }
    > }
    > }
    > printf("Line count: %d\n\n", lc);
    > if (mode == 0)
    > {
    > puts("Closing file");
    > fclose(out);
    > }
    > return;
    > }


    <snip>
    --
    Ben.
     
    Ben Bacarisse, May 29, 2010
    #3
  4. Default User

    Default User Guest

    Ben Bacarisse wrote:

    > "Default User" <> writes:
    >
    > > Here's the message again without attachment. Sorry for the mess.
    > > Some days you should stay in bed.
    > >
    > > ========= original message follows =========
    > >
    > > Perhaps someone can spot what I'm doing wrong here. I have a
    > > function that reads in line-oriented text (socket stuff OT, but I
    > > believe that's irrelevant).

    >
    > I'm not so sure...


    I could be wrong on that, certainly. I just can't imagine what within
    the context of the function it could be.

    > > while (!done)
    > > {
    > > res = recv(socket, buffer, sizeof buffer, 0);
    > > if (res <= 0)
    > > done = 1;

    >
    > Why do you set done = 1 here since a short return is usually
    > considered a success? No don't answer that. It's off topic and you
    > won't get proper scrutiny of any relies.


    A short return less than or equal to 0 means either error or no
    characters read. Either way, you don't want to process the buffer. Just
    to make sure there's not a SOCKET_ERROR problem, I modified that bit as
    follows:


    if (res < 0)
    {
    fprintf(stderr, "Socket Error");
    done = 1;
    }
    if (res == 0)
    done = 1;

    > Start by treating a short reply like a full one (but don't process
    > more that the received bytes) and if it starts to work, post in
    > comp.unix.programmer about why.


    I guess I'm not following. I already do that if the receive count is
    less than the requested amount, but greater than 0.


    > > linebuf[linepos++] = buffer[bufpos];

    >
    > C issue: Long lines will overflow the line buffer.


    Correct. It doesn't happen to be the error source, as none of the lines
    are that long. I just haven't added that check.

    > There is no need print one line at a
    > time. I'd juts print data as I get it. Of course, this might be a
    > framework for something that needs whole lines, in which case, just
    > check the bounds.


    The goal is not to print lines, it's to extract them for further
    handling. It started out printing to console so I could do a bare
    sanity check by visually examining the results. Then I wanted to store
    off to a file and compare to a file that's just a dump of the session,
    to compare and make sure there weren't any corner cases where I screwed
    up the lines. Unfortunately, the process of writing output to the file
    gave way truncated results.

    I made an alternate version that just reads buffers of data and writes
    to file or console. Similar results.

    void extract_lines(SOCKET socket, const char *cmd, char* filename)
    {
    int done = 0;
    char buffer[BUFFERSIZE];
    int res;
    FILE *out;
    int mode = 0;
    long cc = 0;

    /* see whether it should output to console or a file */
    if (strcmp(filename, "stdout") == 0)
    {
    mode = 1;
    out = stdout;
    }
    else
    {
    out = fopen(filename, "w");
    if (out == 0)
    {
    fprintf(stderr, "Failed to open: %s", filename);
    return;
    }
    }
    res = send(socket, cmd, strlen(cmd), 0);
    while (!done)
    {
    res = recv(socket, buffer, sizeof buffer, 0);
    if (res < 0)
    {
    fprintf(stderr, "Socket Error");
    done = 1;
    }
    if (res == 0)
    done = 1;
    else
    {
    if (res < sizeof buffer)
    done = 1;
    fwrite(buffer, 1, res, out );
    fflush(out);
    cc+=res;
    }
    }
    if (mode == 0)
    {
    puts("Closing file");
    fclose(out);
    }
    printf("Characters: %ld\n", cc);
    return;
    }

    Results are similar:

    Output to console
    [snip]
    Characters: 448691

    Output to file
    Closing file
    Characters: 9904
     
    Default User, May 29, 2010
    #4
  5. On 29 May 2010 16:09:10 GMT, "Default User" <>
    wrote:

    >Perhaps someone can spot what I'm doing wrong here. I have a function
    >that reads in line-oriented text (socket stuff OT, but I believe
    >that's irrelevant). It can send the extracted lines to the console or
    >to a file as desired. When output to the console, it works normally,
    >getting several thousand lines from the remote system and ending with
    >the proper termination line. When sent to a file, it stops after a few
    >hundred lines.


    Probably off topic but how do you insure that the remote system is
    actually sending the same data (quantity and content for each
    execution of recv) for both executions of extract_lines?

    Assuming that it does, the only apparent difference is the target of
    the fputs. Could this possibly be a timing issue? Do stdout and the
    file have the same buffering? It is common for lines to appear on
    stdout as soon as the \n is transmitted. For output to a file, it
    would be reasonable for the data transfer to wait until the "hardware
    buffer" was full. This could significantly change the frequency with
    which recv is called.

    >
    >#define BUFFERSIZE 1024
    >
    >void extract_lines(SOCKET socket, const char *cmd, char *filename)
    >{
    > int done = 0;
    > char buffer[BUFFERSIZE];
    > char linebuf[BUFFERSIZE];
    > int res;
    > int bufpos = 0;
    > int linepos = 0;
    > int lc = 0;
    > FILE *out;
    > int mode = 0;


    snip

    > res = send(socket, cmd, strlen(cmd), 0);
    > while (!done)
    > {
    > res = recv(socket, buffer, sizeof buffer, 0);
    > if (res <= 0)
    > done = 1;


    Not related to your question but you could eliminate this if statement
    since when res <= 0 the following if will also set done to 1 and the
    subsequent for loop will iterate zero times.

    > else
    > {
    > if (res < sizeof buffer)
    > done = 1;
    > for (bufpos = 0; bufpos < res; bufpos++)
    > {
    > if (buffer[bufpos] == '\r')
    > continue; /* just skip that */


    Not related to your question but do you really want to ignore all \r
    or only the ones that are part of a \r\n pair?

    > else if (buffer[bufpos] == '\n')
    > {
    > linebuf[linepos] = 0;
    > fputs(linebuf, out);
    > fputs("\n", out);
    > linepos = 0;
    > lc++;
    > }
    > else
    > {
    > linebuf[linepos++] = buffer[bufpos];
    > }
    > }
    > }
    > }
    > printf("Line count: %d\n\n", lc);
    > if (mode == 0)
    > {
    > puts("Closing file");
    > fclose(out);
    > }
    > return;
    >}
    >
    >I'll skip the rest of the program, as it's mostly setting up the
    >socket and initializing communication with the remote system. All
    >that seems to be ok. The only relevant lines there are the calls to
    >this function:
    >
    > puts("Output to console");
    > extract_lines(m_socket, cmds, "stdout");
    > puts("\nOutput to file");
    > extract_lines(m_socket, cmds, "line.txt");
    >
    >Results from running:
    >
    >Output to console
    >[many lines of output deleted]
    >Line count: 8681
    >
    >
    >Output to file
    >Line count: 195
    >
    >Closing file
    >
    >
    >Only difference in the calls is the output target. Makes no difference
    >which is called first.


    Are the line counts always the same? Do the first 195 lines match?

    --
    Remove del for email
     
    Barry Schwarz, May 29, 2010
    #5
  6. Default User

    Moi Guest

    On Sat, 29 May 2010 17:53:06 +0000, Default User wrote:

    > Ben Bacarisse wrote:
    >
    >> "Default User" <> writes:


    >
    > if (res < 0)
    > {
    > fprintf(stderr, "Socket Error");
    > done = 1;
    > }


    You could check errno here and act appropriately.

    > if (res == 0)
    > done = 1;
    >
    >> Start by treating a short reply like a full one (but don't process more
    >> that the received bytes) and if it starts to work, post in
    >> comp.unix.programmer about why.

    >
    > I guess I'm not following. I already do that if the receive count is
    > less than the requested amount, but greater than 0.
    >
    >
    >> > linebuf[linepos++] = buffer[bufpos];

    >>
    >> C issue: Long lines will overflow the line buffer.

    >
    > Correct. It doesn't happen to be the error source, as none of the lines
    > are that long. I just haven't added that check.


    You don't need two buffers. Skipping \r and counting \n can be done in place.


    >> There is no need print one line at a
    >> time. I'd juts print data as I get it. Of course, this might be a
    >> framework for something that needs whole lines, in which case, just
    >> check the bounds.

    >
    > The goal is not to print lines, it's to extract them for further
    > handling. It started out printing to console so I could do a bare sanity
    > check by visually examining the results. Then I wanted to store off to a
    >



    > res = send(socket, cmd, strlen(cmd), 0); while (!done)
    > {
    > res = recv(socket, buffer, sizeof buffer, 0); if (res < 0)
    > {
    > fprintf(stderr, "Socket Error");
    > done = 1;
    > }
    > if (res == 0)
    > done = 1;
    > else
    > {
    > if (res < sizeof buffer)
    > done = 1;


    This is plain wrong.
    Short reads don't mean there is something wrong.

    > fwrite(buffer, 1, res, out );
    > fflush(out);
    > cc+=res;
    > }
    > }




    BTW: this thread belongs in c.u.p

    HTH,
    AvK
     
    Moi, May 29, 2010
    #6
  7. Default User

    bart.c Guest

    "Default User" <> wrote in message
    news:...

    What does this version do?

    void extract_lines(SOCKET socket, const char *cmd /*, char* filename*/)
    {
    int done = 0;
    char buffer[BUFFERSIZE];
    int res;
    /* FILE *out; */
    int mode = 0;
    long cc = 0;

    res = send(socket, cmd, strlen(cmd), 0);
    while (!done)
    {
    res = recv(socket, buffer, sizeof buffer, 0);
    if (res < 0)
    {
    fprintf(stderr, "Socket Error");
    done = 1;
    }
    if (res == 0)
    done = 1;
    else
    {
    if (res < sizeof buffer)
    done = 1;
    cc+=res;
    }
    }

    printf("Characters: %ld\n", cc);
    return;
    }

    Ie. Does it count the right number of chars, or too few? In either case,
    start putting back code and see what makes it flip.

    --
    Bartc
     
    bart.c, May 29, 2010
    #7
  8. Default User

    Default User Guest

    Barry Schwarz wrote:

    > On 29 May 2010 16:09:10 GMT, "Default User" <>
    > wrote:
    >
    > > Perhaps someone can spot what I'm doing wrong here. I have a
    > > function that reads in line-oriented text (socket stuff OT, but I
    > > believe that's irrelevant). It can send the extracted lines to the
    > > console or to a file as desired. When output to the console, it
    > > works normally, getting several thousand lines from the remote
    > > system and ending with the proper termination line. When sent to a
    > > file, it stops after a few hundred lines.

    >
    > Probably off topic but how do you insure that the remote system is
    > actually sending the same data (quantity and content for each
    > execution of recv) for both executions of extract_lines?


    That's certainly a reasonable question. It should be nearly identical.
    When I change the program from one console/one file to two console
    runs, I get similar size outputs. Also, when the server is done
    sending, it outputs a line with a single . in it. I see that with
    console output, but not the file.

    Not to go too far off-topic, but I am requesting a list of message IDs
    from a news server for a specific date range.

    > Assuming that it does, the only apparent difference is the target of
    > the fputs. Could this possibly be a timing issue? Do stdout and the
    > file have the same buffering? It is common for lines to appear on
    > stdout as soon as the \n is transmitted. For output to a file, it
    > would be reasonable for the data transfer to wait until the "hardware
    > buffer" was full. This could significantly change the frequency with
    > which recv is called.


    The best I could think to do there was add an fflush() after writing
    the line out. That didn't seem to make any difference.

    > > res = send(socket, cmd, strlen(cmd), 0);
    > > while (!done)
    > > {
    > > res = recv(socket, buffer, sizeof buffer, 0);
    > > if (res <= 0)
    > > done = 1;

    >
    > Not related to your question but you could eliminate this if statement
    > since when res <= 0 the following if will also set done to 1 and the
    > subsequent for loop will iterate zero times.


    I had that in there for "growth". Special handling and whatnot.

    > > else
    > > {
    > > if (res < sizeof buffer)
    > > done = 1;
    > > for (bufpos = 0; bufpos < res; bufpos++)
    > > {
    > > if (buffer[bufpos] == '\r')
    > > continue; /* just skip that */

    >
    > Not related to your question but do you really want to ignore all \r
    > or only the ones that are part of a \r\n pair?


    For the problem at hand, it's only to appear in the form of
    line-termination. I could do a look-ahead and see.
    > > Only difference in the calls is the output target. Makes no
    > > difference which is called first.

    >
    > Are the line counts always the same? Do the first 195 lines match?


    The line counts vary slightly depending on long it's been between runs.
    The lines seem to match as best I can tell.

    I cut down the size of input (a few day's posts from CLC) and got
    identical results from console and file output (under 200 lines). When
    I bump it up to about 400 lines (to the console) then file is truncated
    again.

    If I were confident that there's no C problem, I'd move on to another
    forum. I could just move on to the next phase, which is to store off
    the strings in memory, but I'd like to understand what's going on here.



    Brian
     
    Default User, May 29, 2010
    #8
  9. Default User

    Default User Guest

    bart.c wrote:

    > "Default User" <> wrote in message
    > news:...
    >
    > What does this version do?


    [snip]

    > Ie. Does it count the right number of chars, or too few? In either
    > case, start putting back code and see what makes it flip.


    Well, that's very interesting:

    Output to console
    Characters: 11356
    Output to file
    Characters: 2904


    Looking less and less like a C problem, and some problem with
    understanding how the interaction with the remote system works. I added
    a line to print out the value of "res" on two runs:

    1024
    1024
    1024
    1024
    1024
    1024
    1024
    1024
    1024
    1024
    1024
    92
    Characters: 11356

    1024
    1024
    856
    Characters: 2904
     
    Default User, May 29, 2010
    #9
  10. Default User

    Eric Sosman Guest

    On 5/29/2010 12:09 PM, Default User wrote:
    > Here's the message again without attachment. Sorry for the mess. Some
    > days you should stay in bed.
    >
    > ========= original message follows =========
    >
    > Perhaps someone can spot what I'm doing wrong here. I have a function
    > that reads in line-oriented text (socket stuff OT, but I believe
    > that's irrelevant). It can send the extracted lines to the console or
    > to a file as desired. When output to the console, it works normally,
    > getting several thousand lines from the remote system and ending with
    > the proper termination line. When sent to a file, it stops after a few
    > hundred lines.
    > [...]


    It seems to me most likely that the problem *is* socket-related;
    as Barry Schwarz suggested it may well be a matter of timing. At
    one point, you've got

    > res = recv(socket, buffer, sizeof buffer, 0);
    > if (res<= 0)
    > done = 1;
    > else
    > {
    > if (res< sizeof buffer)
    > done = 1;


    .... and the inference "non-full buffer means we're done" seems
    suspect to me. Check on a forum like comp.unix.programmer for more
    informed opinion, but ISTR that an "incomplete read" is perfectly
    normal, and not an indication that there's no more data to come.

    By the way, I cannot see what purpose linebuf[] and linepos
    serve. Why not just putc() the characters as you get 'em, and not
    first store them in a buffer that might or might not be big enough?

    --
    Eric Sosman
    lid
     
    Eric Sosman, May 29, 2010
    #10
  11. Default User

    Default User Guest

    Eric Sosman wrote:

    > On 5/29/2010 12:09 PM, Default User wrote:


    > It seems to me most likely that the problem is socket-related;
    > as Barry Schwarz suggested it may well be a matter of timing.


    That could be.

    > > res = recv(socket, buffer, sizeof buffer, 0);
    > > if (res<= 0)
    > > done = 1;
    > > else
    > > {
    > > if (res< sizeof buffer)
    > > done = 1;

    >
    > ... and the inference "non-full buffer means we're done" seems
    > suspect to me.


    I need to get more into the sockety stuff, which is off-topic here of
    course.

    Check on a forum like comp.unix.programmer for more
    > informed opinion, but ISTR that an "incomplete read" is perfectly
    > normal, and not an indication that there's no more data to come.


    It's winsock actually for the code I'm working, but they're pretty
    similar. It was easy to use blocking sockets and quit when a partial
    buffer was found, but perhaps too easy. I'll go off and work it with a
    better approach. It's looking like not a C problem, so I need to
    terminate off-topicalnessing.

    > By the way, I cannot see what purpose linebuf[] and linepos
    > serve. Why not just putc() the characters as you get 'em, and not
    > first store them in a buffer that might or might not be big enough?


    This is the first step and was an easy way to come up with individual
    lines. The goal is not to print out lines, but to copy and save them.



    Brian
     
    Default User, May 29, 2010
    #11
  12. Default User

    Default User Guest

    It did seem to be socket stuff, working now. As that's well off-topic,
    I won't go any further expect to say that some of you sussed out the
    problem.



    Brian
     
    Default User, May 29, 2010
    #12
  13. "Default User" <> writes:

    > Ben Bacarisse wrote:
    >
    >> "Default User" <> writes:

    <snip>
    >> > while (!done)
    >> > {
    >> > res = recv(socket, buffer, sizeof buffer, 0);
    >> > if (res <= 0)
    >> > done = 1;

    >>
    >> Why do you set done = 1 here since a short return is usually
    >> considered a success? No don't answer that. It's off topic and you
    >> won't get proper scrutiny of any relies.

    >
    > A short return less than or equal to 0 means either error or no
    > characters read.


    Yes, that's fine -- these are errors. Unfortunately I put my comment
    against the wrong part of the code so you quote reasonably
    misunderstood. Later you have:

    | if (res < sizeof buffer)
    | done = 1;

    This is what I call a "short return" and I intended to comment here
    rather than earlier. The point is that there is no reason (as far as I
    can see) to set done = 1 here.

    > Either way, you don't want to process the buffer. Just
    > to make sure there's not a SOCKET_ERROR problem, I modified that bit as
    > follows:
    >
    >
    > if (res < 0)
    > {
    > fprintf(stderr, "Socket Error");
    > done = 1;
    > }
    > if (res == 0)
    > done = 1;
    >
    >> Start by treating a short reply like a full one (but don't process
    >> more that the received bytes) and if it starts to work, post in
    >> comp.unix.programmer about why.

    >
    > I guess I'm not following. I already do that if the receive count is
    > less than the requested amount, but greater than 0.


    Yes, but (the old code) processed that one short buffer and then set
    done = 1 so the loop stopped. More data might have been available on a
    subsequent recv call.

    My reply was confusing, but one way or another you don't have a C
    problem. Getting less that sizeof buffer does not mean that there is no
    more data.

    <snip>
    --
    Ben.
     
    Ben Bacarisse, May 30, 2010
    #13
  14. Default User

    Default User Guest

    Ben Bacarisse wrote:

    > My reply was confusing, but one way or another you don't have a C
    > problem. Getting less that sizeof buffer does not mean that there is
    > no more data.


    Right, see my follow-up message. Working well now. Thanks for the input.



    Brian
     
    Default User, May 30, 2010
    #14
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. z. f.
    Replies:
    5
    Views:
    591
    David Wang [Msft]
    Jan 31, 2005
  2. Chris
    Replies:
    0
    Views:
    420
    Chris
    Apr 10, 2006
  3. jza

    File name gets truncated

    jza, May 8, 2004, in forum: C Programming
    Replies:
    9
    Views:
    389
    Darrell Grainger
    May 10, 2004
  4. Fuzzyman
    Replies:
    0
    Views:
    321
    Fuzzyman
    Mar 15, 2005
  5. Replies:
    3
    Views:
    121
    J├╝rgen Exner
    Oct 15, 2005
Loading...

Share This Page