Re: LYNX-DEV Lynx 2.7.1ac-0.74 and LYUnEscapeEntities problem under digital UNIX

[T.E.Dickey]

> On Thu, 2 Oct 1997, T.E.Dickey wrote:
> 
> > >     Str = (char *)calloc(1, len);
> > ...
> > > (to get some more diagnostic output), and changing calloc(1, len) to
> > > calloc(len, 1) or to just malloc(len); and changing "int len;" at the
> 
> > right - that one was backwards: the number of elements is first.
> 
> Does it actualy make a difference anywhere?  (Aren't those numbers just
> multiplied?)
it sure does:  the allocator can (and some do) use the element size to
derive alignment constraints.  Of course it doesn't matter for 'char',
but it's a bad practice.
 
> > hmm: bear in mind that this is a 64-bit machine, and sizeof(unsigned)
> > is not the same as sizeof(size_t) -- or so I was informed.  There's
> > a lot of places where Lynx uses int's where unsigned values are appropriate,
> > which may also produce problems.
> 
> In this specific case - calloc(1, len) should do the right thing, whether
> len is defined as char, unsigned char, int, unsigned, size_t etc, as long
> as there is no overflow or sign extension involved.  That's what .h files
> are for, right?  (Assuming the right .h with the right prototype for
> calloc() gets included.)
right.  but I was responding to the sense that you were telling him to
change types of some of the variables - without seeing which spot in the
code (they could be passed by address somewhere).
 
>     Klaus

-- 
Thomas E. Dickey
address@hidden
http://www.clark.net/pub/dickey
;
; To UNSUBSCRIBE:  Send a mail message to address@hidden
;                  with "unsubscribe lynx-dev" (without the
;                  quotation marks) on a line by itself.
;