Re: [PATCH] fix profiling

Christopher Faylor wrote: > Please use your best judgement about the +r/=r thing given Dave's > comments. I think Dave's right, because when I compile with +r I get a "may be used uninitialized" warning, so I'll just leave it as it is. Both patches are now committed. I wonder how long this was

Re: [PATCH] fix profiling

Brian Dessent wrote: > Since this code is lifted from the BSDs I did check that this change was > made there as well, e.g. > <http://www.openbsd.org/cgi-bin/cvsweb/src/sys/arch/i386/include/profile.h?rev=1.10&content-type=text/x-cvsweb-markup>. Actually, I also missed that the

[PATCH] fix profiling

rev=1.10&content-type=text/x-cvsweb-markup>. Unfortuantely there seems to also be some bitrot in the gprof side, as the codepath to read BSD style gmon.out files is also broken. I've posted a separate patch to the binutils list. With both these fixes, gprof again works with Cygwin.

Re: [patch] recognise when an exec()d process terminates due to unhandled exception

Christopher Faylor wrote: > After poking at this a little, I think it would be better to issue a > linux-like error message. > > In my sandbox, I now have this: > > bash-3.2$ ./libtest > /cygdrive/s/test/libtest.exe: error while loading shared libraries: liba.dll: > cannot open shared object fi

[PATCH] stackdump rev2

Brian Dessent wrote: > Yes, it means there is one frame that says "sigbe" instead of the actual > return location somewhere else. I don't think that's impossible to fix > either: the fault handler gets the context of the faulting thread so it > can look up its tl

Re: addr2line [ Was: better stackdumps ]

Brian Dessent wrote: > I think I see what's going on here though, the Cygwin fault handler took > the first chance exception and wrote the stackdump file, and only then > passed it on to the debugger, so that by the time gdb got notice of the > fault the stack was all fubar.

addr2line [ Was: better stackdumps ]

Corinna Vinschen wrote: > Is it a big problem to fix addr2line to deal with .dbg files? > > I like your idea to add names to the stackdump especially because of > addr2line's brokenness. But, actually, if addr2line would work with > .dbg files, there would be no reason to add this to the stackdu

Re: [PATCH] better stackdumps

Pedro Alves wrote: > Sorry I missed the discussion at [EMAIL PROTECTED] What does info > sharelibrary say? > The last I looked at this, it worked. Is this broken in gdb head > and on the cygwin distributed gdb? With gdb CVS HEAD, it gives: (gdb) i sh >FromTo Syms Read Share

Re: [PATCH] better stackdumps

Christopher Faylor wrote: > Sorry, but I don't like this concept. This bloats the cygwin DLL for a > condition that would be better served by either using gdb or generating > a real coredump. I hear you, but part of the motivation for writing this was a recent thread the other week on the gdb li

Re: [PATCH] better stackdumps

Igor Peshansky wrote: > Would it make sense to force a newline before the function name and to > display it with a small indent? That way people who want the old-style > stackdump could just feed the new one into "grep -v '^ '" or something... Yes, that would be one way. That actually reminds

Re: [PATCH] better stackdumps

Brian Dessent wrote: > Of course the labeling works for any module/dll, not just cygwin1.dll, > but I didn't have a more elaborate testcase to demonstrate. Forgot to mention... The symbols are just tacked on on the right hand side there for now. I wasn't really sure how to

[PATCH] better stackdumps

I can't think of a reliable way to figure out the correct location on the tls stack where the real return address is stored. Of course the labeling works for any module/dll, not just cygwin1.dll, but I didn't have a more elaborate testcase to demonstrate. Brian2008-03-18

Re: [PATCH] normalize_posix_path and c:/foo/bar

Corinna Vinschen wrote: > Actually that was intended, but unfortunately the current path handling > deliberately creates DOS paths with slashes (in find_exec) right now, > so that doesn't work ATM. I guess what I don't understand is how it's both possible for open("c:/foo/bar.exe") to succeed and

Re: [PATCH] QueryDosDevice in handle_to_fn

Corinna Vinschen wrote: > len is a const value. Checking len for being < 65536 is a constant > expression which always results in qddlen being 65535 so the ?: is > a noop, more or less. Yeah, I realized that, and the compiler should optimize it away completely. I put it explicitly as a test in

