On Tue, Feb 8, 2022 at 12:09 AM Ángel wrote:
>
> On 2022-02-07 at 11:55 +0100, Alex fxmbsw7 Ratchev wrote:
> > > > however my solution still stays
> > > > you just use memory locations instead of c strings
> > > > and those entries in memory are of course of known length, before
> > > > setting an
On 2022-02-07 at 11:55 +0100, Alex fxmbsw7 Ratchev wrote:
> > > however my solution still stays
> > > you just use memory locations instead of c strings
> > > and those entries in memory are of course of known length, before
> > > setting and all is fine
> >
> > "Your" solution is decades old. Ev
> In the case of bash with environment having LC_CTYPE: C.UTF-8 or
> en_US.UTF-8
> read:
> 0xC3 (len=1) i.e. Ã ('A' w/tilde in a legacy 8-bit latin-compatible
> charset),
> but invalid if bash processes the environment setting of en_US.UTF-8.
>
> Should bash process it as legacy input or invali
On Mon, Feb 7, 2022 at 7:45 AM Lawrence Velázquez wrote:
>
> On Mon, Feb 7, 2022, at 1:26 AM, Alex fxmbsw7 Ratchev wrote:
> > well i saw now, printf a char of "\0" results in 0 bytes out to wc -c
>
> % /usr/bin/printf '\0' | wc -c
>1
>
>
> > however my solution still stays
> > you just use
On Mon, Feb 7, 2022, at 1:26 AM, Alex fxmbsw7 Ratchev wrote:
> well i saw now, printf a char of "\0" results in 0 bytes out to wc -c
% /usr/bin/printf '\0' | wc -c
1
> however my solution still stays
> you just use memory locations instead of c strings
> and those entries in memory are of
On Mon, Feb 7, 2022 at 6:19 AM Lawrence Velázquez wrote:
>
> On Sun, Feb 6, 2022, at 11:53 PM, Alex fxmbsw7 Ratchev wrote:
> > On Mon, Feb 7, 2022 at 12:02 AM Greg Wooledge wrote:
> >> There are other programming languages besides bash. Some of them can
> >> store NUL bytes internally, either by
On Sun, Feb 6, 2022, at 11:53 PM, Alex fxmbsw7 Ratchev wrote:
> On Mon, Feb 7, 2022 at 12:02 AM Greg Wooledge wrote:
>> There are other programming languages besides bash. Some of them can
>> store NUL bytes internally, either by encoding and decoding them on the
>> fly, or by not using C-style s
On Mon, Feb 7, 2022 at 3:37 AM Chet Ramey wrote:
>
> On 2/6/22 5:11 PM, Alex fxmbsw7 Ratchev wrote:
> > i just have a small question here
> > the dropping of null bytes is no friend of me and i understand you're
> > there to skip it instead of process, which results in null bytes gone
> > which is
On Mon, Feb 7, 2022 at 1:47 AM L A Walsh wrote:
>
>
>
>
> On 2022/02/06 09:26, Frank Heckenbach wrote:
> >> On 2022/01/02 17:43, Frank Heckenbach wrote:
> >>
> >>
> >>> Why would you? Aren't you able to assess the severity of a bug
> >>> yourself? Silent data corruption is certainly one of the mos
On Mon, Feb 7, 2022 at 12:02 AM Greg Wooledge wrote:
>
> On Sun, Feb 06, 2022 at 11:11:43PM +0100, Alex fxmbsw7 Ratchev wrote:
> > [[ Regarding nul bytes discarded by command substitution ]]
> > can't these \0 bytes be encoded at least when a utf8 locale is used as
> > \u0 instead of dropping ? a
On 2/6/22 5:11 PM, Alex fxmbsw7 Ratchev wrote:
i just have a small question here
the dropping of null bytes is no friend of me and i understand you're
there to skip it instead of process, which results in null bytes gone
which is not much of an use
can't these \0 bytes be encoded at least when a
On 2022/02/06 09:26, Frank Heckenbach wrote:
On 2022/01/02 17:43, Frank Heckenbach wrote:
Why would you? Aren't you able to assess the severity of a bug
yourself? Silent data corruption is certainly one of the most severe
kind of bugs ...
---
That's debatable, BTW, as I was rem
Date:Sun, 6 Feb 2022 18:01:03 -0500
From:Greg Wooledge
Message-ID:
| I urge you to learn one of these other languages, and use it.
|
| Bash is a shell, not a full general-purpose programming language. It's
| not suited to all tasks. Many other languages are
On Sun, Feb 06, 2022 at 11:11:43PM +0100, Alex fxmbsw7 Ratchev wrote:
> [[ Regarding nul bytes discarded by command substitution ]]
> can't these \0 bytes be encoded at least when a utf8 locale is used as
> \u0 instead of dropping ? and a null, ... just
> prefix the utf 8 encoding chars to the nul
a replacement sequence to null bytes i would find a solution to null bytes
no i didnt understand these posts of these emails but i am just
concerned about the null bytes not being dropped
On Sun, Feb 6, 2022 at 11:16 PM Alex fxmbsw7 Ratchev wrote:
>
> im sorry i didnt realize it would just prefix
im sorry i didnt realize it would just prefix to null byte, which uses
nullbyte, so it wont work
cheers
On Sun, Feb 6, 2022 at 11:11 PM Alex fxmbsw7 Ratchev wrote:
>
> i just have a small question here
> the dropping of null bytes is no friend of me and i understand you're
> there to skip it inst
i just have a small question here
the dropping of null bytes is no friend of me and i understand you're
there to skip it instead of process, which results in null bytes gone
which is not much of an use
can't these \0 bytes be encoded at least when a utf8 locale is used as
\u0 instead of dropping ?
On 2/5/22 9:41 PM, L A Walsh wrote:
That's debatable, BTW, as I was reminded of a similar
passthrough of what one might call 'invalid input' w/o warning,
resulting in code that worked in a specific circumstance to a change
in bash issuing a warning that resulted in breaking code, that, at that
p
> On 2022/01/02 17:43, Frank Heckenbach wrote:
>
> > Why would you? Aren't you able to assess the severity of a bug
> > yourself? Silent data corruption is certainly one of the most severe
> > kind of bugs ...
> ---
> That's debatable, BTW, as I was reminded of a similar
> passthrough of what one m
On 2022/01/02 17:43, Frank Heckenbach wrote:
Chet Ramey wrote:
After all, we're talking about silent data corruption, and now I
learn the bug is known for almost a year, the fix is known and still
hasn't been released, not even as an official patch.
If you use the number of bug repor
20 matches
Mail list logo
