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

[dickey]

> 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." 

well, that's useful to know - but I don't believe it went into the standard.
(I looked at the relevant stuff in Plauger's book - don't happen to have
the full standard ;-)

The language in Solaris' manpage is more readable but says the same
as Plauger:

     The fread() function reads into an array pointed to  by  ptr
     up  to  nitems  items  of data from stream, where an item of
     data is a sequence of bytes (not necessarily terminated by a
     null  byte)  of  length  size.  It stops reading bytes if an
     end-of-file or error condition is encountered while  reading
     stream,  or  if  nitems items have been read.  It increments
     the data pointer in stream to point to  the  byte  following
     the  last byte read if there is one.  It does not change the
     contents of stream.  It returns the number of items read.
  
> | 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. 

but you've overlaid it with a string that you have the right length
(assuming that fread did not lie ;-)
  
> 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 ... :-) ...! 

oh, I usually get a good night's sleep on Friday night and then work all
weekend on these projects.  But Fridays are worst since I've been juggling
this & day-work all week.
  
> Happy Superbowl Sunday ... 
>  
> /kim 


-- 
Thomas E. Dickey
address@hidden
http://www.clark.net/pub/dickey