from:"Jeff Johnston"

Re: [Fwd: [1.7] wcwidth failing configure tests]

2009-05-14 Thread Jeff Johnston


Corinna Vinschen wrote:

On May 15 00:58, IWAMURO Motonori wrote:
  

2009/5/13 Corinna Vinschen :


http://www.cl.cam.ac.uk/~mgk25/ucs/wcwidth.c


This looks nice.
  

Do you import Markus Kuhn's wcwidth implementation?



Trouble is, there's the thorny issue of the "CJK Ambiguous Width"
category of characters, which consists of things like Greek and
Cyrillic letters as well as line drawing symbols. Those have a width
of 1 in Western use, yet with CJK fonts they have a width of 2. That's
why Markus Kuhn's code includes the mk_wcswidth_cjk() variant.


We should use the standard variation alone, imho.
  

I don't think so.

1) It is very very inconvenient for me :-)
(Now, I apply the local patch of CJK width support to cygwin1.dll in
my environment.)

2) Unicode Standard Annex #11
http://www.unicode.org/unicode/reports/tr11/ recommends:


5 Recommendations
  

(snip)


When processing or displaying data
  

(snip)


Ambiguous characters behave like wide or narrow characters depending
on the context (language tag, script identification, associated
font, source of data, or explicit markup; all can provide the
context). If the context cannot be established reliably, they should
be treated as narrow characters by default.
  

The recommendation is independent of legacy encoding.

I think that a new locale category that specifies the "context" is necessary.
Because the "context" influences only the display or text layout.

However, there is no such standard now.

Therefore, I propose to use *_cjk() when the language part of LC_CTYPE
is 'ja', 'ko', 'vi' or 'zh'.



That would be fine with me, but tests for the actual language are not
used anywhere in newlib, so that's something very new.  Can we check in my 
patch for the time being and
extend it with the CJK variation later?  I will not be available for the
next two weeks, but I'd be glad if at least the default variation can go
in so I can create another Cygwin test release before I'm offline.


  
Corinna, I have no problem with checking the new patch in and extending 
this later, assuming you have thoroughly tested this implementation.


-- Jeff J.

Corinna

  



--
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple
Problem reports:   http://cygwin.com/problems.html
Documentation: http://cygwin.com/docs.html
FAQ:   http://cygwin.com/faq/

Re: [Fwd: Possible sscanf %f conversion glitch]

2009-01-28 Thread Jeff Johnston

Patch has been made.  The vfscanf code to look for "inf" and "nan" was 
not stopped if we
had only collected zeroes to that point so it thought it was processing 
an invalid infinity.


-- Jeff J.

Corinna Vinschen wrote:

I'm forwarding this problem to the newlib list.  I checked against
the latest Cygwin from CVS and the problem still exists, afaics.

- Forwarded message from KHMan -
  

Date: Wed, 28 Jan 2009 23:19:07 +0800
From: KHMan
Subject: Possible sscanf %f conversion glitch
To: cygwin@cygwin.com

Hi all,

Someone ran into a problem with sscanf %f conversion on the Lout list. It 
appeared that one specific case fails. I am running cygwin-1.5.25-15. Test 
cases:


#include 
int main()
{
char *foo1 = "10i";
char *foo2 = "0i";
char *foo3 = "0.0i";
char *foo4 = "1.0i";
char *foo5 = "0.1i";
float f;
printf("%d ", sscanf(foo1, "%f", &f)); printf("%f\n", f);
printf("%d ", sscanf(foo2, "%f", &f)); printf("%f\n", f);
printf("%d ", sscanf(foo3, "%f", &f)); printf("%f\n", f);
printf("%d ", sscanf(foo4, "%f", &f)); printf("%f\n", f);
printf("%d ", sscanf(foo5, "%f", &f)); printf("%f\n", f);
}

As the scanf man page specifies, 'i' is not supposed to be converted, only 
the number part is supposed to be recognized.


On Cygwin:
$ ./test
1 10.00
0 10.00
1 0.00
1 1.00
1 0.10

On Linux (Ubuntu 8.04) and MinGW, the second case succeeds, the result 
being the same as the third case. I've done some googling, and haven't 
found anything related to this behaviour.


--
Cheers,
Kein-Hong Man (esq.)
Kuala Lumpur, Malaysia


- End forwarded message -


Corinna

  



--
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple
Problem reports:   http://cygwin.com/problems.html
Documentation: http://cygwin.com/docs.html
FAQ:   http://cygwin.com/faq/

Re: Problem with lroundf()

2007-08-24 Thread Jeff Johnston

I have just made a patch.  The code in lroundf() was making a comparison 
between an int and a calculation using sizeof.  This ended up being an 
unsigned comparison and in this case, the int value was < 1.


-- Jeff J.

Dave Korn wrote:

On 24 August 2007 17:16, François-Xavier Coudert wrote:


Hi all,

I think the following exhibits a bug in the lroundf() routine:


  Gahh, it's entirely likely, we keep finding cruft and corner cases in the fp
math.  Cygwin's maths routines come from newlib; post redirected there and
fups-to set.

 

$ cat a.c
#include 
#include 

int main (void) {
  printf ("%d\n", (int) lroundf(0.7));
}

$ gcc a.c && ./a.exe
0

The result of lroundf(0.7) should be 1, not 0. If lround() is used
instead of lroundf(), then it's working OK.

I didn't file a PR in bugzilla because the bug report instructions say
to send a mail to this list, but I can open one if need be.

Thanks,
FX


  Might get some spare time over the weekend to look at this with you, might 
not.
Sorry I can't be more certain.