[PATCH] QueryDosDevice in handle_to_fn

;re doing this on strings that we had just converted *out* of UNICODE. I think ascii_strncasematch() is probably what we want here instead, either that or try to stay in unicode throughout. Brian2008-03-16 Brian Dessent <[EMAIL PROTECTED]> * dtable.cc (handle_to_fn): Don'

[PATCH] normalize_posix_path and c:/foo/bar

use win32 paths, but really a reduced testcase is simply open("c:/cygwin/bin/ls.exe", O_RDONLY) = ENOENT. Brian2008-03-16 Brian Dessent <[EMAIL PROTECTED]> * path.cc (normalize_posix_path): Correctly identify a win32 path beginning with a drive letter and forward

Re: [patch] cygcheck.cc update for cygpath()

atter if we want to make cygcheck support long paths though, since it's just ReadFile, SetFilePointer, and GetFileInformationByHandle -- the HANDLE is already open so this should require no change to support WCHAR. Brian2008-03-15 Brian Dessent <[EMAIL PROTECTED]> * path.cc: Inc

Re: [patch] recognise when an exec()d process terminates due to unhandled exception

Christopher Faylor wrote: > That was going to be my first observation, actually. I'm still trying > to digest the patch but it seems like it wouldn't work well with the > fork retry code. The patch doesn't change any behavior though: in current Cygwin if the thing we're exec()ing returns a Win32

Re: [patch] recognise when an exec()d process terminates due to unhandled exception

Brian Dessent wrote: > isn't present, etc. I was really hoping to figure out a cool way to get > that info, perhaps by poking around in the TEB or PEB somewhere, but I > haven't gotten that far. If anyone has any general ideas where to look > for NTLDR's internal sta

Re: [patch] recognise when an exec()d process terminates due to unhandled exception

Brian Dessent wrote: > As we all know, Cygwin calls SetErrorMode (SEM_FAILCRITICALERRORS) to > suppress those pop up GUI messageboxes from the operating system when Oh, I forgot to mention: In the course of testing this I came to realize that because of some sort of "retry if fork d

Re: [patch] recognise when an exec()d process terminates due to unhandled exception

Eric Blake wrote: > Should we also mention 'cygcheck ./dll_not_found' to find out which ones > are missing? It might be a good idea. On the other hand it's kind of long already. I'm totally not married to what I've got for the wording though, consider it a very rough draft. > | missing_import.

[patch] recognise when an exec()d process terminates due to unhandled exception

x27;d process in a debugger loop and pumping WaitForDebugEvent() messages, since those can have parameters attached to exception codes. But that's a little too extreme. Brian2008-03-13 Brian Dessent <[EMAIL PROTECTED]> * ntdll.h: Add several missing NTSTATUS defines. *

Re: [patch] cygcheck.cc update for cygpath()

Corinna Vinschen wrote: > Urgh. MAX_PATH is defined with trailing 0, SYMLINK_MAX is defined > without trailing 0 (like NAME_MAX). You should better change the > SYMLINK_MAX stuff back, afaics... D'oh! 'Kay.

Re: [patch] cygcheck.cc update for cygpath()

Corinna Vinschen wrote: > Btw., you don't need to make the buffers MAX_PATH + 1. MAX_PATH is > defined including the trailing NUL. Existing code shows a lot of > irritation about this... Oh, I wasn't even thinking of that... the reason I used MAX_PATH + 1 was because earlier I had written +

Re: [patch] cygcheck.cc update for cygpath()

ateFile, but the thing that provides the filename passed here is itself driven by GetFileAttributes(), so it would need to be updated too... and so on. It looks like a lot of work to go completely longfile-clean here. Brian2008-03-11 Brian Dessent <[EMAIL PROTECTED]>

Re: [patch] cygcheck.cc update for cygpath()

Corinna Vinschen wrote: > The problem is that the cwd is stored as UNICODE_STRING with a > statically allocated buffer in the user parameter block. The > MaximumLength is set to 520. SetCurrentDirectory refuses to take paths > longer than that. In theory it would be possible to define a longer

Re: [patch] cygcheck.cc update for cygpath()

