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

Groups > comp.std.c > #6491

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

Show all headers | View raw

Jakob Bohm <jb-usenet@wisemo.com.invalid> writes:
> On 2023-06-02 07:18, Keith Thompson wrote:
>> 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.)
>> 
>
> Would the ability of the (new) generic mechanism to choose among a
> short prioritized list of types, combined with a rule that all the
> argument promotion rules continue to apply to the selection solve the
> conundrum?
> This is what typically happens with C++ overloads done for the same
> purposes.

I don't think so.

Generic selections (_Generic) have been in the language since C11.  The
issue is that the argument promotion rules do *not* apply.  C23 adds a
new use for them for several functions declared in <string.h>.  (And the
corresponding functions in <wchar.h>; I had forgotten about those.)

> So if the generic declaration gives the priority list [char*, const
> char* ], then non-const pointers compatible with char* formal argument
> types will get selected first and return a non-const char*, while other
> pointers compatbile with const char* formal arguments will be selected
> second and return a const char*.  This would even work if the generic
> declaration also covered the wchar_t and related types, omitting
> whichever of UTF-16/UCS-4 is equivalent to the implementation defined
> wchar_t* .

The str*() generic functions can be handled by accepting:
    char*       // selects function returning char*
    const char* // selects function returning const char*
    void*       // selects function returning char*
    const void* // selects function returning const char*

For memchr(), which currently takes an argument of type const
void*, I don't think there's any way for the new generic function
to accept arguments of all pointer-to-[const]-object types (without
adding a new language mechanism, which isn't practical this late
in the process).  It would be possible to accept pointers to char,
signed char, and unsigned char as well as pointers to void, which
might handle most of the existing cases, but it might be cleaner
just to require a pointer to void (which could break some existing
valid code).

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