On 6/15/17 9:01 PM, Peter & Kelly Passchier wrote:
> On 16/06/2560 03:11, Chet Ramey wrote:
>> You still have to look at every character. The world isn't all UTF-8:
>> there are character sets where multibyte characters include characters
>> that are valid ascii (including, I suspect, `=').
>
> I
On 16/06/2560 03:11, Chet Ramey wrote:
> You still have to look at every character. The world isn't all UTF-8:
> there are character sets where multibyte characters include characters
> that are valid ascii (including, I suspect, `=').
I think supporting all kinds of other encodings besides UTF-8
Chet Ramey wrote:
On 6/15/17 3:04 PM, L A Walsh wrote:
Two problems with locale-based rules are:
1) they differ based on local convention, potentially,
even down to what "side of the street" you live on, and
That's precisely what makes them valuable to users.
---
But such dif
Chet Ramey wrote:
On 6/15/17 11:22 AM, PePa wrote:
On 15/06/2560 22:03, Chet Ramey wrote:
I don't know other languages well enough to point one out, but
I can easily imagine that a particular character is an
"alphabetic" in, say, Mandarin, but doesn't exist in someone's
en_US characte
On 6/15/17 3:04 PM, L A Walsh wrote:
> Two problems with locale-based rules are:
>
>1) they differ based on local convention, potentially,
> even down to what "side of the street" you live on, and
That's precisely what makes them valuable to users.
>2) they don't account or allow for "d
On 6/15/17 11:22 AM, PePa wrote:
> On 15/06/2560 22:03, Chet Ramey wrote:
>> I don't know other languages well enough to point one out, but I can easily
>> imagine that a particular character is an "alphabetic" in, say, Mandarin,
>> but doesn't exist in someone's en_US character set.
>
> I though
Since the subject's come up - difficulties with /dev/tcp, no timeout
feature, somehow a failure to interrupt it, etc. I want to suggest
an alternative. I don't propose removing /dev/tcp from Bash (since
it's been there quite a long time, people use it and I'm sure many
people like it), but I pro
Chet Ramey wrote:
On 6/14/17 5:52 PM, L A Walsh wrote:
Chet Ramey wrote:
But people don't work in Unicode. They work in their own locale.
Ok, I have my locale set to latin9 (iso8859-15).
Attached is a pic ...
I am less concerned with how glyphs display in a console than how
I can't think of what could cause this problem. The TCP connection
code in Bash seems pretty straightforward, and in my experiments I was
able to interrupt it even if it was waiting for the server to accept a
connection, or waiting for an available slot in the listen queue. It's
possible the probl
On Thu, Jun 15, 2017 at 10:36 AM, wrote:
[...]
> Description:
> This is a little complicated and I can't give you full details on how
> to
> replicate it, since I don't fully understand it myself. But under
> certain
> circumstances, the following line takes a very long
On Thu, Jun 15, 2017 at 1:19 PM, Eduardo Bustamante wrote:
[..]
> Please report this to the Cygwin folks. This is not a bash issue.
Err, not the Cygwin folks. You seem to be using Cmder, so ask them.
On Thu, Jun 15, 2017 at 11:30 AM, Jon Morris wrote:
> Hi,
>
> Just tried to submit a bug, but bashbug command failed, so here is the
> problem text.
>
> Thanks,
>
> Jon
Please report this to the Cygwin folks. This is not a bash issue.
Hi,
Just tried to submit a bug, but bashbug command failed, so here is the problem
text.
Thanks,
Jon
From: jonmorris
To: bug-bash@gnu.org
Subject: cygheap base mismatch detected
Configuration Information [Automatically generated, do not change]:
Machine: i686
OS: msys
Compiler: gcc
Compilatio
Configuration Information [Automatically generated, do not change]:
Machine: x86_64
OS: linux-gnu
Compiler: gcc
Compilation CFLAGS: -DPROGRAM='bash' -DCONF_HOSTTYPE='x86_64'
-DCONF_OSTYPE='linux-gnu' -DCONF_MACHTYPE='x86_64-unknown-linux-gnu'
-DCONF_VENDOR='unknown' -DLOCALEDIR='/.../local/share
On 15/06/2560 22:03, Chet Ramey wrote:
> I don't know other languages well enough to point one out, but I can easily
> imagine that a particular character is an "alphabetic" in, say, Mandarin,
> but doesn't exist in someone's en_US character set.
I though you were referring to a character existing
I'll leave my progress on the Unicode identifiers patch here (or the PR
in Github, if you fancy that:
https://github.com/dualbus/bash/pull/2/files).
I won't have much time to work on this for a few weeks, so it's up to
you all to complete it :-) It has markers on the places where it needs
work (ma
On 6/14/17 8:54 PM, PePa wrote:
> On 15/06/2560 07:13, Chet Ramey wrote:
>> A character that is classified as an alphanumeric in a particular locale,
>> but not in another, can lead to portability problems. That's what we're
>> debating here, not how something gets displayed in a text editor.
>
>
Found by fuzzing `read -e' with AFL. The stacktrace reported by Address
Sanitizer is followed by the base64 encoded crashing input.
==7938==ERROR: AddressSanitizer: heap-buffer-overflow on address 0x60c0bd00
at pc 0x55ae5ef673f0 bp 0x7ffd16140ec0 sp 0x7ffd16140eb8
WRITE of size 1 at 0x60c000
Found by fuzzing `read -e' with AFL. The stacktrace reported by Address
Sanitizer is followed by the base64 encoded crashing input.
==11018==ERROR: AddressSanitizer: heap-buffer-overflow on address
0x6070ccc0 at pc 0x559bb60f1be7 bp 0x7ffc36ec8710 sp 0x7ffc36ec8708
READ of size 8 at 0x607000
Found by fuzzing `read -e' with AFL. The stacktrace reported by Address
Sanitizer is followed by the base64 encoded crashing input.
==15910==ERROR: AddressSanitizer: heap-buffer-overflow on address
0x6110977f at pc 0x55794384fd88 bp 0x7ffd35b10720 sp 0x7ffd35b10718
READ of size 1 at 0x611000
Found by fuzzing `read -e' with AFL. The stacktrace reported by Address
Sanitizer is followed by the base64 encoded crashing input.
==1098==ERROR: AddressSanitizer: global-buffer-overflow on address
0x55e61a6b4c5c at pc 0x55e61a3426ca bp 0x7fff1820a300 sp 0x7fff1820a2f8
READ of size 4 at 0x55e61
Found by fuzzing `read -e' with AFL. The stacktrace reported by Address
Sanitizer is followed by the base64 encoded crashing input.
==472==ERROR: AddressSanitizer: heap-buffer-overflow on address 0x6110977f
at pc 0x562befba4a14 bp 0x7ffdee172bb0 sp 0x7ffdee172ba8
READ of size 1 at 0x6110
Found by fuzzing `read -e' with AFL. The stacktrace reported by Address
Sanitizer is followed by the base64 encoded crashing input.
==1736==ERROR: AddressSanitizer: heap-buffer-overflow on address 0x61109880
at pc 0x7f464da3a063 bp 0x7ffe86032fe0 sp 0x7ffe86032790
READ of size 115 at 0x61100
23 matches
Mail list logo