cheers,
  DaveK



--
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple
Problem reports:   http://cygwin.com/problems.html
Documentation: http://cygwin.com/docs.html
FAQ:   http://cygwin.com/faq/

Re: popen bug [patch]

2006-08-22 Thread Jeff Johnston


Patch checked in.  Thanks.

-- Jeff J.

Eric Blake wrote:

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1



Cygwin popen does not match Linux popen when stdout is closed.


...


Oops - when stdout is closed, and the pipe is output on child, cygwin
popen mistakenly lost the pipe in both processes.


The real world case that found this:
cygwin$ echo 'errprint(esyscmd(echo hi))dnl' | m4 >&-
sh: line 0: echo: write error: Bad file descriptor

linux$ echo 'errprint(esyscmd(echo hi))dnl' | m4 >&-
hi



Fixed as follows, along with a fix to obey POSIX "The popen() function
shall ensure that any streams from previous popen() calls that remain open
in the parent process are closed in the new child process."

2006-08-22  Eric Blake  <[EMAIL PROTECTED]>

* libc/posix/popen.c (popen): Don't close output end of pipe in
child if stdout was closed on entry.
[HAVE_FCNTL]: In parent, mark file as close-on-exec, per POSIX.

- --
Life is short - so eat dessert first!

Eric Blake [EMAIL PROTECTED]
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.2.1 (Cygwin)
Comment: Public key at home.comcast.net/~ericblake/eblake.gpg
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFE61fw84KuGfSFAYARArN1AJ0ePKBbffbvvJaJOyW2XlsXUBFixwCffAvM
xu28ESQ/Md1uD58Bh77N+V4=
=oy2k
-END PGP SIGNATURE-




Index: libc/posix/popen.c
===
RCS file: /cvs/src/src/newlib/libc/posix/popen.c,v
retrieving revision 1.5
diff -u -p -r1.5 popen.c
--- libc/posix/popen.c  6 Jun 2003 19:57:51 -   1.5
+++ libc/posix/popen.c  22 Aug 2006 19:13:23 -
@@ -1,7 +1,7 @@
 /* $NetBSD: popen.c,v 1.11 1995/06/16 07:05:33 jtc Exp $   */
 
 /*

- * Copyright (c) 1988, 1993
+ * Copyright (c) 1988, 1993, 2006
  * The Regents of the University of California.  All rights reserved.
  *
  * This code is derived from software written by Ken Arnold and
@@ -55,6 +55,7 @@ static char rcsid[] = "$NetBSD: popen.c,
 #include 
 #include 
 #include 
+#include 
 
 static struct pid {

struct pid *next;
@@ -102,7 +103,9 @@ _DEFUN(popen, (program, type),
(void)dup2(pdes[1], STDOUT_FILENO);
(void)close(pdes[1]);
}
-   (void) close(pdes[0]);
+   if (pdes[0] != STDOUT_FILENO) {
+   (void) close(pdes[0]);
+   }
} else {
if (pdes[0] != STDIN_FILENO) {
(void)dup2(pdes[0], STDIN_FILENO);
@@ -129,6 +132,12 @@ _DEFUN(popen, (program, type),
(void)close(pdes[0]);
}
 
+#ifdef HAVE_FCNTL

+   /* Hide pipe from future popens; assume fcntl can't fail.  */
+   fcntl (fileno (iop), F_SETFD,
+  fcntl (fileno (iop), F_GETFD, 0) | FD_CLOEXEC);
+#endif /* HAVE_FCNTL */
+
/* Link into list of file descriptors. */
cur->fp = iop;
cur->pid =  pid;



--
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple
Problem reports:   http://cygwin.com/problems.html
Documentation: http://cygwin.com/docs.html
FAQ:   http://cygwin.com/faq/

Re: dtoa.c fails to compile for sh-elf -m2e (Was: Re: strtod (and atof) on hex numbers)

2006-06-26 Thread Jeff Johnston


Joern Rennecke wrote:

You change to mprec.h broke dtoa.c compilation for sh2e:



Please try the attached patch and let me know if it sovles the problem.

-- Jeff J.
Index: libc/stdlib/mprec.h
===
RCS file: /cvs/src/src/newlib/libc/stdlib/mprec.h,v
retrieving revision 1.4
diff -u -p -r1.4 mprec.h
--- libc/stdlib/mprec.h	22 Jun 2006 17:59:52 -	1.4
+++ libc/stdlib/mprec.h	26 Jun 2006 15:39:17 -
@@ -141,6 +141,12 @@ typedef union { double d; __ULong L[2]; 
 #if 0
 #define IEEE_Arith  /* it is, but the code doesn't handle IEEE singles yet */
 #endif
+/* Following is needed due to IEEE_Arith not being set on above.  */
+#if defined(__v800)
+#define n_bigtens 2
+#else
+#define n_bigtens 5
+#endif
 #define Emin(-126)
 #define Exp_1   ((__uint32_t)0x3f80L)
 #define Exp_11  ((__uint32_t)0x3f80L)

--
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple
Problem reports:   http://cygwin.com/problems.html
Documentation: http://cygwin.com/docs.html
FAQ:   http://cygwin.com/faq/

Re: strtod (and atof) on hex numbers

2006-06-22 Thread Jeff Johnston

I have integrated a newer version of strtod from David M. Gay's gdtoa 
FreeBSD code.  This code has the C99 support in question including nan 
and inf support.  I have tested on x86-linux and mn10300.


As usual, please run it through its paces on Cygwin and let me know if 
there are any problems.


-- Jeff J.

Jeff Johnston wrote:
This is a C99 extension to strtod over original ANSI C90 which is what 
newlib started with.  I'll start working on it, but don't expect 
anything too quick.


-- Jeff J.

Corinna Vinschen wrote:


This is a newlib issue.  I redirected this to the appropriate mailing
list newlib AT sourceware DOT org.


On Jun 20 13:00, Paul Biggar wrote:


Hi,

atof (and hence strtod) on hexadecimal numbers results in 0.0 (errno
of 0). This may be related to an old issue where NaN isnt correctly
parsed. I believe it isnt correct behaviour:

http://www.opengroup.org/onlinepubs/95399/functions/atof.html



I've tested it for integers in the range 0x800 to 0x. It
works properly on

ubuntu dapper, gcc 4.1 on i386;
debian stable, gcc 3.3 on amd64
sunos ?, gcc 3.4 on sparc

I'm using standard cygwin distribution, which uses gcc 3.4.4 (cygming 
special)


