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 CF99543DAB; Mon, 1 Apr 2024 21:34:14 +0200 (CEST) Received: from mails.dpdk.org (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 6C7E2402CD; Mon, 1 Apr 2024 21:34:14 +0200 (CEST) Received: from mail-pl1-f169.google.com (mail-pl1-f169.google.com [209.85.214.169]) by mails.dpdk.org (Postfix) with ESMTP id 3A0C24029F for ; Mon, 1 Apr 2024 21:34:12 +0200 (CEST) Received: by mail-pl1-f169.google.com with SMTP id d9443c01a7336-1e0fa980d55so34197075ad.3 for ; Mon, 01 Apr 2024 12:34:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=networkplumber-org.20230601.gappssmtp.com; s=20230601; t=1712000051; x=1712604851; 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=B2kdiY7ClZz9QutM666YLnYIwSioGJ6Triyv+X5a1Ao=; b=h1ALhynyRVBixwGPgn05n0i54q8drsxtDITtc4VOa3+rpdYMfkrflxqZKu5EosVkSS AOzOXsiFi1xl5hgGeCxATtiodfpPqsByjaCViTeMZZB06w5L2jG3e4RMmFlFe1KWd8SO KD1hgLydAhqmZh3RQD9bYXPD9KaSNX6JlLiy7TViO3ykL/NksET15igJf8Gugn8VYi0D 2KprJH4dJ6s5kk4QC6OeH/qwGJLnfSEd/yuoPWMV9p5mT3EV2/0ueVRd83uSLbbkRPrQ VH3t1yfhn3KrcUjoELswmpovr5JgaE92sYd6Ca00vmj4tCL44fI1meG2+tLV7jXGeDrN NGAg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1712000051; x=1712604851; 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=B2kdiY7ClZz9QutM666YLnYIwSioGJ6Triyv+X5a1Ao=; b=lylKkRkAeBua1iWP8pPPhr+NLUMLr4kxiR4cJgtpRUKse0fB3NQilVBYxd7I1lYN31 MABW0ASRBN6ryz3nnAXL3HOeJJ+eAq55hbHh7Ez98wW0dxTd21ogVe1CkDKx1rY8swnJ U6It8RBYKjOnTR0StLNIgaoC7iI4TyX4BaqNooqsuAET7cMPM7QpfzH411jjMo5eSYN/ /isnNvX1IhKm/S9gaALRTbJxEY8c/Ka6QmKNn9Ieu0od2aQT2nwcUyd3rD4I4CY2AkJd 9LGCHD9cSRsI4skeweZ68P+ddTSh42hncKfzegMCRq0Vo+hFWXj3S69lK59LBZH1GDz9 I7bg== X-Forwarded-Encrypted: i=1; AJvYcCVExdqUfLfHwMVw8B883AErl/uoHFLPiYjcz7n9Hdgfd6pMH/9Aug8MDV5yXvUIiFe5rXQs1unP7pXc96M= X-Gm-Message-State: AOJu0Yxg7JNnpS076Kk/azrZojY+/nFPvLF2H/fbuhRV9KYY/0gq/dgZ ouynVt1xOkkovlx9F5WaZPPwIJqt1NAkYf7+UqAHXiDWh2Y1SRZCWbbgI833FgY= X-Google-Smtp-Source: AGHT+IFH+sbF3iwrLFjpx8LmNcEoJAfot+xGAyQtDMQt1H/ahS9CPFPdYMUcmzXYqOwZp1LyQhyQhQ== X-Received: by 2002:a17:902:e0d1:b0:1e0:a7ca:42f8 with SMTP id e17-20020a170902e0d100b001e0a7ca42f8mr6429816pla.60.1712000050971; Mon, 01 Apr 2024 12:34:10 -0700 (PDT) Received: from hermes.local (204-195-123-203.wavecable.com. [204.195.123.203]) by smtp.gmail.com with ESMTPSA id cp12-20020a170902e78c00b001e2059a6386sm9326310plb.12.2024.04.01.12.34.10 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 01 Apr 2024 12:34:10 -0700 (PDT) Date: Mon, 1 Apr 2024 12:34:08 -0700 From: Stephen Hemminger To: Tyler Retzlaff Cc: bugzilla@dpdk.org, dev@dpdk.org Subject: Re: [DPDK/core Bug 1409] arparse library assumes enum are 64 bit Message-ID: <20240401123408.1c05958c@hermes.local> In-Reply-To: <20240401172014.GA5321@linuxonhyperv3.guj3yctzbm1etfxqx2vob5hsef.xx.internal.cloudapp.net> References: <20240401172014.GA5321@linuxonhyperv3.guj3yctzbm1etfxqx2vob5hsef.xx.internal.cloudapp.net> 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 Mon, 1 Apr 2024 10:20:14 -0700 Tyler Retzlaff wrote: > On Sat, Mar 30, 2024 at 02:58:41AM +0000, bugzilla@dpdk.org wrote: > > https://bugs.dpdk.org/show_bug.cgi?id=1409 > > > > Bug ID: 1409 > > Summary: arparse library assumes enum are 64 bit > > Product: DPDK > > Version: 24.03 > > Hardware: All > > OS: All > > Status: UNCONFIRMED > > Severity: normal > > Priority: Normal > > Component: core > > Assignee: dev@dpdk.org > > Reporter: stephen@networkplumber.org > > Target Milestone: --- > > > > MSVC correctly flags that this line in rte_argparse.h is incorrect: > > RTE_ARGPARSE_ARG_RESERVED_FIELD = RTE_GENMASK64(63, 48), > > > > The problem is that enum values are just an alias for int, and it can be 32 > > bits. > > > > Taken from the current C Standard (C99): > > http://www.open std.org/JTC1/SC22/WG14/www/docs/n1256.pdf > > > > 6.7.2.2 Enumeration specifiers > > [...] > > Constraints > > The expression that defines the value of an enumeration constant shall be an > > integer constant expression that has a value representable as an int. > > [...] > > Each enumerated type shall be compatible with char, a signed integer type, or > > an unsigned integer type. The choice of type is implementation-defined, but > > shall be capable of representing the values of all the members of the > > enumeration. > > > > Since rte_argparse only uses 10 bits now. The suggested fix here is to: > > 1. Assume 32 bits > > 2. Get rid of the reserved field - reserved fields are bad idea > > > > as some additional information i was aware of this issue and had already > discussing it internally with the visual studio engineers. we reviewed > relevant parts of C11 standard we believe there are 2 points of > interest. > > the C11 standard does appear to direct the implementation to select an > integer wide enough to hold the 64-bit enum value but it is only > reasonable to do so when the target has a native 64-bit type. i.e. if > your target has no 64-bit integer than the size of the above constant > expression will be truncated. > > the MSVC compiler requires an extra command line argument to provide > standard C conformant behavior (/Zc:enumTypes). when used with a C++ TU > MSVC does select a 64-bit type for the prescribed constant expression > but does not correctly select a 64-bit type with a C TU (this matters if > we are exposing this enum type in a public header consumed by C++) > > i'm in the process of requesting that /Zc:enumTypes be brought into > alignment with how it functions with C++ TU. > > * /Zc:enumTypes should result in "the same" type being selected for > C or C++ TU, whatever that type may be. > > * /Zc:enumTypes in a C TU should select a 64-bit integer type for the > above example value when the target supports 64-bit integer natively. > > as the current released compiler obviously does not conform to the above > we may apply a conditionally compiled workaround that declares a 64-bit > integer with an identifier matching the name of the un-scoped enum > value. All well and good, but the assumption of 64 bit enum's breaks on 32 bit builds which DPDK still has. The library didn't need the bits. Just deleting the unused reserved field and changing the shifts to be 32 fixes the issue.