Christopher Faylor wrote: > I guess I misunderstood. I thought that the current working directory > could be derived through some complicated combination of Nt*() calls. I could be wrong here but the way I understood it, there is no concept of a working directory at the NT level, that is somethi

Re: [patch] cygcheck.cc update for cygpath()

Corinna Vinschen wrote: > Now that you mention it... did you see the comment in path.cc, line 3112ff? > There's a good chance that Windows shortcuts are not capable of long path > names. I didn't test it so far, but it would be certainly better for > readlink to use the POSIX path in the symlink

Re: [patch] cygcheck.cc update for cygpath()

Corinna Vinschen wrote: > > > I'm wondering if you would like to tweak the readlink functions, too. > > > Cygwin shortcuts can now have the path name appended to the actual > > > shortcut data. This hack was necessary to support pathnames longer than > > > 2000 chars. See the comment and code in

Re: [patch] cygcheck.cc update for cygpath()

Corinna Vinschen wrote: > Given that Cygwin changes to support long path names, I don't really > like to see new code still using MAX_PATH and Win32 Ansi functions > in the utils dir. Regardless of this patch, path.cc:rel_vconcat() currently uses GetCurrentDirectory() to resolve relative paths.

Re: [patch] utils/path.cc fixes and testsuite

Corinna Vinschen wrote: > Doesn't that install testsuite.exe at `make install' time? Ack, how about the attached? Brian2008-03-09 Brian Dessent <[EMAIL PROTECTED]> * Makefile.in (install): Don't install the testsu

Re: [patch] cygcheck.cc update for cygpath()

ttached. The main idea is that when normalizing a link's target in find_app_on_path, we should temporarily set the CWD to the same dir as the link, otherwise relative links will get normalized relative to whatever dir cygcheck was run from. Brian2008-03-08 Brian Dessent <[EMAIL PROTEC

Re: [patch] utils/path.cc fixes and testsuite

I'm not all that crazy with this idea of symlinking a file in order to compile it to a differently-named object, but doing it otherwise would require repeating the compile rule with all its ugly VERBOSE casing and I just went to the trouble to eliminate all such repetition in the Makefile. Br

[patch] utils/path.cc fixes and testsuite

tried to emulate what a real mount table is typically like, with a couple additional mounts. The Makefile changes to support this are pretty straightforward: nothing changes for the default "make all" case. If you run "make check" it builds the required files and runs the testsui

[patch] reorganize utils/Makefile.in

a crosscompile but I can if that's necessary. I have tested builds in both a combined tree as well as just winsup. Brian2008-03-08 Brian Dessent <[EMAIL PROTECTED]> * Makefile.in: Reorganize considerably, using GNU make's static pattern rules

[patch] handle_to_fn: null terminate