Sample code:

#include "limits.h"
#include 
#include "errno.h"

int main()

{
  cout << ULONG_MAX << endl;
  cout << 0x << endl;

  errno = 0;
  cout << atof("0x") << endl;
  cout << errno << endl;

  errno = 0;
  cout << strtod("0x", NULL) << endl;
  cout << errno << endl;

}


Is this being fixed? I could find a mention of it before. Does anyone
know a simple workaround?

Thanks
Paul




Corinna






--
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple
Problem reports:   http://cygwin.com/problems.html
Documentation: http://cygwin.com/docs.html
FAQ:   http://cygwin.com/faq/

Re: strtod (and atof) on hex numbers

2006-06-20 Thread Jeff Johnston

This is a C99 extension to strtod over original ANSI C90 which is what 
newlib started with.  I'll start working on it, but don't expect 
anything too quick.


-- Jeff J.

Corinna Vinschen wrote:

This is a newlib issue.  I redirected this to the appropriate mailing
list newlib AT sourceware DOT org.


On Jun 20 13:00, Paul Biggar wrote:


Hi,

atof (and hence strtod) on hexadecimal numbers results in 0.0 (errno
of 0). This may be related to an old issue where NaN isnt correctly
parsed. I believe it isnt correct behaviour:

http://www.opengroup.org/onlinepubs/95399/functions/atof.html



I've tested it for integers in the range 0x800 to 0x. It
works properly on

ubuntu dapper, gcc 4.1 on i386;
debian stable, gcc 3.3 on amd64
sunos ?, gcc 3.4 on sparc

I'm using standard cygwin distribution, which uses gcc 3.4.4 (cygming 
special)


Sample code:

#include "limits.h"
#include 
#include "errno.h"

int main()

{
  cout << ULONG_MAX << endl;
  cout << 0x << endl;

  errno = 0;
  cout << atof("0x") << endl;
  cout << errno << endl;

  errno = 0;
  cout << strtod("0x", NULL) << endl;
  cout << errno << endl;

}


Is this being fixed? I could find a mention of it before. Does anyone
know a simple workaround?

Thanks
Paul



Corinna




--
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple
Problem reports:   http://cygwin.com/problems.html
Documentation: http://cygwin.com/docs.html
FAQ:   http://cygwin.com/faq/

Re: gcc-3.4.4-1: c++: cmath: calling std::isnan results in endless loop

2006-02-27 Thread Jeff Johnston


Jeff Johnston wrote:

Corinna Vinschen wrote:


Jeff,

On Feb 27 12:13, Jeff Johnston wrote:


Gabriel Dos Reis wrote:


yes, isnan and friends are supposed to be macros only, not functions.



I'll start working on a newlib patch for this.




while you're at it, please do *not* remove the isnan function
implementation.  It's still required to run applications which
have been linked against older newlib versions.  Just adding
a isnan macro should be sufficient, shouldn't it?




Yep, way ahead of you :).  I will rename the current implementations to 
be double-underscored, have the macros call these, and have 
non-underscored versions that directly call the underscored versions.  I 
think that should satisfy all concerns.


-- Jeff J.



I have just checked in a solution.  Builds fine for x86-linux and I 
verified both the new macro versions work and the old function names can 
be called.  Let me know if anything breaks that I didn't anticipate.


-- Jeff J.



--
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple
Problem reports:   http://cygwin.com/problems.html
Documentation: http://cygwin.com/docs.html
FAQ:   http://cygwin.com/faq/

Re: gcc-3.4.4-1: c++: cmath: calling std::isnan results in endless loop

2006-02-27 Thread Jeff Johnston


Corinna Vinschen wrote:

Jeff,

On Feb 27 12:13, Jeff Johnston wrote:


Gabriel Dos Reis wrote:


yes, isnan and friends are supposed to be macros only, not functions.


I'll start working on a newlib patch for this.



while you're at it, please do *not* remove the isnan function
implementation.  It's still required to run applications which
have been linked against older newlib versions.  Just adding
a isnan macro should be sufficient, shouldn't it?




Yep, way ahead of you :).  I will rename the current implementations to 
be double-underscored, have the macros call these, and have 
non-underscored versions that directly call the underscored versions.  I 
think that should satisfy all concerns.


-- Jeff J.


--
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple
Problem reports:   http://cygwin.com/problems.html
Documentation: http://cygwin.com/docs.html
FAQ:   http://cygwin.com/faq/

Re: gcc-3.4.4-1: c++: cmath: calling std::isnan results in endless loop

2006-02-27 Thread Jeff Johnston


Gabriel Dos Reis wrote:

"Dave Korn" <[EMAIL PROTECTED]> writes:

[...]

