When we offer startswith() and endswith() functions for plain unibyte C strings,
we need to do the same with multibyte strings as well. Done as follows:
2025-01-03 Bruno Haible
doc: Mention the new modules.
* doc/strings.texi (Comparison of string APIs): Add rows for startswit
Hi Bruno,
Bruno Haible via Gnulib discussion list writes:
> I'm not opposed to using 'bool'. But when I saw that no function in
> gnulib's , , or , so far uses 'bool',
> it made me hesitate.
>
> Should we break the "tradition" here to use 'int' for a Boolean value,
> and actually use 'bool' for
Bruno Haible via Gnulib discussion list writes:
>> * What happens when strings contain encoding errors? It's not clear from
>> the spec. I hope behavior isn't simply undefined.
>
> When the str_* functions are used, the byte-wise encoding will matter.
> When the mbiter primitives are used, recal
On 2025-01-03 05:09, Bruno Haible via Gnulib discussion list wrote:
When we offer startswith() and endswith() functions for plain unibyte C strings,
we need to do the same with multibyte strings as well.
Some comments:
* The comments in string.in.h should be imperative sentences. E.g., say
"R
Paul Eggert wrote:
> * The comments in string.in.h should be imperative sentences. E.g., say
> "Return true if ..." not "Returns true if ...". Doing it this way is a
> bit briefer and is more likely to result in valid English sentences.
You know that I disagree with that.
The style that I am us
Paul Eggert wrote:
> * These functions return int 1 or 0. Why not bool? Are you thinking of
> extending them later? If not, bool seems like the way to go.
I'm not opposed to using 'bool'. But when I saw that no function in
gnulib's , , or , so far uses 'bool',
it made me hesitate.
Should we brea
For many years, I know about the Java functions String.startsWith and
String.endsWith and how easy they are to use, compared to the 3-argument
strncmp. And nevertheless I thought that in C, we are all expert programmers,
we don't need one-liner abstractions.
And now I see that six years ago, I wro
As for the existing PO files... I cannot simply change the license
line, even when it is incoherent.
But you could write mails to the translation teams, asking them to resubmit
As in my opinion things are fine as they are, I'm not going to
send such an email. But you are welcome to send on
Paul Eggert wrote:
> I'm more familiar with the longstanding tradition of Emacs, where the
> manual says "This function returns X." and the doc strings (which is
> closer to what we're talking about here) say "Return X." In both cases
> English-language sentences are used.
>
> Of course other s
On 2025-01-03 13:09, Bruno Haible wrote:
Should we break the "tradition" here to use 'int' for a Boolean value,
and actually use 'bool' for the first time in ?
I would prefer it, if it's a boolean function.
I don't know what to do about it. Generate an 'info' file with a
page width of 100 in
On 2025-01-03 13:09, Bruno Haible wrote:
Paul Eggert wrote:
* The comments in string.in.h should be imperative sentences. E.g., say
"Return true if ..." not "Returns true if ...". Doing it this way is a
bit briefer and is more likely to result in valid English sentences.
You know that I disagre
On Fri, Jan 3, 2025 at 8:04 PM Bruno Haible via Gnulib discussion list
wrote:
>
> Paul Eggert wrote:
> > I'm more familiar with the longstanding tradition of Emacs, where the
> > manual says "This function returns X." and the doc strings (which is
> > closer to what we're talking about here) say "
12 matches
Mail list logo