On Wed, 24 May 2017 16:36:03, Steven Penny wrote:
Aren’t both wrong? By definition %i is a signed integer, and size_t is unsigned.
So %zu or %llu would be more correct:
http://wikipedia.org/wiki/C_data_types
They all seem to do the job though:
Correcting myself. Here is why you cannot use %zi
On Wed, 24 May 2017 07:33:27, Eric Blake wrote:
Buggy. size_t should be printed with %zi, not %i (since size_t and int
are not necessarily the same type).
Aren’t both wrong? By definition %i is a signed integer, and size_t is unsigned.
So %zu or %llu would be more correct:
http://wikipedia.or
Am 24.05.2017 um 12:01 schrieb Andrey Repin:
Did you notice this entry and does anyone know where this comes from?
!C:=C:\cygwin\bin
This is coming from CMD, and denotes current working directory on an indicated
drive.
And for (most of) all the hairy details, see
https://blogs.msd
Further to my first question, I also tried llrint() as below. It gives the same
output as lrint(). This may not be a big surprise as long long int and long int
have the same length.
#include /* printf */
#include/* lrint, llrint, rint */
int main ()
{
char text[64];
printf ( "
On 22/05/2017 14:39, miserable variable wrote:
I regularly see these two processes taking more that 25% CPU Time
each, as reported by ProcessExplorer.
This shouldn't be happening.
I have often terminated both not been able to notice any functionality
lost, but I am sure I am missing something
On 24/05/2017 14:54, Pavel Fedin wrote:
Hello! I'd like to report a strange bug in 64-bit bash. The following script:
cut ---
#/bin/bash -e
DIR="$( cd "$( dirname "${BASH_SOURCE[0]}" )" && pwd )"
echo Works: $DIR
cut ---
Simply exits and produces no output (never reaches echo). The
On 05/24/2017 11:53 AM, Erik Bray wrote:
>>> dropping down to assembly; it could very well be that the assembly code
>>> is incorrectly truncating things at 32 bits (where it is just fine for
>>> 32-bit Cygwin, but wrong for 64-bit):
>>>
>>> long lrint (double x)
>>> {
>>> long retval = 0L;
>>>
On Wed, May 24, 2017 at 5:55 PM, Erik Bray wrote:
> On Wed, May 24, 2017 at 2:33 PM, Eric Blake wrote:
>> On 05/24/2017 07:00 AM, Carl Fredrik Forsberg wrote:
>>> I am experiencing problems printing long int values under cygwin64
>>> installed on a Windows 10 machine.
>>>
>>> Below is a test prog
On Wed, May 24, 2017 at 2:33 PM, Eric Blake wrote:
> On 05/24/2017 07:00 AM, Carl Fredrik Forsberg wrote:
>> I am experiencing problems printing long int values under cygwin64 installed
>> on a Windows 10 machine.
>>
>> Below is a test program followed by its output to demonstrate the problem.
>>
Hello! I'd like to report a strange bug in 64-bit bash. The following script:
cut ---
#/bin/bash -e
DIR="$( cd "$( dirname "${BASH_SOURCE[0]}" )" && pwd )"
echo Works: $DIR
cut ---
Simply exits and produces no output (never reaches echo). The same script works
perfectly on 32 bits. V
> Anything suspicious in logout script?
I don't think so. Until now, I didn't even know about such a script
(I guess it's "/etc/bash.bash_logout").
Thanks anyway.
--
Dani Moncayo
--
Problem reports: http://cygwin.com/problems.html
FAQ: http://cygwin.com/faq/
Documentat
On 05/24/2017 07:00 AM, Carl Fredrik Forsberg wrote:
> I am experiencing problems printing long int values under cygwin64 installed
> on a Windows 10 machine.
>
> Below is a test program followed by its output to demonstrate the problem.
> The program was initially written to demonstrate the out
On 05/24/2017 02:52 AM, Ronald Fischer wrote:
> I have a file X which contains ASCII text, but also in some lines German
> umlaut characters. The file is classified as:
>
> $ file X
> X: ISO-8859 text, with CRLF line terminators
In ISO-8859, a German umlaut occupies one byte with the hi
I am experiencing problems printing long int values under cygwin64 installed on
a Windows 10 machine.
Below is a test program followed by its output to demonstrate the problem. The
program was initially written to demonstrate the output from lrint(), and
developed further to demonstrate to myse
On Wed, May 24, 2017 at 10:30 AM, Václav Haisman wrote:
> Hi.
>
> I have recently hit an issue ([1]) with Python 2.7 and regex package
> for it on Cygwin. It appears that Cygwin's Python 2.7 is so called
> narrow build. This causes issues when working with Unicode code point
> outside BMP, like the
On Wed, May 24, 2017 at 9:52 AM, Ronald Fischer wrote:
> I have a file X which contains ASCII text, but also in some lines German
> umlaut characters. The file is classified as:
>
> $ file X
> X: ISO-8859 text, with CRLF line terminators
>
> If I grep the file using, say,
>
> $ grep
The following packages have been uploaded to the Cygwin distribution:
* tmux-2.4-1
tmux enables a number of terminals (or windows) to be accessed and
controlled from a single terminal like screen. tmux runs as a server-client
system. A server is created automatically when necessary and holds a nu
Greetings, Dani Moncayo!
> Hi,
> subject line says it all.
> I've been experiencing this problem for some months, on windows 10.
> But the problem does not appear in another windows 8.1 system I use.
> To reproduce the problem, just open the standard cygwin terminal (e.g.
> by double-clicking t
> > If I grep the file using, say,
>
> > $ grep . X >Y
>
> > (i.e. select every non-empty line and write the result to Y), this works
> > fine, if LANG is set to one of: UTF-8, C, C.de_DE, C.en_EN, en_EN,
> > de_DE.
>
> > However, if LANG is set to C.UTF-8, two things happen:
>
> > - gr
Greetings, Brian Inglis!
> On 2017-05-23 16:30, Michael Stellar wrote:
>> I am getting the following when running my self-compiled xar 1.6.1 archiver
>> gdb xar
>> Starting program: /usr/local/bin/xar
>> [New Thread 12044.0x1f54]
>> [New Thread 12044.0xfc8]
>> [New Thread 12044.0x2dcc]
>> [New Thr
Greetings, Michael Lemke!
>> Michael Lemke writes:
>>> Now, how about an answer to my actual question? How do I get the Apache/php
>>> dlls properly rebased? For reference, here's the error again and so is the
>>> attached
>>> cygcheck.out.
>>
>> How large is your UserVM? You don't stand a sno
Greetings, Ronald Fischer!
> I have a file X which contains ASCII text, but also in some lines German
> umlaut characters. The file is classified as:
> $ file X
> X: ISO-8859 text, with CRLF line terminators
> If I grep the file using, say,
> $ grep . X >Y
> (i.e. select ever
Tried, on 1 different machine without vs 2015 and vs 2017 installed on
it, pretty much minimum env variables, getting the same result,
probably it's a bug in the cygwin runtime?,
does anyone or cygwin developer have other clue?.
On Wed, May 24, 2017 at 2:42 PM, Michael Stellar
wrote:
> Hello Bri
Hi,
subject line says it all.
I've been experiencing this problem for some months, on windows 10.
But the problem does not appear in another windows 8.1 system I use.
To reproduce the problem, just open the standard cygwin terminal (e.g.
by double-clicking the desktop icon), an then type the "ex
Hi.
I have recently hit an issue ([1]) with Python 2.7 and regex package
for it on Cygwin. It appears that Cygwin's Python 2.7 is so called
narrow build. This causes issues when working with Unicode code point
outside BMP, like the emoji code points in my issue.
Is there a chance Cygwin's Python
I have a file X which contains ASCII text, but also in some lines German
umlaut characters. The file is classified as:
$ file X
X: ISO-8859 text, with CRLF line terminators
If I grep the file using, say,
$ grep . X >Y
(i.e. select every non-empty line and write the result to Y
Hello Brian,
Appreciated the reply, tried to search "!C:" on registry or
searching for "!C:" in all files (*.*) content on c:\cygwin or using
tools like rapidee (to edit env variables), and the result is i could
not found it!.
Looks like it's being added by either the bash shell? itself or
27 matches
Mail list logo