I noticed in strace some lines like: fhandler_base::close: closing '/Device/NamedPipe/Win32Pipes.08e0.0002' handle 0x740 This was caused by handle_to_fn simply forgetting to add a \0 when converting, as in the attached patch. Brian2008-03-07 Brian Dessent <[EM

Re: PATCH: avoid system shared memory version mismatch detected by versioning shared memory name

Noel Burton-Krahn wrote: > The problem is there are several installable apps built on Cygwin, > like EAC, ClamAV, and one I just found which is a > Cygwin-on-a-thumbdrive. The problem is they can't all coexist because > they're distributed with different versions of the cygwin dlls. > Making them

[patch] fix strfuncs-related breakage of cygserver

two patches, one for cygwin/ and one in cygserver/. Brian2008-02-03 Brian Dessent <[EMAIL PROTECTED]> * smallprint.cc (__small_vsprintf): Use HEAP_NOTHEAP for type. * strfuncs.cc (sys_wcstombs_alloc): Guard use of ccalloc to !__OUTSIDE_CYG

Re: [patch] un-NT-ify cygcheck (was: cygwin 1.5.25-7: cygcheck does not work?)

Christopher Faylor wrote: > Unless Corinna says differently, I think she wants to be in control of > what goes into the branch so I don't want to suggest that you should > check it in there too. Okay, I'll let her take care of the branch since she's been handling all the releases from it. > The

Re: [patch] un-NT-ify cygcheck (was: cygwin 1.5.25-7: cygcheck does not work?)

Brian Dessent wrote: > ... but sadly a similar cleanup is > still required for cygpath as well if we are to support 9x/ME out of the > 1.5 branch. In that case I suppose you could just revert cygpath.cc to > an older revision before the native APIs were added. Er, nevermind. I wa

[patch] un-NT-ify cygcheck (was: cygwin 1.5.25-7: cygcheck does not work?)

Brian Dessent wrote: > Fortunately, I have VMware with a Win98 image here. > > The problem is that bloda.c calls NtQuerySystemInformation without using > any kind of autoload.cc-type indirection, and so cygcheck gets a hard > dependency on ntdll.dll which doesn't exist on 9

Re: Rewrite/fix cygwin1.dbg generation

Pedro Alves wrote: > 10 .cygheap 000a 611e 611e 2**2 > ALLOC > 11 .gnu_debuglink 0010 6128 6128 001d0a00 2**2 > CONTENTS, READONLY, DEBUGGING > > I'll come up with a different fix. Just thinking out loud here... wh

Re: Rewrite/fix cygwin1.dbg generation

Pedro Alves wrote: > The dllfixdbg hunk looks hard to read. Here's what is looks > like after patching: I think that if whatever bugs used to exist in older binutils PE support that necessitated this hackery are now gone, we can just do away with dllfixdbg alltogether and just put this: > ${STR

Re: [patch] inline __getreent in newlib

Brian Dessent wrote: > Done. I added the following comment to config.h to hopefully clarify > the situation: > > /* The following provides an inline version of __getreent() for newlib, >which will be used throughout the library whereever there is a _r >version of a f

Re: [patch] inline __getreent in newlib

s (a large and complex Cygwin internal data structure) into newlib. The machinery to compute these offsets already exists for the sake of gendef so we might as well just use it here. */ Brian2007-09-06 Brian Dessent <[EMAIL PROTECTED]> * libc/reent/getreent.c: Allow for

[patch] inline __getreent in newlib

represents reading the whole 16MB file one byte at a time, where this _REENT overhead would be most pronounced. So, valid optimization or just complication? Brian2007-09-06 Brian Dessent <[EMAIL PROTECTED]> * include/cygwin/config.h (__getreent): Define inline version. Index

Re: [patch] Fix multithreaded snprintf

Christopher Faylor wrote: > Go ahead and check this in but could you add a comment indicating that > this part of include/sys/stdio.h has to be kept in sync with newlib? Done. > Nice catch! I wish I could say I caught this by inspection but it was only by single stepping through python guts tha

[patch] Fix multithreaded snprintf

.cc) I couldn't do the "test ? 0 : func()" idiom where void is the return type as that generates a compiler error, so I use an 'if'. Brian2007-09-06 Brian Dessent <[EMAIL PROTECTED]> * include/sys/stdio.h (_flockfile): Don't try to lock a FILE

Re: Doc change request

Cygwin/rxvt-<ver>.README. Unless my grep-fu failed that's it. Brian2007-07-18 Brian Dessent <[EMAIL PROTECTED]> * faq-using.xml (faq.using.console-window): Mention FHS location of docs and remove outdated reference to ash. Index: faq-using.xml ===

Re: Failure in rebuilding Cygwin-1.5.24-2 with recent newlib

wed by use of __FBSDID without having to explicitly undefine it. Patch attached which fixes the build for me. Brian2007-06-16 Brian Dessent <[EMAIL PROTECTED]> * include/sys/cdefs.h (__FBSDID): Define. Index: include/sys/cdefs.h ===

Re: [Patch] "strace ./app.exe" probably runs application from /bin

Christopher Faylor wrote: > Let me rephrase the problem: > > "cygpath does not properly deal with the current directory" > > Thanks for the patch but we won't be applying it in this form. I've been meaning to take a look at fixing this myself, because I'm tired of: $ cd /usr/bin $ cygcheck ./

Re: [patch] support -gdwarf-2 when creating cygwin1.dbg

Corinna Vinschen wrote: > I debugged Cygwin native GDB a couple of days ago with code created by > gcc 4.2. It turned out that the DWARF2_UNWIND_INFO define set to 0 > resulted in the DW_CFA_offset column missing. The result is that GDB is > unable to get the return address on the stack when usi

Re: [patch] support -gdwarf-2 when creating cygwin1.dbg

