From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from dpdk.org (dpdk.org [92.243.14.124]) by inbox.dpdk.org (Postfix) with ESMTP id 7D6ADA0471 for ; Thu, 18 Jul 2019 20:30:04 +0200 (CEST) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id 7C8521041; Thu, 18 Jul 2019 20:30:02 +0200 (CEST) Received: from mail-pg1-f194.google.com (mail-pg1-f194.google.com [209.85.215.194]) by dpdk.org (Postfix) with ESMTP id 1F6DA23D for ; Thu, 18 Jul 2019 20:29:59 +0200 (CEST) Received: by mail-pg1-f194.google.com with SMTP id w10so13271400pgj.7 for ; Thu, 18 Jul 2019 11:29:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=networkplumber-org.20150623.gappssmtp.com; s=20150623; h=date:from:to:cc:subject:message-id:in-reply-to:references :mime-version:content-transfer-encoding; bh=cr2Nwe8oYsPObj+FC3Sa1bcc/+VgmMYPHaoW5Vitob8=; b=pt/eXThlsr76uarhDvs9thO2K0H6rlgUpWJIxnQe8x4yIzKe1igD2nt14uKc0nyy+V wwp7IE1DAINeC5LIIlz6NWOBB1JgQcG94biEyeJLcpq8ixavY1n8OE0/OE72dG1+Qg+B g5lTOcMQhpc2jkaCu8fKc/oVyFENRN4nZ9KTCNvwQuerZ+xVgTTay1VrBdURLQjYU3Ly 1eUr1AmoJ5Lk35bOXKd5QyQCZ+fBNk/L+2KK+I3cnrg64KjtmveNP2saQp3ih4cj+Ot7 InBE802imR0uDf5x6JGLMFXtSWENqEl8xQrKxcX1cuaMfNki/U0za9P5SvNcJS3uXU9Y v/Vg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:in-reply-to :references:mime-version:content-transfer-encoding; bh=cr2Nwe8oYsPObj+FC3Sa1bcc/+VgmMYPHaoW5Vitob8=; b=GngZCHVvOt2IIdCcm6fMlccCjLd0xXbE1t1uwBCd9efCe34kJIulUk9Lrs8fzPQOcc Jde8/qSrXr1nMBPpFW1eWTaVcJNZ+zWGSydMtZQsO7eh6xpyzHCQ+rWQ6+OwOG2Amw5F X+8IhrJQ1o2dt/ddaCluluyKgN3A8m+K5WglPA+V1UYuCE1LoGTp5qUiYwHFuBrydNXD +uvSmBx/Pwpw/KFmcyvyWQOtvtUO8p1UCeVF0jA7UqcQVnxo9aHzZ754KPR+yFlOQMpF pl2Z9gvPrg23FO76agFgX18qnrg5WH3vade4oNcCpUtwDQdGGIUzw0eRsVK0/47P+SMS XOrw== X-Gm-Message-State: APjAAAUiugivBxYzf97GxEdMxpQ9MWHvsHE5oBb/S64GATiNbVwsqD3w +WN3y0TR5d2OuRPUhluyBDmxeVDU X-Google-Smtp-Source: APXvYqxTxQy21KsBPUWDh9YxfkwjFvH3DoUGFVof7qzFMR7hhGILxTHAL4ldrlrVdGvA6YmUoG9oJQ== X-Received: by 2002:a17:90a:c20e:: with SMTP id e14mr9805317pjt.0.1563474598960; Thu, 18 Jul 2019 11:29:58 -0700 (PDT) Received: from xps13 ([67.23.203.6]) by smtp.gmail.com with ESMTPSA id m4sm54608722pff.108.2019.07.18.11.29.58 (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256); Thu, 18 Jul 2019 11:29:58 -0700 (PDT) Date: Thu, 18 Jul 2019 11:29:57 -0700 From: Stephen Hemminger To: Olivier Matz Cc: dev@dpdk.org Message-ID: <20190718112957.3f7c5c73@xps13> In-Reply-To: <20190718074703.7mjsnliicnx5eexq@platinum> References: <20190717184945.4025-1-stephen@networkplumber.org> <20190718074703.7mjsnliicnx5eexq@platinum> MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Subject: Re: [dpdk-dev] [RFC] net: be more restrictive in ether_unformat_addr X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DPDK patches and discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dev-bounces@dpdk.org Sender: "dev" On Thu, 18 Jul 2019 09:47:03 +0200 Olivier Matz wrote: > Hi, > > I'm fine with a more strict version like you proposed here. I checked > that the cmdline tests pass. > > Few minor comments below. > > On Wed, Jul 17, 2019 at 11:49:45AM -0700, Stephen Hemminger wrote: > > The current code acts more like BSD ether_aton and allows leading zeros > > which breaks the cmdline tests. > > > > Change the code to be more restrictive and only allow the fully > > expanded standard formats. > > > > Fixes: 596d31092d32 ("net: add function to convert string to ethernet address") > > Signed-off-by: Stephen Hemminger > > Can you add the bugzilla id ? > https://bugs.dpdk.org/show_bug.cgi?id=324 Sure, will do. I wish there was a one week delay during development and reserve Bugzilla for stuff in released code. > > + for (i = 0; i < RTE_ETHER_ADDR_LEN; i++) { > > + int8_t x; > > + > > + x = get_xdigit(*s++); > > + if (x < 0) > > + return false; > > + ea->addr_bytes[i] = x << 4; > > + x = get_xdigit(*s++); > > + if (x < 0) > > + return false; > > + ea->addr_bytes[i] |= x; > > Maybe we should say in the API doc that ether address can be modified > even if parsing fails. > No. Standard practice is that the state of returned data is undefined in any function that returns an error. > > - } else { > > - /* unknown format */ > > - rte_errno = EINVAL; > > + if (get_ether_addr6(s, ea) || get_ether_addr3(s, ea)) > > + return 0; > > + else { > > + rte_errno = -EINVAL; > > return -1; > > rte_errno should be positive Will fix.