|   It looks to me like the cygwin/newlib combination is not being compliant if
| it implements isnan as a function rather than a macro.  I couldn't see
| anything in the standard that says it can be a function, and every reference
| to it describes it as a macro, not a function.  It may be the case that
| libstdc++ is within its rights to assume that isnan is a macro after all.

yes, isnan and friends are supposed to be macros only, not functions.



I'll start working on a newlib patch for this.


|   OTOH it may be that libstdc++ was only supposed to be shadowing those ctype
| macros that are guaranteed to have underlying function implementations; I
| don't know what the shadowing is for, so I can't comment.

libstdc++ is supposed to shadow ctype macros -- and it also expect
them to have a function implementation.

-- Gaby



--
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple
Problem reports:   http://cygwin.com/problems.html
Documentation: http://cygwin.com/docs.html
FAQ:   http://cygwin.com/faq/

Re: ieeefp.h: C++ guards

2005-11-07 Thread Jeff Johnston


Corinna Vinschen wrote:

On Nov  6 16:41, Yaakov S (Cygwin Ports) wrote:


The ieeefp.h header does not contain C++ guards.  Is there a reason for
this?

This particularly affects C++ perl extensions, as perl.h includes
ieeefp.h, although I just ran across another, non-perl case where it
caused a compilation error.


Yaakov



This is a newlib issue since ieeefp.h is a newlib header file.  I've
redirected to the newlib list.  A patch like the below should do the
trick.  Jeff?



Seems very sensible considering that a number of the identifiers are 
also declared in math.h and protected there (e.g. isnan).


-- Jeff J.



Corinna

* libc/include/ieeefp.h: Add C++ guards.


Index: libc/include/ieeefp.h
===
RCS file: /cvs/src/src/newlib/libc/include/ieeefp.h,v
retrieving revision 1.1.1.1
diff -u -p -r1.1.1.1 ieeefp.h
--- libc/include/ieeefp.h   17 Feb 2000 19:39:46 -  1.1.1.1
+++ libc/include/ieeefp.h   7 Nov 2005 16:26:24 -
@@ -5,6 +5,8 @@
 
 #include 
 
+#define _BEGIN_STD_C

+
 /* FIXME FIXME FIXME:
Neither of __ieee_{float,double}_shape_tape seem to be used anywhere
except in libm/test.  If that is the case, please delete these from here.
@@ -238,4 +240,6 @@ int _EXFUN(finitef, (float));
 
 #endif /* _DOUBLE_IS_32BITS */
 
+#define _END_STD_C

+
 #endif /* _IEEE_FP_H_ */





--
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple
Problem reports:   http://cygwin.com/problems.html
Documentation: http://cygwin.com/docs.html
FAQ:   http://cygwin.com/faq/

Re: [patch] lrint/lrintf oddity

2005-09-08 Thread Jeff Johnston


Thanks Brian.  Patch checked in and s_lrint.c modified similiarly.

-- Jeff J.

Brian Dessent wrote:

