From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 21515 invoked by alias); 1 Apr 2008 02:54:02 -0000 Received: (qmail 21381 invoked by uid 48); 1 Apr 2008 02:53:14 -0000 Date: Tue, 01 Apr 2008 02:54:00 -0000 Message-ID: <20080401025314.21380.qmail@sourceware.org> X-Bugzilla-Reason: CC References: Subject: [Bug c/35592] Want attribute to enable precision loss warning In-Reply-To: Reply-To: gcc-bugzilla@gcc.gnu.org To: gcc-bugs@gcc.gnu.org From: "manu at gcc dot gnu dot org" Mailing-List: contact gcc-bugs-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-bugs-owner@gcc.gnu.org X-SW-Source: 2008-04/txt/msg00011.txt.bz2 ------- Comment #3 from manu at gcc dot gnu dot org 2008-04-01 02:53 ------- (In reply to comment #2) > > If the size_t given to memcpy is truncated, that does not overwrite a buffer. > But if the size_t given to malloc is truncated, that is a pretty surefire way > to find a security issue. I guess that depends on how the conversion occurs: int i = -5; ... memcpy (dest, src, i); I would have trouble defining which cases are security issues. On the other hand, the truncation may actually take place far from where malloc is called: size_t len = 999999999999999LL; ... buffer = malloc (len); not sure how your proposal could handle that. -- manu at gcc dot gnu dot org changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |manu at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35592