And this patch makes sure that we apply the same logic also when a
line break was seen in the input string.
2024-09-15 Bruno Haible
unilbrk: Some more tweaks.
* lib/unilbrk/u8-possible-linebreaks.c (u8_possible_linebreaks_loop):
Assign to preceding_prop at each loop ro
On 2024-09-15 02:25, Bruno Haible wrote:
it can happen that you add the attribute in order to placate one GCC
version
and then another GCC version complains that you should not have added it.
Yes, and if memory serves older GCC versions were pretty bad about this,
and that caused me
This patch adds most test cases from Unicode.org's LineBreakTest.txt
to the gnulib tests. I wish I had done this earlier: I would have noticed
the several bugs that I fixed yesterday and today much earlier.
2024-09-15 Bruno Haible
unilbrk: Strengthen tests.
* lib/gen-uni-table
The unilbrk implementation does not implement the rules sequentially,
but uses a table and as few as possible 'if' conditions in the main
code flow, for speed. This has the effect that in some cases, the
implementation of a rule with lower priority has side effects on a
rule with higher priority.
This patch enables Unicode rule (LB29). I had previously disabled it
because I did not like a particular effect of this rule in a special case.
With this patch, only that special case gets exempted.
2024-09-15 Bruno Haible
unilbrk: Enable most cases of Unicode rule (LB29).
* l
Part of the (LB9) rule was not implemented right in the unilbrk modules,
namely the requirement "Treat X (CM | ZWJ)* as if it were X."
This patch does it, taking care to resolve to not introduce a conflict
with rule (LB8a) "Do not break after a zero width joiner."
This patch too fixes a couple of
The implementation of the Unicode rules (LB15a), (LB15b) on 2024-01-30 was
not correct: It causes several test failures in Unicode.org's LineBreak.txt.
This patch fixes it.
2024-09-15 Bruno Haible
unilbrk: Fix bugs in implementation of Unicode rules (LB15a), (LB15b).
* lib/gen
Samuel Tardieu wrote:
> Agreed. However since there are more than 50 static functions marked pure in
> C files already, and this seems to be the only missed compiler warning in GCC
> 14.2, I thought you were favoring the absence of warning.
We added these attributes before we realized that
- i
Bruno Haible writes:
> No, thanks. This is a 'static' function. It is a waste of time for us
> developers to add attributes in order to declare information that GCC
> has already found out by itself.
Agreed. However since there are more than 50 static functions marked pure in C
files already, a
