Re: Bug in handling of "1$", "2$" in printf format

2024-12-09 Thread Corinna Vinschen via Cygwin
On Dec 7 16:33, Jon Turney via Cygwin wrote: > On 07/12/2024 05:26, Keith Thompson via Cygwin wrote: > > Brian Inglis wrote: > > > On 2024-12-06 19:16, Keith Thompson via Cygwin wrote: > > > > The use of "1$", "2$" et al in printf format specifiers is a > > > > POSIX-specific feature. > > > > > >

Re: Bug in handling of "1$", "2$" in printf format

2024-12-07 Thread Jon Turney via Cygwin
On 07/12/2024 05:26, Keith Thompson via Cygwin wrote: Brian Inglis wrote: On 2024-12-06 19:16, Keith Thompson via Cygwin wrote: The use of "1$", "2$" et al in printf format specifiers is a POSIX-specific feature. On Cygwin (newlib) this is handled correctly in most cases, but one example I tri

Re: Bug in handling of "1$", "2$" in printf format

2024-12-06 Thread Keith Thompson via Cygwin
Brian Inglis wrote: > On 2024-12-06 19:16, Keith Thompson via Cygwin wrote: > > The use of "1$", "2$" et al in printf format specifiers is a > > POSIX-specific feature. > > > > On Cygwin (newlib) this is handled correctly in most cases, but one > > example I tried misbehaves. > > The output is corr

Re: Bug in handling of "1$", "2$" in printf format

2024-12-06 Thread Brian Inglis via Cygwin
On 2024-12-06 19:16, Keith Thompson via Cygwin wrote: The use of "1$", "2$" et al in printf format specifiers is a POSIX-specific feature. On Cygwin (newlib) this is handled correctly in most cases, but one example I tried misbehaves. The output is correct on other implementations, including gli

Bug in handling of "1$", "2$" in printf format

2024-12-06 Thread Keith Thompson via Cygwin
The use of "1$", "2$" et al in printf format specifiers is a POSIX-specific feature. On Cygwin (newlib) this is handled correctly in most cases, but one example I tried misbehaves. The output is correct on other implementations, including glibc and musl on Ubuntu. This C program: #include int m

Re: bug in .. handling

2005-04-09 Thread Christopher Faylor
On Sat, Apr 09, 2005 at 03:34:21PM -0600, Eric Blake wrote: >Cygwin is taking too much liberty when resolving paths with .. in them. >I've tested this with both 1.5.14 and the 20050408 snapshot. POSIX >requires that the pathname before the .. exist, and if it is a symlink, >that it is resolved,

bug in .. handling

2005-04-09 Thread Eric Blake
Cygwin is taking too much liberty when resolving paths with .. in them. I've tested this with both 1.5.14 and the 20050408 snapshot. POSIX requires that the pathname before the .. exist, and if it is a symlink, that it is resolved, before going to the parent directory. For example: $ cd /tmp/

Re: Possible bug in handling of BSS sections?

2001-12-18 Thread Danny Smith
--- Julian Hall <[EMAIL PROTECTED]> wrote: > > Hi; I don't know whether this has been mentioned before, but I just had > a bug report for NASM, which I am one of the maintainers of, relating to > linking code assembled by NASM with the cygwin or mingw linkers. > > I've done a little investigati

Possible bug in handling of BSS sections?

2001-12-18 Thread Julian Hall
Hi; I don't know whether this has been mentioned before, but I just had a bug report for NASM, which I am one of the maintainers of, relating to linking code assembled by NASM with the cygwin or mingw linkers. I've done a little investigation, and have managed to rule out NASM as the source of t