Re: [bug-libunistring] Documentation error of u*_grapheme_{next, prev} APIs

[Kang-Che Sung]

On Sun, Feb 9, 2025 at 11:45 PM Bruno Haible <bruno@clisp.org> wrote:
>
> Kang-Che Sung wrote:
> > I think for a wider compiler compatibility, the `Generic` should be
> > done the other way around:
> >
> > ```
> > #define u8_grapheme_prev(s,start) \
> >       _Generic ((s), \
> >                 const uint8_t *: (const uint8_t *) u8_grapheme_prev
> > ((s), (start)), \
> >                 default  :                         u8_grapheme_prev
> > ((s), (start)))
> > ```
>
> That would be a no-op, because u8_grapheme_prev already returns a
> 'const uint8_t *'.
>
> Bruno
>

Let me clarify. I mean the u8_grapheme_prev function prototype could
adjust to returning `uint8_t *` (without const) for pre-C11 standard
mode, then in C11 and later standard, use the `_Generic` macro to
magically add the const cast.

That way the function prototypes would become this, achieving wider
compatibility:

```
/* C89 and C99 */
uint8_t * u8_grapheme_prev (const uint8_t *s, const uint8_t *start);

/* C11 and later standard, C++ (all versions) */
const uint8_t * u8_grapheme_prev (const uint8_t *s, const uint8_t *start);
uint8_t * u8_grapheme_prev (uint8_t *s, uint8_t *start);
```

The current version of u8_grapheme_prev prototype would require the
caller to manually cast away the const if they want to modify the
buffer manually.
This is not a bug on the library's side, but it would be inconvenient
to use for code targeting the C89 or C99 standard. (Manually casting
away the `const` for pointers can hide potential errors, thus some
style guides discourage that.)

On Sun, Feb 9, 2025 at 11:42 PM Bruno Haible <bruno@clisp.org> wrote:
>
> Kang-Che Sung wrote:
> > By the way, it's a little ironic, that the API designer didn't think
> > of returning `ptrdiff_t` or `size_t` (that is, returning in offsets
> > rather than direct addresses) and the whole issue would go away.
>
> That's what one would do in a language that does not have pointers,
> like Java or Python. But in C pointers are a very natural thing to use.

Perhaps the real reason is that the `strchr` function existed before
the ANSI C standard introduced `const` on data types.
(`strchr` in Research Unix 8th edition man page
https://man.cat-v.org/unix_8th/3/string )
When the C standards had the `const` on data types, it was too late to
change the existing uses of the `strchr` function.

And they had the non-const return type on `strchr` for compatibility
with existing code and as a compromise to the problem.

And the rest was history we both know.

That's it.