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 for
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 case
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
&g
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 implem
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 pro
On Wed, Nov 27, 2024 at 1:49 AM Brian Inglis via Cygwin
wrote:
>
> On 2024-11-26 17:08, Roland Mainz via Cygwin wrote:
> > Cygwin 3.5.4/Win10/64bit, the following program prints a '?' where I
> > would expect a '€' (EURO) symbol:
> > snip ---
O) symbol:
---- snip
printf '#include \n#include \n#include
\n#include \n#include \nint main(int ac, char
*av[]) { setlocale(LC_ALL, ""); printf("%%S\\n", L"hello € world");
return 0; }\n' >x.c && clang -target x86_64-pc-windows-gnu -Wall x.c
-o x.
On 2024-11-26 17:08, Roland Mainz via Cygwin wrote:
Cygwin 3.5.4/Win10/64bit, the following program prints a '?' where I
would expect a '€' (EURO) symbol:
---- snip
printf '#include \n#include \n#include
\n#include \n#include \nint main(int ac, char
*av[]) { setl
Hi!
Cygwin 3.5.4/Win10/64bit, the following program prints a '?' where I
would expect a '€' (EURO) symbol:
---- snip
printf '#include \n#include \n#include
\n#include \n#include \nint main(int ac, char
*av[]) { setlocale(LC_ALL, ""); printf("%
On Mon, 1 Apr 2024 at 16:29, Chris Elvidge via Cygwin wrote:
>
> Using bash builtin printf '%(fmt)T', when fmt contains %-d (or %_d),
> there is no output - should print daynumber with no preceding 0 (or with
> preceding space). Similarly %-e. date +"%B %-d" work
Using bash builtin printf '%(fmt)T', when fmt contains %-d (or %_d),
there is no output - should print daynumber with no preceding 0 (or with
preceding space). Similarly %-e. date +"%B %-d" works OK.
$ uname -a
CYGWIN_NT-10.0-19045 ASUS-X550C-WIN 3.5.1-1.x86_64 2024-02-
To Brian Inglis: thanks! Forwarded to newlib mailing list.
--
Problem reports: https://cygwin.com/problems.html
FAQ: https://cygwin.com/faq/
Documentation:https://cygwin.com/docs.html
Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple
Ah, sorry! Now I see:
https://www.mail-archive.com/cygwin@cygwin.com/msg168488.html.
--
Problem reports: https://cygwin.com/problems.html
FAQ: https://cygwin.com/faq/
Documentation:https://cygwin.com/docs.html
Unsubscribe info: https://cygwin.com/ml/#unsubscribe-
Hello. Is there any update on this? Thanks.
--
Problem reports: https://cygwin.com/problems.html
FAQ: https://cygwin.com/faq/
Documentation:https://cygwin.com/docs.html
Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple
Christian Franke wrote:
This fixes an unrelated bug found during analysis of the cygdrop crash.
In theory, the bug affects the 64-bit version (which didn't exist when I
contributed this tool in 2009).
In practice, it doesn't because 64-bit ABI uses registers to pass the first args
of a va_list
Christian
From 4cf442906ea9654543dd6683960993361f02e525 Mon Sep 17 00:00:00 2001
From: Christian Franke
Date: Sat, 14 Aug 2021 15:14:27 +0200
Subject: [PATCH] cygdrop: Fix printf format strings.
---
src/cygdrop/cygdrop.cc | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/s
On 2021-06-12 14:45, Pavel M via Cygwin wrote:
Sample code (t903.c):
#include
int main(void)
{
printf("%.43f\n", 0x1.52f8a8e32e982p-140);
return 0;
}
Invocations:
# gcc on Windows 10 (Cygwin)
$ gcc t903.c -Wall -Wextra -std=c11 -pedantic -Wfatal-errors
Pavel M via Cygwin writes:
> Sample code (t903.c):
> #include
> int main(void)
> {
> printf("%.43f\n", 0x1.52f8a8e32e982p-140);
> return 0;
> }
>
> Invocations:
> # gcc on Windows 10 (Cygwin)
> $ gcc t903.c -Wall -Wextra -
Sample code (t903.c):
#include
int main(void)
{
printf("%.43f\n", 0x1.52f8a8e32e982p-140);
return 0;
}
Invocations:
# gcc on Windows 10 (Cygwin)
$ gcc t903.c -Wall -Wextra -std=c11 -pedantic -Wfatal-errors && ./a.exe
0.010
$ gcc
Am 11.09.2019 um 02:03 schrieb Blair, Charles E III:
> I have just installed cygwin (64 bit) and gcc. The "hello world" program
> works, but
>
> #include
> int main(){printf( "%c\n" , 'X' );return 0;}
>
> leads to
>
> Unable to i
Greetings, Blair, Charles E III!
> I have just installed cygwin (64 bit) and gcc. The "hello world" program
> works, but
> #include
> int main(){printf( "%c\n" , 'X' );return 0;}
> leads to
>
> Unable to initialize device PRN
> Unable
I have just installed cygwin (64 bit) and gcc. The "hello world" program
works, but
#include
int main(){printf( "%c\n" , 'X' );return 0;}
leads to
Unable to initialize device PRN
Unable to initialize device PRN
--
Problem reports: http:
On Tue, May 6, 2014 at 9:10 AM, Marco Atzeri wrote:
> what is PS1 setting ?
> Likely PS1 is overwriting any "echo -e '\e]0;blah\a'" command
Yes sir! That was it! Culpable file
/etc/bash.bashrc
Thanks for the help.
--
Problem reports: http://cygwin.com/problems.html
FAQ:
On 06/05/2014 14:12, Steven Penny wrote:
On Tue, May 6, 2014 at 6:27 AM, Chris J. Breisch wrote:
Works for me. Are you sure you don't have PROMPT_COMMAND set, and it's
overriding it?
This is on a clean Cygwin install. I deleted the Cygwin folder and reinstall
from that.
I even tried a clean i
On Tue, May 6, 2014 at 6:27 AM, Chris J. Breisch wrote:
> Works for me. Are you sure you don't have PROMPT_COMMAND set, and it's
> overriding it?
This is on a clean Cygwin install. I deleted the Cygwin folder and reinstall
from that.
I even tried a clean install in a virtual machine with VirtualB
Steven Penny wrote:
As seen here
http://cygwin.com/ml/cygwin/2005-05/msg01263.html
He mention this command
echo -e '\E]0;blah\a'
However I think he meant to lowercase "E"
echo -e '\e]0;blah\a'
Either way, these commands are no longer changing the window title. Note that
PS1='\
As seen here
http://cygwin.com/ml/cygwin/2005-05/msg01263.html
He mention this command
echo -e '\E]0;blah\a'
However I think he meant to lowercase "E"
echo -e '\e]0;blah\a'
Either way, these commands are no longer changing the window title. Note that
PS1='\e]0;blah\a'
Still works
ntty-1.1.3-1
>>> gdb-7.6.50-1
>>> gcc-4.5.3-3
>>>
>>> The problem seems to be related to threads calling fprintf inside gdb,
>>> it runs fine from the command line, or with printf instead; both fprintf
>>> and printf sometimes trigger &quo
-DBUG bug.cpp
I currently have the following package versions:
cygwin-1.7.18(0.263/5/3) 2013-04-19
mintty-1.1.3-1
gdb-7.6.50-1
gcc-4.5.3-3
The problem seems to be related to threads calling fprintf inside gdb,
it runs fine from the command line, or with printf instead; both fprintf
and printf some
currently have the following package versions:
>cygwin-1.7.18(0.263/5/3) 2013-04-19
>mintty-1.1.3-1
>gdb-7.6.50-1
>gcc-4.5.3-3
>
>The problem seems to be related to threads calling fprintf inside gdb,
>it runs fine from the command line, or with printf instead; both fprintf
>
1
gdb-7.6.50-1
gcc-4.5.3-3
The problem seems to be related to threads calling fprintf inside gdb,
it runs fine from the command line, or with printf instead; both fprintf
and printf sometimes trigger "warning: SuspendThread failed. (winerr 6)"
(not sure if that matters).
Kn
On Jan 1 16:16, furrylogical wrote:
> Hello everyone,
>
> Cygwin seems to behave strangely when `printf` is used in threads: if
> the first `printf` encountered occurs in another thread, then the
> first `printf` that occurs in the main function will vanish into thin
> a
On Aug 28 04:36, Dave Korn wrote:
> On 18/08/2011 15:33, Corinna Vinschen wrote:
>
> > If I try that with Yaakov's 4.5.3 cross compilers, then __STRICT_ANSI__
> > is not defined with -std=c__0x, unless I also specify `-ansi' on the
> > command line. However, there's a weird warning:
> >
> > $
On 18/08/2011 10:33 AM, Corinna Vinschen wrote:
If I try that with Yaakov's 4.5.3 cross compilers, then __STRICT_ANSI__
is not defined with -std=c__0x, unless I also specify `-ansi' on the
command line. However, there's a weird warning:
$ i686-pc-cygwin-g++ -std=c++0x -dM -E -< /dev/null |
On 18/08/2011 15:33, Corinna Vinschen wrote:
> If I try that with Yaakov's 4.5.3 cross compilers, then __STRICT_ANSI__
> is not defined with -std=c__0x, unless I also specify `-ansi' on the
> command line. However, there's a weird warning:
>
> $ i686-pc-cygwin-g++ -std=c++0x -dM -E - < /dev/nu
On Aug 17 11:04, Ryan Johnson wrote:
> Hi all,
>
> I'm using the experimental gcc-4.5 package and hit a strange error:
> c++0x mode suppresses the definition of the v*printf() family of
> functions in stdio.h in c++0x mode. The offending code seems to be:
>
> #i
Hi all,
I'm using the experimental gcc-4.5 package and hit a strange error:
c++0x mode suppresses the definition of the v*printf() family of
functions in stdio.h in c++0x mode. The offending code seems to be:
#if !defined(__STRICT_ANSI__) || (__STDC_VERSION__ >= 199901L)
#ifndef _RE
> Some comments:
> 1- I think that printf(string_constant) and printf(char_array) should give
> the same
> output in any circumstance.
> 2- In absence of a call to setlocale printf((string_constant) writes
> according to
> the locale of the environment, but printf(char_a
f 8-bit bytes in character contexts. Programs that
>use LC_ALL=C to try to get 8-bit transparency from character contexts are
>flat-out non-portable. They get other well-defined benefits on 8-bit
>bytes (such as sorting by strcmp instead of strcoll, fixed-format
>messages, ...), but only
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
According to Andy Koppe on 12/29/2009 6:30 AM:
>> Remember, POSIX states that any use in a character context of bytes with
>> the 8th-bit set is specifically undefined in the C locale (whether that be
>> C.ASCII or C.UTF-8).
>
> I very much disagree w
2009/12/29 Eric Blake:
>> I couldn't find specific text about invalid bytes in the POSIX printf
>> spec,
>
> http://www.opengroup.org/onlinepubs/9699919799/functions/fprintf.html
>
> "all forms of fprintf() shall fail if:
>
> [EILSEQ]
> [CX] A wide-c
ytes, but printf is specified as a mix between bytes (arguments matching
%s) and characters (the format string itself, and arguments matching %ls).
>
> Ah, the problem actually is that your program is missing a call to
> setlocale(LC_CTYPE, "") to switch to the locale and char
2009/12/29 Rodrigo Medina:
>>Ah, the problem actually is that your program is missing a call to
>>setlocale(LC_CTYPE, "") to switch to the locale and character set
>>specified in the environment...
>
> That worked!, but what that means is that if one wants to
> use any locale other than C.UTF-8, on
>2009/12/28 Andy Koppe:
>...
>Ah, the problem actually is that your program is missing a call to
>setlocale(LC_CTYPE, "") to switch to the locale and character set
>specified in the environment...
That worked!, but what that means is that if one wants to
use any locale other than C.UTF-8, one has,
har* line3 =
>> " These letters have an accent -->á, these ones have no accent -->A!\n\n";
>> static char* line4 =
>> " This letter has an accent -->Ã, this one has no accent -->A\n\n";
>> printf(" This letter has an accent -->á, this one h
\n\n";
> static char* line4 =
> " This letter has an accent -->Ã, this one has no accent -->A\n\n";
> printf(" This letter has an accent -->á, this one has no accent
> -->a\n\n");
> printf(line2);
> printf("%d %d %d\n\n",
sentence.
For some reason, "info libc" gets you to a broken index page, by which I
mean the links don't work in info, and nothing shows up with apropos. But
running "info diprintf" or "man diprintf" directly do work. So there is at
least a fair amount o
>> We unfortunately don't have a package of man pages for our C library
>> functions.
>
> Actually the cygwin-doc package does have man pages for much of the C
> standard library.
D'oh, that's what Dave said in the next sentence.
Sorry,
Andy
--
Unsubscribe info: http://cygwin.com/ml/#unsub
>> I couldn't figure this out. What package to install to get
>> man 3 printf ?
Search http://cygwin.com/packages for "printf.3".
> We unfortunately don't have a package of man pages for our C library
> functions.
Actually the cygwin-doc package does hav
Ian Kelling wrote:
> I couldn't figure this out. What package to install to get
> man 3 printf ?
We unfortunately don't have a package of man pages for our C library
functions. Sorry about that; your best bet is online references. We have all
the standard C library functions,
I couldn't figure this out. What package to install to get
man 3 printf ?
- Ian Kelling
--
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Problem reports: http://cygwin.com/problems.html
Documentation: http://cygwin.com/docs.html
FAQ:
On May 15 13:49, Alexey Borzenkov wrote:
> On Fri, May 15, 2009 at 1:30 PM, Alexey Borzenkov wrote:
> > And I found why. It appears that there's a bug in printf with %ls that
> > will refuse to print the string completely if the wide string for %ls
> > cannot be repr
On May 15 13:30, Alexey Borzenkov wrote:
> [...]
> It appears that there's a bug in printf with %ls that
> will refuse to print the string completely if the wide string for %ls
> cannot be represented in current charset. It's interesting that
> sometimes it behaves
On Fri, May 15, 2009 at 1:30 PM, Alexey Borzenkov wrote:
> And I found why. It appears that there's a bug in printf with %ls that
> will refuse to print the string completely if the wide string for %ls
> cannot be represented in current charset.
[...]
> Prints nothing, i.e.
t appears that there's a bug in printf with %ls that
will refuse to print the string completely if the wide string for %ls
cannot be represented in current charset. It's interesting that
sometimes it behaves differently. For example:
$ mkpasswd -C
NDGAMES\aborzenkov:unused:11721:1051
On 02/25/2009, Helmut Brandl wrote:
I use the type "unsigned long long" and "long long" to get 64 bit
integers on gcc.
For reading and writing I use the formatting e.g.
unsigned long long u64;
u64 = ...;
printf("a 64 bit integer %llu\n", u64);
This has w
I use the type "unsigned long long" and "long long" to get 64 bit
integers on gcc.
For reading and writing I use the formatting e.g.
unsigned long long u64;
u64 = ...;
printf("a 64 bit integer %llu\n", u64);
This has worked up to now on all systems using
On 2009-01-21 11:10Z, Alexey Lyubimov wrote:
> Excuse me, if it is not correct mailing list to post this message
> (if so, please point me to the right one).
Try
because you're using 'mno-cygwin'. To search archives first,
I'd suggest:
http://search.gmane.org/?query=mingw+russian
http://sea
! :-(
If I write the same text in the same encoding in a shell script (for example
"echo Это русский текст") and run it under Cygwin - everything is Ok! But the
C-program can not make the "right" output using printf().
May be somebody can give me an advice, how I can change the
Dave Korn wrote:
Well... that requires editing every single printf in the whole
program, no?
It might be easier to just at the start of main() open the first
three file
descriptors, so that 0, 1 and 2 are allocated. If you open 0 from
/dev/null
in read mode and open 1 and 2 for write to
ns a serial port, which becomes stdout, causing all
> printf statements to go out the serial port.
> The solution is quite simple, just disable all printf statements for a
> cygwin build.
Well... that requires editing every single printf in the whole program, no?
It might be eas
Hi, I was pointed to this discussion at the archives:
http://www.cygwin.com/ml/cygwin/2008-12/msg00489.html
I have a similar problem with my app, all printf statements go out the
serial port.
The problem is, I'm using the -mwindows flag to get a sort of "real"
windows app
On Thu, Dec 25, 2008 at 10:52:14AM +0800, "?" wrote:
>It is strange that the error disappeared if replacing any cygwin1.dll
>on the snapshot page
>http://cygwin.com/snapshots/
>For these versions, I see a more line "Huh? No /etc/fstab file? Using
>default root and cygdrive prefix..."
I find the pthread source for
cygwin? is it pthread-win32? Thanks ..
I want to look into it.
2008/12/24 陈晓晖 :
> Hi,
>
>I found that pthread may stop work if using printf in thread.
> I'm not sure that printf is thread safe or not, so I tried to wrap the
> printf with a mutex
Hi,
I found that pthread may stop work if using printf in thread.
I'm not sure that printf is thread safe or not, so I tried to wrap the
printf with a mutex, but the problem still exists.
After I removed all printfs, everything is OK.
The testing environment:
$ uname -a
CYGWIN_N
rialio class that
provides functions like open, close, read, write, flush), opening and
closing the devices, etc has never changed (that is, the code is the
same code since back when printf worked). Other code has changed, that
is, the gui layout, function flow, etc.
Given the description so far, t
Gary R. Van Sickle wrote:
From: Alex Martin
Well, I was using a port monitor to debug some of the traffic
between my serial device, and my software, when I noticed the
output accidentally.
I am not sure when the behavior started. It used to work
fine, I was using printf to debug things
> >>
> >> I am not sure when the behavior started. It used to work
> fine, I was
> >> using printf to debug things, then I turned off all of
> those printf
> >> statements, and continued development on the gui side (fox
> toolkit)
> >>
Matt Wozniski wrote:
On Fri, Dec 19, 2008 at 2:30 PM, Gary R. Van Sickle wrote:
From: Alex Martin
Hello,
I have a cygwin environment, running some software I am
writing to talk to some serial devices.
Somehow, trying to debug why I could not see printf output to
console, I ran a serial port
> From: Alex Martin
>
> Well, I was using a port monitor to debug some of the traffic
> between my serial device, and my software, when I noticed the
> output accidentally.
>
> I am not sure when the behavior started. It used to work
> fine, I was using printf to deb
Well, I was using a port monitor to debug some of the traffic between my
serial device, and my software, when I noticed the output accidentally.
I am not sure when the behavior started. It used to work fine, I was
using printf to debug things, then I turned off all of those printf
statements
On Fri, Dec 19, 2008 at 2:30 PM, Gary R. Van Sickle wrote:
>> From: Alex Martin
>>
>> Hello,
>>
>> I have a cygwin environment, running some software I am
>> writing to talk to some serial devices.
>>
>> Somehow, trying to debug why I could not see
> From: Alex Martin
>
> Hello,
>
> I have a cygwin environment, running some software I am
> writing to talk to some serial devices.
>
> Somehow, trying to debug why I could not see printf output to
> console, I ran a serial port sniffer and voila all of my
>
Hello,
I have a cygwin environment, running some software I am writing to talk
to some serial devices.
Somehow, trying to debug why I could not see printf output to console, I
ran a serial port sniffer and voila all of my printf commands are
writing on the serial port.
Any idea how to fix
Yaakov,
On Thu, Aug 28, 2008 at 12:25:49PM -0500, Yaakov (Cygwin Ports) wrote:
> Jason Tishler wrote:
> > This is one option -- possibly a difficult one.
>
> Hmm, my mindreading isn't working so well today. What do you mean by
> that?
I guess I should have used another word instead of difficult
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
Jason Tishler wrote:
> This is one option -- possibly a difficult one.
Hmm, my mindreading isn't working so well today. What do you mean by that?
> Another option is to only support Python 3.0 under Cygwin 1.7
> and later.
Not optimal, but may no
Corinna,
On Thu, Aug 28, 2008 at 03:13:15PM +0200, Corinna Vinschen wrote:
> On Aug 28 08:41, Jason Tishler wrote:
> > On Wed, Aug 27, 2008 at 04:27:58PM +0200, Corinna Vinschen wrote:
> > > Thanks for the testcase. This looks like a bug in the newlib
> > > function _wcsrtombs_r. I'll send a bug
Jason Tishler wrote:
If you are going to release another Cygwin 1.5, would you be willing to
back port this fix? Otherwise, Python 3.0 will not be able to run under
Cygwin 1.5.
And the madness begins
Ralph
--
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Problem report
On Aug 28 08:41, Jason Tishler wrote:
> Corinna,
>
> On Wed, Aug 27, 2008 at 04:27:58PM +0200, Corinna Vinschen wrote:
> > Thanks for the testcase. This looks like a bug in the newlib function
> > _wcsrtombs_r. I'll send a bug report and a proposed fix upstream.
> > This will be fixed in Cygwin
Corinna,
On Wed, Aug 27, 2008 at 04:27:58PM +0200, Corinna Vinschen wrote:
> Thanks for the testcase. This looks like a bug in the newlib function
> _wcsrtombs_r. I'll send a bug report and a proposed fix upstream.
> This will be fixed in Cygwin 1.7.
If you are going to release another Cygwin 1
On Aug 27 16:36, Corinna Vinschen wrote:
> Hi,
>
> the following bug report has been send to the Cygwin list a couple of
> minutes ago.
> [...]
Argh, wrong mailing list. Sorry about that.
Corinna
--
Corinna Vinschen Please, send mails regarding Cygwin to
Cygwin Project Co-Le
3.0 interpreter, as
> reported here:
> http://bugs.python.org/issue3626
>
> Is there a problem with cygwin's implementation, or did I miss
> something obvious?
>
>
> /* ==== */
> #include
Is there a problem with cygwin's implementation, or did I miss
> something obvious?
>
>
> /* ==== */
> #include
> int main()
> {
> wchar_t text[] = L"T";
> printf("Test %d (%ls)\n", wcslen(text), text)
roblem with cygwin's implementation, or did I miss
something obvious?
/* */
#include
int main()
{
wchar_t text[] = L"T";
printf("Test %d (%ls)\n", wcslen(text), text);
}
/* */
--
Amaury
/
#include
int main()
{
wchar_t text[] = L"T";
printf("Test %d (%ls)\n", wcslen(text), text);
}
/* */
--
Amaury Forgeot d'Arc
--
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Problem reports: http://cygwin.
ed by libiberty. It is used internally *in*
gcc as a portability aide for gcc itself. When you call printf in a
Cygwin program, the implementation is in cygwin1.dll, and Cygwin
implements this internally via newlib. Look at the Cygwin source (which
includes the newlib source) if you want to see h
"Brian Dessent" Wrote:
> 1. gcc does not implement a C library, so there is no
> implementation of any printf in gcc. The C library
> is separate from gcc, gcc is just the compiler.
> 2. libiberty is only a portabilty library. It does
> not implement any actual p
"Frederich, Eric P21322" wrote:
> The author says...
> "Note that if you want a portable version of printf() in your code, you
> are _much_ better off using something that natively parses the format
> string. This ensures that you get the same parsing behavior on all
Hello guys,
I came across this page comparing different implementations of printf.
http://www.and.org/vstr/printf_comparison
The author says...
"Note that if you want a portable version of printf() in your code, you
are _much_ better off using something that natively parses the format
s
On Sun, May 27, 2007 at 08:15:23AM -0600, Eric Blake wrote:
>According to Brian Dessent on 5/27/2007 7:01 AM:
>> Currently sprintf("%p") does not work because the path taken for
>> handling %p shares most of the code with %x but fails to populate the
>> char ox[2] used to emit the prefix, resulting
Tom Rodman wrote:
On Wed 12/6/06 14:34 EST Larry Hall wrote:
This is a change (or bug) in 'file', not Cygwin. I get the same thing as you
do with Cygwin's version on FC4. If you think there is an issue here, you
should take it upstream.
Per, the upstream maintainer of 'file', it is a bug tha
On Wed 12/6/06 14:34 EST Larry Hall wrote:
> This is a change (or bug) in 'file', not Cygwin. I get the same thing as you
> do with Cygwin's version on FC4. If you think there is an issue here, you
> should take it upstream.
Per, the upstream maintainer of 'file', it is a bug that can not be fix
his is not a Cygwin issue.)
--Ken Nellis
-Original Message-
From: Corinna Vinschen
Sent: Wednesday, December 06, 2006 2:51 PM
To: cygwin@cygwin.com
Subject: Re: printf '\377\376h\000\r\000\n\000'|file - #wrong result?
On Dec 6 14:34, Larry Hall (Cygwin) wrote:
> Tom Rodma
ck -c file
> > Cygwin Package Information
> > Package Version
> > file 3.39-1
> >
> > Use -h to see help about each section
> > ~ $ printf '\377\376h\000\r\000\n\000'|file -
> > standard input: Little
Tom Rodman wrote:
On Mon 12/4/06 14:47 CST cygwin@cygwin.com wrote:
--snip
~ $ date;uname -a
Mon Dec 4 14:31:38 CST 2006
CYGWIN_NT-5.0 OurServer121 1.5.22(0.156/4/2) 2006-11-13 17:01 i686 Cygwin
~ $ printf '\377\376h\000\r\000\n\000'|file -
/dev/stdin: MPEG ADTS, l
On Mon 12/4/06 14:47 CST cygwin@cygwin.com wrote:
--snip
>~ $ date;uname -a
>Mon Dec 4 14:31:38 CST 2006
>CYGWIN_NT-5.0 OurServer121 1.5.22(0.156/4/2) 2006-11-13 17:01 i686 Cygwin
> ~ $ printf '\377\376h\000\r\000\n\000'|file -
>/dev/stdin: MPEG ADT
Thanks Corinna
On Mon 12/4/06 22:10 +0100 cygwin@cygwin.com wrote:
> On Dec 4 14:47, Tom Rodman wrote:
> > Should this directed to the "file" package maintainer?:
>
> No. You're using different versions of the `file' package. The output
> of `file' is based on data files which are updated with
On Dec 4 14:47, Tom Rodman wrote:
> Should this directed to the "file" package maintainer?:
No. You're using different versions of the `file' package. The output
of `file' is based on data files which are updated with each new version.
Hint: Don't rely on the output of file being 100% accurate
Should this directed to the "file" package maintainer?:
~ $ date;uname -a
Mon Dec 4 14:31:38 CST 2006
CYGWIN_NT-5.0 OurServer121 1.5.22(0.156/4/2) 2006-11-13 17:01 i686 Cygwin
~ $ printf '\377\376h\000\r\000\n\000'|file -
/dev/stdin: MPEG ADTS, layer I, v
that worked around the
entry point problem and provided wrappers around the stdio routines.
(The students had programmed in C++ and had never used printf/scanf
and I wanted to get them started with I/O as quickly as possible.)
Anyway the lecture notes and the library source code are online at
http:/
1 - 100 of 189 matches
Mail list logo
