lynx-dev Re: [dev.15] fixup patch: edit TEXTAREA

[Kim DeVaughn]

On Fri, Jan 29, 1999, address@hidden (address@hidden) said:
|
| > Far as I know, fread() can return one or more nulls at the end of the file
| > (implementation dependent).  I was just making sure I was backing up thru
| > any extra nulls that might be there.  If there aren't any, it's a near nop.
|
| I've not seen that (the stat call, on the other hand I know in VAX C will
| return the filesize rounded up to the next block).

To quote from at least one man page (Amdahl UTS 2.x, an older flavor of
SVR3, IIRC), "... the number of bytes written (read) will be the same as
those found in the external device.  The proposed standard does specify,
however, that a stream may have an implementation defined number of null
bytes appended to its end.  These null bytes might be used to pad the
information so that it fills a sector on disk, for example."

There's probably other such implementation caveats floating around, hence
the test for a string of nulls on the tail.


| > | or embedded nulls?
| > |
| > | >-        *p = '\0';
| > | >+for (size = MAX_LINE, p = line + (size - 1); size != 0; p--, size--) {
| > | >+    if ((isspace(*p)) || (*p == '\0'))
| > | >+       *p = '\0';
| >
| > Heh ... not embedded nulls.  We are scanning from the tail end of the
| > buffer

| but the test for null is redundant then (why would the buffer be full
| of nulls?).

Because of the immediately preceeding two lines:

        strncpy (line, "\0", MAX_LINE);
        strncpy (line, lp, len);

which is a quick'n'dirty way of making sure you have a null on the end
of the strncpy()'d data, without thinking about char counts, lengths,
and pointers.  Remember that strncpy() doesn't tack on a null if the
strlen(src) is greater than the count.

Useful when you're just getting something running, and want to concentrate
on the overall algorithm.

Now that the overall feature is working, I should probably eliminate the
1st buffer-clearing strncpy(), and properly set *(line + len) = \0.

Or is that "line + len + 1" or "line + len - 1"  or ... :-) ...


OTOH, the above methodology is probably marginally faster that doing it
the "proper way", when MAX_LINE is closer to the average line length,
than in the lynx case (eg, a max of 128, where the typical line is around
80 chars, etc).  Of course with lynx having MAX_LINE at 1024, that is not
the case ...


| oops - sorry (friday/long week).  your usage is correct (X has to be a quoted
| string, and an ANSI compiler will indeed concatenate them when adjacent).

Thank God for weekends ... :-) ...!

Happy Superbowl Sunday ...

/kim