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 7A7C742B19; Tue, 16 May 2023 01:20:36 +0200 (CEST) Received: from mails.dpdk.org (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 14A3740A7A; Tue, 16 May 2023 01:20:36 +0200 (CEST) Received: from mail-pf1-f182.google.com (mail-pf1-f182.google.com [209.85.210.182]) by mails.dpdk.org (Postfix) with ESMTP id F1B484068E for ; Tue, 16 May 2023 01:20:34 +0200 (CEST) Received: by mail-pf1-f182.google.com with SMTP id d2e1a72fcca58-644d9bf05b7so7701556b3a.3 for ; Mon, 15 May 2023 16:20:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=networkplumber-org.20221208.gappssmtp.com; s=20221208; t=1684192834; x=1686784834; 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=VmLSbaJ1CmlLefQp/QGSiF67hYIEY8Lxvs8RilveGzU=; b=0SJ93oj7IjaKYFGQkEvhhJu3lAqW58MXGOyuoFj9Geod/dxTTa7RlrT5HtWKKYqttz Kdd/UXQfMqcr2ypTmeOwfPlugzgioTsPVWIeSFNZaqnzZI73eiQM5P0KpGsCO55bQ998 TAuhNBiqPyF4DTNilTKZtM1Lh+0Rlaxh+1UMeV7FZpZc5X/v/8m7LlreubVbKRlSsvyT yc/htoj3IsjPZ4ITGwtPUQjuv4PFOWGb7VMjLnfOdWa0Xop7hrB5lIkqAuwdRocSPisu iG0jAEoZYMwtvDB/LETaei7F1qS39UtzKmOU/Sx9FIfs4oPD2/kl9Miypz5kScI+8BE6 xlPQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1684192834; x=1686784834; 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=VmLSbaJ1CmlLefQp/QGSiF67hYIEY8Lxvs8RilveGzU=; b=ImhZboupjOA2Ry6ipKst9UVbVran+JG0E5dOxyF8Nv5u8/eYHQN6WUuTtxshF1O1+D +3qvJKy9JWKGgmqzGQiteKdQf34Fa3y2NE1M/+7kl6S5h9gCLVkBkhjG92JlxdEIRXXr wehW49jXwavHFYJGU1gYOeXUb0VgiAvDiUoXzubTHT9/hGuq/q2LLS9CFuu1deS8MTvM ieEl6Kh8FaVdew0rt9ONr+DKeQ/d1ycHhlvHoMjd8+9aO2dKzEexpDaaBCWEvMLVw7Tq fFNAn2oGoFkFkkZmyEnQmRpR9eV2I2klp1tkmVZxjuz4wJrR/Zq6iPf57puR+B94IcL9 O89Q== X-Gm-Message-State: AC+VfDyYHQ3eiKw/aMEMj9Z7sZ7c3ObOJcINIwi4eO4Q7KQkL60W/DNF H60O8Cs/xHVhyUU2iIOi+yfaMw== X-Google-Smtp-Source: ACHHUZ5iv2EuLRAFwsQmp5XMihoVGBNLk1bXj8f9nst7sduW6JNJXXYGJQAn+XX8rdo9VWXbjPMwDg== X-Received: by 2002:aa7:888c:0:b0:63b:859f:f094 with SMTP id z12-20020aa7888c000000b0063b859ff094mr47792721pfe.20.1684192834023; Mon, 15 May 2023 16:20:34 -0700 (PDT) Received: from hermes.local (204-195-120-218.wavecable.com. [204.195.120.218]) by smtp.gmail.com with ESMTPSA id f8-20020a631008000000b004fab4455748sm12171161pgl.75.2023.05.15.16.20.33 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 15 May 2023 16:20:33 -0700 (PDT) Date: Mon, 15 May 2023 16:20:32 -0700 From: Stephen Hemminger To: Ferruh Yigit Cc: David Christensen , dev@dpdk.org, stable@dpdk.org Subject: Re: [PATCH v2] net/tap: resolve stringop-overflow with gcc 12 on ppc64le Message-ID: <20230515162032.36a4f3ec@hermes.local> In-Reply-To: <165a233b-b41b-3a65-1866-5b7c94993b40@amd.com> References: <20230322212439.524725-1-drc@linux.vnet.ibm.com> <20230323170145.129901-1-drc@linux.vnet.ibm.com> <165a233b-b41b-3a65-1866-5b7c94993b40@amd.com> MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit 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 Tue, 16 May 2023 00:14:52 +0100 Ferruh Yigit wrote: > Hi David, > > I confirm the build error, btw it helps to future references to put > build failure to the commit log, > > and change is reasonable to convert PMD local parse function to an API, > BUT my concern is they don't behave exactly same, which changes user > interface of the driver. > > The 'rte_ether_unformat_addr()' API expects exact "XX:XX:XX:XX:XX:XX or > XXXX:XXXX:XXXX" format. > Like 'parse_user_mac()' accepts 'a:a:a:a:a:a' as input, but API requires > '0A:0A:0A:0A:0A:0A'. > > This is a small change but still may create a bad experience if an > existing user/script hit by this, and I believe we don't have a strong > reason to change the interface. > > > To keep behavior same, we can either update 'rte_ether_unformat_addr()' > to accept singe chars between ':', > or fix the existing 'parse_user_mac()' for compiler warning, what do you > think? This is the kind of change where a simple release note will suffice. Not sure if anyone beyond some test script would ever use this anyway.