From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: by dpdk.org (Postfix, from userid 33) id D2DF42E81; Tue, 2 Apr 2019 09:38:39 +0200 (CEST) From: bugzilla@dpdk.org To: dev@dpdk.org Date: Tue, 02 Apr 2019 07:38:39 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: new X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: DPDK X-Bugzilla-Component: other X-Bugzilla-Version: unspecified X-Bugzilla-Keywords: X-Bugzilla-Severity: enhancement X-Bugzilla-Who: david.marchand@redhat.com X-Bugzilla-Status: CONFIRMED X-Bugzilla-Resolution: X-Bugzilla-Priority: Low X-Bugzilla-Assigned-To: dev@dpdk.org X-Bugzilla-Target-Milestone: future X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: bug_id short_desc product version rep_platform op_sys bug_status bug_severity priority component assigned_to reporter target_milestone Message-ID: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: http://bugs.dpdk.org/ Auto-Submitted: auto-generated X-Auto-Response-Suppress: All MIME-Version: 1.0 Subject: [dpdk-dev] [Bug 238] [tree-wide] enhance getopt_long usage 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: , X-List-Received-Date: Tue, 02 Apr 2019 07:38:39 -0000 https://bugs.dpdk.org/show_bug.cgi?id=3D238 Bug ID: 238 Summary: [tree-wide] enhance getopt_long usage Product: DPDK Version: unspecified Hardware: All OS: All Status: CONFIRMED Severity: enhancement Priority: Low Component: other Assignee: dev@dpdk.org Reporter: david.marchand@redhat.com Target Milestone: future We have quite a couple of the following pattern in the apps and examples (quoting examples/fips_validation/main.c as a bad example): struct option lgopts[] =3D { {REQ_FILE_PATH_KEYWORD, required_argument, 0, 0}, {RSP_FILE_PATH_KEYWORD, required_argument, 0, 0}, {FOLDER_KEYWORD, no_argument, 0, 0}, {CRYPTODEV_KEYWORD, required_argument, 0, 0}, {CRYPTODEV_ID_KEYWORD, required_argument, 0, 0}, {CRYPTODEV_ST_KEYWORD, no_argument, 0, 0}, {CRYPTODEV_BK_ID_KEYWORD, required_argument, 0, 0}, {CRYPTODEV_BK_DIR_KEY, required_argument, 0, 0}, {NULL, 0, 0, 0} }; while ((opt =3D getopt_long(argc, argvopt, "s:", lgopts, &option_index)) !=3D EOF) { switch (opt) { case 0: if (strcmp(lgopts[option_index].name, REQ_FILE_PATH_KEYWORD) =3D=3D 0) env.req_path =3D optarg; else if (strcmp(lgopts[option_index].name, RSP_FILE_PATH_KEYWORD) =3D=3D 0) env.rsp_path =3D optarg; else if (strcmp(lgopts[option_index].name, FOLDER_KEYWORD) =3D=3D 0) env.is_path_folder =3D 1; else if (strcmp(lgopts[option_index].name, ... We can get rid of all those strcmp by directly binding each longopt with an= int enum. eal has been using this convention for quite some time, see: https://git.dpdk.org/dpdk/tree/lib/librte_eal/common/eal_options.h?h=3Dv19.= 02 https://git.dpdk.org/dpdk/tree/lib/librte_eal/common/eal_common_options.c?h= =3Dv19.02 --=20 You are receiving this mail because: You are the assignee for the bug.= From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from dpdk.org (dpdk.org [92.243.14.124]) by dpdk.space (Postfix) with ESMTP id C4C52A0679 for ; Tue, 2 Apr 2019 09:38:41 +0200 (CEST) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id 467BF2E81; Tue, 2 Apr 2019 09:38:41 +0200 (CEST) Received: by dpdk.org (Postfix, from userid 33) id D2DF42E81; Tue, 2 Apr 2019 09:38:39 +0200 (CEST) From: bugzilla@dpdk.org To: dev@dpdk.org Date: Tue, 02 Apr 2019 07:38:39 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: new X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: DPDK X-Bugzilla-Component: other X-Bugzilla-Version: unspecified X-Bugzilla-Keywords: X-Bugzilla-Severity: enhancement X-Bugzilla-Who: david.marchand@redhat.com X-Bugzilla-Status: CONFIRMED X-Bugzilla-Resolution: X-Bugzilla-Priority: Low X-Bugzilla-Assigned-To: dev@dpdk.org X-Bugzilla-Target-Milestone: future X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: bug_id short_desc product version rep_platform op_sys bug_status bug_severity priority component assigned_to reporter target_milestone Message-ID: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: http://bugs.dpdk.org/ Auto-Submitted: auto-generated X-Auto-Response-Suppress: All MIME-Version: 1.0 Subject: [dpdk-dev] [Bug 238] [tree-wide] enhance getopt_long usage 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" Message-ID: <20190402073839.gE6B1XeUQ4UPhITY1JyyF8m5A3C1aIDKGFAub76k0Ao@z> https://bugs.dpdk.org/show_bug.cgi?id=3D238 Bug ID: 238 Summary: [tree-wide] enhance getopt_long usage Product: DPDK Version: unspecified Hardware: All OS: All Status: CONFIRMED Severity: enhancement Priority: Low Component: other Assignee: dev@dpdk.org Reporter: david.marchand@redhat.com Target Milestone: future We have quite a couple of the following pattern in the apps and examples (quoting examples/fips_validation/main.c as a bad example): struct option lgopts[] =3D { {REQ_FILE_PATH_KEYWORD, required_argument, 0, 0}, {RSP_FILE_PATH_KEYWORD, required_argument, 0, 0}, {FOLDER_KEYWORD, no_argument, 0, 0}, {CRYPTODEV_KEYWORD, required_argument, 0, 0}, {CRYPTODEV_ID_KEYWORD, required_argument, 0, 0}, {CRYPTODEV_ST_KEYWORD, no_argument, 0, 0}, {CRYPTODEV_BK_ID_KEYWORD, required_argument, 0, 0}, {CRYPTODEV_BK_DIR_KEY, required_argument, 0, 0}, {NULL, 0, 0, 0} }; while ((opt =3D getopt_long(argc, argvopt, "s:", lgopts, &option_index)) !=3D EOF) { switch (opt) { case 0: if (strcmp(lgopts[option_index].name, REQ_FILE_PATH_KEYWORD) =3D=3D 0) env.req_path =3D optarg; else if (strcmp(lgopts[option_index].name, RSP_FILE_PATH_KEYWORD) =3D=3D 0) env.rsp_path =3D optarg; else if (strcmp(lgopts[option_index].name, FOLDER_KEYWORD) =3D=3D 0) env.is_path_folder =3D 1; else if (strcmp(lgopts[option_index].name, ... We can get rid of all those strcmp by directly binding each longopt with an= int enum. eal has been using this convention for quite some time, see: https://git.dpdk.org/dpdk/tree/lib/librte_eal/common/eal_options.h?h=3Dv19.= 02 https://git.dpdk.org/dpdk/tree/lib/librte_eal/common/eal_common_options.c?h= =3Dv19.02 --=20 You are receiving this mail because: You are the assignee for the bug.=