public inbox for [email protected]
 help / color / mirror / Atom feed
From: Willy Tarreau <[email protected]>
To: Ammar Faizi <[email protected]>
Cc: "Paul E. McKenney" <[email protected]>,
	Alviro Iskandar Setiawan <[email protected]>,
	Nugraha <[email protected]>,
	Linux Kernel Mailing List <[email protected]>,
	GNU/Weeb Mailing List <[email protected]>
Subject: Re: [RFC PATCH v1 6/6] tools/include/string: Implement `strdup()` and `strndup()`
Date: Mon, 21 Mar 2022 12:43:05 +0100	[thread overview]
Message-ID: <[email protected]> (raw)
In-Reply-To: <[email protected]>

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

      reply	other threads:[~2022-03-21 11:43 UTC|newest]

Thread overview: 29+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-03-20  9:37 [RFC PATCH v1 0/6] Add dynamic memory allocator support for nolibc Ammar Faizi
2022-03-20  9:37 ` [RFC PATCH v1 1/6] tools/nolibc: x86-64: Update System V ABI document link Ammar Faizi
2022-03-20  9:37 ` [RFC PATCH v1 2/6] tools/nolibc: Make the entry point not weak for clang Ammar Faizi
2022-03-20 19:16   ` Willy Tarreau
2022-03-21 11:38     ` Ammar Faizi
2022-03-21 17:27       ` Nick Desaulniers
2022-03-20  9:37 ` [RFC PATCH v1 3/6] tools/nolibc: i386: Implement syscall with 6 arguments Ammar Faizi
2022-03-20 10:33   ` Alviro Iskandar Setiawan
2022-03-20 10:42     ` Alviro Iskandar Setiawan
2022-03-20 15:09       ` Ammar Faizi
2022-03-20 13:10   ` David Laight
2022-03-20 14:01     ` Willy Tarreau
2022-03-20 15:04     ` Ammar Faizi
2022-03-20 18:22       ` David Laight
2022-03-20  9:37 ` [RFC PATCH v1 4/6] tools/nolibc/sys: Implement `mmap()` and `munmap()` Ammar Faizi
2022-03-20  9:37 ` [RFC PATCH v1 5/6] tools/nolibc/stdlib: Implement `malloc()`, `calloc()`, `realloc()` and `free()` Ammar Faizi
2022-03-20 15:50   ` Alviro Iskandar Setiawan
2022-03-20 16:10     ` Ammar Faizi
2022-03-20 16:16   ` Willy Tarreau
2022-03-20 16:36     ` Ammar Faizi
2022-03-20 16:46       ` Willy Tarreau
2022-03-20  9:37 ` [RFC PATCH v1 6/6] tools/include/string: Implement `strdup()` and `strndup()` Ammar Faizi
2022-03-20 15:55   ` Alviro Iskandar Setiawan
2022-03-20 16:10     ` Ammar Faizi
2022-03-21  7:53   ` Willy Tarreau
2022-03-21  8:16     ` Alviro Iskandar Setiawan
2022-03-21  8:51       ` Willy Tarreau
2022-03-21 11:36     ` Ammar Faizi
2022-03-21 11:43       ` Willy Tarreau [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    [email protected] \
    [email protected] \
    [email protected] \
    [email protected] \
    [email protected] \
    [email protected] \
    [email protected] \
    [email protected] \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox