On 2018-08-14 13:24, Achim Gratz wrote:
> Corinna Vinschen writes:
>> With your patch, strtold looks more correct, but it still prints the
>> sign of NaN:
>>
>> strtod ("nan", NULL) = nan
>> strtod ("-nan", NULL) = nan
>> strtold ("nan", NULL) = nan
>> strtold ("-nan", NULL) = -nan
>> nan
;
> Cygwin is indeed buggy for turning "NaN" into -NaN; that's easy enough to fix.
> The remaining question is whether it should turn "-NaN" into -NaN; and the
> argument that glibc JUST fixed their bug 23007 to make strtod("-nan") return
> -NaN means t
gt;From 91cf4a20e0773f4a38d6d56b0867fe3725859e5e Mon Sep 17 00:00:00 2001
From: Masamichi Hosoda
Date: Tue, 14 Aug 2018 22:29:34 +0900
Subject: [PATCH v2 1/2] Fix strtod ("nan") returns negative NaN
The definition of qNaN for x86_64 and i386 was wrong.
So strtod ("nan") and st
On Tue, 14 Aug 2018 16:44:59, Eric Blake wrote:
The remaining question is whether it should turn "-NaN" into
-NaN; and the argument that glibc JUST fixed their bug 23007 to make
strtod("-nan") return -NaN means that Cygwin should, indeed, preserve
the negative sign bi
[Does that make sense?]
Cygwin is indeed buggy for turning "NaN" into -NaN; that's easy enough
to fix. The remaining question is whether it should turn "-NaN" into
-NaN; and the argument that glibc JUST fixed their bug 23007 to make
strtod("-nan") return -NaN
On Tue, 14 Aug 2018 at 17:09, Andy Moreton wrote:
>
> On Tue 14 Aug 2018, Steven Penny wrote:
> > a number can be positive or negative. as "NaN" is by definition not a
> > number,
> > it cannot be positive or negative, it is simply itself, something anathe
On Tue 14 Aug 2018, Steven Penny wrote:
> a number can be positive or negative. as "NaN" is by definition not a number,
> it cannot be positive or negative, it is simply itself, something anathema to
> a number.
The C standard disagrees with you [ISO:IEC 9899:2011, secti
On Wed, 15 Aug 2018, Masamichi Hosoda wrote:
> On Linux with glibc, both strtod ("nan")
> and strtod ("-nan") return positive NaN.
>
> So I've created the patch that behaves like glibc.
> Both strtod ("nan") and strtod ("-nan") return positive NaN.
I would suggest that you should not consider fi
Corinna Vinschen writes:
> With your patch, strtold looks more correct, but it still prints the
> sign of NaN:
>
> strtod ("nan", NULL) = nan
> strtod ("-nan", NULL) = nan
> strtold ("nan", NULL) = nan
> strtold ("-nan", NULL) = -nan
> nan ("") = nan
>
> Question: What's wrong with that?
-nan (""));
=3D=3D>
nan ("") =3D nan
-nan ("") =3D -nan
So, shouldn't the ideal outcome be this:
strtod ("nan", NULL) =3D nan
strtod ("-nan", NULL) =3D -nan
strtold ("nan", NULL) =3D nan
strtold ("-nan",
Well, that's what I get in linux and cygwin for:
#include
#include
#include /* the last two printfs requires this */
int main (void) {
printf ("strtof (\"nan\", NULL) = %f\n", strtof ("nan", NULL));
printf ("strtof (\"-nan\", NULL) = %f\n", strtof ("-nan", NULL));
printf ("strtod (\"nan\
t;> > strtold ("-nan", NULL) = -nan
>> > nan ("") = nan
>> >
>> > Question: What's wrong with that? Wouldn't it be more correct if
>> > strtod returns -NaN for "-nan" as well?
>>
>> In my investigate
t the better/best approach as, even though it makes sense,
> all other implementations or linux distributions treat it as a plain "nan".
> So anything written for linux will potentially break on cygwin, I am not
> sure this is the idea behind cygwin, right?
My point is, ev
NULL) = nan
strtod ("nan", NULL) = nan
strtod ("-nan", NULL) = nan
strtold ("nan", NULL) = nan
strtold ("-nan", NULL) = nan
This further supports the reasoning to always return just 'nan'.
On 8/14/2018 12:05 PM, Masamichi Hosoda wrote:
Hi
more correct if
strtod returns -NaN for "-nan" as well?
In my investigate,
strtold sets sign bit when parameter has '-' character.
The wrong long double NaN definition is negative NaN that is set sign bit.
So without my patch, both strtold ("nan") and
strtold ("-n
Hi
I've found that strtod ("nan") returns negative NaN on Cygwin 64 bit.
https://cygwin.com/ml/cygwin/2018-08/msg00168.html
On Linux with glibc, both strtod ("nan")
and strtod ("-nan") return positive NaN.
So I've created the patch that behaves like glib
trtod ("nan", NULL) = nan
> > > strtod ("-nan", NULL) = nan
> > > strtold ("nan", NULL) = nan
> > > strtold ("-nan", NULL) = -nan
> > > nan ("") = nan
> > >
> > > Question: What's wrong wi
ith your patch, strtold looks more correct, but it still prints the
> > sign of NaN:
> >
> > strtod ("nan", NULL) = nan
> > strtod ("-nan", NULL) = nan
> > strtold ("nan", NULL) = nan
> > strtold ("-nan", NULL) = -na
uot;nan", NULL) = -nan
> strtold ("-nan", NULL) = -nan
> nan ("") = nan
>
> so it prints always -nan.
>
> With your patch, strtold looks more correct, but it still prints the
> sign of NaN:
>
> strtod ("nan", NULL) = nan
On Aug 14 11:56, Corinna Vinschen wrote:
> On Aug 14 13:45, Masamichi Hosoda wrote:
> > >From a50ee5a4747a99c70469a53fe959f3dc22d3b79a Mon Sep 17 00:00:00 2001
> > From: Masamichi Hosoda
> > Date: Tue, 14 Aug 2018 12:50:32 +0900
> > Subject: [PATCH] Fix strtod ("nan") returns qNaN
> >
> > The def
On Aug 14 13:45, Masamichi Hosoda wrote:
> >From a50ee5a4747a99c70469a53fe959f3dc22d3b79a Mon Sep 17 00:00:00 2001
> From: Masamichi Hosoda
> Date: Tue, 14 Aug 2018 12:50:32 +0900
> Subject: [PATCH] Fix strtod ("nan") returns qNaN
>
> The definition of qNaN for x86_64 and x86 was wrong.
> So strt
>>> On Mon, 13 Aug 2018 at 19:46, Duncan Roe wrote:
On Mon, Aug 13, 2018 at 12:52:48PM -0400, Stephen John Smoogen wrote:
> On Mon, 13 Aug 2018 at 11:16, Masamichi Hosoda
> wrote:
[...]
> On Fedora 27 with 7.3.1 it gives
> ```
> stod ("nan") = nan
> s
On Tue, 14 Aug 2018 11:31:35, Masamichi Hosoda wrote:
If I understand correctly,
`std::stod ()` uses cygwin1.dll's `strtod ()` for the conversion.
`std::stod ()` is defined in
/usr/lib/gcc/x86_64-pc-cygwin/7.3.0/include/c++/bits/basic_string.h L6388-.
It calls `__gnu_cxx::__stoa ()` with pointer
>> On Mon, 13 Aug 2018 at 19:46, Duncan Roe wrote:
>>>
>>> On Mon, Aug 13, 2018 at 12:52:48PM -0400, Stephen John Smoogen wrote:
>>> > On Mon, 13 Aug 2018 at 11:16, Masamichi Hosoda
>>> > wrote:
>>> [...]
>>> > On Fedora 27 with 7.3.1 it gives
>>> > ```
>>> > stod ("nan") = nan
>>> > stod ("-nan
> On Mon, 13 Aug 2018 at 19:46, Duncan Roe wrote:
>>
>> On Mon, Aug 13, 2018 at 12:52:48PM -0400, Stephen John Smoogen wrote:
>> > On Mon, 13 Aug 2018 at 11:16, Masamichi Hosoda
>> > wrote:
>> [...]
>> > On Fedora 27 with 7.3.1 it gives
>> > ```
>> > stod ("nan") = nan
>> > stod ("-nan") = nan
>
On Mon, 13 Aug 2018 at 19:46, Duncan Roe wrote:
>
> On Mon, Aug 13, 2018 at 12:52:48PM -0400, Stephen John Smoogen wrote:
> > On Mon, 13 Aug 2018 at 11:16, Masamichi Hosoda wrote:
> [...]
> > On Fedora 27 with 7.3.1 it gives
> > ```
> > stod ("nan") = nan
> > stod ("-nan") = nan
> > quiet_NaN ()
On Mon, Aug 13, 2018 at 12:52:48PM -0400, Stephen John Smoogen wrote:
> On Mon, 13 Aug 2018 at 11:16, Masamichi Hosoda wrote:
[...]
> On Fedora 27 with 7.3.1 it gives
> ```
> stod ("nan") = nan
> stod ("-nan") = nan
> quiet_NaN () = nan
> ```
[...]
Same with Slackware 14.2 / gcc (GCC) 5.3.0
--
P
On Mon, 13 Aug 2018 at 11:16, Masamichi Hosoda wrote:
>
> Hi
>
> I've found a curious behavior about `std::stod ("nan")` on Cygwin.
> Only on Cygwin, `std::stod ("nan")` returns negative NaN.
> On Linux etc., `std::stod ("nan")`
Hi
I've found a curious behavior about `std::stod ("nan")` on Cygwin.
Only on Cygwin, `std::stod ("nan")` returns negative NaN.
On Linux etc., `std::stod ("nan")` returns positive NaN.
Here is a reproduction code.
```
// g++ -std=c++11 foobar.cc
#inc
Corinna Vinschen writes:
> On Sep 1 14:39, Henry S. Thompson wrote:
>> This is not new, I don't think, but I thought I'd check if it's a known
>> problem.
>>
>> Running Cygwin 2.5.2 on Windows 10 (which just forced the Anniversary
>> update on me, various minor irritations to be overcome),
>
> B
On Sep 1 14:39, Henry S. Thompson wrote:
> This is not new, I don't think, but I thought I'd check if it's a known
> problem.
>
> Running Cygwin 2.5.2 on Windows 10 (which just forced the Anniversary
> update on me, various minor irritations to be overcome),
Be glad, be *really* glad, you don't
This is not new, I don't think, but I thought I'd check if it's a known
problem.
Running Cygwin 2.5.2 on Windows 10 (which just forced the Anniversary
update on me, various minor irritations to be overcome), I see the
following:
> cygcheck python27.dll
Found: C:\WINDOWS\system32\python27.dll
On Jun 29 20:13, Stanisław Wawszczak wrote:
> >
> > Do you have the cygserver service running? (See
> > /usr/share/doc/Cygwin/cygserver.README.)
> >
> > Ken
> Yes, I have. And I have believed that defaults are as stated in config file,
> but they aren't.
> Just after uncommenting the
> kern.ipc
>
> Do you have the cygserver service running? (See
> /usr/share/doc/Cygwin/cygserver.README.)
>
> Ken
Yes, I have. And I have believed that defaults are as stated in config file,
but they aren't.
Just after uncommenting the
kern.ipc.semmsl 60
config line and restarting the cygserver it started
On 6/29/2016 3:20 PM, Stanisław Wawszczak wrote:
On 29/06/2016 18:06, Stanisław Wawszczak wrote:
*Real question is why Cygwin's implementation of getsem() is not allowing to
ask for more than nsems == 1?*
Here is stated, that the platform is limiting the nsems value:
http://pubs.opengroup.org/
>On 29/06/2016 18:06, Stanisław Wawszczak wrote:
>> Dear Corinna,
>>
>> I am sorry about confusing you.
>> Simply:
>>
>> - Issue
>> ----
>> Call to ftok() returns negative value
>
On 29/06/2016 18:06, Stanisław Wawszczak wrote:
Dear Corinna,
I am sorry about confusing you.
Simply:
- Issue
Call to ftok() returns negative value
Hi Stanisław,
may be I am missing somthing, but nothing on
http
Dear Corinna,
I am sorry about confusing you.
Simply:
- Issue
Call to ftok() returns negative value
- Conditions -
Windows 2012 R2 with latest patches
Cygwin x64 installed
can see the path
> and id in arguments are correct and stat() function returns correct values.
> Finally result in %rax is negative:
> rax 0xaf0b000701cc1d53 -5833568862233420461
Ok, but what's the exact problem? Following a GDB session is kind
of a lot of work.
%rax is negative:
rax 0xaf0b000701cc1d53 -5833568862233420461
Best Regards,
Stanislaw Wawszczak
Iscg Poland
###
# GDB session
###
Breakpoint 1, ftok (path
Dave,
Was snprintf not printf, but same problem. Thanks - much appreciated.
- Original Message
From: Dave Korn <[EMAIL PROTECTED]>
To: cygwin@cygwin.com
Sent: Sunday, October 1, 2006 7:36:28 PM
Subject: RE: ntohl returns negative on Windows XP
On 02 October 2006 03:28, Mark
On 02 October 2006 03:28, Mark Seery wrote:
> ntohl is returning 0xFE725D7B as a negative number (-26059397).
> Is this the correct beavior. Should be: 4268907899?
>
> variables being used are declared as unsigned int.
Show us the code. Probably you forgot the 'u' off
ntohl is returning 0xFE725D7B as a negative number (-26059397).
Is this the correct beavior. Should be: 4268907899?
variables being used are declared as unsigned int.
cyg version 1.90
windows XP professional 2002 service pack 2
--
Unsubscribe info: http://cygwin.com/ml/#unsubscribe
On Oct 24 07:49, bill test wrote:
> $ df -l -h
> FilesystemSize Used Avail Use% Mounted on
> D:\cygwin\bin 11G 1.6G 8.6G 16% /usr/bin
> D:\cygwin\lib 11G 1.6G 8.6G 16% /usr/lib
> D:\cygwin 11G 1.6G 8.6G 16% /
> c:4.0G 2.6G 1
$ df -l -h
FilesystemSize Used Avail Use% Mounted on
D:\cygwin\bin 11G 1.6G 8.6G 16% /usr/bin
D:\cygwin\lib 11G 1.6G 8.6G 16% /usr/lib
D:\cygwin 11G 1.6G 8.6G 16% /
c:4.0G 2.6G 1.5G 65%
/cygdrive/c
d: 11
On Sun, Jun 12, 2005 at 11:33:08AM +0200, Corinna Vinschen wrote:
>I see. It seems the 3.4.x code is just assuming a bit too much when
>examining functions, whereas the 4.x implementation is a bit more careful.
AFAICT, the code was just plain wrong with gcc 3.4.4. However, I found a bug
report w
On Jun 12 11:22, Gerrit P. Haase wrote:
> Corinna Vinschen wrote:
> >I'm wondering if we should do that or not. I'm not a gcc person, so I'm
> >not exactly the right one to make such a decision. It's just interesting
> >that the strict-aliasing problem Chris found, is no problem in gcc 4
> >anymo
Corinna Vinschen wrote:
On Jun 11 18:53, Gerrit P. Haase wrote:
Corinna Vinschen wrote:
Otherwise, do you know by any chance, if there exists some fix for that
problem? The above kludge is almost a year old, so there's a chance
that somebody already found the fix.
Where we had a problem wa
On Jun 11 18:53, Gerrit P. Haase wrote:
> Corinna Vinschen wrote:
> >Otherwise, do you know by any chance, if there exists some fix for that
> >problem? The above kludge is almost a year old, so there's a chance
> >that somebody already found the fix.
>
> Where we had a problem was with -fschedul
On Jun 11 16:37, Christopher Faylor wrote:
> On Sat, Jun 11, 2005 at 02:33:32PM -0400, Christopher Faylor wrote:
> >I did a little more debugging on this and it seems like, in this case at
> >least, the problem is that the newlib code is wrong. Compiling it with
> >-Wstrict-aliasing revealed a pro
On Sat, Jun 11, 2005 at 02:33:32PM -0400, Christopher Faylor wrote:
>I did a little more debugging on this and it seems like, in this case at
>least, the problem is that the newlib code is wrong. Compiling it with
>-Wstrict-aliasing revealed a problem. Correcting the strict aliasing problem
>seem
On Sat, Jun 11, 2005 at 06:53:14PM +0200, Gerrit P. Haase wrote:
>Corinna Vinschen wrote:
>>Gerrit, could you please follow up on this? It seems the simplest way is
>>to just switch off -funit-at-a-time for the -O2 optimization. This is the
>>patch we applied internally, if that's of any help for
Corinna Vinschen wrote:
Gerrit, could you please follow up on this? It seems the simplest way is
to just switch off -funit-at-a-time for the -O2 optimization. This is the
patch we applied internally, if that's of any help for you:
Index: gcc/opts.c
=
On Jun 10 20:57, David Rothenberger wrote:
> rsync has started reported negative statistics with the 20050610
> snapshot and a DLL I built from CVS HEAD today using gcc 3.4.4 and the
> latest gcc-mingw release. Interestingly (to me, at least), it works
> correctly with CVS HEAD
rsync has started reported negative statistics with the 20050610
snapshot and a DLL I built from CVS HEAD today using gcc 3.4.4 and the
latest gcc-mingw release. Interestingly (to me, at least), it works
correctly with CVS HEAD built today using gcc 3.3.3 and the previous
gcc-mingw release
Hello,
I'm using the negative lookahead assertion in a regular expression to
parse tokens of a text file that start with a '>'. Some of the tokens can
be very long like 500, 1000 or up to 2000 lines long. It seems that the
negative lookahead assertion fails on tokens that are t
> On Wed, Jan 05, 2005 at 03:15:31PM -0500, "Patrick J. LoPresti" wrote:
> > Rodrigo de Salvo Braz writes:
> >
> > > The point would be to bring this to the attention of the people
> > > being negative. By seeing that not just one person feels
> l
On Wed, Jan 05, 2005 at 03:15:31PM -0500, "Patrick J. LoPresti" wrote:
> Rodrigo de Salvo Braz writes:
>
> > The point would be to bring this to the attention of the people
> > being negative. By seeing that not just one person feels like that,
> > people ma
Rodrigo de Salvo Braz writes:
> The point would be to bring this to the attention of the people
> being negative. By seeing that not just one person feels like that,
> people may decide to stop and think whether their ways are
> constructive. Hopefully this would effect a change fo
> At 06:14 PM 1/4/2005, you wrote:
> >On Wednesday 05 January 2005 00:26, Isaac Foraker wrote:
> >
> >> I am, however, greatly disappointed at how negatively
> certain members
> >> of
> >
> >Totally agree. "Negative" is the correct word.
At 09:03 PM 1/4/2005, you wrote:
>On Tue, 4 Jan 2005, Larry Hall wrote:
>
>> Well, negative or positive, we cannot change how anyone responds to posts
>> on this list nor can we change how people interpret those responses. As
>> a result, I don't see much point in
On Tue, 4 Jan 2005, Larry Hall wrote:
> Well, negative or positive, we cannot change how anyone responds to posts
> on this list nor can we change how people interpret those responses. As
> a result, I don't see much point in lots of "me too"s along this line,
The poin
On Tue, 4 Jan 2005, Larry Hall wrote:
> At 06:14 PM 1/4/2005, you wrote:
> >On Wednesday 05 January 2005 00:26, Isaac Foraker wrote:
> >
> >> I am, however, greatly disappointed at how negatively certain members of
> >
> >Totally agree. "Negative" i
At 06:14 PM 1/4/2005, you wrote:
>On Wednesday 05 January 2005 00:26, Isaac Foraker wrote:
>
>> I am, however, greatly disappointed at how negatively certain members of
>
>Totally agree. "Negative" is the correct word. I never felt so much of it (I'm
>talking a
On Wednesday 05 January 2005 00:26, Isaac Foraker wrote:
> I am, however, greatly disappointed at how negatively certain members of
Totally agree. "Negative" is the correct word. I never felt so much of it (I'm
talking about just certain members, of course) on any other lists.
Igor could be right about (status &= 0x), just in case is not masked by
_exit() as for msvcrt exit()
% cat err.c
#include
int main(int argc, char **argv)
{
if (argc == 1)
return (0);
exit(strtol(argv[1], NULL, 16));
}
- b31 = b16 = 0 -
% err-cl 0x7ffeff5a ; printf "%
On Fri, Jul 09, 2004 at 11:24:04AM +0200, Daniel Lungu wrote:
>> -wrong-nil(!)-exit-status-
>> % nerr-cl.exe; echo $?
>> 0
>>
>> $? cannot distinguish exit(0) from exit(-2) ... this is
>> logical anarchy!
>
>:) Ah, but those aren't just two different values passed to exit, they are
>:)
> -wrong-nil(!)-exit-status-
> % nerr-cl.exe; echo $?
> 0
>
> $? cannot distinguish exit(0) from exit(-2) ... this is
> logical anarchy!
:) Ah, but those aren't just two different values passed to exit, they are
:) in fact two entirely different versions of the exit function: gcc links
8 11:49, Daniel Lungu wrote:
>> >> > Feel like bash tcsh on Cygwin mess up with negative exit status
>> >> > from a cl compiled .exe
>
>> >> The answer is "don't do that". Use positive values in the r
> -Original Message-
> From: cygwin-owner On Behalf Of Daniel Lungu
> Sent: 08 July 2004 18:14
> Indeed, but same arithmetic should apply when exit status
> comes from a "cl
> compiled .exe". It is not the case when compiling nerr.c with cl:
>
> -wrong-nil(!)-exit-status-
> % ner
:) "The value of status may be 0, EXIT_SUCCESS, EXIT_FAILURE, [CX] or any
:) other value"
:) but what you shouldn't do is expect the exit status in the shell to be
:) anything other than the least-significant byte of the value you passed:
:) "though only the least significant 8 bits (that is, sta
On Thu, 8 Jul 2004, Christopher Faylor wrote:
> On Thu, Jul 08, 2004 at 10:25:09AM -0400, Igor Pechtchanski wrote:
> >On Thu, 8 Jul 2004, Corinna Vinschen wrote:
> >
> >> On Jul 8 11:49, Daniel Lungu wrote:
> >> > Feel like bash tcsh on Cygwin mess up with n
On Thu, Jul 08, 2004 at 10:25:09AM -0400, Igor Pechtchanski wrote:
>On Thu, 8 Jul 2004, Corinna Vinschen wrote:
>
>> On Jul 8 11:49, Daniel Lungu wrote:
>> > Feel like bash tcsh on Cygwin mess up with negative exit status from a cl
>> > compiled .exe
>>
&g
On Thu, 8 Jul 2004, Corinna Vinschen wrote:
> On Jul 8 11:49, Daniel Lungu wrote:
> > Feel like bash tcsh on Cygwin mess up with negative exit status from a cl
> > compiled .exe
>
> The answer is "don't do that". Use positive values in the range from
> 0
On Jul 8 14:00, Daniel Lungu wrote:
> > Feel like bash tcsh on Cygwin mess up with negative exit status from a cl
> > compiled .exe
>
> :) The answer is "don't do that". Use positive values in the range from
> :) 0 to 255. See
> :) http://www.openg
> -Original Message-
> From: cygwin-owner On Behalf Of Corinna Vinschen
> Sent: 08 July 2004 11:09
> On Jul 8 11:49, Daniel Lungu wrote:
> > Feel like bash tcsh on Cygwin mess up with negative exit
> status from a cl
> > compiled .exe
>
> The answer
> Feel like bash tcsh on Cygwin mess up with negative exit status from a cl
> compiled .exe
:) The answer is "don't do that". Use positive values in the range from
:) 0 to 255. See
:) http://www.opengroup.org/onlinepubs/009695399/functions/exit.html
I wouldn't do that
On Jul 8 11:49, Daniel Lungu wrote:
> Feel like bash tcsh on Cygwin mess up with negative exit status from a cl
> compiled .exe
The answer is "don't do that". Use positive values in the range from
0 to 255. See
http://www.opengroup.org/onlinepubs/009695399/functio
Feel like bash tcsh on Cygwin mess up with negative exit status from a cl
compiled .exe
% uname -a
CYGWIN_NT-5.0 pc 1.3.22(0.78/3/2) 2003-03-18 09:20 i686 unknown unknown Cygwin
% echo $SHELL
/bin/bash
% cat nerr.c
int main()
{
exit (-2);
}
% gcc -o nerr-gcc nerr.c
% cl -o nerr-cl nerr.c
n" <[EMAIL PROTECTED]>
To: "Cygwin List" <[EMAIL PROTECTED]>
Sent: Thursday, April 15, 2004 10:58 PM
Subject: Re: df reports negative values on Network Shares
> Carl Peto schrieb:
> > It gets better.
> >
> > There is something quite wierd going on here.
&g
Carl Peto schrieb:
It gets better.
There is something quite wierd going on here.
I just wanted to upgrade cygwin1.dll so I downloaded cygwin-1.5.9-1.tar.bz2
from
ftp://ftp.mirror.ac.uk/sites/sources.redhat.com/pub/cygwin/release/cygwin/
I then went into cygwin (bash), changed to /cygdrive/c/cygwi
ger and,
> anyway, surely what I did is all that the installer does anyway?
>
> I posted a cygcheck report on the last posting so I won't waste space by
> re-posting here.
>
> Please do let me know if there's any other diagnostics I can attach to
> help make
ay about this rather than installing using the setup.exe installer. I'm
>pretty confident that something similar would have happened had I used
>setup.exe, it would have just taken longer and, anyway, surely what I did is
>all that the installer does anyway?
>
>I posted a cygchec
.
Please do let me know if there's any other diagnostics I can attach to help
make this easier.
Regards,
Carl Peto
- Original Message -
From: "Larry Hall" <[EMAIL PROTECTED]>
To: "Carl Peto" <[EMAIL PROTECTED]>; <[EMAIL PROTECTED]>
Cc: <[E
At 02:55 PM 4/14/2004, you wrote:
>I had exactly the same problem as Thomas...
>
>$ df -h
>FilesystemSize Used Avail Use% Mounted on
>C:\Program Files\Borland\Interbase
> 1.0G -64Z 37M 101% /opt/interbase
>C:\cygwin\usr\X11R6\lib\X11\fonts
>
I had exactly the same problem as Thomas...
$ df -h
FilesystemSize Used Avail Use% Mounted on
C:\Program Files\Borland\Interbase
1.0G -64Z 37M 101% /opt/interbase
C:\cygwin\usr\X11R6\lib\X11\fonts
1.0G -64Z 37M 101% /usr/X11R6/lib/X11/
>On Tue, Nov 18, 2003 at 07:53:19AM +0100, Demmer, Thomas wrote:
>> $ df
>> Filesystem 1k-blocks Used Available Use% Mounted on
>> m: 307200 -73786976294741950464 7308 101% /m
>>
>> All the drives with the -64Z (zillion?) are on the same server subsystem,
n
>On Tue, Nov 18, 2003 at 07:53:19AM +0100, Demmer, Thomas wrote:
>> $ df
>> Filesystem 1k-blocks Used Available Use% Mounted on
>> m: 307200 -73786976294741950464 7308 101% /m
>>
>> All the drives with the -64Z (zillion?) are on the same server subsystem,
n
On Tue, Nov 18, 2003 at 07:53:19AM +0100, Demmer, Thomas wrote:
> $ df
> Filesystem 1k-blocks Used Available Use% Mounted on
> m: 307200 -73786976294741950464 7308 101% /m
>
> All the drives with the -64Z (zillion?) are on the same server subsystem, n:
> is
Hi all,
this may or may not be a bug in fileutils. Here are the
symptoms:
$ df
Filesystem 1k-blocks Used Available Use% Mounted on
C:\cygwin\usr\X11R6\lib\X11\fonts
19542568 7468884 12073684 39%
/usr/X11R6/lib/X11/fonts
C:\cygwin\bin 19542568 7468
On Wed, Oct 29, 2003 at 09:42:21AM -0500, Ken Shaffer wrote:
> The setup thinks I'm up to date. Is there a specific mirror I need to try?
No. Just wait.
Corinna
--
Corinna Vinschen Please, send mails regarding Cygwin to
Cygwin Developermailto:[E
The setup thinks I'm up to date. Is there a specific mirror I need to try?
--
Ken Shaffer
Staff Software Engineer
770-236-3421
[EMAIL PROTECTED]
I've uploaded a new gawk package. The definition of INTMAX_MIN
has been fixed in current CVS.
Thanks for the report.
Corinna
--
Corinna Vinschen
On Tue, Oct 28, 2003 at 05:28:23PM -0500, [EMAIL PROTECTED] wrote:
Content-Description: Mail message body
> I expected the output of a negative 1234 in hex to look like 0xfb2e:
>
> > echo |gawk '{n = -1234; printf("0x%x\n",n+0)}'
> 0x-1234
>
> >
On Tue, 28 Oct 2003, Shankar Unni wrote:
> [EMAIL PROTECTED] wrote:
>
> >> echo |gawk '{n = -1234; printf("0x%x\n",n+0)}'
> > 0x-1234
> >> gawk --version
> > GNU Awk 3.1.3
>
> Definitely a cygwin port problem. On linux, it does print 0xfb2e.
> (At least, versions 3.1.0 and 3.1.1 on Linux do -
[EMAIL PROTECTED] wrote:
>> echo |gawk '{n = -1234; printf("0x%x\n",n+0)}'
> 0x-1234
>> gawk --version
> GNU Awk 3.1.3
Definitely a cygwin port problem. On linux, it does print 0xfb2e.
(At least, versions 3.1.0 and 3.1.1 on Linux do - I don't have the
latest version compiled on Linux).
In ei
I expected the output of a negative 1234 in hex to look like 0xfb2e:
> echo |gawk '{n = -1234; printf("0x%x\n",n+0)}'
0x-1234
> gawk --version
GNU Awk 3.1.3
running under cygwin for the PC.
I believe the INTMAX_MIN mentioned in an earlier thread has somethi
96 matches
Mail list logo
