Received: by 2002:a05:6a10:413:0:0:0:0 with SMTP id 19csp2232322pxp; Mon, 21 Mar 2022 14:29:57 -0700 (PDT) X-Google-Smtp-Source: ABdhPJzBm7dKYefW0eEJe9Aqv0QnbdZBGi3sfDdKgtOKqAUrAtBNstZ3bu3eaUaRJYJ/kanyNML/ X-Received: by 2002:a65:4681:0:b0:382:b4f5:84c2 with SMTP id h1-20020a654681000000b00382b4f584c2mr1596309pgr.218.1647898196973; Mon, 21 Mar 2022 14:29:56 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1647898196; cv=none; d=google.com; s=arc-20160816; b=CBnGnQxawN1tlAUyAOLyj8gZdR1gE7NlFJmco2G60scFqfHPXHE/JiOLS+boDXjyX5 1W4OXN/xXLx4MoyWI7tQptPutdU9WFup2me8sbQvz4ngqF5lJVRy5f0/TJrgjL4+XAK8 +IpoUjI9pXsQO9mxGRQRBsEVFmG1UevYVtEVvhZusj9NhYUJctR0d7I5cp6zvrXS3FRs Ei7oVAQjOqJYXrAjhh3bWAG+LVJeegL6Pz8HsN2Cpww87/fkba1U/efJhUw8XqbdK5mC uw6wEQfd75XhzbLLvnMVgAvedaa8crhVuKcqW3vqqXxdQlOr0ocYeAXtqfW/hD8nSFbp AnaA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:in-reply-to:subject :from:references:cc:to:content-language:user-agent:mime-version:date :message-id:dkim-signature; bh=RGOAtpOZE/CBeNDkBW8Z9V1EmSgZp+b5sYBDM51bsh4=; b=fIVg5D1QVBx80dLmw2ZS2Lk8CMyC+WbZnd2h6Ogvrcbeo8r8N+dEeh6aGXm46uz/Wb ZgXDe/RCFOfyLramQ5MRLIUaSAAKYQ7b7zJuw4G/RKeQIjZrOp27e59zSrgEfVs7EPjk TpaOX+PrFloW1D2SZ3vlnS3Nn4Ly2giqQiXSjZGZVqaFPpKBxGqhW6AfbTqZMwycXYkY paHHN3PLwqCXwzM2m1n4FNax/7nBx7mMffQ4awpzzvtDRhm/2cXJb8GrN9Eg1yhIGNx1 xQ7OfzP2r7AGk/V7ZdUUYFqecLgua8yx69TEdC7fd2pkT+N2j1yE2MrMP2gcaQ5cNY7a M4GA== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@gnuweeb.org header.s=default header.b=R70bbJOb; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=gnuweeb.org Return-Path: Received: from lindbergh.monkeyblade.net (lindbergh.monkeyblade.net. [2620:137:e000::1:18]) by mx.google.com with ESMTPS id ot4-20020a17090b3b4400b001c6b47837e0si314861pjb.157.2022.03.21.14.29.56 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 21 Mar 2022 14:29:56 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:18 as permitted sender) client-ip=2620:137:e000::1:18; Authentication-Results: mx.google.com; dkim=pass header.i=@gnuweeb.org header.s=default header.b=R70bbJOb; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=gnuweeb.org Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by lindbergh.monkeyblade.net (Postfix) with ESMTP id E54904BBAE; Mon, 21 Mar 2022 14:09:46 -0700 (PDT) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1346789AbiCULiJ (ORCPT + 99 others); Mon, 21 Mar 2022 07:38:09 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:55224 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S234145AbiCULiI (ORCPT ); Mon, 21 Mar 2022 07:38:08 -0400 Received: from gnuweeb.org (gnuweeb.org [51.81.211.47]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 93D38B2478 for ; Mon, 21 Mar 2022 04:36:43 -0700 (PDT) Received: from [192.168.12.80] (unknown [182.2.38.58]) by gnuweeb.org (Postfix) with ESMTPSA id E22227E2DA; Mon, 21 Mar 2022 11:36:40 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=gnuweeb.org; s=default; t=1647862603; bh=shXz+PPwGv/jCiUSvqesE15IVm1U37j4KlhDNrdLfUQ=; h=Date:To:Cc:References:From:Subject:In-Reply-To:From; b=R70bbJObaaNyygAkbHkYtcBndeLDF77NhHVi1QDM8QlNyL/sOqXPzGz1MYEt20DKv SIqb3bD+Xc+oaMvTvsoNPSswy6h96MATz1kFBRmy3tfT4kCjWs0zsr8853KdzkrK8T TDEZrBnSIQfwi7MI/DscH0LwhbYuyd4OvDxuqpggNJejbysoTpZfZ+gUKYGYsEqXC0 PQS5EsXSFypTbNqMHzUYgUV85GOep3mApWeF58SB3e2QvsWLFdIvyYgcBzO4DrjObC wKUVbFZaONWzpaKU9twK2catacPghOhzJsdxP9n8h4/l8scVJqye9PbMvgM8Gua2Gn oLbxbIZ66WF0Q== Message-ID: Date: Mon, 21 Mar 2022 18:36:37 +0700 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Thunderbird/91.5.0 Content-Language: en-US To: Willy Tarreau Cc: "Paul E. McKenney" , Alviro Iskandar Setiawan , Nugraha , Linux Kernel Mailing List , GNU/Weeb Mailing List References: <20220320093750.159991-1-ammarfaizi2@gnuweeb.org> <20220320093750.159991-7-ammarfaizi2@gnuweeb.org> <20220321075308.GD29580@1wt.eu> From: Ammar Faizi Subject: Re: [RFC PATCH v1 6/6] tools/include/string: Implement `strdup()` and `strndup()` In-Reply-To: <20220321075308.GD29580@1wt.eu> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-2.0 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,NICE_REPLY_A,RDNS_NONE,SPF_HELO_NONE, T_SCC_BODY_TEXT_LINE autolearn=no autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 3/21/22 2:53 PM, Willy Tarreau wrote: > Hi Ammar, [...] >> +static void free(void *ptr); >> +static void *malloc(size_t len); >> +static void *realloc(void *old_ptr, size_t new_size); > > Better include the required h files here. I can't do that, in nolibc.h, we have something like this: ``` #include "stdlib.h" <--- We inlcude string.h from here #include "string.h" <--- This is a no-op. ``` Note, stdlib.h is included first before string.h, next, in stdlib.h, we have this: ``` #include "string.h" // malloc, calloc, free here ``` If I include "stdlib.h" in "string.h", it will just be a no-op, and the declarations will not be taken, because the declarations happen after #include "string.h". So it doesn't work. It's somewhat circular dependency. stdlib.h needs string.h string.h needs stdlib.h One of them must fully see the other before they can use the defined functions in another header. Suggestion welcome... I am thinking of creating a new header just for the forward declarations where all function declarations live there, we just split off the real functions' body. [...] > > This version is suboptimal in terms of code size, CPU usage and memory > usage. And it even seems it contains a buffer overflow: if the string > is exactly a multiple of 2048, it seems to me that you'll write the > trailing zero past the end. Please instead use the more intuitive form > below (not tested but you get the idea): > > size_t len = strlen(str); > char *ret = malloc(len + 1); > if (ret) > memcpy(ret, str, len); > return ret; Ah right, that's indeed overflow. Will fold this in as you suggested. [...] > Here it can cost quite a lot for large values of maxlen. Please just use > a variant of the proposal above like this one: > > size_t len; > char *ret; > > len = strlen(str); > if (len > maxlen) > len = maxlen; > ret = malloc(len + 1); > if (ret) > memcpy(ret, str, len); > return ret; Will take the Alviro's suggestion for this part... -- Ammar Faizi