On Tue, Nov 21, 2023 at 4:33 AM Jie Hai <haij...@huawei.com> wrote: > > On 2023/11/15 23:08, Stephen Hemminger wrote: > > On Wed, 15 Nov 2023 12:27:37 +0100 > > Morten Brørup <m...@smartsharesystems.com> wrote: > > > >>>> just a final follow up, i can see that we already have a rte_strerror > >>>> here to do the replace with reentrant dance. it is probably good to > >>>> follow the already established pattern for this and have a > >>> rte_strtok. > >>> > >>> +1 for have rte_strtok which could cover different platform. > >> > >> +1 to rte_strtok doing the reentrant dance for us. > >> > >> If we had such an rte_strtok(), we could also generally disallow the use > >> of strtok(). > > > > Good idea, I like this. > > Would be good to have a version on Windows as well. > > > > . > Hi, all maintainers, > > Since the map of strtok_r to strtok_s with three patramaters has > been done in "rte_os_shim.h", I just include this file. > And the rte_strtok is defined as below. > My question is whether the > "strtok_s(s, stringlen, delim, save_ptr)" and > "strtok_s(str, delim, saveptr)" are compatible for C11. > > And I check the glibc codes here, > https://sourceware.org/git/glibc.git > there is no definition of strtok_s, is strtok_s not in use? > > If so, should we delayed processing for the C11 standard strtok_s > function? That is, delete the "#ifdef __STDC_LIB_EXT1__... > #endif" part, but keep the extension of the four parameters for later > use. Or keep the following change but never use stringlen as not null > until the function can be used. > > What do you think?
Regardless of how it is done internally, I would not inline this helper. This will minimise headaches with checks against toolchain/compiler support in a DPDK header. -- David Marchand
