From isupov@moonhe.jinr.ru  Tue Feb  9 23:45:20 1999
Received: from jimex.jinr.ru (jimex.jinr.ru [159.93.17.7])
          by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id XAA26082
          for <FreeBSD-gnats-submit@freebsd.org>; Tue, 9 Feb 1999 23:44:36 -0800 (PST)
          (envelope-from isupov@moonhe.jinr.ru)
Received: from moonhe.jinr.ru (isupov@moonhe.jinr.ru [159.93.18.27])
          by jimex.jinr.ru (8.8.8/8.8.4) with ESMTP
	  id KAA18149 for <FreeBSD-gnats-submit@freebsd.org>; Wed, 10 Feb 1999 10:42:56 +0300 (MSK)
Received: (from isupov@localhost)
	by moonhe.jinr.ru (8.8.8/8.8.8) id KAA20855;
	Wed, 10 Feb 1999 10:43:23 +0300 (MSK)
	(envelope-from isupov)
Message-Id: <199902100743.KAA20855@moonhe.jinr.ru>
Date: Wed, 10 Feb 1999 10:43:23 +0300 (MSK)
From: isupov@moonhe.jinr.ru
Reply-To: isupov@moonhe.jinr.ru
To: FreeBSD-gnats-submit@freebsd.org
Subject: malloc() system warnings suppression
X-Send-Pr-Version: 3.2

>Number:         10001
>Category:       standards
>Synopsis:       malloc() system warnings suppression
>Confidential:   no
>Severity:       serious
>Priority:       medium
>Responsible:    gnats-admin
>State:          closed
>Quarter:        
>Keywords:       
>Date-Required:  
>Class:          sw-bug
>Submitter-Id:   current-users
>Arrival-Date:   Tue Feb  9 23:50:01 PST 1999
>Closed-Date:    Wed Feb 10 00:35:45 PST 1999
>Last-Modified:  Thu Oct 31 02:51:11 PST 2002
>Originator:     
>Release:        
>Organization:
>Environment:
>Description:
 Submitter-Id:   current-users
 Originator:     Isupov A.Yu.
 Organization:   LHE, JINR
 Confidential:   no
 Synopsis:       malloc() system warnings suppression
 Severity:       non-critical
 Priority:       low
 Release:        FreeBSD-current i386
 Class:          change-request
 Category:       bin
 
 Environment: 
                 FreeBSD-current i386
 
 Description: 
                 current FreeBSD malloc() realization is very severe in some
                 aspects. From malloc(3):
      "A side effect of this architecture is that many minor transgressions on
      the interface which would traditionally not be detected are in fact de-
      tected.  As a result, programs that have been running happily for years
      may suddenly start to complain loudly, when linked with this allocation
      implementation."
                 And not so clean written, but very large and (sometimes)
                 useful programs too... So mechanism for warnings suppression
                 is proposed. Additional key 's' in standard /etc/malloc.conf
                 will _s_uppress warnings (by default), if 'A' not setted,
                 'S' - enable it.
 
 How-To-Repeat: 
 
 Fix: 
 
 *** malloc.c.orig	Wed Feb 10 10:26:04 1999
 --- malloc.c	Wed Feb 10 10:34:29 1999
 ***************
 *** 228,233 ****
 --- 228,236 ----
   /* junk fill ?  */
   static int malloc_junk;
   
 + /* write warnings ?  */
 + static int malloc_warn;
 + 
   #ifdef HAS_UTRACE
   
   /* utrace ?  */
 ***************
 *** 289,298 ****
       char *q = " warning: ";
       if (malloc_abort)
   	wrterror(p);
 !     write(STDERR_FILENO, __progname, strlen(__progname));
 !     write(STDERR_FILENO, malloc_func, strlen(malloc_func));
 !     write(STDERR_FILENO, q, strlen(q));
 !     write(STDERR_FILENO, p, strlen(p));
   }
   
   
 --- 292,303 ----
       char *q = " warning: ";
       if (malloc_abort)
   	wrterror(p);
 !     if (malloc_warn) {
 !        write(STDERR_FILENO, __progname, strlen(__progname));
 !        write(STDERR_FILENO, malloc_func, strlen(malloc_func));
 !        write(STDERR_FILENO, q, strlen(q));
 !        write(STDERR_FILENO, p, strlen(p));
 !     }
   }
   
   
 ***************
 *** 418,423 ****
 --- 423,430 ----
   		case 'R': malloc_realloc = 1; break;
   		case 'j': malloc_junk    = 0; break;
   		case 'J': malloc_junk    = 1; break;
 + 		case 's': malloc_warn    = 0; break;
 + 		case 'S': malloc_warn    = 1; break;
   #ifdef HAS_UTRACE
   		case 'u': malloc_utrace  = 0; break;
   		case 'U': malloc_utrace  = 1; break;
 
>How-To-Repeat:
>Fix:
>Release-Note:
>Audit-Trail:
State-Changed-From-To: open->closed 
State-Changed-By: phk 
State-Changed-When: Wed Feb 10 00:35:45 PST 1999 
State-Changed-Why:  
Sorry, I've had this request before, but I don't entertain the notion of 
ignoring errors of this kind. 
. 
>Unformatted: