On 2025-01-18 Paul Eggert wrote:
> On 2025-01-18 11:45, Lasse Collin wrote:
> > On 2025-01-18 Paul Eggert wrote:
> >> Does the unaligned read trick work even with CheriBSD's memory-safe
> >> model? That is an edge case that might need an ifdef or something.
>
so the behavior with short inputs is irrelevant. I'm sorry for the
false alarm. Having
assert(len >= 16);
at the beginning of the pclmul function could have made it obvious but
that's not an excuse, I should have looked at crc.c too.
--
Lasse Collin
it in places.
Oh that...
https://github.com/tukaani-project/xz/commit/30e95bb44c36ae26b2ab12a94343b215fec285e7
I heard the standardization news last year. It was a nice surprise.
--
Lasse Collin
48 < n < 64: some
> hardware allows this, but it's an ISO C violation nevertheless.
That wouldn't be a good idea in assembly code either.
--
Lasse Collin
On 2025-01-17 Simon Josefsson wrote:
> Lasse Collin writes:
>
> > [1]
> > https://github.com/tukaani-project/xz/blob/master/src/liblzma/check/crc_x86_clmul.h
> >
>
> Oh. Do you see any chance to merge your code into gnulib? If there
> is any feature in
Gnulib but opendir.c is one of them.
The \\?\ prefix bypasses the MAX_PATH limit but long path aware
programs don't need that trick.
I don't plan to continue my side quest to Windows issues further. :-)
Thanks for the comments!
--
Lasse Collin
t the intrinsics
differently than memcpy.
[1]
https://github.com/tukaani-project/xz/blob/master/src/liblzma/check/crc_x86_clmul.h
--
Lasse Collin
On 2025-01-14 Paul Eggert wrote:
> On 2025-01-14 02:43, Lasse Collin wrote:
> > Pedantic interpretation might be that EILSEQ isn't allowed in this
> > situation because EOVERFLOW already describes the error condition.
>
> No, because EOVERFLOW is intended for thing
On 2025-01-13 Paul Eggert wrote:
> On 2025-01-13 00:05, Lasse Collin wrote:
>
> > I pondered it before sending the patch. POSIX.1-2024 readdir() [1]:
> >
> > [EOVERFLOW]
> > One of the values in the structure to be returned cannot be
> >
erhaps EOVERFLOW handling is also worth checking. This is too much
for me in the foreseeable future, so if it means that the current patch
isn't usable alone, then that's how it is. The feedback I have received
has still been useful.
--
Lasse Collin
On 2025-01-13 Lasse Collin wrote:
> On 2025-01-12 Paul Eggert wrote:
> > Also, the POSIX spec suggests that readdir should return a null
> > pointer right away with errno set, rather than wait for the end of
> > the directory. A subsequent readdir resumes traversal of the
>
On 2025-01-12 Paul Eggert wrote:
> On 2025-01-12 12:26, Lasse Collin wrote:
> > The patch makes readdir() detect that lossless conversion isn't
> > possible and inform the application with EOVERFLOW
>
> Wouldn't EILSEQ be more appropriate? That's what "
uld
affect open(), chdir(), etc. negatively.
If you suspect that I'm missing something, please try to explain again.
Thanks!
--
Lasse Collin
gets it
wrong.
The code in pathmax.h does no harm but the issue was fixed in MinGW-w64
in 2010. I haven't looked at MinGW so I don't know if the issue is
still there.
Gnulib uses "mingw" in docs. Does it refer to MinGW or MinGW-w64 or
both? In configure triplets, MinGW uses
support. However, MinGW-w64's replacement via "#define
__USE_MINGW_ANSI_STDIO 1" provides an implementation that does support
thousand separators.
--
Lasse Collin
On 2024-12-24 Bruno Haible wrote:
> Lasse Collin wrote:
> > (1)
> > In 9f7ff4f423cd ("localename-unsafe: Support the UTF-8 environment
> > on native Windows."), the N(name) macro is used with strings that
> > include @modifier. For example, N("az_AZ@cyrill
On 2024-12-23 Bruno Haible wrote:
> Lasse Collin reported in
> <https://lists.gnu.org/archive/html/bug-gettext/2024-12/msg00111.html>
> that the setlocale() override from GNU libintl does not support the
> UTF-8 environment of native Windows correctly. That setlocale()
> ove
olumn but in languages which
mostly use non-ASCII chars it can be mostly 2 bytes == 1 column. Then
the wrapping occurs far too early, resulting in narrow output.
--
Lasse Collin
gt; mgetgroups [GPLv3+] => *Jim, *Eric, Bruno
> xalloc-oversized [GPLv3+] => [*all] Eric, Paul, Jim, (Bruno)
Relicensing is fine with me. (I barely touched the code.)
--
Lasse Collin | IRC: Larhzu @ IRCnet & Freenode
19 matches
Mail list logo
