linux-kernel - Re: [RFC PATCH v1 6/6] tools/include/string: Implement `strdup()` and `strndup()`

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:   Mon, 21 Mar 2022 12:43:05 +0100
From:   Willy Tarreau <w@....eu>
To:     Ammar Faizi <ammarfaizi2@...weeb.org>
Cc:     "Paul E. McKenney" <paulmck@...nel.org>,
        Alviro Iskandar Setiawan <alviro.iskandar@...weeb.org>,
        Nugraha <richiisei@...il.com>,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
        GNU/Weeb Mailing List <gwml@...r.gnuweeb.org>
Subject: Re: [RFC PATCH v1 6/6] tools/include/string: Implement `strdup()`
 and `strndup()`

On Mon, Mar 21, 2022 at 06:36:37PM +0700, Ammar Faizi wrote:
> 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.

OK, usual stuff indeed.

> Suggestion welcome...

Then just leave it as-is.

> 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.

That's why I'm doing in my projects for the exact reason above. But
here we only have static functions so this will increase the burden to
contribute. Better wait for the situation to reach a point where we're
certain there will be some benefit in doing that.

Thanks,
Willy