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. Such

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 ptsekov AT gmx.net * path.cc (cygdrive_getmntent): Do not skip over drives of type DRIVE_REMOVABLE. Perhaps you should be discussing this with Pavel. Okay, I

[Patch] Fix buffer overflow in kill utility

. Example: $ /bin/kill -s `perl -e 'print Ax200'` 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 [EMAIL PROTECTED] * kill.cc (getsig): Use

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

placeholder value that is initialized to .. paths[1] contains the CWD anyway so there's no need to examine paths[0]. Brian === 2005-03-24 Brian Dessent [EMAIL PROTECTED] * cygcheck.cc (init_paths): Use full path instead

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

getservbyname(auth, tcp) success, port = 113 getservbyname(25, tcp) success, port = 113 Brian === 2005-04-05 Brian Dessent [EMAIL PROTECTED] * net.cc (__dup_ent): Make dst point to NULL if src is NULL. Free dst

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

[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 (main): Use 'NULL

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. We

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

of steps that should cover everything. 2005-05-17 Brian Dessent [EMAIL PROTECTED] * install.texinfo (How do I uninstall...): Rewrite to cover removing services, dealing with permissions, and other common tasks for removing Cygwin completely.Index: install.texinfo

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 heart SpamAssassin. :) Close all Cygwin command prompts, xterms, etc. and stop

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, thanks.

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] It

[patch] several new features for cygrunsrv

this. Brian 2005-05-19 Brian Dessent [EMAIL PROTECTED] * cygrunsrv.cc (longopts): Add '--list' and '--verbose' options. (opts): Add '-L' and '-V' options; keep order consistent with above. (action_t): Add 'List'. (err_out_set_error): Define version of 'err_out' macro

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 couldn't overflow

[patch] dump service info in cygcheck

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 function that uses new cygrunsrv options to dump service info. (dump_sysinfo): Call

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

) 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. * cygcheck.cc: Add includes. (grep_packages): New global variable. (display_internet_error): New

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

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 because if I had run cygrunsrv --list Now that I re-read what

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 changs

[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 (cygcheck.exe): Do

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,

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

[patch] fix spurious SIGSEGV faults under Cygwin

/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): Likewise for when the fault handler is installed

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 that. Apparently strace expects anything starting

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

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 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 calling

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] support -gdwarf-2 when creating cygwin1.dbg

in ?? () Brian2007-04-18 Brian Dessent [EMAIL PROTECTED] * cygwin.sc: Remove duplicated .debug_macinfo section. * dllfixdbg: Also copy DWARF-2 sections into .dbg file. Index: cygwin.sc === RCS file: /cvs/src/src/winsup

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

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

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 using

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 ./ls

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

which fixes the build for me. Brian2007-06-16 Brian Dessent [EMAIL PROTECTED] * include/sys/cdefs.h (__FBSDID): Define. Index: include/sys/cdefs.h === RCS file: /cvs/src/src/winsup/cygwin/include/sys/cdefs.h,v retrieving

Re: Doc change request

/doc/Cygwin/rxvt-lt;vergt;.README/literal. 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

[patch] Fix multithreaded snprintf

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 that has the __SSTR flag set. (_ftrylockfile): Likewise. (_funlockfile): Likewise. 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 that

Re: [patch] inline __getreent in newlib

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 case where __getreent is defined as a macro. Index

[patch] inline __getreent in newlib

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: include/cygwin/config.h

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 function that takes _REENT

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:

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... what

[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 9x/ME. We need to do one

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 was accidently

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

[patch] fix strfuncs-related breakage of cygserver

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_CYGWIN__ for use in cygserver. (sys_mbstowcs_alloc

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] handle_to_fn: null terminate

I noticed in strace some lines like: fhandler_base::close: closing '/Device/NamedPipe/Win32Pipes.08e0.0002several junk bytes' 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 [EMAIL

[patch] reorganize utils/Makefile.in

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 and target-specific variables. Makefile.in | 229

[patch] utils/path.cc fixes and testsuite

case. If you run make check it builds the required files and runs the testsuite. I've attached a sample output. Brian2008-03-08 Brian Dessent [EMAIL PROTECTED] * Makefile.in: Add a 'check' target that builds and runs testsuite.exe from path-testsuite.o and testsuite.o

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

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. Brian2008-03-08 Brian Dessent [EMAIL PROTECTED] * Makefile.in: Add a 'check

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

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 PROTECTED] * cygcheck.cc (save_cwd_helper): New helper function

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 testsuite. Index: Makefile.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. It

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: 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()

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

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 cwd

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()

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.

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

too extreme. Brian2008-03-13 Brian Dessent [EMAIL PROTECTED] * ntdll.h: Add several missing NTSTATUS defines. * pinfo.cc (pinfo::maybe_set_exit_code_from_windows): Recognise and preserve the exit status of a child that terminated with an unhandled exception

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. |

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 state, I'm all ears. I have

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] cygcheck.cc update for cygpath()

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: Include malloc.h for alloca. (is_symlink): Rewrite. Just read the whole file

[PATCH] normalize_posix_path and c:/foo/bar

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 slashes. path.cc |2

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 the

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 for

[PATCH] better stackdumps

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 Brian Dessent [EMAIL PROTECTED] * exceptions.cc

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 handle that. I

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 me

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 list

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 stackdump

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. This could be the reason

[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 tls area through %fs:4 and peek

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 file: No

[PATCH] fix profiling

-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. Brian2008-08-04 Brian Dessent [EMAIL PROTECTED

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