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 E25D7A034F; Tue, 23 Feb 2021 22:53:19 +0100 (CET) Received: from [217.70.189.124] (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 9932340FDF; Tue, 23 Feb 2021 22:53:19 +0100 (CET) Received: from mail-wr1-f47.google.com (mail-wr1-f47.google.com [209.85.221.47]) by mails.dpdk.org (Postfix) with ESMTP id A83A5188763 for ; Tue, 23 Feb 2021 22:53:18 +0100 (CET) Received: by mail-wr1-f47.google.com with SMTP id y17so2513508wrs.12 for ; Tue, 23 Feb 2021 13:53:18 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mayadata-io.20150623.gappssmtp.com; s=20150623; h=from:subject:to:cc:references:message-id:date:user-agent :mime-version:in-reply-to:content-transfer-encoding:content-language; bh=OjknkJt5jvHpuPHVnaj+wi/NataCUVvSHMJ78Vhkes8=; b=zOBbm49t74ZWtq46/TJEDrSxq8Mmo13yzLTHpx4V/44+BH/+XgTWw3g24AOKstiI6j W4QjXMuBXh7W/4sm0p8eyjk6fXoOMslvWQEXuEf8LzGNNoiGH/+bf2kP0zsFJcyy6ep8 apfyHZXqFh0xqAWTqwv/Pgp9BL12iIy9Ic9i4zn6rMlxh3vLkWa2bPG2Ol4JKqTs6B5j ufCpwEkGZt/G+6SxtbGJrImdDCkXigxR3FmmJra8n3LhJH9GMrs77TRg6FjjXcKXX79q /wRw8HE7G0QufV1I4BtJcOgI/ZEfTs/ZznCOEaOhhPGBED6eH8sKe4RPYmZvk5Sg5e/1 k0NA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:subject:to:cc:references:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding :content-language; bh=OjknkJt5jvHpuPHVnaj+wi/NataCUVvSHMJ78Vhkes8=; b=fovtI+aHSBhRjPtL7qkZtFj2RR+9lt+MRbQoBxqGE1R6MU7Te8KFKWTssaEr6gUhtF LsvG2dp7c/ZWGiHEGw6RK6pI4s/A+uxBDDUDIQ4yHOTc3wZpWja2auJR2CTq7eF3r+OZ i1/Mqr7Kw5ZO0F9242jzT3449705hKmoxiyS7C6QJvjndCQ6x8URAr/kE87ta1UE65hw vcdqk7Ven8tcyLzUYaoRsDgLyszovchkPuLCeu4bHc7i3pu7t7S/YdAfnSHwOG7GvYmw 7tG4sjLmJf+mgwcRJ0Pn7OpyiTo3AGJXUWI2L4ahLacsEYjp4PK9pzRl8H5HYpyby98F GEuQ== X-Gm-Message-State: AOAM533+k/IFSaFSVidinRno8bCJ9CxtKqP+hxTWWTfOUBVl5MdKX4YB g9cwu3DL/TN0Vd0XOmXBIo+dzw== X-Google-Smtp-Source: ABdhPJx3AK5BIIqczyGljidgMqh9nzjFrrrQY6cS6nCxJuhcEYibiydnr8AmrJDHs1QgCWxOoQQaqw== X-Received: by 2002:adf:b345:: with SMTP id k5mr4073506wrd.14.1614117198399; Tue, 23 Feb 2021 13:53:18 -0800 (PST) Received: from [192.168.0.33] (cpc98320-croy25-2-0-cust77.19-2.cable.virginm.net. [80.235.134.78]) by smtp.gmail.com with ESMTPSA id w13sm62834wrt.49.2021.02.23.13.53.17 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 23 Feb 2021 13:53:17 -0800 (PST) From: Nick Connolly X-Google-Original-From: Nick Connolly To: Andrew Rybchenko , Dmitry Kozlyuk , dev@dpdk.org Cc: Tal Shnaiderman , Jerin Jacob , Sunil Kumar Kori References: <20210221012831.14643-1-dmitry.kozliuk@gmail.com> <20210221142819.6769-1-dmitry.kozliuk@gmail.com> <20210221142819.6769-2-dmitry.kozliuk@gmail.com> Message-ID: <1f95cbbf-2f89-f716-1087-0b02985d4d39@mayadata.io> Date: Tue, 23 Feb 2021 21:53:15 +0000 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.7.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-GB Subject: Re: [dpdk-dev] [PATCH v3 1/7] eal: add wrappers for POSIX string functions 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 Sender: "dev" > Allocating memory using rte_strdup() I'd use rte_free() > to release it. I guess it will fail badly. > So, I think that a different, more specific prefix is > required for POSIX wrappers. Andrew: my understanding of Bruce's proposal is that the strdup() name will now be kept (in this case through an inline definition), so I think this will be ok.  However, your comment reminded me of something else that it's probably worth mentioning as an aside: As a general guideline on Windows, memory allocated within a shared library is best freed within the same DLL to ensure it goes back to the correct heap.  So we'd want to avoid calling strdup and then returning the value to the application for it to free (hopefully this doesn't happen). With an inline definition there's no change in behaviour, but adding rte_strdup (or anything else that calls malloc) into librte_eal might be an issue. Regards, Nick