From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mails.dpdk.org (mails.dpdk.org [217.70.189.124]) by inbox.dpdk.org (Postfix) with ESMTP id F160A440D9; Mon, 27 May 2024 01:32:35 +0200 (CEST) Received: from mails.dpdk.org (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 7EB9C402D4; Mon, 27 May 2024 01:32:35 +0200 (CEST) Received: from mail-pl1-f176.google.com (mail-pl1-f176.google.com [209.85.214.176]) by mails.dpdk.org (Postfix) with ESMTP id AB10A402AB for ; Mon, 27 May 2024 01:32:34 +0200 (CEST) Received: by mail-pl1-f176.google.com with SMTP id d9443c01a7336-1f47f0d8ec9so7021335ad.3 for ; Sun, 26 May 2024 16:32:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=networkplumber-org.20230601.gappssmtp.com; s=20230601; t=1716766353; x=1717371153; darn=dpdk.org; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:subject:cc:to:from:date:from:to:cc:subject:date :message-id:reply-to; bh=mKk5LUPtufsT+IglJ0lldstYTyB+5VMMfDmduRSqUzk=; b=KxqjEx52sWrHt2bbcLA9rGFG5EfREvPZHRrRrPPuePJtERhlvQqk+uzwCl0lZVfxAw YuWRuBDgP577M1RPs5fvwmpBr0FcTwM3TQ0oJeD0k0pJ3SmUZW3cqzprc+cz0nihXPWD 0/aw5wtEhQTPmLHr0Ata2GSB3cwgC/waS2lipcRd+msJS1YvrS3LwvP5LOCRsmJZOGfD 7K9IuW8b4WRZJcDbB23DDFNxoc1q2qxWwlSmSpTU5j1TvLNEQFyi2CDMKB+NHtv5aXmi nJcRUkjRg0vkD/Yj1eIIOl6rfdpLTOocB9l4tCBEpVyP+IUO/ARV5q8q+sRFIZ6biVYT /YGA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1716766353; x=1717371153; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:subject:cc:to:from:date:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=mKk5LUPtufsT+IglJ0lldstYTyB+5VMMfDmduRSqUzk=; b=uNcw7xIAkSZubVQnN09m9OjXST5j0vHWh42gfXKpPMqtApr9pGDRiRuzwy6ErP+rdk 8dBVx53CaIPOAOdLmAYFPGerB2ReZQWVOCjuDC5ZEDudXbaItgtqGp3Mn3nawaN1qZpo yFPZem4Sk9dnvaKl++cCHlnAAGapNvSXwupcE5Wr/r89wTY+fN0ER6kS9fJXG7IjnV3u rQWFesE+B1MF0Bv8CoTyU3MtbsvTo6gw1L5r7DcMV/ZRggZUnTQ8j8piFGjKXs5qD2BE KtRpB1IRIy3RFcyaQqQivCYEjbtPYSZm9nKnL4ZP39SDsB+T1+nMl9nAk98QIKgIs5GI iY9A== X-Gm-Message-State: AOJu0Yz59A1qY/ogC13K7ixq132Yc+qz9f2o0FEK/liOEVAz2m7tmVkd 8fUbAUWjy/mwTroQp6OvihG1OzMTxvRqcXY5ImIca4r95cxHTjqUstxep7WzY1EM2H0hRN0Cvfo e+z0= X-Google-Smtp-Source: AGHT+IGeKZU3R+mKfeDywk8k7N6vgqViXHyp8Mu2+XNMJw1AuaMgbjgfurcxQFK6uA715QqsPI3XCA== X-Received: by 2002:a17:902:d50b:b0:1f4:5911:198b with SMTP id d9443c01a7336-1f459111c52mr73265745ad.55.1716766353405; Sun, 26 May 2024 16:32:33 -0700 (PDT) Received: from hermes.local (204-195-96-226.wavecable.com. [204.195.96.226]) by smtp.gmail.com with ESMTPSA id d9443c01a7336-1f44c75b04bsm49446765ad.55.2024.05.26.16.32.32 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Sun, 26 May 2024 16:32:33 -0700 (PDT) Date: Sun, 26 May 2024 16:32:32 -0700 From: Stephen Hemminger To: Mattias =?UTF-8?B?UsO2bm5ibG9t?= Cc: dev@dpdk.org Subject: Re: [PATCH v5 00/32] replace use of rte_memcpy() with fixed size Message-ID: <20240526163232.171ca90d@hermes.local> In-Reply-To: References: <20240403163432.437275-1-stephen@networkplumber.org> <20240522033009.143100-1-stephen@networkplumber.org> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: DPDK patches and discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dev-bounces@dpdk.org On Sun, 26 May 2024 16:51:52 +0200 Mattias R=C3=B6nnblom wrote: > > This does not change the resulting binary on almost all architectures > > because x86 version of intrisics and glibc are the same, and > > other architectures were using __builtin_constant_p(). > >=20 > > The main benefit is that analysis tools like fortify, Coverity, and ASAN > > analyzers can check these memcpy's. A recent example is that > > on Ubuntu 22.04 detected undefined use of memcpy such as: > > memcpy(dst, NULL, 0) > > =20 >=20 > Would it be possible to instead have a build mode where rte_memcpy() is=20 > *always* delegating to memcpy(), and run these tools on that configuratio= n? >=20 > It seems easier to just always using rte_memcpy() in DPDK code, then let= =20 > the platform (not the programmer) choose whatever is most appropriate. I would prefer that rte_memcpy be laid to rest and go away. It never had a reason to be there.