Christopher Faylor wrote: > So, maybe a top-level configure option would be useful? At the very least > we can get rid of the -gstabs specific use in configure. Oh, I didn't know there was anything that specifically mentions -gstabs in there, just that if you don't set {C,CXX}FLAGS yourself auto

Re: [patch] support -gdwarf-2 when creating cygwin1.dbg

Christopher Faylor wrote: > Thanks for doing this. Please check in. Can we switch to dwarf-2 by > default in the cygwin makefile(s)? I thought about that, but the problem is anything you do to *FLAGS in winsup/cygwin won't affect flags used in the other dirs like libiberty or newlib, and so unl

[patch] support -gdwarf-2 when creating cygwin1.dbg

inCRTStartup () at /usr/src/sourceware/winsup/cygwin/crt0.c:51 Exact same breakpoint, -g (stabs): (gdb) bt #0 fstat64 (fd=1628141592, buf=0x1) at /usr/src/sourceware/winsup/cygwin/syscalls.cc:1102 #1 0x611b5708 in _libntdll_a_iname () from /bin/cygwin1.dll #2 0x0000 in ?? () Brian200

Re: Patch to mapping up to 128 SCSI Disk Devices

Corinna Vinschen wrote: > I must admit that I don't quite understand why that happens, but > when I save your patch into a file, all '=' characters are converted > into a '=3D' sequence. This is a bit weird given that you're using > us-ascii encoding. Does anybody know why this happens? That's

[patch] make clean

Doing a "make clean" inside winsup/cygwin leaves behind a stale cygwin1.dbg file. 2006-05-10 Brian Dessent <[EMAIL PROTECTED]> * Makefile.in (clean): Also delete *.dbg.Index: Makefile.in === RCS file: /cv

Re: Patch for silent crash with Cygwin1.dll v 1.5.19-4

Gary Zablackis wrote: > I did some more research over the weekend and my > problem seems to only come when loading a dll via > dlopen() and run_ctors() is called from dll:init() and > pthread_key_create() is called during the time that > run_ctors() is active. I still have not found who is > calli

Re: [patch] fix spurious SIGSEGV faults under Cygwin

Dave Korn wrote: > I'm having a conceptual difficulty here: Under what circumstances would you > expect there *not* to be a debugger attached to the > inferior to which the debugger is attached? That's a bit zen, isn't it? The code in question here runs many times in the normal course of any

Re: [patch] fix spurious SIGSEGV faults under Cygwin

Christopher Faylor wrote: > Thanks for the patch but I've been working on this too and, so far, I think > it is possible to have a very minimal way of dealing with this problem. I > haven't had time to delve into it too deeply but I have been exploring this > problem on and off for a couple of we

Re: [patch] fix spurious SIGSEGV faults under Cygwin

Brian Dessent wrote: > #define _CYGWIN_SIGNAL_STRING "cYgSiGw00f" > +#define _CYGWIN_FAULT_IGNORE_STRING "cYgfAuLtIg" > +#define _CYGWIN_FAULT_NOIGNORE_STRING "cYgNofAuLtIg" Sigh, this breaks strace under Cygwin, I should have tested more. Sorry about th

[patch] fix spurious SIGSEGV faults under Cygwin

to both cygwin and gdb. Brian winsup/cygwin: 2006-02-02 Brian Dessent <[EMAIL PROTECTED]> * cygtls.h: Include sys/cygwin.h. (myfault::~myfault): If a debugger is present, inform it that our fault handler has been removed. (myfault::faulted): Like

Re: [Patch] regtool: Add load/unload commands and --binary option

Igor Peshansky wrote: > What if you want to redirect the hex dump to a file? IMO, isatty() checks > are only useful if the output won't change qualitatively on redirection > (e.g., for coloring). Otherwise, it's always better to use an explicit > flag. Good point. Why don't we just emulate the

Re: [Patch] regtool: Add load/unload commands and --binary option

Christian Franke wrote: > At least when regtool is used interactively, it is IMO not very useful > to have > modem-line-noise-like output for REG_BINARY, but human readable output for > the other value types. > But this is the current behavior of "regtool get ...". Instead of an explicit -b flag,

[patch] load wininet dynamically in cygcheck

