From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 28037 invoked by alias); 28 Mar 2017 16:13:14 -0000 Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sourceware.org Received: (qmail 28010 invoked by uid 89); 28 Mar 2017 16:13:13 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-1.9 required=5.0 tests=BAYES_00,FREEMAIL_FROM,RCVD_IN_DNSWL_NONE,SPF_PASS autolearn=ham version=3.3.2 spammy=Hx-languages-length:1390 X-HELO: mail-wr0-f171.google.com Received: from mail-wr0-f171.google.com (HELO mail-wr0-f171.google.com) (209.85.128.171) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Tue, 28 Mar 2017 16:13:12 +0000 Received: by mail-wr0-f171.google.com with SMTP id l43so109803653wre.1 for ; Tue, 28 Mar 2017 09:13:12 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:cc:subject:references:date:in-reply-to :message-id:user-agent:mime-version:content-transfer-encoding; bh=BZxplyKa8Q2IxmfmYQXcoPYMIooojBLt15fQHTN7+F8=; b=Jz0goe6e78cZz1PsfSWxR3TycfmBTGzbdtUlWDts6EXLW9Ax5FWY15uuc09Hpj7qLw RL8UnYSdopRomYsLVdl0hr5IhYbrzlZPCd052pG0Ybr3533jX4bRDsPkkrESETXe/MiA GRkgXaZeaE7PDSu91/0QbrUFvdmlJqwwAsnzWxL5Zukzm4tVHYYk/tgyGbZcqfTm2M3z Kw6gS3y+XrKAA73rjQHtcKygRVTzabGnSPmmjgfK7vIkJfnh550Vnej7B6B5bHR4fdds Nld/lXsZhYajRU1a0HzJqrOedb2iY36iA8XjsqbifsXFf96lUSzGNMRwFvSWnGFbXLFS gfcw== X-Gm-Message-State: AFeK/H13/bg8AOCHEPJw2dwPN07LB08lMbOBnDnXxoRxuF66Qks+uAHuYJXIK6k7TSIS5A== X-Received: by 10.223.153.228 with SMTP id y91mr25390951wrb.81.1490717591274; Tue, 28 Mar 2017 09:13:11 -0700 (PDT) Received: from E107787-LIN ([194.214.185.158]) by smtp.gmail.com with ESMTPSA id t68sm69271wrc.55.2017.03.28.09.13.09 (version=TLS1_2 cipher=AES128-SHA bits=128/128); Tue, 28 Mar 2017 09:13:10 -0700 (PDT) From: Yao Qi To: Pedro Alves Cc: Alan Hayward , "gdb-patches\@sourceware.org" , nd Subject: Re: extract_unsigned_integer API (Re: [PATCH] Remove MAX_REGISTER_SIZE from frame.c) References: <86lgspqisk.fsf@gmail.com> <5f2f0cb0-6265-46aa-4ad6-eda5ba817da4@redhat.com> Date: Tue, 28 Mar 2017 16:13:00 -0000 In-Reply-To: <5f2f0cb0-6265-46aa-4ad6-eda5ba817da4@redhat.com> (Pedro Alves's message of "Tue, 28 Mar 2017 15:08:51 +0100") Message-ID: <8660itnzvv.fsf@gmail.com> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-IsSubscribed: yes X-SW-Source: 2017-03/txt/msg00489.txt.bz2 Pedro Alves writes: > class extractor > { > public: > extractor () =3D default; > > // Get buffer. Could take a "size" parameter too, > // for pre-validation instead of passing "size" to "extract". > // Or make that a separate size() method. Or add a "size" parameter > // to the ctor and validate there. Whatever. The lambda-based > // solution isn't validating upfront either. My lambda-based solution does validate the boundary before reading contents to buffer, +ULONGEST +extract_unsigned_integer (gdb::function_view content_provider, + int len, enum bfd_endian byte_order) +{ + if (len > (int) sizeof (ULONGEST)) + error (_("\ +That operation is not available on integers of more than %d bytes."), + (int) sizeof (ULONGEST)); + + gdb_byte buf[sizeof (ULONGEST)]; + + content_provider (buf, len); + return extract_unsigned_integer_1 (buf, len, byte_order); +} > > extractor extr; > frame_unwind_register (frame, regnum, ext.buffer ()); We may overflow ext.buffer (), because the boundary checking is done in .extract below, > return extr.extract (size, byte_order); > > Instead of: > > return extract_unsigned_integer ([&] (gdb_byte *buf, size_t size) > { > frame_unwind_register (frame, regnum, buf); > }, size, byte_order); --=20 Yao (=E9=BD=90=E5=B0=A7)