Path: csiph.com!news.mixmin.net!eternal-september.org!news.eternal-september.org!.POSTED!not-for-mail From: Keith Thompson Newsgroups: comp.std.c Subject: Re: Can the new generic string functions accept void* arguments? Date: Fri, 02 Jun 2023 11:52:38 -0700 Organization: None to speak of Lines: 92 Message-ID: <874jnpg0i1.fsf@nosuchdomain.example.com> References: <87fs7afpcw.fsf@nosuchdomain.example.com> <87bkhyfnm7.fsf@nosuchdomain.example.com> MIME-Version: 1.0 Content-Type: text/plain Injection-Info: dont-email.me; posting-host="f8d848194142d7e3625a334b0a4a3860"; logging-data="3439260"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX1/Zp6jg0nJzS5oJZ8Uj5f67" User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/27.2 (gnu/linux) Cancel-Lock: sha1:G5KgBYsOCFC3FZipoHYyuq1ZJ50= sha1:WbfAOK5j8Cozdw7OLQl3QsDrjc0= Xref: csiph.com comp.std.c:6491 Jakob Bohm writes: > On 2023-06-02 07:18, Keith Thompson wrote: >> Keith Thompson 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 , 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 >> #include >> 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 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 . (And the corresponding functions in ; 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 */