Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.std.c > #6489

Re: Can the new generic string functions accept void* arguments?

Show all headers | View raw

Keith Thompson <Keith.S.Thompson+u@gmail.com> writes:
> The latest draft of the upcoming C23 standard is:
>     https://www.open-std.org/jtc1/sc22/wg14/www/docs/n3096.pdf
> It introduces several type-generic functions in <string.h>, replacing
> normal functions of the same names: memchr, strchr, strpbrk, strrchr,
> strstr.
>
> I'll use strchr() as an example; the same applies to the other str*()
> generic functions (but not to memchr()).
[...]

Just after I posted the above, I thought of a potential issue with
memchr() that just might affect real code.

In C17 and earlier, memchr() has this declaration:

    void *memchr(const void *s, int c, size_t n);

Given the implicit conversions between void* and other object pointer
types, the first argument can be a pointer to any const object type.
This is something that might plausibly be used in practice, unlike
(I think) passing a void pointer to the str*() functions.

It's probably impractical to fix this, since it would require
the generic selection to cover all possible object pointer types.
Any code that depends on the current behavior would have to add
(void*) or (const void*) casts to ensure that the type actually
matches.

For example, this (contrived) program is valid in C17 and earlier:

    #include <stdio.h>
    #include <string.h>
    int main(void) {
        const unsigned u = 0x12345678;
        printf("u = 0x%x", u);
        unsigned char *p = memchr(&u, 0x34, sizeof u);
        if (p != NULL) printf(", p points to 0x%x", *p);
        putchar('\n');
    }

The output is:

    u = 0x12345678, p points to 0x34

(Conceivably p might be a null pointer if unsigned int has padding
bits that cause 0x34 not to be stored in a single byte.)

A call to memchr with a char* argument is, I suspect, more likely to
appear in real code.

The underlying issue is that the implicit conversions that happen with
function arguments do not happen with operands of a generic selection.
(The generic functions in <tgmath.h> are defined in a way that this
isn't an issue, as far as I can tell.)

-- 
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
Will write code for food.
void Void(void) { Void(); } /* The recursive call of the void */

Back to comp.std.c | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll thread

Thread

Can the new generic string functions accept void* arguments? Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2023-06-01 21:41 -0700
  Re: Can the new generic string functions accept void* arguments? Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2023-06-01 22:18 -0700
    Re: Can the new generic string functions accept void* arguments? Jakob Bohm <jb-usenet@wisemo.com.invalid> - 2023-06-02 15:03 +0200
      Re: Can the new generic string functions accept void* arguments? Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2023-06-02 11:52 -0700
    Re: Can the new generic string functions accept void* arguments? Ben Bacarisse <ben.usenet@bsb.me.uk> - 2023-06-02 22:01 +0100
      Re: Can the new generic string functions accept void* arguments? Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2023-06-04 21:37 -0700
        Re: Can the new generic string functions accept void* arguments? Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2023-06-04 21:50 -0700
    Re: Can the new generic string functions accept void* arguments? Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2023-06-02 15:11 -0700

csiph-web