On Tuesday, February 27th, 2024 at 23:02, Rob Landley wrote:
> On 2/27/24 21:46, Oliver Webb wrote:
>
> > On Tuesday, February 27th, 2024 at 19:19, Rob Landley r...@landley.net
> > wrote:
> >
> > > On 2/27/24 13:46, Oliver Webb via Toybox wrote:
> > >
> > > > Since we build toybox with
On 2/27/24 21:46, Oliver Webb wrote:
> On Tuesday, February 27th, 2024 at 19:19, Rob Landley
> wrote:
>> On 2/27/24 13:46, Oliver Webb via Toybox wrote:
>>
>> > Since we build toybox with -funsigned-char, there is no reason to have a
>> > type for unnsigned chars in bc.c,
>> > since that is the
On 2/27/24 21:27, Oliver Webb wrote:
> 2 are help text, do_xzcat was due to replacing the case statement for error
> handling with a array
> If I had to guess, xz_dec_run or xz_dec_bcj_reset
>
> It was the case statement I stripped out in xz_dec_bcj_reset, it works with
> the attached patch
On Tuesday, February 27th, 2024 at 19:19, Rob Landley wrote:
> On 2/27/24 13:46, Oliver Webb via Toybox wrote:
>
> > Since we build toybox with -funsigned-char, there is no reason to have a
> > type for unnsigned chars in bc.c,
> > since that is the default for all chars. And removing it gets
On Tuesday, February 27th, 2024 at 20:51, Oliver Webb via Toybox
wrote:
> On Tuesday, February 27th, 2024 at 20:01, Rob Landley r...@landley.net wrote:
>
> > On 2/27/24 19:23, Oliver Webb wrote:
> >
> > > The below patch does a bunch cleanup on xzcat.c.
> > > It resolves the ifdefs that were
On 2024-02-27 20:29:31, Rob Landley wrote:
> On 2/27/24 19:45, David Seikel wrote:
> > On 2024-02-27 19:37:39, Rob Landley wrote:
> >> "We put all the switches together in a common fusebox, it's down in the
> >> basement. If you want to control any lights in the house, go down there
> >> and read
On Tuesday, February 27th, 2024 at 20:01, Rob Landley wrote:
> On 2/27/24 19:23, Oliver Webb wrote:
>
> > The below patch does a bunch cleanup on xzcat.c.
> > It resolves the ifdefs that were in the code (But everything they were
> > checking was defined so they didn't do anything)
> > Adds
On 2/27/24 19:45, David Seikel wrote:
> On 2024-02-27 19:37:39, Rob Landley wrote:
>> "We put all the switches together in a common fusebox, it's down in the
>> basement. If you want to control any lights in the house, go down there and
>> read
>> the labels, it's so much tidier that way."
>
>
On 2/27/24 19:23, Oliver Webb wrote:
> The below patch does a bunch cleanup on xzcat.c.
> It resolves the ifdefs that were in the code (But everything they were
> checking was defined so they didn't _do_ anything)
> Adds Tests for errors (And while we are changing the test suite, converts
>
On 2024-02-27 19:37:39, Rob Landley wrote:
> "We put all the switches together in a common fusebox, it's down in the
> basement. If you want to control any lights in the house, go down there and
> read
> the labels, it's so much tidier that way."
Wait, your switches in the basement have labels?
On 2/27/24 15:22, Mouse wrote:
And also, bc_program_stdin_name never changes from "" so
there's no reason to make it a variable
>>> Well, I [...] would say that there is at least potentially reason to
>>> leave it as a variable even if it's never changed: namely,
Building domain
On 2/27/24 13:46, Oliver Webb via Toybox wrote:
> Since we build toybox with -funsigned-char, there is no reason to have a type
> for unnsigned chars in bc.c,
> since that is the default for all chars. And removing it gets rid of a typedef
Sigh, the bc in the tree is "fraught". The guy who
On Tuesday, February 27th, 2024 at 15:22, Mouse
wrote:
> > > > And also, bc_program_stdin_name never changes from "" so
> > > > there's no reason to make it a variable
> > > > Well, I [...] would say that there is at least potentially reason to
> > > > leave it as a variable even if it's never
>>> And also, bc_program_stdin_name never changes from "" so
>>> there's no reason to make it a variable
>> Well, I [...] would say that there is at least potentially reason to
>> leave it as a variable even if it's never changed: namely,
>> future-proofing. If someone wants to change it in the
Back in September when I wrote ts, I added TOYFLAG_MAYFORK in the flags,
this patch removes that.
TOYFLAG_LINEBUF for ts makes sense, the main use case for ts is creating
log files for daemons (foobard | ts | tee logfile). If something happens
(Kernel Panic, Power Off, SIGKILL, etc) It should
On Tuesday, February 27th, 2024 at 14:00, Mouse
wrote:
> > And also, bc_program_stdin_name never changes from "" so
> > there's no reason to make it a variable
>
>
> Well, I haven't read all the context. But I would say that there is at
> least potentially reason to leave it as a variable even
> And also, bc_program_stdin_name never changes from "" so
> there's no reason to make it a variable
Well, I haven't read all the context. But I would say that there is at
least potentially reason to leave it as a variable even if it's never
changed: namely, future-proofing. If someone wants to
Since we build toybox with -funsigned-char, there is no reason to have a type
for unnsigned chars in bc.c,
since that is the default for all chars. And removing it gets rid of a typedef
- Oliver Webb From f91d771e43969a437ba96428b336d547e30ec76e Mon Sep 17 00:00:00 2001
From: Oliver Webb
The -l library in bc.c is stored in a obfuscated block of numbers, even though
it's a ASCII string.
Why? I don't know, but I took the string bc_lib and turned it from a block of
numbers into something
someone could look at and at least have a vague idea of what's happening in it.
This patch
19 matches
Mail list logo
