On May 12 13:53, Ryan Johnson wrote:
> On 12/05/2011 1:11 PM, Corinna Vinschen wrote:
> >On May 12 18:55, Corinna Vinschen wrote:
> >>On May 12 12:31, Ryan Johnson wrote:
> >>>On 12/05/2011 11:09 AM, Corinna Vinschen wrote:
> >>>>-void *base;
>
On May 12 20:42, Corinna Vinschen wrote:
> I created a test application with several heaps [...]
Btw., here's my test app. It's ugly but it's just for testing the
results anyway.
Corinna
#include
#define _WIN32_WINNT 0x0601
#include
#include
#include
typedef struct
On May 12 15:19, Ryan Johnson wrote:
> On 12/05/2011 2:48 PM, Corinna Vinschen wrote:
> >Nope. As I wrote in my previoous mail and as you can still see in my
> >quote above, the two virtual memory areas from 0x2 to 0x3 and
> >from 0x3 to 0x23 together cons
On May 12 20:42, Corinna Vinschen wrote:
> As for the big blocks, they are apparently identified by the value in
> the "Unknown" member of the DEBUG_HEAP_BLOCK structure. Here's what I
> figured out so far as far as "Unknown" is concerned:
Scratch that. I fin
On May 12 15:30, Ryan Johnson wrote:
> On 12/05/2011 2:42 PM, Corinna Vinschen wrote:
> >On May 12 13:53, Ryan Johnson wrote:
> >>On 12/05/2011 12:55 PM, Corinna Vinschen wrote:
> >>>>>heap *heaps;
> >>>>This is a misnomer now -- it's rea
ative to CVS HEAD?
Thanks,
Corinna
--
Corinna Vinschen Please, send mails regarding Cygwin to
Cygwin Project Co-Leader cygwin AT cygwin DOT com
Red Hat
Hi Yaakov,
On May 15 14:31, Yaakov (Cygwin/X) wrote:
> On Sun, 2011-05-15 at 21:11 +0200, Corinna Vinschen wrote:
> > I just applied a patch to implement pthread_attr_setstack etc.
>
> Yes, I just saw that, thank you.
>
> > This affects your patch in that it won
On May 16 18:10, Yaakov (Cygwin/X) wrote:
> On Mon, 2011-05-16 at 12:43 +0200, Corinna Vinschen wrote:
> > Thanks for this patch. It looks good to me with two exceptions:
> > [...]
> Revised patch attached.
Thank you. You can apply it, but while I was looking into it,
On May 17 04:10, Yaakov (Cygwin/X) wrote:
> On Tue, 2011-05-17 at 07:58 +0200, Corinna Vinschen wrote:
> > Thank you. You can apply it, but while I was looking into it,
> > this occured to me:
> >
> > This conversion arithmetic from FILETIME to long long happens
On May 18 01:08, Yaakov (Cygwin/X) wrote:
> I have found some more discrepancies in posix.sgml. Patch attached.
Thanks, go ahead.
Corinna
--
Corinna Vinschen Please, send mails regarding Cygwin to
Cygwin Project Co-Leader cygwin AT cygwin DOT com
Red Hat
On May 18 01:46, Yaakov (Cygwin/X) wrote:
> These are the patches for exporting __fpurge(3) on our side, once my
> patch on newlib@ is approved.
After we got note from Ralf on the newlib list on the #ifndef __rtems__
issue, this will be obviously good to go as well.
Thanks,
Corinna
--
C
. Then you can block the unwanted
space and call LoadLibrary again. See (*) for a discussion how
you can unload the exe itself to reload another one. Maybe that's
something we can look into as well. ObNote: Of course, if we
could influnce the address at which a DLL gets loaded right from the
perror without the newlib patch.
You can apply this together with the newlib patch. But please
make sure that you also tested the newlib-only implementation.
Thanks,
Corinna
--
Corinna Vinschen Please, send mails regarding Cygwin to
Cygwin Project Co-Leader cygwin AT
On May 24 07:27, Ryan Johnson wrote:
> On 23/05/2011 3:31 AM, Corinna Vinschen wrote:
> >On May 22 14:42, Ryan Johnson wrote:
> >>In theory, this should completely eliminate the case where us
> >>loading one DLL pulls in dependencies automatically (= uncontrolled
>
al to the list
maintained in the PEB_LDR_DATA member InInitializationOrderModuleList?
Or, in other words, can't we just use the data which is already
available?
Corinna
--
Corinna Vinschen Please, send mails regarding Cygwin to
Cygwin Project Co-Leader cygwin AT cygwin DOT com
Red Hat
etry): Don't retry on unknown exit_code
> from non-cygwin programs.
This looks ok to me, but cgf should have a say here. He's on vacation
for another week, though.
Thanks,
Corinna
--
Corinna Vinschen Please, send mails regarding Cygwin to
Cygwin Project Co-L
nd I can see how it belongs to
the Cygwin utils given that getconf on Linux is part of glibc. I'm
inclined to stick it into utils for the latter reason. Chris? What's
your stance?
Corinna
--
Corinna Vinschen Please, send mails regarding Cygwin to
Cygwin
int _EXFUN(clock_nanosleep, ...
Additionally _POSIX_CLOCK_SELECTION has to be activated in features.h.
Would you mind to send this patch to the newlib list then?
I haven't much time right now. If cgf doesn't beat me to it, I'll
review the function later.
Thanks,
Corinna
--
C
On Jul 20 04:50, Yaakov (Cygwin/X) wrote:
> On Wed, 2011-07-20 at 04:16 -0500, Yaakov (Cygwin/X) wrote:
> > On Wed, 2011-07-20 at 09:56 +0200, Corinna Vinschen wrote:
> > > This doesn't look right. In contrast to nanosleep, clock_nanosleep
> > > is not subsumed und
On Jul 20 17:03, Yaakov (Cygwin/X) wrote:
> On Wed, 2011-07-20 at 16:11 +0200, Corinna Vinschen wrote:
> > (*) Does it also influence pthread_cond_timedwait? This information seems
> > to be missing in SUSv4.
>
> The last paragraph of RATIONALE -> Timed Wait Sema
On Jul 20 21:22, Yaakov (Cygwin/X) wrote:
> On Wed, 2011-07-20 at 17:03 -0500, Yaakov (Cygwin/X) wrote:
> > On Wed, 2011-07-20 at 16:11 +0200, Corinna Vinschen wrote:
> > > The only problem I see is the fact that a call to clock_settime
> > > influences calls to cl
On Jul 21 11:21, Corinna Vinschen wrote:
> On Jul 20 21:22, Yaakov (Cygwin/X) wrote:
> > Looking at the other uses of cancelable_wait(), would the following make
> > sense:
> >
> > * change the timeout argument to struct timespec *;
> > * cancelable_wait (object,
mething else occured to me, but I think we should do this in an extra
step, if at all. IMO the family of sleep functions should be moved out
of signal.cc into times.cc. It just seems to belong there.
Corinna
--
Corinna Vinschen Please, send mails regarding Cygwin to
Cygw
On Jul 21 13:51, Yaakov (Cygwin/X) wrote:
> On Thu, 2011-07-21 at 12:37 +0200, Corinna Vinschen wrote:
> > Something else occured to me, but I think we should do this in an extra
> > step, if at all. IMO the family of sleep functions should be moved out
> > of signal.cc in
On Jul 21 13:59, Yaakov (Cygwin/X) wrote:
> On Thu, 2011-07-21 at 11:35 +0200, Corinna Vinschen wrote:
> > On Jul 21 11:21, Corinna Vinschen wrote:
> > > No, you're not at all off-base. Personally I'd prefer to use the native
> > > NT timer functions, but
On Jul 21 21:09, Corinna Vinschen wrote:
> On Jul 21 13:59, Yaakov (Cygwin/X) wrote:
> > On Thu, 2011-07-21 at 11:35 +0200, Corinna Vinschen wrote:
> > > On Jul 21 11:21, Corinna Vinschen wrote:
> > > > No, you're not at all off-base. Personally I'd p
On Jul 22 01:34, Yaakov (Cygwin/X) wrote:
> On Thu, 2011-07-21 at 21:15 +0200, Corinna Vinschen wrote:
> > On Jul 21 21:09, Corinna Vinschen wrote:
> > > On Jul 21 13:59, Yaakov (Cygwin/X) wrote:
> > > Good idea. The value can be immediately used in NtSetTimer and it
&g
Hi Yaakov,
anything new from the clock_nanosleep frontier?
On Jul 21 13:51, Yaakov (Cygwin/X) wrote:
> On Thu, 2011-07-21 at 12:37 +0200, Corinna Vinschen wrote:
> > Given our current discussion to change cancelable_wait, does it make
> > sense to review this patch?
Corinna reported that having
> the value set had no effect in her test cases so I don't think your
> analysis here is 100% correct.
Erm, I tested on 32 bit. The slowdown occured on all platforms, not
only 64 bit. 64 bit is still only half as fast in the date loop for
reason or reasons unkn
On Jul 31 14:51, Christopher Faylor wrote:
> On Sun, Jul 31, 2011 at 10:26:23AM +0200, Corinna Vinschen wrote:
> >On Jul 30 17:04, Christopher Faylor wrote:
> >> On Fri, Jul 29, 2011 at 08:41:10PM +0900, jojelino wrote:
> >> >As sigproc_init is called during dll init
Hi guys,
the copyright assignment for Jinn-woo Ye (jojelino) arrived. Patch
away.
Corinna
--
Corinna Vinschen Please, send mails regarding Cygwin to
Cygwin Project Co-Leader cygwin AT cygwin DOT com
Red Hat
On Aug 1 23:09, Yaakov (Cygwin/X) wrote:
> On Sun, 2011-07-31 at 10:24 +0200, Corinna Vinschen wrote:
> > anything new from the clock_nanosleep frontier?
>
> Sorry, I've been having elusive problems with CVS HEAD that have been
> making it hard to test my patch.
>
&
On Aug 3 01:20, Yaakov (Cygwin/X) wrote:
> On Tue, 2011-08-02 at 17:42 +0200, Corinna Vinschen wrote:
> > Does that mean the return value from NtQueryTimer is unreliable?
> > In what way is it wrong?
>
> I'm not sure. When I run an STC (attached), it works as expec
On Aug 3 04:19, Yaakov (Cygwin/X) wrote:
> On Wed, 2011-08-03 at 09:45 +0200, Corinna Vinschen wrote:
> > On Aug 3 01:20, Yaakov (Cygwin/X) wrote:
> > > On Tue, 2011-08-02 at 17:42 +0200, Corinna Vinschen wrote:
> > > > Does that mean the return value from NtQueryT
On Aug 3 04:35, Yaakov (Cygwin/X) wrote:
> On Wed, 2011-08-03 at 11:27 +0200, Corinna Vinschen wrote:
> > On Aug 3 04:19, Yaakov (Cygwin/X) wrote:
> > > Never mind, I figured it out. The difference is the timeout to
> > > WaitFor*Object*(); my STC doesn'
eep.
> (sleep): Ditto.
> (usleep): Ditto.
> * thread.cc: Mark clock_nanosleep in list of cancellation points.
> * include/cygwin/version.h (CYGWIN_VERSION_API_MINOR): Bump.
Thumbs up.
Thank you,
Corinna
--
Corinna Vinschen Please, send mails regar
On Aug 18 13:54, Yaakov (Cygwin/X) wrote:
> * sysv_shm.cc (ACCESSPERMS): Remove to fix redefined warning, as
> this is now defined in .
Please apply.
Thanks,
Corinna
--
Corinna Vinschen Please, send mails regarding Cygwin to
Cygwin Project Co-
ty2
$ ls -l /dev/tty
crw--w 1 corinna vinschen 136, 2 Aug 18 21:51 /dev/tty
Same for /dev/console. Chris, is it tricky to return always the
real major, minor pairs 5, 0 and 5, 1 for /dev/tty and /dev/console?
> Here is a second version which adds the closely related /proc/misc[1] as
On Aug 18 20:54, Yaakov (Cygwin/X) wrote:
> On Thu, 2011-08-18 at 21:55 +0200, Corinna Vinschen wrote:
> > > 2011-08-18 Yaakov Selkowitz
> > >
> > > * devices.h (fh_devices): Define DEV_MISC_MAJOR, DEV_MEM_MAJOR,
> > > DEV_SOUND_MAJOR. Use throughou
the child's address space, leading to base address
> +collisions which rebasing cannot fix. The only way to resolve this
> +problem is to remove (usually uninstall) the offending
> +app.
> +In summary, current Windows implementations make it
> +impossible to implement a perfectly reliable fork, and occasional
> +fork failures are inevitable. PTC.
> +
> +
> +
Corinna
--
Corinna Vinschen Please, send mails regarding Cygwin to
Cygwin Project Co-Leader cygwin AT cygwin DOT com
Red Hat
efault to some $LANG, while setting the LC_xxx
values is the job of the user if the $LANG value doesn't suffice.
However, if the user wants to do that, we will have the new flag.
Corinna
--
Corinna Vinschen Please, send mails regarding Cygwin to
Cygwin Project Co-Leader cygwin AT cygwin DOT com
Red Hat
On Oct 9 11:31, Andy Koppe wrote:
> On 8 October 2011 16:03, Corinna Vinschen wrote:
> > Therefore, afaics, it would be better if we change locale to use the
> > GetFooDefaultUILanguage functions by default, and we add a modifier
> > (-r/--region?) to switch to LOCALE_FOO_DE
Hi Yaakov,
On Jul 19 09:43, Corinna Vinschen wrote:
> On Jul 18 21:20, Yaakov (Cygwin/X) wrote:
> > This patch adds getconf(1) as required by POSIX:
>
> This looks good. I'm just wondering... on one hand the code seems to
> have nothing Cygwin-specifc and could be packed
On Oct 11 11:45, Yaakov (Cygwin/X) wrote:
> On Mon, Oct 10, 2011 at 10:04, Corinna Vinschen wrote:
> > what I didn't realize at the time was the fact that you didn't provide a
> > documentation patch, too. My latest patch to utils.sgml adds a short
> > descript
ersonally I don't plan
to look into W8 so soon. Stuff like that is bound to change this early
in the release game anyway.
Therefore I don't want to disable this message. If you're interested
to get rid of it, it would be most helpful trying to track down how to
find the global
the relocation support
in libintl trying to accomplish? Why does a internationalization
library has to know the path of a module based on an address?
Is that a functionality required on other POSIX systems?
Can we discuss this on cygwin-developers first, please? So far I doubt
th
On Nov 2 20:53, Christian Franke wrote:
> On Jun 24, Corinna Vinschen wrote:
> >Hi Christian,
> >
> >On Jun 23 19:52, Christian Franke wrote:
> >>If a non-Cygwin .exe started from a Cygwin shell window segfaults,
> >>Cygwin restarts the .exe 5 times.
>
s, especially when heap
and mmaps are out of the way, and given that the more recent rebaseall
will not create an arbitrary 64K hole between DLLs anymore when
rebasing.
With these changes, feel free to check in the patch.
Thanks,
Corinna
--
Corinna Vinschen Please, send mails regarding Cygwin to
Cygwin Project Co-Leader cygwin AT cygwin DOT com
Red Hat
o create portable, multibyte-aware code:
wchar_t wc;
mbtowc (&wc, s, strlen (s));
if (iswalpha ((wint_t) wc))
Corinna
--
Corinna Vinschen Please, send mails regarding Cygwin to
Cygwin Project Co-Leader cygwin AT cygwin DOT com
Red Hat
nice addition to create sylinks in SUA, but the way
they have been implemented even disqualifies them for usage in SUA.
That's probably the reason SUA still creates its own symlink style
to date.
--
Corinna Vinschen Please, send mails regarding Cygwin to
Cygwin Project Co-Leader cygwin AT cygwin DOT com
Red Hat
tcut-style symlinks contain the POSIX path as well
and Cygwin only utilizes the POSIX path. See symlink_info::check_shortcut.
Corinna
--
Corinna Vinschen Please, send mails regarding Cygwin to
Cygwin Project Co-Leader cygwin AT cygwin DOT com
Red Hat
ll : (LONGLONG) freq;
> }
>
> UINT
Thanks, applied.
Corinna
--
Corinna Vinschen Please, send mails regarding Cygwin to
Cygwin Project Co-Leader cygwin AT cygwin DOT com
Red Hat
t;winsymlink"
setting. It seemed such a good idea at the time, but the extra
code necessary to support .lnk symlinks transparently is a big
mess.
--
Corinna Vinschen Please, send mails regarding Cygwin to
Cygwin Project Co-Leader cygwin AT cygwin DOT com
Red Hat
for those who really want them there are tools out
there to create them, but in these cases the tool provider has to take
the support burden.
Corinna
--
Corinna Vinschen Please, send mails regarding Cygwin to
Cygwin Project Co-Leader cygwin AT cygwin DOT com
Red Hat
On Jan 12 05:28, Yaakov (Cygwin/X) wrote:
> New header just committed to newlib. Patch attached.
Yup, go ahead.
Thanks,
Corinna
--
Corinna Vinschen Please, send mails regarding Cygwin to
Cygwin Project Co-Leader cygwin AT cygwin DOT com
Red Hat
On Jan 13 03:26, Yaakov (Cygwin/X) wrote:
> New feature just added to newlib. Patch for winsup/doc attached.
Yep.
Corinna
--
Corinna Vinschen Please, send mails regarding Cygwin to
Cygwin Project Co-Leader cygwin AT cygwin DOT com
Red Hat
come useful and their (different) implementation probably falls into
place.
Corinna
--
Corinna Vinschen Please, send mails regarding Cygwin to
Cygwin Project Co-Leader cygwin AT cygwin DOT com
Red Hat
On Feb 24 02:38, Yaakov (Cygwin/X) wrote:
> The pldd(1) command apparently originates from Solaris and was added to
> glibc-2.15[1]. Patches and new file attached.
Looks good, works fine. Please apply.
Thanks,
Corinna
--
Corinna Vinschen Please, send mails regarding
On Feb 24 05:00, Yaakov (Cygwin/X) wrote:
> On Fri, 2012-02-24 at 10:38 +0100, Corinna Vinschen wrote:
> > On Feb 23 21:38, Yaakov (Cygwin/X) wrote:
> > > This patchset adds pthread_getname_np and pthread_setname_np. These
> > > were added to glibc in 2.12[1] and are a
On Feb 24 15:31, Christopher Faylor wrote:
> On Fri, Feb 24, 2012 at 10:47:07AM +0100, Corinna Vinschen wrote:
> >On Feb 24 02:38, Yaakov (Cygwin/X) wrote:
> >> The pldd(1) command apparently originates from Solaris and was added to
> >> glibc-2.15[1]. Patches and new
ting MAXPATHLEN to 8192.
I change that in CVS.
Corinna
--
Corinna Vinschen Please, send mails regarding Cygwin to
Cygwin Project Co-Leader cygwin AT cygwin DOT com
Red Hat
On Mar 8 14:37, Václav Zeman wrote:
> Hi.
>
> Here is a tiny patch to avoid calling strlen() twice in readlink().
>
> ChangeLog:
>
> 2012-03-08 Václav Zeman <...>
>
> * path.cc (readlink): Avoid calling strlen() twice.
Thanks, applied
27;s an inline method. I'm pretty
sure the compiler will optimize this just fine.
Corinna
--
Corinna Vinschen Please, send mails regarding Cygwin to
Cygwin Project Co-Leader cygwin AT cygwin DOT com
Red Hat
{
> LARGE_INTEGER t;
> t.HighPart = SharedUserData.InterruptTime.High1Time;
> t.LowPart = SharedUserData.InterruptTime.LowPart;
> if (t.HighPart == SharedUserData.InterruptTime.High2Time)
> return t.QuadPart;
>
> for (;;)
> ;
> }
Wow, thanks a lot for figurin
unction to handle this, along the
lines of the getwinenv function and the conv_envvars array.
It might only contain TZ now, but there's always a chance we suddenly
stumble over a similar problem, isn't it?
Corinna
--
Corinna Vinschen Please, send mails regarding Cy
attached.
I uploaded the changes to the FAQ pages on cygwin.com.
Thanks,
Corinna
--
Corinna Vinschen Please, send mails regarding Cygwin to
Cygwin Project Co-Leader cygwin AT cygwin DOT com
Red Hat
ease use __small_sprintf rather than
sprintf. I also changed the CHangeLog entry slightly. Keep it short
and in present tense.
Thanks,
Corinna
--
Corinna Vinschen Please, send mails regarding Cygwin to
Cygwin Project Co-Leader cygwin AT cygwin DOT com
Red Hat
On Apr 24 21:35, Thomas Wolff wrote:
> Am 24.04.2012 16:44, schrieb Corinna Vinschen:
> >On Apr 22 21:07, Thomas Wolff wrote:
> >>This patch replaces my previous proposal
> >>(http://cygwin.com/ml/cygwin-patches/2012-q2/msg5.html) with two
> >>modifica
On Apr 24 21:45, Corinna Vinschen wrote:
> On Apr 24 21:35, Thomas Wolff wrote:
> > Am 24.04.2012 16:44, schrieb Corinna Vinschen:
> > >On Apr 22 21:07, Thomas Wolff wrote:
> > >>This patch replaces my previous proposal
> > >>(http://cygwin.com/ml/cygw
On Apr 24 22:00, Thomas Wolff wrote:
> Am 24.04.2012 21:47, schrieb Corinna Vinschen:
> >On Apr 24 21:45, Corinna Vinschen wrote:
> >>That was exactly the patch I applied. I only chnaged the formatting
> >>and changed sprintf to __small_sprintf.
> >...and as far
On Apr 24 23:58, Thomas Wolff wrote:
> Am 24.04.2012 22:22, schrieb Corinna Vinschen:
> >On Apr 24 22:00, Thomas Wolff wrote:
> >>Am 24.04.2012 21:47, schrieb Corinna Vinschen:
> >>>On Apr 24 21:45, Corinna Vinschen wrote:
> >>>>That was exactly the pa
rchr.
> * include/cygwin/version.h (CYGWIN_VERSION_API_MINOR): Bump.
> 2012-05-09 Yaakov Selkowitz
>
> * new-features.sgml (ov-new1.7.15): Document memrchr.
Thanks, applied.
Corinna
--
Corinna Vinschen Please, send mails regarding Cygwin to
Cygwin Proje
nt_fsname = buf, mnt->mnt_fsname);
mntbuf->mnt_type = stpcpy (mntbuf->mnt_dir, mnt->mnt_dir);
mntbuf->mnt_opts = stpcpy (mntbuf->mnt_type, mnt->mnt_type);
mntbuf->mnt_freq = mnt->mnt_freq;
mntbuf->mnt_passno = mnt->mnt_passno;
memcpy (buf, tmpbuf, buflen);
return mntbuf;
Corinna
--
Corinna Vinschen Please, send mails regarding Cygwin to
Cygwin Project Co-Leader cygwin AT cygwin DOT com
Red Hat
On Jun 5 14:42, Corinna Vinschen wrote:
> Hi Yaakov,
>
> thanks for the patch, but this won't fly.
>
> On Jun 5 00:08, Yaakov (Cygwin/X) wrote:
> > This patch set implements getmntent_r, a GNU extension:
> >
> > http://man7.org/linux/man-pages/man3/getmnt
And I missed a line in my dirty code example:
On Jun 5 14:42, Corinna Vinschen wrote:
> What you want is more like this (untested):
>
> struct mntent *mnt = mount_table->getmntent (_my_tls.locals.iteration++);
> if (!mnt)
> return NULL;
>int maxlen = st
On Jun 5 16:39, Corinna Vinschen wrote:
> And I missed a line in my dirty code example:
And I missed to add a + 1 to the pointers returned from stpcpy. Sigh.
Let's restart:
struct mntent *mnt = mount_table->getmntent (_my_tls.locals.iteration++);
if (!mnt)
return NULL;
On Jun 5 21:29, Yaakov (Cygwin/X) wrote:
> On 2012-06-05 07:42, Corinna Vinschen wrote:
> >>+extern "C" struct mntent *
> >>+getmntent_r (FILE *, struct mntent *mntbuf, char *buf, int buflen)
> >>+{
> >>+ struct mntent *mnt = mount_table->
On Jul 18 05:21, Yaakov (Cygwin/X) wrote:
> Somehow this one fell through the cracks. Picking up where we left off:
>
> On 2012-06-06 02:33, Corinna Vinschen wrote:
> >On Jun 5 21:29, Yaakov (Cygwin/X) wrote:
> >>The string returned into buf is in the following for
On Jul 18 15:23, Yaakov (Cygwin/X) wrote:
> On 2012-07-18 06:17, Corinna Vinschen wrote:
> >On Jul 18 05:21, Yaakov (Cygwin/X) wrote:
> >>On 2012-06-06 02:33, Corinna Vinschen wrote:
> >>>In case of Cygwin this is not needed since we don't read from
has the assignment, I'll apply your patch.
Thanks,
Corinna
--
Corinna Vinschen Please, send mails regarding Cygwin to
Cygwin Project Co-Leader cygwin AT cygwin DOT com
Red Hat
ssion is missing a slash.
Anyway, thanks for the patch. I also added a reference to whatis in the
actual text.
Corinna
--
Corinna Vinschen Please, send mails regarding Cygwin to
Cygwin Project Co-Leader cygwin AT cygwin DOT com
Red Hat
On Aug 14 22:11, Daniel Colascione wrote:
> On 8/14/12 10:02 PM, Christopher Faylor wrote:
> > On Tue, Aug 14, 2012 at 02:49:17PM -0700, Daniel Colascione wrote:
> >> On 7/27/2012 2:32 AM, Corinna Vinschen wrote:
> >>> There's just the problem of the co
r = get_readahead ();
> + ret = 1;
(*) Ok, that works, but wouldn't it be more efficient to do that in
a tiny loop along the lines of
int x;
ret = 0;
while (ret < len && (x = get_readahead ()) >= 0)
ptr++ = x;
ret++;
?
Corinna
--
Corinna Vinschen Please, send mails regarding Cygwin to
Cygwin Project Co-Leader cygwin AT cygwin DOT com
Red Hat
On Aug 16 14:11, Thomas Wolff wrote:
> Hi Corinna,
>
> On 16.08.2012 11:33, Corinna Vinschen wrote:
> >Hi Thomas,
> >
> >thanks for the patch. I have a few minor nits:
> >
> >On Aug 14 22:56, Thomas Wolff wrote:
> >>--- sav/fhandler_clipbo
mic function in the future, which could then possibly
> > have the same problems as MB_CUR_MAX.
>
> POSIX requires MB_LEN_MAX to be a constant, only MB_CUR_MAX can be
> dynamic. We cannot change MB_LEN_MAX to be dynamic in the future.
...also, Cygwin's include/limits.h doe
On Aug 17 10:44, Thomas Wolff wrote:
> On 16.08.2012 18:22, Corinna Vinschen wrote:
> >On Aug 16 09:24, Eric Blake wrote:
> >>On 08/16/2012 08:20 AM, Thomas Wolff wrote:
> >>
> >>>>>MB_CUR_MAX does not work because its value is 1 at this point
>
an array for two
page information entries around for no good reason.
I checked in a simplified version of your patch. Please have a look.
Since the code in question is in the public domain, it doesn't require
a Cygwin copyright assignment.
Thanks,
Corinna
--
Corinna Vinschen
tention of the mingw.org and
> > mingw64.sf.net people, if it's not too much trouble.
> >
> > --
> > Chuck
> >
> >
> >
>
> Original message already forwarded to mingw-w64 devel list. Thanks
> Jin-woo Ye.
Do you want the patch I eventual
On Sep 3 19:02, JonY wrote:
> On 9/3/2012 18:35, Corinna Vinschen wrote:
> > On Sep 3 17:34, JonY wrote:
> >> On 9/3/2012 11:05, Charles Wilson wrote:
> >>> On 9/2/2012 1:51 PM, Jin-woo Ye wrote:
> >>>> Now it is clear that this patch would be needed
submission is broken due to wrong
line-breaks. Can you please resend the patch, if you don't trust your
MUA, maybe better as text/plain attachment?
Oh and, btw., in the Cygwin ChangeLogs we tend to use up to 80 chars
per line. That's not a big problem, I just want you to know for future
/Makefile.common 17 Oct 2012 15:21:32 -
>
> Can we just get rid of this as well? That's what I did in my now-unneeded
> revamp of the configury in the cygwin git repository.
>
> I think I'd rather just move everything into winsup, cygserver, utils and
> not bother
LAGS_FOR_TARGET=$FLAGS_FOR_TARGET' -L$$r/$(TARGET_SUBDIR)/winsup
> -L$$r/$(TARGET_SUBDIR)/winsup/cygwin -isystem $$s/winsup/include -isystem
> $$s/winsup/cygwin/include'
This change reminds me. Why on earth do we have a
-L$$r/$(TARGET_SUBDIR)/winsup in there? How old is that? We don't
have any libs in the winsup dir anyway, so we should remove that,
isn't it?
Corinna
--
Corinna Vinschen Please, send mails regarding Cygwin to
Cygwin Project Co-Leader cygwin AT cygwin DOT com
Red Hat
On Oct 18 17:57, Kai Tietz wrote:
> Hi Corinna,
>
> 2012/10/18 Corinna Vinschen:
> > Hi Yaakov,
> >
> > On Oct 18 02:33, Yaakov (Cygwin/X) wrote:
> >> On Wed, 2012-10-17 at 15:32 -0400, Christopher Faylor wrote:
> >>> But, anyway, nevermi
On Oct 18 12:20, Yaakov (Cygwin/X) wrote:
> On Thu, 2012-10-18 at 10:34 +0200, Corinna Vinschen wrote:
> > Any problem to move mingw64-i686-zlib into the distro?
>
> None; should I also move the other setup.exe prerequisites for
> i686-w64-mingw32? Would you also like x86_64
On Oct 19 11:21, Corinna Vinschen wrote:
> Thanks. Looks good, I have problems with this patch.
That should have been:
Thanks. Looks good, I just have a few small problems with this patch.
Corinna
--
Corinna Vinschen Please, send mails regarding Cygwin to
Cygwin Proj
On Oct 19 11:33, Yaakov (Cygwin/X) wrote:
> On Fri, 2012-10-19 at 11:21 +0200, Corinna Vinschen wrote:
> > On Oct 18 12:20, Yaakov (Cygwin/X) wrote:
> > > None; should I also move the other setup.exe prerequisites for
> > > i686-w64-mingw32? Would you also like x86_
On Oct 19 20:46, Corinna Vinschen wrote:
> On Oct 19 11:33, Yaakov (Cygwin/X) wrote:
> > On Fri, 2012-10-19 at 11:21 +0200, Corinna Vinschen wrote:
> > > Other than that, I think it's good to go in after the 1.7.17 release.
> > > I'll try to do the release
t do you think about removing these directories
> from the depot and moving repo to sourceforge, or some other place?
>
> You've got a home for as long as you like on sourceware.org but I was
Yeah, since the changes to the configury separate Cygwin from mingw and
w32api, staying
herwise, you can safely ignore this warning.'
Index: configure.in
[...]
AC_ARG_PROGRAM
-AC_CHECK_LIB(iconv, libiconv, libiconv=-liconv)
-AC_SUBST(libiconv)
-
INSTALL="/bin/sh "`cd $srcdir/../..; echo $(pwd)/install-sh -c`
[...]
If the original patch with the aforementioned
On Oct 22 08:00, Christopher Faylor wrote:
> On Mon, Oct 22, 2012 at 10:29:13AM +0200, Corinna Vinschen wrote:
> >On Oct 22 00:09, Christopher Faylor wrote:
> >Yeah, since the changes to the configury separate Cygwin from mingw and
> >w32api, staying in src/winsup is no prob
101 - 200 of 2885 matches
Mail list logo
