On Wed, Apr 22, 2009 at 11:41:17AM +0100, Dave Korn wrote:
> Corinna Vinschen wrote:
> > On Apr 21 22:18, Eric Blake wrote:
[... explanation of the sed/cygwin problem]
> > Thanks for the explanation. Apparently I'm unable to explain this
> > clearly enough.
>
> When you referred to "broken ap
Corinna Vinschen wrote:
> On Apr 21 22:18, Eric Blake wrote:
>> The bug was that isblank(-1) was blindly treated as if were equivalent
>> with isblank(0xff), which, in some locales, is flat out wrong
>> (isblank(EOF) should always be 0, even when isblank(0xff) is well-defined
>> as 1). Broken apps
On Apr 21 22:18, Eric Blake wrote:
> The bug was that isblank(-1) was blindly treated as if were equivalent
> with isblank(0xff), which, in some locales, is flat out wrong
> (isblank(EOF) should always be 0, even when isblank(0xff) is well-defined
> as 1). Broken apps can't tell the difference bet
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
According to Dave Korn on 4/21/2009 5:57 PM:
>> And better so since sed isn't broken. It puts EOF into the isblank
>> function and rightly expects that isblank returns 0.
>
> I thought the problem was that it puts 0xff into the isblank function and
Corinna Vinschen wrote:
> On Apr 21 18:56, Corinna Vinschen wrote:
>> The fact
>> that sed would be better off with a fix as well was not part of the
>> discussion.
>
> And better so since sed isn't broken. It puts EOF into the isblank
> function and rightly expects that isblank returns 0.
I
On Apr 21 18:56, Corinna Vinschen wrote:
> The fact
> that sed would be better off with a fix as well was not part of the
> discussion.
And better so since sed isn't broken. It puts EOF into the isblank
function and rightly expects that isblank returns 0.
Corinna
--
Corinna Vinschen
On Apr 21 19:35, Corinna Vinschen wrote:
> isFOO (128) == isFOO (-127)
Ouch, make that
isFOO (128) == isFOO (-128)
> isFOO (255) == isFOO (-1)
Corinna
--
Corinna Vinschen Please, send mails regarding Cygwin to
Cygwin Project Co-Leader cygwin AT cygwin DOT co
On Apr 21 18:24, Dave Korn wrote:
> Corinna Vinschen wrote:
>
> > I didn't explain that well enough. The problem is not the char value
> > 0xff if it's defined as unsigned char value as expected by the ctype
> > functions. The problem is how to treat this value if it's given as
> > signed char v
Corinna Vinschen wrote:
> I didn't explain that well enough. The problem is not the char value
> 0xff if it's defined as unsigned char value as expected by the ctype
> functions. The problem is how to treat this value if it's given as
> signed char value to the ctype functions by broken applicat
On Apr 21 18:13, Spiro Trikaliotis wrote:
> Hello,
>
> * On Tue, Apr 21, 2009 at 05:23:34PM +0200 Corinna Vinschen wrote:
> > On Apr 14 19:08, Thomas Wolff wrote:
> > > On April 14, Corinna Vinschen wrote:
> [...]
> > This is a real problem. In the OEM codepages the 0xff character is a
> > non-b
Hello,
* On Tue, Apr 21, 2009 at 05:23:34PM +0200 Corinna Vinschen wrote:
> On Apr 14 19:08, Thomas Wolff wrote:
> > On April 14, Corinna Vinschen wrote:
[...]
> This is a real problem. In the OEM codepages the 0xff character is a
> non-breaking space. Unfortunately there's no way to distinguis
On Apr 14 19:08, Thomas Wolff wrote:
> On April 14, Corinna Vinschen wrote:
>
> > > ... the setting of the console would depend on the
> > > LC_ALL/LC_CTYPE/LANG setting when you start the first Cygwin process of
> > > a Cygwin process tree in that console. It would last for all Cygwin
> > > proc
On April 14, Corinna Vinschen wrote:
> > ... the setting of the console would depend on the
> > LC_ALL/LC_CTYPE/LANG setting when you start the first Cygwin process of
> > a Cygwin process tree in that console. It would last for all Cygwin
> > processes within the same process tree.
>
> This app
On Apr 3 16:51, Corinna Vinschen wrote:
> On Apr 3 12:37, Thomas Wolff wrote:
> > This would mean you could no longer effectively invoke the cygwin.bat
> > or cygwinutf.bat scripts within a Windows console and get the proper
> > charset? That would not be good.
>
> No, that's not right. The l
On Apr 3 12:37, Thomas Wolff wrote:
> [For some reason I'm not receiving the mailing list right now once again,
> so I hand-crafted the References and In-Reply-To headers of this mail,
> if that matter.]
Worked fine :)
> Corinna wrote:
> > These are the choices we have, afaics:
> >
> > 1. Use
[For some reason I'm not receiving the mailing list right now once again,
so I hand-crafted the References and In-Reply-To headers of this mail,
if that matter.]
I had written:
> Now with 1.7.0-45, after remote login, the encoding is always just
> ISO-8859-1, while of course, if I have a UTF-8
On Apr 2 17:44, Stephan Mueller wrote:
> On Apr 2 16:59, Corinna Vinschen wrote:
> " 2. Use the environment variable setting of LC_ALL/LC_CTYPE/LANG at
> "the moment the console is opened the first time and then never
> "change this setting again until the console is closed again.
> "
> "
On Apr 2 16:59, Corinna Vinschen wrote:
" 2. Use the environment variable setting of LC_ALL/LC_CTYPE/LANG at
"the moment the console is opened the first time and then never
"change this setting again until the console is closed again.
"
" 3. Change rlogin to call setlocale(LC_ALL, ""); at
On Apr 2 16:59, Corinna Vinschen wrote:
> On Apr 2 16:30, Thomas Wolff wrote:
> > > removed in favor of using $LANG, $LC_ALL, or $LC_CTYPE.
> > >
> > [...]
> > Now with 1.7.0-45, after remote login, the encoding is always just
> > ISO-8859-1, while of course, if I have a UTF-8 terminal, I w
On Apr 2 16:30, Thomas Wolff wrote:
> [Should I have responded to cygwin-announce? Not sure.]
Definitely not.
> Corinna Vinschen wrote on cygwin-announce:
> > What's new in contrast to 1.7.0-44
> > ===
> >
> > - A lot of character sets are supported now via a call
[Should I have responded to cygwin-announce? Not sure.]
Corinna Vinschen wrote on cygwin-announce:
> Hi folks,
>
>
> I just uploaded a new Cygwin 1.7 test release, 1.7.0-45.
>
> ...
>
>
> What's new in contrast to 1.7.0-44
> ===
>
> - A lot of character sets are sup
21 matches
Mail list logo