This uses LoadLibrary and GetProcAddress instead of -lwininet so that systems lacking IE3 can still run cygcheck. Tested on XP and NT4, and verified that with WININET.DLL renamed cygcheck can still function. 2006-01-13 Brian Dessent <[EMAIL PROTECTED]> * Makefile.in (cygche

Re: [PATCH] Fix cygrunsrv invocation in cygcheck

Christopher Faylor wrote: > Go ahead and check this in. Thanks. Ok. > Thanks, Igor, for bringing this up (again). Thanks Igor, I had meant to bring this up but forgot. > There's no need to ping anybody. I do read this list and I haven't > forgotten about the patch. If it didn't require chan

Re: [PATCH] Fix cygrunsrv invocation in cygcheck

Brian Dessent wrote: > Now that I re-read what you said I think I misunderstood. You're right, > it could have simply done Here is a patch that fixes both issues. Brian 2005-08-16 Brian Dessent <[EMAIL PROTECTED]> * cygcheck.cc (dump_sysinfo_services): Properly nu

Re: [PATCH] Fix cygrunsrv invocation in cygcheck

Brian Dessent wrote: > > why not simply run "cygrunsrv --list --verbose" in verbose mode, instead > > of actually going through one iteration of the loop? Simply to reuse the > > "copy output" code? Brian? > > The reason I did it that way is becaus

Re: [PATCH] Fix cygrunsrv invocation in cygcheck

Igor Pechtchanski wrote: > As mentioned in , I > noticed something strange in the "cygcheck -s" output: This fix was part of my patch from June in but since it was grouped with the unrel

Re: [Patch]: Changes to how-programming.texinfo

Christopher Faylor wrote: > Btw, the "other license" provision in the cygwin licensing web page was > really meant as a way to accommodate other, already existing projects. And it was very gracious of them to do that. For an example of why this makes life a lot easier, consider MySQL (GPL) and O

[patch] add -p option to cygcheck to query website package search

code was not 200. It will also emit an error (and call FormatMessage to get a textual version) if there is a problem connecting or resolving the domain. Brian winsup/utils: 2005-06-20 Brian Dessent <[EMAIL PROTECTED]> * Makefile.in: Link cygcheck with libwininet.a. *

[patch] dump service info in cygcheck

#x27; in an unrelated printf that I happened to notice. Not sure if that's desired or not but I would imagine most direct references to Cygnus are probably anachronisms. Brian 2005-05-22 Brian Dessent <[EMAIL PROTECTED]> * cygcheck.cc (dump_sysinfo_services): Add new functi

Re: [patch] several new features for cygrunsrv

Brian Dessent wrote: > -controlsToString(DWORD controls) > + char *base, *end; > + static char buf[34]; > + int used = 0, dsiz = strlen (delim); Crap, that is a mistake. buf[34] should be something more generous like 128 or 256. I had it set small to test to make sure it could

[patch] several new features for cygrunsrv

s a little large, but I also took the liberty of doing some minor code cleanups here and there while implementing this. Brian 2005-05-19 Brian Dessent <[EMAIL PROTECTED]> * cygrunsrv.cc (longopts): Add '--list' and '--verbose' options. (opts): Add '

gcc4 and local statics

Corinna Vinschen wrote: > While this might help to avoid... something, I'm seriously wondering > what's wrong with this expression. Why does each new version of gcc > add new incompatibilities? I think I've figured this out. PR/13684 added thread safety to initialization of local statics.[1] I

Re: [patch] gcc4 fixes

Brian Dessent wrote: > entirely in their build scripts due to compiler problems. So who knows, > maybe I should try with a release build. With the release version of gcc 4.0.0 and without the mmap() kludge I get the same thing: FAIL: mmaptest01.c (execute) FAIL: mmaptest03.c (execute

Re: [patch] gcc4 fixes

Christopher Faylor wrote: > >While this might help to avoid... something, I'm seriously wondering > >what's wrong with this expression. Why does each new version of gcc > >add new incompatibilities? > > Well, it might actually be "a gcc bug". Here I admit to using a snapshot verion of gcc and n

Re: [patch] update documentation Was: cygwin-host-setup does not install sshd

Corinna Vinschen wrote: > > Alright. I am not sure how to push out the new version to the web site, > > so someone else will have to do that (or tell me what to do - check in > > the .html files into the website CVS or something?) > > Yep. cvs -d :ext:cygwin.com:/cvs/cygwin co htdocs Got it, t

Re: [patch] update documentation Was: cygwin-host-setup does not install sshd

Corinna Vinschen wrote: > Looks good. Please check in. Alright. I am not sure how to push out the new version to the web site, so someone else will have to do that (or tell me what to do - check in the .html files into the website CVS or something?) Brian

Re: [patch] update documentation Was: cygwin-host-setup does not install sshd

Corinna Vinschen wrote: > > 2005-05-17 Brian Dessent <[EMAIL PROTECTED]> > > http://cygwin.com/acronyms#PCYMTNQREAIYR ;-) Yeah, I know. Spammers have had my address for some time, I don't feel like hiding. Me SpamAssassin. :) > "Close all Cygwin command pro

[patch] update documentation Was: cygwin-host-setup does not install sshd

eel a little hand-holding in the FAQ can't hurt. Rather than saying basically to delete the folder and the registry key and "you're on your own for the other stuff", this gives a list of steps that should cover everything. 2005-05-17 Brian Dessent <[EMAIL PROTECTED]>

Re: [patch] gcc4 fixes

Christopher Faylor wrote: > Go ahead and check these in but please use GNU formatting conventions, > i.e., it's (char *) NULL, not (char *)NULL. Actually, isn't just NULL > sufficient? I must have had C++ on the mind, thinking that the cast was necessary. > Sorry but no. This is a workaround.

[patch] gcc4 fixes

This is just a trivial change of argument to execl() testcases, which supresses the warning 'missing sentinel in function call' in gcc4 that causes the tests to fail. winsup/testsuite 2005-05-17 Brian Dessent <[EMAIL PROTECTED]> * winsup.api/signal-into-win32-api.c (

Re: [patch] cygdrive and user/system documentation clarification

Corinna Vinschen wrote: > P.S.: Weren't you going to send a copyright assignment at one point? I did actually mail it a week or two ago, but I know these sorts of things take forever to process. Brian

[patch] cygdrive and user/system documentation clarification

Corinna Vinschen wrote: > Looks good to me. However, please send patches to cygwin-patches and > add a ChangeLog entry. As requested. I include two patches and two ChangeLog entries since the two files are in different directories. Is that the preferred way? utils/ 2005-04-20 Brian D

Re: [patch] dup_ent does not set dst when src is NULL

Christopher Faylor wrote: > Thanks for the patch, but I went out of my way to avoid freeing the > buffer when I maded changes to dup_ent a couple of weeks ago. I don't > want to revert to doing that again, so I've just used the return value > in all cases. Thanks for taking care of that. My ori

[patch] dup_ent does not set dst when src is NULL

uot;, "tcp"); mygetservbyname("25", "tcp"); return 0; } $ ./getservbyname getservbyname("25", "tcp") returns NULL getservbyname("auth", "tcp") success, port = 113 getservbyname("25", "tcp") success, port = 1

[patch] fix for cygcheck -s if run from /usr/bin

rting with paths[1] instead of paths[0], since paths[0] is a special "placeholder" value that is initialized to ".". paths[1] contains the CWD anyway so there's no need to examine paths[0]. Brian ======= 2005-03

[Patch] Fix buffer overflow in kill utility

ot;far-fetched" part though. Example: $ /bin/kill -s `perl -e 'print "A"x200'` Segmentation fault (core dumped) As far as I can tell from CVS history this has existed in kill.cc since its first version (~5 years.) Trivial patch below. 2005-02-26 Brian Dessent &

stopping floppy seeks (Was: available for test: findutils-20041219-1)

Brian Dessent wrote: > > Let me say it again. This is not new behavior: > > > > 2003-08-05 Pavel Tsekov > > > > * path.cc (cygdrive_getmntent): Do not skip over drives of type > > DRIVE_REMOVABLE. > > > > Perhaps you sh

Re: Patch to allow trailing dots on managed mounts

Reini Urban wrote: > > Thinking some more about this, there are really some inconsistencies with > > the current and proposed behavior that I don't like. > > [...] > I have no strong opinion in these issues (yet), but please look also at > the related ending-colon ':extension' problem on NTFS. > S