On Thu, Jul 6, 2017 at 8:04 AM, Denys Vlasenko wrote:
> On Tue, Jun 27, 2017 at 3:20 PM, Kang-Che Sung wrote:
>> Hello. Can I suggest another way?
>> How about modifying the `line` buffer so it can be used directly as the name,
>> and avoid the malloc problem or STRINGIFY(PATH_MAX) altogether.
>>
On Tue, Jun 27, 2017 at 3:20 PM, Kang-Che Sung wrote:
> Hello. Can I suggest another way?
> How about modifying the `line` buffer so it can be used directly as the name,
> and avoid the malloc problem or STRINGIFY(PATH_MAX) altogether.
>
> My suggestion (warning, this code is not tested):
>
> ---
Op 05-07-17 om 22:23 schreef Denys Vlasenko:
> Fixed in git, please confirm.
Confirmed.
Thanks,
- M.
___
busybox mailing list
busybox@busybox.net
http://lists.busybox.net/mailman/listinfo/busybox
On Wed, Jul 5, 2017 at 11:53 AM, Peter Korsgaard wrote:
> dpkg moved to away from dynamically allocating the hashtables in commit
> c87339d584 (dpkg: trivial code shrinkage, and redo G trick correctly) almost
> ten years ago, but the cleanup code was never adjusted to match.
>
> Glibc loudly compl
On Wed, Jul 5, 2017 at 8:56 PM, Martijn Dekker wrote:
> Op 05-07-17 om 19:15 schreef Denys Vlasenko:
>> Fix is in git, please try and let me know how does it work.
>
> It fixes the bug I reported, but it introduces a new bug: the presence
> of a quoted closing square bracket in a pattern (whether
Op 05-07-17 om 19:15 schreef Denys Vlasenko:
> Fix is in git, please try and let me know how does it work.
It fixes the bug I reported, but it introduces a new bug: the presence
of a quoted closing square bracket in a pattern (whether it's quoted
literally or passed from a variable) causes the pat
All,
On Tue, Jun 27, 2017 at 8:36 AM, Jared Bents
wrote:
> On Mon, Jun 26, 2017 at 10:31 PM, Baruch Siach wrote:
>> Hi Matthew,
>>
>> On Mon, Jun 26, 2017 at 08:45:42PM -0500, Matthew Weber wrote:
>>> On Mon, Jun 26, 2017 at 7:36 PM, Emmanuel Deloget wrote:
>>> > On Mon, Jun 26, 2017 at 11:23 P
From: Jared Bents
Update to increase the pathname limit to the
linux limit of 4096 characters.
Similar patch:
https://patchwork.openembedded.org/patch/131475/
Signed-off-by: Jared Bents
Signed-off-by: Matt Weber
---
Changes
v1 -> v2
[Baruch Siach
- Use of PATH_MAX instead of just increasing
On Wed, Jul 5, 2017 at 6:15 PM, Denys Vlasenko wrote:
> I reproduced it on another machine, with this libc:
>
> $ /lib/libc-2.22.so
> GNU C Library (Gentoo 2.22-r4 p13) stable release version 2.22, by
> Roland McGrath et al.
>
> The cause: ash uses chars 0x81...0x88 for special purposes.
> "π" is
Op 05-07-17 om 18:15 schreef Denys Vlasenko:
> On Wed, Jul 5, 2017 at 1:50 AM, Martijn Dekker wrote:
>> Slackware 14.1 (with multilib added):
>>
>> $ /lib64/libc.so.6
>> GNU C Library (GNU libc) stable release version 2.17, by Roland McGrath et
>> al.
>
> So, bug triggers with this one.
>
> And
On Wed, Jul 5, 2017 at 1:50 AM, Martijn Dekker wrote:
> Op 04-07-17 om 20:23 schreef Denys Vlasenko:
>> Ok. I just tested it again, and it works for me.
>> Let's narrow it down more. My libc is:
>>
>> $ /lib64/libc.so.6
>> GNU C Library (GNU libc) development release version 2.25.90, by
>> Roland
On Tue, Jul 04, 2017 at 07:06:10PM +0200, Denys Vlasenko wrote:
> On Sun, Jul 2, 2017 at 3:42 PM, Patrick Steinhardt wrote:
> > setpriv from util-linux has an option to dump the current state
> > regarding privilege settings via `--dump`. It prints out information on
> > the real and effective use
dpkg moved to away from dynamically allocating the hashtables in commit
c87339d584 (dpkg: trivial code shrinkage, and redo G trick correctly) almost
ten years ago, but the cleanup code was never adjusted to match.
Glibc loudly complains about this:
*** Error in `dpkg': free(): invalid pointer: 0x
Since version 1.0.23, uclibc-ng no longer includes a RPC implementation, the
error directive is not relevant for this and above versions.
In buildroot the libtirpc package should be used instead.
Signed-off-by: Jean-Loup 'clippix' Bogalho
---
util-linux/mount.c | 5 +++--
1 file changed, 3 inser
14 matches
Mail list logo