🚀 go-pugleaf

In article <432@ria.ccs.uwo.ca>, reggers@ria.ccs.uwo.ca (Reg Quinton) writes:
|> We were having trouble with sendmail core dumping when dealing with
|> long recipient lists (at least with 5.61 on our Mips machine). I
|> managed to localize the problem into deliver.c and the deliver()
|> procedure where the string array "tobuf" was causing the problem -- to
|> much data was being written into the array and this was corrupting
|> other structures on the stack.
|> 
|> The following patch fixed that problem.
|> 
|> *** deliver.c	Wed May 30 14:45:02 1990
|> --- deliver.c.orig	Wed May 30 15:35:32 1990
|> ***************
|> *** 221,227 ****
|>   			continue;
|>   
|>   		/* avoid overflowing tobuf */
|> ! 		if ((strlen(to->q_paddr) + strlen(tobuf) + 2) > sizeof(tobuf))
|>   			break;
|>   
|>   		if (tTd(10, 1))
|> --- 221,227 ----
|>   			continue;
|>   
|>   		/* avoid overflowing tobuf */
|> ! 		if (sizeof tobuf - (strlen(to->q_paddr) + strlen(tobuf) + 2) < 0)
|>   			break;
|>   
|>   		if (tTd(10, 1))

I ran into this one on a a machine running HPUX 7.0. The problem there
(and I suspect on the Mips box) is the type of value (size_t) returned
by sizeof and strlen. 'size_t' is defined to be 'long' in BSD 4.3, 'int'
in SunOS and 'unsigned int' in HPUX (and ANSI C).

I checked through the sendmail code and other uses of 'sizeof' and
'strlen' are written to avoid this problem - good luck rather than judgement?

The important point is that this sort of problem will almost certainly
surface again as old code is recompiled on newer machines.