> On April 5, 2017 at 5:28 AM Paul Eggert wrote:
> If my assumption is wrong and
> users prefer an error message when memory is low, the patch would make sense.
> It's low priority, though, as the behavior is well-defined whether or not the
> patch is installed.
Your assumption is correct, m
Pádraig Brady wrote:
A quick scan shows that functions using tz handle the NULL case,
falling back to default behavior.
Yes, when I wrote that code I assumed that users prefer getting UTC time stamps
to getting a diagnostic and no time stamps. That's the Unix tradition for other
tz setting fa
On 04/04/17 13:04, Tobias Stoeckmann wrote:
> The function tzalloc of gnulib can return NULL. It uses malloc()
> internally and forwards its possible NULL value to the caller.
>
> As other gnulib functions rely on that behaviour, it cannot be simply
> exchanged with an error-calling malloc alterna
tags 26362 notabug wishlist
stop 26362
Hello,
> On Apr 4, 2017, at 10:01, Ronald Schaten wrote:
>
> I'm not sure if this is bug or if I'm using it wrong.
Neither - it is simply the GNU tr does not yet support multibyte characters.
> The simplest way to reproduce this looks like this (sorry, u
On 04/04/17 09:47, Sebastian Kisela wrote:
> * src/tail.c (tail_forever_inotify): Add the IN_DELETE_SELF flag when
> creating watch for the parent directory. After the parent directory
> is removed, an event is caught and then we switch from inotify to
> polling mode. Till now, inotify has alway
The function tzalloc of gnulib can return NULL. It uses malloc()
internally and forwards its possible NULL value to the caller.
As other gnulib functions rely on that behaviour, it cannot be simply
exchanged with an error-calling malloc alternative.
Take possible NULL return value into account in
* src/tail.c (tail_forever_inotify): Add the IN_DELETE_SELF flag when
creating watch for the parent directory. After the parent directory
is removed, an event is caught and then we switch from inotify to
polling mode. Till now, inotify has always frozen because it waited for
an event from a watc
Hey...
I'm not sure if this is bug or if I'm using it wrong. As a matter of
fact, I tested this on several systems, and on BSD-based systems (Mac)
the tr tool gives different results -- the one I expected.
The simplest way to reproduce this looks like this (sorry, umlaut
ahead):
$ echo -ne "\xc3