Erik de Castro Lopo wrote:



   $ gcc -Wall -O3 lrintf_test.c -o lrintf_test
   $ ./lrintf_test.exe
   lrintf_test ( .00) : ok
   lrint_test  ( .00) : ok
   lrintf_test (3.00) :

   Line 70: float : Incorrect sample (#252 : -8399916.00 => 889181140).



Yes, this does in fact seem to be a bug in lrintf.  A reduced testcase
is:

#include 
#include 

int main ()
{
  float f = -8399916.0;
  printf ("f = %f, k = %ld\n", f, lrintf (f));
}

The value -8399916.0 in binary is

1 10010110 01011101100

The exponent (j0) is 23 (150 - 127 = 23).

In lrintf, the problem is the part of the algorithm that acts on the
case of 23 <= j0 < 31.  In this case, the mantissa is simply extracted
and shifted left by (j0 - 23).  This is handled by line 66 of
sf_lrint.c:

result = (long int) i0 << (j0 - 23);

This variable 'result' is then returned, optionally negated if the sign
bit was set.  However, this calculation makes two errors: First, it must
mask off only the mantissa from i0, removing the sign bit and exponent. 
Second, it neglects to add the implicit MSB "1" which is always present

to the left of the decimal but not actually included in the mantissa.

The attached patch fixes these two problems and fixes the poster's test
case. It appears that lrint() also might suffer from the same problem:

  else if (j0 < (int)(8 * sizeof (long int)) - 1)
{
  if (j0 >= 52)
result = ((long int) i0 << (j0 - 20)) | (i1 << (j0 - 52));

However, this section of code will never be reached on 32 bit hardware
since the first 'if' will guarantee that j0 < 31.  However this looks
like it's still broken for 64 bit machines, and someone should probably
audit this.

Brian

2005-09-03  Brian Dessent  <[EMAIL PROTECTED]>

* sf_lrint.c (lrintf): Mask 'i0' correctly when extracting
mantissa.




Index: sf_lrint.c
===
RCS file: /cvs/src/src/newlib/libm/common/sf_lrint.c,v
retrieving revision 1.2
diff -u -p -r1.2 sf_lrint.c
--- sf_lrint.c  28 Jun 2005 17:03:18 -  1.2
+++ sf_lrint.c  3 Sep 2005 15:13:06 -
@@ -63,7 +63,7 @@ TWO23[2]={
   if (j0 < -1)
 return 0;
   else if (j0 >= 23)
-result = (long int) i0 << (j0 - 23);
+result = (long int) (i0 & 0x7f | 0x80) << (j0 - 23);
   else
 {
   w = TWO23[sx] + x;





--
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple
Problem reports:   http://cygwin.com/problems.html
Documentation: http://cygwin.com/docs.html
FAQ:   http://cygwin.com/faq/

Re: bug in freopen

2005-07-18 Thread Jeff Johnston


Dave Korn wrote:

Original Message


From: Eric Blake
Sent: 15 July 2005 00:14




POSIX requires that freopen(NULL, mode, f) reopen f in the new
mode, and allows implementations the option of not even closing
f in the first place.  But in cygwin, it is failing with EFAULT, which is
not even one of the errors allowed by POSIX.

http://www.opengroup.org/susv3xsh/freopen.html

#include 
#include 
int main(void)
{
  FILE* f = freopen (NULL, "rb", stdin); /* Ensure that stdin is binary
  */ printf ("file is %s, errno %d:%s\n", f ? "good" : "null", errno,
  strerror(errno));
  return 0;
}

CVS coreutils recently switched to this idiom, replacing its former
use of the nonstandard  and setmode() with something
that is required by the standards.  But until this bug is fixed, CVS
coreutils will not work with cygwin.  The strace in cygwin shows
that newlib tried to perform open(NULL), which is the cause of
the EFAULT.




  I could take a look at this over the weekend if nobody gets to it first :)



A little late, but please do.  I'm a little busy at the moment.

-- Jeff J.



cheers,
  DaveK



--
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple
Problem reports:   http://cygwin.com/problems.html
Documentation: http://cygwin.com/docs.html
FAQ:   http://cygwin.com/faq/

Re: HUGE is missing in math.h

2005-06-27 Thread Jeff Johnston


Corinna Vinschen wrote:

On Jun 26 09:37, Humberto Bortolossi wrote:


Hi!

I'm trying to port a C program written originally in
Linux to the Microsoft Windows plataform.

I've realized that math.h under cygwin doesn't
define the macro HUGE, that is defined in
the math.h under linux:

/* Declarations for math functions.
  Copyright (C) 1991-1993,1995-1999,2001,2002 Free Software Foundation, Inc.
  This file is part of the GNU C Library.
*/
/* SVID mode specifies returning this large value instead of infinity.  */
# define HUGE   3.40282347e+38F

I thought math.h should be quite portable ...



HUGE is not portable.  It's not defined in the standard, see
http://www.opengroup.org/onlinepubs/009695399/basedefs/math.h.html
Use HUGE_VAL instead. 


However, other definitions are missing in math.h, like HUGE_VALF,
HUGE_VALL, INFINITY and NAN.



I'll take a look at adding these unless you want to.  HUGE_VALL is the 
only one that is difficult.



Since math.h is part of newlib, I've redirect this posting to the
newlib mailing list.


Corinna




--
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple
Problem reports:   http://cygwin.com/problems.html
Documentation: http://cygwin.com/docs.html
FAQ:   http://cygwin.com/faq/

Re: [PATCH] Fix newly exposed bug [was RE: RFC: Fix partial NaN-parsing problem [was RE: sscanf problem]]

2005-04-28 Thread Jeff Johnston

Hi Dave,
  Thanks for looking into this.  Your patch wasn't quite correct.  It ended up 
breaking nan-support which isn't tested in the accompanying testcase.  It needed 
to verify that x & multiple_flags_ored_together == multiple_flags_ored_together. 
 Anyway, I have checked a patch in and verified that it works for your tests 
below plus it also works for a simple test like
i = sscanf ("nank", "%lf%c%n", &x, &m, &n)

-- Jeff J.
Dave Korn wrote:
Original Message
From: Jean-Christophe Kablitz
Sent: 27 April 2005 00:22

Hello,
I have noticed, that, while parsing {a float_value immediately followed by
'n' or 'N'} with the "%f%c" format, the sscanf function of cygwin-1.5.16-1
behaves differently from the scanf function of cygwin-1.5.14-1.
Until cygwin-1.5.14-1 (included), 'n' matches %c, while with
cygwin-1.5.15-1 

and cygwin-1.5-16-1, 'n' is no more assigned to %c.
In the following test case, I would expect the progran to output
i=2 x=1 m=a
i=2 x=1 m=n
that was the case until cygwin-1.5.14-1 (included).
With cygwin-1.5.15-1 and cygwin-1.5-16-1, the program outputs instead
i=2 x=1 m=a
i=1 x=1 m=_
Maybe I have been misusing sscanf. Or there is a relationship with the
NaN-parsing problem of the "newlib".

  No, your use of sscanf is perfectly correct!  Yes, there is a newly
exposed bug in the NaN parsing code, as you guessed; it falsely accepted the
N as part of 'NaN'.  Then, because it had begun by parsing a number, and
because it successfully parsed the number, it didn't go through the
'nan-parsing-has-failed-so-put-back-the-eaten-chars' bit that my last fix
introduced.

--- beginning of test case ---
jck:/sscanf> cat ssn.c
#include 
int main()
{
   double x;
   char   m;
   inti;
   x = 0.0;
   m = '_';
   i = sscanf("1.0a", "%lf%c", &x, &m);
   printf("i=%d x=%g m=%c\n", i, x, m);
   x = 0.0;
   m = '_';
   i = sscanf("1.0n", "%lf%c", &x, &m);
   printf("i=%d x=%g m=%c\n", i, x, m);
   return 0;
}
jck:/sscanf> gcc -O0 ssn.c -o ssn.exe
jck:/sscanf> ./ssn.exe
i=2 x=1 m=a
i=1 x=1 m=_
--- end of test case ---

  Thank you for the simple test case; I was able to reproduce the problem
easily, although not exactly: the output I got was:
[EMAIL PROTECTED] /test/sscanf> ./ssn.exe
i=2 x=1 m=a
i=0 x=0 m=_
  It turns out there has been an underlying bug that was exposed with my
earlier fix.  The problem is in /src/newlib/libc/stdio/vfscanf.c, function
__SVFSCANF_R, case CT_FLOAT, where it's parsing a float and sees an 'n':
case 'n':
case 'N':
  if (nancount == 0
  && (flags & (SIGNOK | NDIGITS | DPTOK | EXPOK)))
{
  flags &= ~(SIGNOK | DPTOK | EXPOK | NDIGITS);
  nancount = 1;
  goto fok;
}
  else if (nancount == 2)
{
  nancount = 3;
  goto fok;
}
  break;
  The condition at the top of the loop is meant to be testing to ensure we
haven't already parsed any of the other possible components of an FP number,
but what it actually tests is whether or not we've parsed *all* the other
possible components; that's the only case it'll refuse to accept an 'n' at
present.  The reason it used to work is because after bogusly parsing the
'n', the old version then hits this bit of code when it comes time to parse
the %c field (CT_CHAR):
case CT_CHAR:
  /* scan arbitrary characters (sets NOSKIP) */
  if (width == 0)
width = 1;
  I don't understand what this is doing, but it looks like some kind of
kludge that's saying "If we got here, then we know there must have been a
char to parse, so if we don't have any, we must have bogusly consumed it
already, so pretend it's there anyway".  Or something; like I say, I don't
understand it, but it looks like a kludge to me.
  Anyway, the attached patch changes the bitwise-AND (&) to an equality (==)
operator, which genuinely tests that we haven't parsed anything else at all;
it's effectively verifying that the flags haven't changed from their initial
value before beginning to attempt to parse the possible 'NaN' string.  This
fixes the testcase for me: I now see
[EMAIL PROTECTED] /test/sscanf> ./ssn.exe
i=2 x=1 m=a
i=2 x=1 m=n
and indeed, with an expanded version of it, which also verifies the amount
of characters consumed, I see:
[EMAIL PROTECTED] /test/sscanf> cat ssn.c
#include 
int main()
{
double x;
char   m;
inti, n;
x = 0.0;
m = '_';
n = -1;
i = sscanf("1.0a", "%lf%c%n", &x, &m, &n);
printf("i=%d x=%g m=%c n=%d\n", i, x, m, n);
x = 0.0;
m = '_';
n = -1;
i = sscanf("1.0n", "%lf%c%n", &x, &m, &n);
printf("i=%d x=%g m=%c n=%d\n", i, x, m, n);
x = 0.0;
m = '_';
n = -1;
i = sscanf("1.0na", "%lf%c%n", &x, &m, &n);
printf("i=%d x=%g m=%c n=%d\n", i, x, m, n);
x = 0.0;
m = '_';
n = -1;

Re: RFC: Fix partial NaN-parsing problem [was RE: sscanf problem]

2005-04-05 Thread Jeff Johnston

Patch checked in.  Thanks.
-- Jeff J.
Dave Korn wrote:
Original Message
From: Dave Korn
Sent: 04 April 2005 19:07

Original Message
From: Dave Korn
Sent: 04 April 2005 18:51

Original Message
From: Michael Hines
Sent: 04 April 2005 19:43

The following program prints
i=1 x=0
instead of
i=0 x=10
when using the latest version of cygwin1.dll.

 No, hang on, on checking the newlib-l archive that seems to have been
something to do with a zero exponent.  This is a separate bug: it accepts
the first one or two characters of 'nan' and says "ok, everything's still
good", and then because it's reached the end of the string it treats that
as a successful parse; it forgets to verify that it doesn't have an
outstanding half-formed NaN.  I'll post a (provisional) patch shortly.

  Ok, this is only provisional, because as I point out I'm not quite sure
about the corner case where we've refilled the buffer.  It also has minor
formatting issues (slightly long lines in the comment, IMO).  However, it
fixes the testcase, and I've got to go home for the evening, so here's my
work-in-progress; comments welcomed.
--
[EMAIL PROTECTED] /test/sscanf> cat ss.c
#include 
int main() {
 int i;
 double x;
 x = 10;
 i = sscanf("n", "%lf", &x);
 printf("i=%d x=%g\n", i, x);
 i = sscanf("nan", "%lf", &x);
 printf("i=%d x=%g\n", i, x);
 return 0;
}

[EMAIL PROTECTED] /test/sscanf> gcc -O0 -g ss.c -o ss.exe
[EMAIL PROTECTED] /test/sscanf> ./ss.exe
i=0 x=10
i=1 x=NaN
[EMAIL PROTECTED] /test/sscanf>
--

cheers,
  DaveK

--
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple
Problem reports:   http://cygwin.com/problems.html
Documentation: http://cygwin.com/docs.html
FAQ:   http://cygwin.com/faq/

Re: several more bugs found by coreutils

2005-02-08 Thread Jeff Johnston

Corinna Vinschen wrote:
On Feb  8 12:47, Christopher Faylor wrote:
On Tue, Feb 08, 2005 at 06:42:11PM +0100, Corinna Vinschen wrote:
I have attached a patch to newlib this time.  Thinking about that
for a while, I'm pretty sure that it doesn't make sense to build
old 32 bit versions of Cygwin with recent newlib versions.  So I'm
opting for having a clean pwd.h.
The below patch changes the definitions of struct passwd and utimes(2)
according to SUSv3.
Cool.  I was wondering about that.

It requires also a patch to Cygwin, but I'm waiting for Jeff's approval
first.
Done.
Corinna

--
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple
Problem reports:   http://cygwin.com/problems.html
Documentation: http://cygwin.com/docs.html
FAQ:   http://cygwin.com/faq/

Re: several more bugs found by coreutils

2005-02-08 Thread Jeff Johnston

Corinna Vinschen wrote:
On Feb  2 11:07, Corinna Vinschen wrote:
On Feb  1 20:58, Erik Blake wrote:
Further coreutils-5.3.0 debugging turned up more POSIX bugs in cygwin:
 defines struct passwd with the pw_uid and pw_gid members as ints, 
although POSIX requires uid_t and gid_t.
http://www.opengroup.org/onlinepubs/009695399/basedefs/dirent.h.html
include/pwd.h is a newlib file.  However, I was pretty happy that pw_uid
and pw_gid were defined as int, when we changed uids and gids from 16 to
32 bits.  It was the one file which wasn't necessary to change.
We could just redefine struct passwd to use uid_t and gid_t, but this
would break (very very very very unlikely) builds of Cygwin using
sources of versions before 1.5.0.  In other words, old Cygwin sources
using 16 bit uids/gids would go down hell.
Personally, I think I can live with that, but I would like to hear if
there's any good reason to build historic versions (say, b20) with a
recent newlib.

 defines utimes with non-const second parameter, although POSIX requires it to 
be const; likewise for utime in  (deferred to ).  Additionally, 
both utimes() and utime() are required to touch file ctime on success.
http://www.opengroup.org/onlinepubs/009695399/functions/utimes.html
[snip]
That should be easy to change in sys/time.h.
As far as the implementation of utime/utimes is affected, I already
changed it to set st_ctime.

I have attached a patch to newlib this time.  Thinking about that
for a while, I'm pretty sure that it doesn't make sense to build
old 32 bit versions of Cygwin with recent newlib versions.  So I'm
opting for having a clean pwd.h.
The below patch changes the definitions of struct passwd and utimes(2)
according to SUSv3.
Looks fine.  Please go ahead.
-- Jeff J.
Corinna
* libc/include/pwd.h (struct passwd): Change pw_uid and pw_gid
members to uid_t and gid_t according to SUSv3.
* libc/include/sys/time.h (utimes):  Change second parameter
to const according to SUSv3.
Index: libc/include/pwd.h
===
RCS file: /cvs/src/src/newlib/libc/include/pwd.h,v
retrieving revision 1.2
diff -p -u -r1.2 pwd.h
--- libc/include/pwd.h	9 Mar 2003 21:08:51 -	1.2
+++ libc/include/pwd.h	8 Feb 2005 17:37:22 -
@@ -50,8 +50,8 @@ extern "C" {
 struct passwd {
 	char	*pw_name;		/* user name */
 	char	*pw_passwd;		/* encrypted password */
-	int	pw_uid;			/* user uid */
-	int	pw_gid;			/* user gid */
+	uid_t	pw_uid;			/* user uid */
+	gid_t	pw_gid;			/* user gid */
 	char	*pw_comment;		/* comment */
 	char	*pw_gecos;		/* Honeywell login info */
 	char	*pw_dir;		/* home directory */
Index: libc/include/sys/time.h
===
RCS file: /cvs/src/src/newlib/libc/include/sys/time.h,v
retrieving revision 1.4
diff -p -u -r1.4 time.h
--- libc/include/sys/time.h	21 Apr 2001 03:22:47 -	1.4
+++ libc/include/sys/time.h	8 Feb 2005 17:37:22 -
@@ -72,7 +72,7 @@ struct  itimerval {
 
 int _EXFUN(gettimeofday, (struct timeval *__p, struct timezone *__z));
 int _EXFUN(settimeofday, (const struct timeval *, const struct timezone *));
-int _EXFUN(utimes, (const char *__path, struct timeval *__tvp));
+int _EXFUN(utimes, (const char *__path, const struct timeval *__tvp));
 int _EXFUN(getitimer, (int __which, struct itimerval *__value));
 int _EXFUN(setitimer, (int __which, const struct itimerval *__value,
 	struct itimerval *__ovalue));


--
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple
Problem reports:   http://cygwin.com/problems.html
Documentation: http://cygwin.com/docs.html
FAQ:   http://cygwin.com/faq/

Re: short fread(), but no ferror/feof

2004-12-13 Thread Jeff Johnston

Peter Astrand wrote:
Dave Korn wrote:

The fix and the problem Peter is seeing are orthogonal.
The fix referred to above fixes this problem:
http://sources.redhat.com/ml/newlib/2004/msg00478.html
"Hence, one can see that fread() in unbuffered mode always returns the
specified count instead of the number of elements actually read."
That is why, as Peter has observed, fread() returns the number of
elements
actually read.  Without the patch, it would have been returning the entire
number requested, which would have been even wronger.

Ah, thanks for clarifying this.

However Peter's problem is that when fread() does a partial read, it doesn't
set either the EOF mark or the error indication on the file stream.  A strict
reading of the fread() specification suggests that it should have set one of
those.

IMO, there's no room for intepretation in this situation: As I stated
in my original post, IEEE Std 1003.1 is very clear:
"fread() shall return the number of elements successfully read which is
less than nitems only if a read error or end-of-file is encountered."
Where in the POSIX standard did you find that above line?  I could not locate it 
in mine.  The line above is in SUSV3.  ANSI and C99 are more relaxed and simply 
state that the number of elements returned may be less than asked if EOF or an 
error has occurred.

Regardless, the behavior is wrong.  The same test on a buffered file yields the 
EOF.
I have posted a patch.
-- Jeff J.
--
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple
Problem reports:   http://cygwin.com/problems.html
Documentation: http://cygwin.com/docs.html
FAQ:   http://cygwin.com/faq/

Re: __const use instead of const in one place

2004-08-23 Thread Jeff Johnston

Corinna Vinschen wrote:
On Aug 18 15:36, Peter Hinely wrote:
Hi,
I noticed that __const is used in one and only one place in the header files.  

Line 76 of \user\include\sys\unistd.h
char_EXFUN(*getpass, (__const char *__prompt));
That's the only place in all the header files.  Shouldn't it be changed to const?  

That's a newlib issue.  I've redirected to the newlib mailing list.
Corinna
A patch has just been checked in to make the getpass() prototype consistent with 
other function prototypes.

-- Jeff J.

--
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple
Problem reports:   http://cygwin.com/problems.html
Documentation: http://cygwin.com/docs.html
FAQ:   http://cygwin.com/faq/

Resolved: Setup.exe doesn't load on Win95 laptop (Nov. 3)

2002-11-06 Thread Jeff Johnston

Hi,

I went to install TextPad, and it complained that my COMCTL32.DLL file
wasn't up to date and referred me to this Microsoft KB article:

http://support.microsoft.com/default.aspx?scid=KB;EN-US;Q186176&;

I didn't want to install Internet Explorer, and the "Download
50COMUPD.EXE" link doesn't seem to work, so I downloaded the update from
here instead:

http://www.mylistmate.com/Download.htm "Common Controls v5 (499 KB)"

That fixed TextPad, and mow Cygwin's setup.exe loads properly on my
laptop too.

FYI,
Jeff


--
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple
Bug reporting: http://cygwin.com/bugs.html
Documentation: http://cygwin.com/docs.html
FAQ:   http://cygwin.com/faq/

Setup.exe doesn't load on Win95 laptop

2002-11-03 Thread Jeff Johnston


Hi,

Cygwin works great on my desktop machine, so I decided to try it on my old
laptop.  Setup doesn't load.  When I double click setup.exe it gives the
arrow-hourglass combo for half a second then exits without any error
messages or other windows coming up.  I deleted setup.exe, downloaded it
on my desktop machine, copied it to the laptop and compared it, same
files.  Deleted the original anyways and ran the new one.  Still nothing.
The computer is not hooked up to the Internet, I have all the files copied
to the hd.  But the desktop machine runs setup.exe when not online.
Tried copying my setup logs from the desktop, didn't help.  Tried moving
setup.exe to different folders, didn't matter.  Used a hex editor to view
setup.exe and saw what .dll's it calls.  I have them all on the laptop,
but maybe not the versions it is expecting?  Dunno.

Here is info about my laptop:
Win95 4.00.950
Compaq LTE Elite 4/50CX (486 50MHz, latest BIOS update)
16.0 MB RAM
362MB free hd space
640x480xHigh color 16-bit

Any suggestions to get cygwin working on THIS machine would be much
appreciated!

Thanks,
Jeff


--
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple
Bug reporting: http://cygwin.com/bugs.html
Documentation: http://cygwin.com/docs.html
FAQ:   http://cygwin.com/faq/

problem with "more" under cygwin-1.3.13-1

2002-10-14 Thread Jeff Johnston


Hi,

I upgraded to cygwin-1.3.13.1 on Windows 98 SE (previous version cygwin
1.3.12-4), and the more command stopped wroking properly for me.  For
example I have several pages of environment variables set, but with "set |
more" only the first page is shown, it does not display the "More" prompt,
and the bash prompt appears at the bottom.  It does the same thing with
"ls | more", and "more filename.txt".  However, "less" worked okay.

There were also problems loading kde (it froze up X windows loading dcop),
but I don't have KDE working anyways, so thats not as important.

I reinstalled 1.3.12-4 and the above problems went away.

Any ideas on this would be welcome.

Thanks,
Jeffry Johnston



--
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple
Bug reporting: http://cygwin.com/bugs.html
Documentation: http://cygwin.com/docs.html
FAQ:   http://cygwin.com/faq/

Re: [Fwd: [1.7] wcwidth failing configure tests]

Re: [Fwd: Possible sscanf %f conversion glitch]

Re: Problem with lroundf()

Re: popen bug [patch]

Re: dtoa.c fails to compile for sh-elf -m2e (Was: Re: strtod (and atof) on hex numbers)

Re: strtod (and atof) on hex numbers

Re: strtod (and atof) on hex numbers

Re: gcc-3.4.4-1: c++: cmath: calling std::isnan results in endless loop

Re: gcc-3.4.4-1: c++: cmath: calling std::isnan results in endless loop

Re: gcc-3.4.4-1: c++: cmath: calling std::isnan results in endless loop

Re: ieeefp.h: C++ guards

Re: [patch] lrint/lrintf oddity

Re: bug in freopen

Re: HUGE is missing in math.h

Re: [PATCH] Fix newly exposed bug [was RE: RFC: Fix partial NaN-parsing problem [was RE: sscanf problem]]

Re: RFC: Fix partial NaN-parsing problem [was RE: sscanf problem]

Re: several more bugs found by coreutils

Re: several more bugs found by coreutils

Re: short fread(), but no ferror/feof

Re: __const use instead of const in one place

Resolved: Setup.exe doesn't load on Win95 laptop (Nov. 3)

Setup.exe doesn't load on Win95 laptop

problem with "more" under cygwin-1.3.13-1

23 matches

Site Navigation

Mail list logo

Footer information