Re: Invalid tm_zone from localtime() when TZ is not set
On Fri, May 20, 2016 at 6:22 AM, KOBAYASHI Shinji wrote: (snip) > > localtime() calls tzsetwall() when TZ is not set. In tzsetwall(), > the StandardName and DaylightName member values retrieved by > GetTimeZoneInformation() are checked with isupper() and copied to the > char[] buffer used as the timezone name in tzparse(). However, the > type of these member values are wchar_t and isupper() is defined only > when isascii() is true. If the type of those members is WCHAR[] then using isascii() / isupper() on them is just plain wrong. The correct function to use would be iswupper(). The line if (isupper(*src)) *dst++ = *src; (where src is wchar_t* and dst is char*) assumes that the upper 8 bits of *src are zero (or *src is -1). If not, the behavior is at best implementation-defined (maybe even undefined). > So it may happen that the char[] buffer > contains invalid characters as a result of implicit cast from wchar_t > to char. > > The return value of isupper() for non-ascii characters depends on > other data, because an out of bounds access occurs for the small > (128 + 256) table used in isupper(). I confirmed the above error on > Japanese Windows with 64-bit Cygwin 2.5.0-1 and 2.5.1-1, but had no > problem with 64-bit Cygwin 2.4.1-1 nor with 32-bit Cygwins. > > So, I propose to call isascii() to assure the wchar_t fits in the > range of ASCII before calling isupper(). > > I have considered some other methods: > > 1. Using iswupper() instead of isupper(). >- Although this method is effective for Japanese environments, it > is not assured that the character iswupper() returns true fits in > the range of ASCII. It is highly likely that if the argument of iswupper() does not fit into ASCII then its result won't fit either. > 2. Add (char) cast to the argument of isupper(). >- This method assures that the copied characters are uppercase > only. However, it may be different from original characters due > to casting. > -- GCS a+ e++ d- C++ ULS$ L+$ !E- W++ P+++$ w++$ tv+ b++ DI D++ 5++ The Tao of math: The numbers you can count are not the real numbers. Life is complex, with real and imaginary parts. "Ok, it boots. Which means it must be bug-free and perfect. " -- Linus Torvalds "People disagree with me. I just ignore them." -- Linus Torvalds -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
volume shadow copy
Hello! I'm using ElkarBackup to copy backup data from servers. A few days ago a wrote a bash script to also make volume shadow copy via vssadmin... and everything works but ElkarBackup to access /proc/sys/Devices/HarddiskVolumeShadowCopy... cause it recognizes iz as symlink. I can't do anything to change rsynk at ElkarBackup to fallow symlinks. So I thought... is it possible to mount a block device of /proc/sys/Devices/HarddiskVolumeShadowCopy somewhere?!?! Thanks for your help! Regards, Matej -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: Invalid tm_zone from localtime() when TZ is not set
Hi, > Csaba Raduly wrote: > If the type of those members is WCHAR[] then using isascii() / > isupper() on them is just plain wrong. > The correct function to use would be iswupper(). I agree that isw*() functions should be used for wchar_t. But I think just changing isupper() to iswupper() is not enough as I explain below. If iswascii() was available, using both iswascii() and iswupper() might be a candidate. > The line > if (isupper(*src)) *dst++ = *src; > (where src is wchar_t* and dst is char*) assumes that the upper 8 bits > of *src are zero (or *src is -1). > If not, the behavior is at best implementation-defined (maybe even undefined). With Japanese Windows, the upper 8 bits of *src are not zero. So I would like to correct the behavior. I think adding isascii() can be a compromise. >> 1. Using iswupper() instead of isupper(). >>- Although this method is effective for Japanese environments, it >> is not assured that the character iswupper() returns true fits in >> the range of ASCII. > It is highly likely that if the argument of iswupper() does not fit > into ASCII then its result won't fit either. I'm not sure if I understand what you are saying, but for example iswupper(L'\uff21') returns 1 in Japanese locale. Regards, KOBAYASHI Shinji. -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: Help debugging a dll issue
On 5/19/2016 11:28 PM, Sam Habiel wrote: I had trouble with dlopen in Cygwin, where it did not behave intuitively. In my case, I was dlopening libicu and friends. If you search using my name on the Cygwin mailing list, you should be able to find out how I resolved the issue. I don't recall exactly what I did, but I think it was that Cygwin put everything in a global namespace, and you need to dlsym NULL to grab the function addresses. I just tried using NULL for the handle in dlsym, and I get the same result as before, and it does not change between using RTLD_LOCAL or RTLD_GLOBAL in dlopen. What I am seeing is that looking up one symbol is giving the value for a totally different one -- it's not returning an error indication. And this same wrong value is what happens if I just allow the natural linking to take place (which is what I really want to happen -- the dl calls simply help focus the issue). I will look up your previous issue, though, to see if there is something else there of use in this situation. Regards -- EM -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: Help debugging a dll issue
On Fri, May 20, 2016 at 06:37:57AM -0400, Eliot Moss wrote: > On 5/19/2016 11:28 PM, Sam Habiel wrote: > >I had trouble with dlopen in Cygwin, where it did not behave intuitively. In > >my case, I was > >dlopening libicu and friends. If you search using my name on the Cygwin > >mailing list, you should be > >able to find out how I resolved the issue. I don't recall exactly what I > >did, but I think it was > >that Cygwin put everything in a global namespace, and you need to dlsym NULL > >to grab the function > >addresses. > > I just tried using NULL for the handle in dlsym, and I get the same result as > before, and it > does not change between using RTLD_LOCAL or RTLD_GLOBAL in dlopen. > > What I am seeing is that looking up one symbol is giving the value for a > totally different > one -- it's not returning an error indication. > > And this same wrong value is what happens if I just allow the natural linking > to take place > (which is what I really want to happen -- the dl calls simply help focus the > issue). > > I will look up your previous issue, though, to see if there is something else > there of use > in this situation. > > Regards -- EM > Hi Eliot, Do you know what is the name of the totally different symbol? (maybe from nm -D) I wrote a "findit" utility a while back - it would be interesting if it gave the same answer for both symbols. If you would git clone https://github.com/duncan-roe/command_line_tools, cd to the findit subdirectory and enter "make" then you will have it. Example use: > 21:23:15$ ./findit cygwin1.dll printf > Found printf in cygwin1.dll at 0x18012ecbe > 21:24:37$ HTH ... Duncan. -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: Necessity for the assignment form
> David Stacey wrote: > For Cygwin, the boundary between trivial and substantial is usually > taken as ten lines. A two-line patch would probably be accepted > without an assignment form. Thank you for the clarification. Although I started another thread without submitting the patch, this information will be helpful next time. Regards, KOBAYASHI Shinji. -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: Help debugging a dll issue
On 5/20/2016 7:26 AM, Duncan Roe wrote: Hi Eliot, Do you know what is the name of the totally different symbol? (maybe from nm -D) Yes -- I have been using nm and objdump to examine the relevant files. The dll is called libpypy-c.dll. The symbol I want to bind to is pypy_main_startup, and its proper value (as returned by nm and objdump) is 0x6410ac60. The result I get is the value of symbol pypy_g_PyNumber_Negative (an automatically generated C function), which is 0x63443f00. I wonder if these collide in some internal hash table and the hash lookup (or the table building) is broken in some subtle way. Regards -- Eliot -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
exim rewrite rules
Hi all: We are trying to configure exim to send all local email through our sparkpost account. Exim seems to be working fine and we can send emails with "email" command through sparkpost account, but we need to make rewrites inside "From" and "To" mail headers. Inside exim.conf default file we can see: > ## > # REWRITE CONFIGURATION # > ## > # There are no rewriting specifications in this default configuration file. > begin rewrite And we paste here our rewrite rules, which are working fine inside debian jessie exim, but inside cygwing the rules are not applied. Is there a problem with exim rewrite rules inside cygwin? Are we missing something? Any other approach to make rewritings? Any help or information will be appreciate. Thank you, Mario Barcala -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
RE: exim rewrite rules
-Original Message- From: Mario Barcala Sent: Friday, May 20, 2016 8:20 AM Hi all: We are trying to configure exim to send all local email through our sparkpost account. Exim seems to be working fine and we can send emails with "email" command through sparkpost account, but we need to make rewrites inside "From" and "To" mail headers. Inside exim.conf default file we can see: > ## > # REWRITE CONFIGURATION # > ## > # There are no rewriting specifications in this default configuration file. > begin rewrite And we paste here our rewrite rules, which are working fine inside debian jessie exim, but inside cygwing the rules are not applied. Is there a problem with exim rewrite rules inside cygwin? Are we missing something? Any other approach to make rewritings? Any help or information will be appreciate. Mario I am not aware of any differences due to Cygwin that would explain that. It's the same code. You may want to run a test with debug enabled. The exim differences are related to security issues. If you give me a small example of rewrite I will take a look. Pierre Exim maintainer for cygwin -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: Help debugging a dll issue
On Fri, May 20, 2016 at 08:02:20AM -0400, Eliot Moss wrote: > On 5/20/2016 7:26 AM, Duncan Roe wrote: > > >Hi Eliot, > > > >Do you know what is the name of the totally different symbol? (maybe from nm > >-D) > > Yes -- I have been using nm and objdump to examine the relevant files. The > dll > is called libpypy-c.dll. The symbol I want to bind to is pypy_main_startup, > and > its proper value (as returned by nm and objdump) is 0x6410ac60. The result I > get is the value of symbol pypy_g_PyNumber_Negative (an automatically > generated > C function), which is 0x63443f00. > > I wonder if these collide in some internal hash table and the hash lookup (or > the table building) is broken in some subtle way. > > Regards -- Eliot > Does findit give the same answer for both symbols? If you could build your library and libdl.a with debug (-g) then you might be able to see how the lookup goes wrong. HTH ... Duncan. -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: Help debugging a dll issue
On 5/20/2016 9:36 AM, Duncan Roe wrote: On Fri, May 20, 2016 at 08:02:20AM -0400, Eliot Moss wrote: On 5/20/2016 7:26 AM, Duncan Roe wrote: Hi Eliot, Do you know what is the name of the totally different symbol? (maybe from nm -D) Yes -- I have been using nm and objdump to examine the relevant files. The dll is called libpypy-c.dll. The symbol I want to bind to is pypy_main_startup, and its proper value (as returned by nm and objdump) is 0x6410ac60. The result I get is the value of symbol pypy_g_PyNumber_Negative (an automatically generated C function), which is 0x63443f00. I wonder if these collide in some internal hash table and the hash lookup (or the table building) is broken in some subtle way. Regards -- Eliot Does findit give the same answer for both symbols? If you could build your library and libdl.a with debug (-g) then you might be able to see how the lookup goes wrong. HTH ... Duncan. Well, the wrong answer comes back from the Windows routine GetProcAddress. The bug seems to lie either in the Windows run-time code or in how the dll is being built. I am trying giving one of the functions a different name to see what happens (if it's a hash collision effect, presumably something will show up different). Regards -- EM -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
cygport depends: python3 over detection ?
Hi Yaakov, I have the impression that cygport is reporting python3 dependency also when just python is enough. On lilypond, I seen only Python 2.7 dependencies or generic ones: $ file usr/share/lilypond/2.19.42/python/* usr/share/lilypond/2.19.42/python/book_base.py: Python script, ASCII text executable usr/share/lilypond/2.19.42/python/book_base.pyc: python 2.7 byte-compiled usr/share/lilypond/2.19.42/python/book_docbook.py: Python script, ASCII text executable usr/share/lilypond/2.19.42/python/book_docbook.pyc: python 2.7 byte-compiled ... usr/share/lilypond/2.19.42/python/musicxml.py: Python script, UTF-8 Unicode text executable usr/share/lilypond/2.19.42/python/musicxml.pyc: python 2.7 byte-compiled usr/share/lilypond/2.19.42/python/rational.py: Python script, ASCII text executable usr/share/lilypond/2.19.42/python/rational.pyc: python 2.7 byte-compiled usr/share/lilypond/2.19.42/python/safeeval.py: Python script, ASCII text executable usr/share/lilypond/2.19.42/python/safeeval.pyc: python 2.7 byte-compiled I don't see anything that specifically requires python3. I uploaded here http://matzeri.altervista.org/works/cygport/ the log of $ cygport --debug lilypond.cygport depends |& tee depends.log and here the packages: http://matzeri.altervista.org/x86_64/lilypond/ (I removed python3 from setup.hint manually) Regards Marco -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: [RFC] splitting documentation
On 19/05/2016 22:34, Marco Atzeri wrote: To move the documentation in a noarch package I split lilypond in two source packages. http://matzeri.altervista.org/noarch/lilypond-doc/ http://matzeri.altervista.org/x86/lilypond/ http://matzeri.altervista.org/x86_64/lilypond/ The documentation is just a copy of the upstream PDF so : - the source package is a dummy to avoid data duplication I can see why you want to do this, but I'm not sure it's a good idea. One reason being, *IF* we were to ever end up in the situation where only source packages were uploaded, and some build service constructed the binary packages, that builder would not be permitted to download arbitrary files. - the install phase phase grab the files from upstream an put in the proper directory. Question: - How to properly replace the old layout with the new in upload ? I expect that "calm" could complain about: x86/release/lilypond/lilypond-doc/lilypond-doc-2.19.37-1.tar.xz noarch/release/lilypond-doc/lilypond-doc-2.19.42-1.tar.xz Yes, this is not permitted (at the moment). All versions of a package in the package set for a given arch must lie on the same path. (This limitation is tangled up with how we determine if a package upload is permitted, so isn't straightforward to remove) Should I move both as : noarch/release/lilypond-doc/lilypond-doc-2.19.37-1.tar.xz noarch/release/lilypond-doc/lilypond-doc-2.19.42-1.tar.xz Move the existing 2.19.37-1 x86/x86_64 package to noarch, then upload of 2.19.42-1 will be permitted (using cygport 0.22.0 or later, which knows to upload noarch packages to noarch/ paths) -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: Proposed patch for web site: update most links to HTTPS
On Apr 24 17:18, Brian Clifton wrote: > Hi folks, > > I have a proposed change for the web site. This patch (see below) will update > most of the urls to HTTPS. In many cases there was a redirect; for those I > captured the new canonical address. > > (Per the https://cygwin.com/contrib.html, this is *not* a change to anything > in the winsup directory, which is why I chose the cygwin@cygwin distro) > > The patch can be found here: > https://patch.clifton.io/cygwin/cygwin-htdocs_bsclifton_https_20160424.patch Thanks for the patch, but, here's a question: Since Cygwin.com redirects http requests to https anyway, all links to cygwin.com (or, FWIW, sourceware.org) will end up as https requests anyway. Having said that, wouldn't it make sense then to avoid absolute links to cygwin.com and rather convert them to relative links, i.e.: -http://cygwin.com/ml/cygwin/2003-03/msg02182.html";>Inspired by +Inspired by ? Thanks, Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Maintainer cygwin AT cygwin DOT com Red Hat signature.asc Description: PGP signature
Re: Cygwin website / docs
On Apr 23 18:26, Brian Clifton wrote: > Awesome thanks, Corinna! :) > > If I did have changes for review, what does that process look like? I > looked at the FAQ and didn't see anything RE: that. Would it be best > to link to tar up and link to a patch (rebased against the live remote > repo) in the mailing list? Ideally send the patch here or to the cygwin-apps list. Preferredly as plain text attachment, not just an URL. Thanks, Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Maintainer cygwin AT cygwin DOT com Red Hat signature.asc Description: PGP signature
Re: [PATCH] index.html: Minor whitespace fix
On Apr 28 11:49, Adam Dinwoodie wrote: > > --- > index.html | 4 ++-- > 1 file changed, 2 insertions(+), 2 deletions(-) > > diff --git a/index.html b/index.html > index c36ec70..dfeb4d5 100755 > --- a/index.html > +++ b/index.html > @@ -72,8 +72,8 @@ href="faq.html">FAQ, the href="cygwin-ug-net.html">User's > Guide and the mailing list > archives. If you've exhausted these resources then please send > -email to an appropriate mailing list > -. This includes observations about web pages, setup > +email to an appropriate mailing list. > +This includes observations about web pages, setup > questions, questions about where to find things, questions about why > things are done a certain way, questions about the color preferences of > Cygwin developers, questions about the meaning of the number 42, > -- > 2.8.0 Applied. Thanks, Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Maintainer cygwin AT cygwin DOT com Red Hat signature.asc Description: PGP signature
Re: [PATCH] Git is Git, not GIT
Hi Adam, On Apr 28 12:02, Adam Dinwoodie wrote: > --- > contrib.html | 6 +++--- > cvs.html | 20 ++-- > cygwin-ug-net/setup-net.html | 4 ++-- > faq/faq.html | 2 +- > git.html | 28 ++-- > lists.html | 4 ++-- > navbar.html | 2 +- > 7 files changed, 33 insertions(+), 33 deletions(-) This patch can't apply. Please note that the cygwin-api, cygwin-ug-net, and faq subdirs are maintained as part of the cygwin repo itself. Only the generic stuff is maintained in the htdocs repo. Can you please split up the patch in two chunks, one based on the Cygwin repo patching winsup/doc/setup-net.xml(!), and one the rest of the pack? Thanks, Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Maintainer cygwin AT cygwin DOT com Red Hat signature.asc Description: PGP signature
Re: Interface friendly names for AF_INET6
On May 13 17:00, Marco Atzeri wrote:
> On 10/03/2016 18:41, Corinna Vinschen wrote:
> > >
> > > I assume the ifall structures are not visible outside cygwin internal,
> > > correct ?
> > >
> > > If so a ifall_data pointer should cover my current trial.
> >
> > Try the latest snapshot. The ifa_data member now contains a pointer
> > to a struct ifa_hwdata which is defined in .
> >
> >
> > Thanks,
> > Corinna
> >
>
> Hi Corinna,
>
> thanks for it
>
> $ ./get-interface-64.exe
> internal_name: {EC2ABB5C-42A8-431D-A133-8F4BE0F309AF}
> flags: AF_INET6 up multicast
> address: fe80::a479:1393:b7d0:fb25%18
> friendly_name: Local Area Connection 2
>
> internal_name: {EC2ABB5C-42A8-431D-A133-8F4BE0F309AF}
> flags: AF_INET up broadcast multicast
> address: 169.254.251.37
> friendly_name: Local Area Connection 2
>
> internal_name: {9213DBB8-80C6-4316-AA7A-EBF8AD7661E1}
> flags: AF_INET6 up multicast
> address: fe80::8c29:45f0:47fa:536%24
> friendly_name: Wireless Network Connection 3
>
> internal_name: {9213DBB8-80C6-4316-AA7A-EBF8AD7661E1}
> flags: AF_INET up broadcast multicast
> address: 169.254.5.54
> friendly_name: Wireless Network Connection 3
> ...
Glad it works as desired.
Thanks for your feedback,
Corinna
--
Corinna Vinschen Please, send mails regarding Cygwin to
Cygwin Maintainer cygwin AT cygwin DOT com
Red Hat
signature.asc
Description: PGP signature
Can I eliminate diagnostic messages from cp
I use cp as my backup tool from disk to USB. There are maybe 40,000 files involved and each one has a message of "cp: preserving permissions for ’: Not supported". These messages slow down the backup and obscure meaningful faults. Is there any option for removing the messages? My command line is: cp / thanks art -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: Can I eliminate diagnostic messages from cp
On 5/20/2016 1:45 PM, lostbits wrote: I use cp as my backup tool from disk to USB. There are maybe 40,000 files involved and each one has a message of "cp: preserving permissions for ’: Not supported". These messages slow down the backup and obscure meaningful faults. Is there any option for removing the messages? My command line is: cp / Umm, add command line flags that don't request the permissions to be set? E.g., --no-preserve=mode You can play around with the various options of preserving / not preserving mode, ownership, date/time, etc. Regards -- Eliot -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: Can I eliminate diagnostic messages from cp
Greetings, lostbits! > I use cp as my backup tool from disk to USB. There are maybe 40,000 > files involved and each one has a message of > "cp: preserving permissions for ’: Not supported". These messages > slow down the backup and obscure meaningful faults. Is there any option > for removing the messages? > My command line is: cp / If your USB is formatted in FAT, then --preserve=none will get rid of these messages. As FAT doesn't really support anything at all. -- With best regards, Andrey Repin Friday, May 20, 2016 20:49:46 Sorry for my terrible english...
Re: [RFC] splitting documentation
Jon Turney writes: > I can see why you want to do this, but I'm not sure it's a good idea. Sent to the wrong list? Regards, Achim. -- +<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+ Factory and User Sound Singles for Waldorf Q+, Q and microQ: http://Synth.Stromeko.net/Downloads.html#WaldorfSounds -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: Segfault in MAP_NORESERVE mmap above ~4GB
Hi Erik,
On May 12 15:30, Erik Bray wrote:
> Hi all,
>
> This issue pertains to Cygwin 64-bit. The following example program
> demonstrates the issue:
>
> $ cat mmap_test.c
> #include
> #include
> #include
>
>
> #define VSIZE 0x11000
> #define SIZE 0x1000
>
>
> void foo() {
> void *top, *bot, *c;
>
> c = mmap(NULL, VSIZE, PROT_READ|PROT_WRITE,
> MAP_PRIVATE|MAP_ANONYMOUS|MAP_NORESERVE, -1, 0);
>
> top = c + VSIZE;
> bot = top - SIZE;
>
> printf(" c = 0x%016lx\n", c);
> printf(" top = 0x%016lx\n", top);
> printf(" bot = 0x%016lx\n", bot);
>
> printf(" c[0] = %ul\n", *((unsigned long *)c));
> printf("bot[0] = %ul\n", *((unsigned long *)bot));
> }
>
>
> int main(void) {
> foo();
> return 0;
> }
>
> $ gcc mmap_test.c -o mmap_test
>
> $ ./mmap_test.exe
> c = 0x06fe
>top = 0x06ff1000
>bot = 0x06ff
> c[0] = 0l
> Segmentation fault (core dumped)
>
> --
Thanks especially for the testcase. I just applied a fix for this
which, hopefully, catches all problems with too small length/size
variables and parameters.
I've uploaded a new developer snapshot to https://cygwin.com/snapshots/
Would you mind to inspect the patch(*) critically?
Thanks a lot,
Corinna
(*)
https://sourceware.org/git/gitweb.cgi?p=newlib-cygwin.git;a=commitdiff;h=0aa738220bb9dea2ad479e484560767b36701947
--
Corinna Vinschen Please, send mails regarding Cygwin to
Cygwin Maintainer cygwin AT cygwin DOT com
Red Hat
signature.asc
Description: PGP signature
Re: Proposed patch for web site: update most links to HTTPS
On May 20, 2016, at 10:36 AM, Corinna Vinschen wrote: > > On Apr 24 17:18, Brian Clifton wrote: >> >> This patch (see below) will update most of the urls to HTTPS. > > Since Cygwin.com redirects http requests to https anyway, all links > to cygwin.com (or, FWIW, sourceware.org) will end up as https requests > anyway. Additionally, cygwin.com is using HSTS with a half-year expiration time, which means you’ll only visit via HTTP *once*, ever, unless you stop visiting cygwin.com for over half a year. Excepting that case, any HSTS-compliant web client will use HTTPS even if you type HTTP. https://en.wikipedia.org/wiki/HTTP_Strict_Transport_Security You can fix the remaining TOFU problem with the EFF’s “HTTPS Everywhere” plugin for Firefox, Chrome, and Opera: https://www.eff.org/HTTPS-everywhere https://en.wikipedia.org/wiki/Trust_on_first_use https://www.eff.org/https-everywhere/atlas/domains/cygwin.com.html > wouldn't it make sense then to avoid absolute links > to cygwin.com and rather convert them to relative links Internal links within the docs should always use relative URLs, but external links should be absolute. Why? Install cygwin-doc, then say: $ info cygwin-ug-net Now drill down to Cygwin Overview > A brief history of the Cygwin project. The first cygwin.com link (to the ML) should be absolute, but the second (to using-utils.html) should be relative so info(1) can follow it. (Actually, the problem with the second link is that it’s probably using the wrong DocBook link type, so it’s forced to consider it a web link, instead of realizing that it can resolve it as an internal cross-reference.) -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: How to remove pesky persistent +x bits that chmod -x won't remove
On May 19, 2016, at 7:01 PM, Warren Young wrote:
>
> For what it’s worth, setfacl -bk followed by a chmod -x sometimes always
> fixes this.
I’ve solved this by applying that fix to the affected directory trees in bulk:
$ find foo bar baz -exec setfacl -kb {} \;
Heavy-handed, but it works.
--
Problem reports: http://cygwin.com/problems.html
FAQ: http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
