From: Ammar Faizi <[email protected]>
To: Willy Tarreau <[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 18:36:37 +0700 [thread overview]
Message-ID: <[email protected]> (raw)
In-Reply-To: <[email protected]>
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
next prev parent reply other threads:[~2022-03-21 11:36 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 [this message]
2022-03-21 11:43 ` Willy Tarreau
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