Hi Bruno,
On 5/21/24 5:43 PM, Bruno Haible wrote:
> The new patch is good. OK to push.
Done, thanks.
>> Interesting way to think about it, thanks. Do you have a strong math
>> background? It has been a while since I looked at that interval
>> notation.
>
> Oh, I learned the interval notation at
Hi Collin,
The new patch is good. OK to push.
> However with this in my /etc/shells:
>
>
> /bin/bash
> /
> ===
>
> When printing all shells glibc prints both lines. Mine only prints
> "/bin/bash".
>
> Strange function, in my opinion. However, lets trust the BSD and
27; '/' 's' 'h' '\0'
I guess that probably makes everything easier for others to follow. I
didn't think about it too much until you mentioned it.
Feel free to correct any misunderstandings I may have in that
explination + the patch.
CollinFrom 45911704
Hi Collin,
> I tried to do that originally but I don't think you
> would have liked the patch. :)
>
> At the start of 'readname' there is a loop to skip spaces:
>
> while ((c == getc (stream)) != EOF
> && isspace ((unsigned char) c))
>/* Do nothing. */;
>
> Essentially
> invented in 2002-2003.)
Interesting. I don't know very much about Futexes.
Do most libc implementations keep track of if a stream needs to be
locked? I'm thinking about single-threaded programs that don't define
GNULIB_GETUSERSHELL_SINGLE_THREAD. I imagine the stream doesn&#x
Hi Collin,
> I've attached a patch following this method.
I see a method 'next_shell' that is only called in a single place. Would
it make sense to inline it (and move its function comments into the
body of the caller function)?
The main change is to call getline() instead of parsing the file
ch
wait for
review before pushing.
I don't see too much harm in it though since on most platforms getline
should lock much less then repeatedly calling getc. But I figured it
would be rude not to ask first. :)
CollinFrom 192fa52c6efcc290fecb12c00fd69bd9f57c4b49 Mon Sep 17 00:00:00 2001
From: Col
