Alex Riesen wrote:
> On Tue, Aug 4, 2009 at 23:29, Brandon
> Casey<brandon.casey.ctr@xxxxxxxxxxxxxxx> wrote:
>> Alex Riesen wrote:
>>> + if (c == '\n' && len > 1 && buf[len - 2] == '\r')
>>> + buf[--len - 1] = '\n';
>>> buf[len] = '\0';
>>>
>>> return len;
>> What if \r lands at character 99 and \n is at character 100? If buf has
>> exactly 100 characters available for writing. ...
>
> Ah, yes. You're right.
>
> I have strong dislike towards unget, though. How about this, instead:
>
> int read_line_with_nul(char *buf, int size, FILE *in)
> {
> int len = 0, c;
>
> while (len < size) {
> c = getc(in);
> if (c == EOF)
> break;
> buf[len++] = c;
> if (c == '\n')
> break;
> else if (len == size)
> c = 0;
> }
> if (c == '\n' && len > 1 && buf[len - 2] == '\r')
> buf[--len - 1] = '\n';
> buf[len] = '\0';
>
> return len;
> }
I don't see how this solves the problem. Still if the buffer is filled,
and the last character read is '\r', and the next character that has not
yet been read is '\n', then the '\r' will erroneously be returned in buf.
Plus, I think you'll have a problem at buf[len] = '\0' if the loop runs to
completion and len == size.
-brandon
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html