RE: C++ name with leading underscore character not Compiling
Hi, Dave Korn wrote on 16 April 2007 12:29: Thanks for the correction. I'm referring to the C standard; I think C++ follows basically the same rules but don't have a spec handy to refer to. The C++ standard is a little different, but the result in this case is the same:- 17.4.3.1.2/1 Certain sets of names and function signatures are always reserved to the implementation: - Each name that contains a double underscore (__) or begins with an underscore followed by an uppercase letter (2.11) is reserved to the implementation for any use. - Each name that begins with an underscore is reserved to the implementation for use as a name in the global namespace. [such names are also reserved in namespace ::std (17.4.3.1)] This means that a single leading underscore is fine in local scope, as long as it is not followed by an uppercase letter (I am only aware of conflicts with a single upper-case character (eg. _L), but I think the standard would also prevent _Local). So, the case here (_name as an argument name) should be fine. (This could have been an issue for my project, since we adopted the convention of leading underscore for member variables before C++ had been standardized. Fortunately, we also had adopted the convention of using keeping the first letter of identifiers lower case.) Tim. === cut here Tim Adye [EMAIL PROTECTED] http://hepunx.rl.ac.uk/~adye BaBar/Atlas Groups, Particle Physics Dept, Rutherford Appleton Lab -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
RE: C++ name with leading underscore character not Compiling
So, the case here (_name as an argument name) should be fine. Except that that was just an example, and in fact a misleading one, because what Chelton's code was /actually/ using was _N... hence the problem. Ah yes, I didn't see that (I thought his second case was the example, but you are right). _N is used in ctype (as are a number of others like _U and _L). It isn't used in the Linux versions (at least RedHat EL 3/4 and derivatives), which is presumably why he didn't see it before porting. Of course this is the danger of using non-standard language features - these things come and bite you at unexpected times. I'm a bit surprised this isn't flagged by the compiler (it warns you about lots of other non-standard usages), though I guess it would be a bit ugly to implement (the compiler would have to distinguish between usage in a standard header and other code). Tim. === cut here Tim Adye [EMAIL PROTECTED] http://hepunx.rl.ac.uk/~adye BaBar/Atlas Groups, Particle Physics Dept, Rutherford Appleton Lab -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
RE: C++ name with leading underscore character not Compiling
Hi Dave, Dave Korn wrote 16 April 2007 14:28:- On 16 April 2007 13:14, Adye, TJ (Tim) wrote: I'm a bit surprised this isn't flagged by the compiler (it warns you about lots of other non-standard usages), though I guess it would be a bit ugly to implement (the compiler would have to distinguish between usage in a standard header and other code). Actually, the compiler already has a good deal of knowlege about what constitute system headers and what constitute user headers: see '-Wsystem-headers' in the docs. So I think that it wouldn't actually be hard to implement, and I may even take a look at doing so myself. That would certainly be an interesting improvement. An alternative might be to distinguish between and includes. My concern was more that the determination of system headers is done in the preprocessor, while the type of identifier is determined later by the compiler. But I guess the latter knows about the former (eg. for error messages). It's a long time since I delved into the GCC sources... Tim. === cut here Tim Adye [EMAIL PROTECTED] http://hepunx.rl.ac.uk/~adye BaBar/Atlas Groups, Particle Physics Dept, Rutherford Appleton Lab -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
RE: Copy and paste shortcut
Buff Miner wrote on 11 April 2007 17:14: More precisely: Start up bash by doing Start - Programs - Cygwin - Cygwin Bash\ Shell. Right click on the icon in the upper left of the title bar and select properties Under Options, select 'QuickEdit Mode', hit ok Select 'Modify shortcut that started this window', hit ok To copy from a Cygwin Bash window, highlight the text by left clicking and dragging the mouse, then hit the enter key to copy the text. Or, left-click, drag, and right-click. Saves moving your hand back to the keyboard. To paste into a Cygwin Bash window, click on the icon in the upper left of the window menu bar and then do edit - paste or do Alt-Space e p That is, hold down the Alt key, hit the space bar, let up on the Alt key, type an e and then a p. My question is, Is there a way to create a shortcut for Alt-space, e, then p? Can this be with fewer key strokes? Maybe I misunderstood what you are asking, but if you have 'QuickEdit Mode' mode enabled, then you can paste into the Cygwin Bash window by clicking with the right mouse button. It's not a keyboard shortcut, but it is quick and easy! Tim. === cut here Tim Adye [EMAIL PROTECTED] http://hepunx.rl.ac.uk/~adye BaBar/Atlas Groups, Particle Physics Dept, Rutherford Appleton Lab -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Suggestion for run (with patch)
Hi Alexander, For many years I've continued to use Chuck Wilson's old run-1.1.4 because it included a version that was linked without Cygwin (run-native.exe, built with VC). Although it doesn't have all the features of the Cygwin version (eg. it can't translate Cygwin mount points), it does allow one to start applications without needing cygwin1.dll in the path. I know that's often not much of an issue (at least if run.exe is in C:\cygwin\bin), but it is sometimes handy to have a stand-alone version. The latest version of run, run-1.1.10-1 included in the Cygwin setup, has some nice improvements (and is easier to find than the old run-1.1.4!). I have made some small fixes to allow the new version to also build run-native.exe, with gcc -mno-cygwin (it also builds the Cygwin run.exe as before). Would you consider adopting this improvement, in the attached patch (see the top for build instructions)? You might have a better idea for where the non-Cygwin version should go - I just put it in /usr/bin/run-native.exe. Thanks, Tim. === cut here Tim Adye [EMAIL PROTECTED] http://hepunx.rl.ac.uk/~adye BaBar/Atlas Groups, Particle Physics Dept, Rutherford Appleton Lab Build Instructions == cd /usr/src wget http://mirrors.kernel.org/sourceware/cygwin/release/run/run-1.1.10-1-src.tar.bz2 tar jxf run-1.1.10-1-src.tar.bz2 ./run-1.1.10-1.sh prep patch -Z -p0 run-1.1.10-1-native.patch ./run-1.1.10-1.sh conf build install strip pkg This creates run-1.1.10-1.tar.bz2 with an extra file /usr/bin/run-native.exe . That file should be renamed to run.exe and moved elsewhere. It is build without the Cygwin DLL, so can be run without the Cygwin bin directory in the PATH. diff -urN -x .build -x .inst -x .sinst -x .buildlogs run-1.1.10-orig/compile run-1.1.10/compile --- run-1.1.10-orig/compile 1970-01-01 00:00:00.0 + +++ run-1.1.10/compile 2006-11-12 07:52:54.0 + @@ -0,0 +1,142 @@ +#! /bin/sh +# Wrapper for compilers which do not understand `-c -o'. + +scriptversion=2005-05-14.22 + +# Copyright (C) 1999, 2000, 2003, 2004, 2005 Free Software Foundation, Inc. +# Written by Tom Tromey [EMAIL PROTECTED]. +# +# This program is free software; you can redistribute it and/or modify +# it under the terms of the GNU General Public License as published by +# the Free Software Foundation; either version 2, or (at your option) +# any later version. +# +# This program is distributed in the hope that it will be useful, +# but WITHOUT ANY WARRANTY; without even the implied warranty of +# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the +# GNU General Public License for more details. +# +# You should have received a copy of the GNU General Public License +# along with this program; if not, write to the Free Software +# Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, USA. + +# As a special exception to the GNU General Public License, if you +# distribute this file as part of a program that contains a +# configuration script generated by Autoconf, you may include it under +# the same distribution terms that you use for the rest of that program. + +# This file is maintained in Automake, please report +# bugs to bug-automake@gnu.org or send patches to +# automake-patches@gnu.org. + +case $1 in + '') + echo $0: No command. Try \`$0 --help' for more information. 12 + exit 1; + ;; + -h | --h*) +cat \EOF +Usage: compile [--help] [--version] PROGRAM [ARGS] + +Wrapper for compilers which do not understand `-c -o'. +Remove `-o dest.o' from ARGS, run PROGRAM with the remaining +arguments, and rename the output as expected. + +If you are trying to build a whole package this is not the +right script to run: please start by reading the file `INSTALL'. + +Report bugs to bug-automake@gnu.org. +EOF +exit $? +;; + -v | --v*) +echo compile $scriptversion +exit $? +;; +esac + +ofile= +cfile= +eat= + +for arg +do + if test -n $eat; then +eat= + else +case $1 in + -o) + # configure might choose to run compile as `compile cc -o foo foo.c'. + # So we strip `-o arg' only if arg is an object. + eat=1 + case $2 in + *.o | *.obj) + ofile=$2 + ;; + *) + set x $@ -o $2 + shift + ;; + esac + ;; + *.c) + cfile=$1 + set x $@ $1 + shift + ;; + *) + set x $@ $1 + shift + ;; +esac + fi + shift +done + +if test -z $ofile || test -z $cfile; then + # If no `-o' option was seen then we might have been invoked from a + # pattern rule where we don't need one. That is ok -- this is a + # normal compilation that the losing compiler can handle. If no + # `.c' file was seen then we are probably linking. That is also + # ok. + exec $@ +fi + +# Name of file we expect compiler to create. +cofile=`echo $cfile | sed -e
RE: Suggestion for run (with patch)
Hi Christopher, Christopher Faylor wrote: I don't see any reason to include a non-cygwin version of a program in the *cygwin* distribution. If you don't have cygwin1.dll in the path, then you aren't running in a cygwin environment. This is not to say that I don't understand perfectly why someone might want to not use cygwin or how wonderful it might be not to use cygwin1.dll. This just isn't an issue we need to deal with here. This is nothing to do with knocking Cygwin. I'm talking about using run-native.exe to start Cygwin programs. However, when starting Cygwin programs from Windows, I find it clearer to setup the PATH (and perhaps start ancillary programs like Exceed) before invoking a Cygwin program. Yes, I could probably change things around to work with the Cygwin version of run (though for my use cases, that would be more convoluted), but a non-Cygwin version used to be part of the package, and solved the problem neatly. I am just restoring the functionality, and giving people another option. Also, since the run package is now part of Cygwin (and doesn't seem to be maintained elsewhere), it seems an unnecessary confusion to maintain two branches. If you really don't like having anything not linked with cygwin1.dll as part of the distribution, then how about taking the source-code updates and leaving the extra executable out of the distribution - though that would be a pity for people like me who find this the best way to start Cygwin programs. As I said before, run-native.exe doesn't need to live in /usr/bin, and could be called something else. But it is convenient to have available as a way to start Cygwin programs (I have been looking to releasing some other software to help with this, but I'm still tidying that up...). Tim. === cut here Tim Adye [EMAIL PROTECTED] http://hepunx.rl.ac.uk/~adye BaBar/Atlas Groups, Particle Physics Dept, Rutherford Appleton Lab -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
RE: Suggestion for run (with patch)
Hi Dave, Dave Korn wrote on 09 April 2007 17:16: You might have a better idea for where the non-Cygwin version should go - I just put it in /usr/bin/run-native.exe. Or just alias run-native='cmd /c start '. If that did what we wanted, then we wouldn't need the run package in the first place. The run command hides the console for console applications (or at least those that Windows thinks of as console applications) like xterm. cmd gives you that pesky console. Tim. === cut here Tim Adye [EMAIL PROTECTED] http://hepunx.rl.ac.uk/~adye BaBar/Atlas Groups, Particle Physics Dept, Rutherford Appleton Lab -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
RE: Suggestion for run (with patch)
Brian Dessent wrote on 09 April 2007 22:05: If you really want a compromise solution, you could modify run to not depend on cygwin1.dll at link-time but instead LoadLibrary() it at runtime, and if that fails fall back to whatever the native version would have done. Thus you get a single executable that understands posix paths if the DLL is in the PATH and still allows to you run c:\cygwin\bin\bash.exe (or whatever it is that you're currently doing) if the DLL is not in the PATH. Though that itself may cause confusion... That's a nice idea, but I suspect it would indeed cause more confusion than any gain - especially when we're only talking about a 50k executable. Imagine the program silently behaving differently if you change the PATH. A nice cygwin1.dll was not found error message is usually preferable :-) I hope that a separately-named (small) executable, perhaps installed elsewhere, will be acceptable. Tim. === cut here Tim Adye [EMAIL PROTECTED] http://hepunx.rl.ac.uk/~adye BaBar/Atlas Groups, Particle Physics Dept, Rutherford Appleton Lab -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
RE: Updated: inetutils-1.3.2-34 [setsockopt TOS (ignored): Protocol not available]
Hi Corinna, Thanks for the inetutils update. The inetd -D option is particularly welcome (so thanks also to Bryan Thrall). Unfortunately the new version's ftp, rcp, and rlogin commands give an annoying new warning when connecting, eg. ftp: setsockopt TOS (ignored): Protocol not available Actually, I suspect this is due to being compiled against updated headers, because I got the same when recompiling an earlier version of inetutils. Perhaps the IP_TOS (or similar) definition was added (since you built inetutils last), even though it doesn't seem to be implemented in setsockopt (for my XP SP2 system). I assume the messages can be ignored, but it would be good if they could be supressed. Thanks, Tim. -Original Message- From: [EMAIL PROTECTED] On Behalf Of Corinna Vinschen Sent: 11 January 2006 16:30 To: cygann Subject: Updated: inetutils-1.3.2-34 I've updated the version of inetutils to 1.3.2-34. Unfortunately I found that I had a longstanding build problem on my local machine, which could result in stuff like rlogind bombing with a segmentation violation and similar funny problems. However, since a release without some interesting change is too boring, here we go: Changes in 1.3.2-34: - Forced rebuild to fix longstanding(?) local build problem. - Change syslogd-config script to deal with existing syslog-ng installation, in preparation of upcoming syslog-ng package. == === IMPORTANT NOTE: - When updating inetutils, take care that syslogd.exe, inetd.exe and subsequent processes don't run anymore. Otherwise the update will fail. == === === cut here == Tim Adye [EMAIL PROTECTED] http://hepunx.rl.ac.uk/~adye BaBar Group, Particle Physics Dept, Rutherford Appleton Lab, UK -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
RE: Updated: perl-5.8.7-2
Gerrit P. Haase wrote: Hi Tim, Adye, TJ (Tim) wrote: Hi Gerrit, Thanks for the Perl update. Unfortunately this doesn't seem to fix the problem I reported earlier (Perl Win32::Shortcut screws up fork). My test script worked fine after rebaseall, but when I reinstalled Cygwin from scratch (including Perl 5.8.7-2) it dies with Have you recompiled Win32::Shortcut? Do you use the standard perl linker wrapper ld2 / perlld? If not have you used the --enable-auto-image-base flag to link the DLL? No, I didn't recompile Win32::Shortcut. I guess I should repeat my earlier Apologies if I was being overoptimistic and this release (alone) wasn't expected to fix my problem. I guess I need to be patient and wait for an update to perl-libwin32 to fix the problem. Thanks, Tim. == cut here == Tim Adye, BaBar Group, Particle Physics Dept., _ /| Rutherford Appleton Laboratory, UK. \'o.O' Oop! e-mail: [EMAIL PROTECTED]=(___)= Ack! WWW: http://hepwww.rl.ac.uk/Delphi/Adye/homepage.htmlU Thphft! -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
RE: Updated: perl-5.8.7-2
Hi Gerrit, -Original Message- From: Gerrit P. Haase [EMAIL PROTECTED] Sent: 12 July 2005 13:03 To: Adye, TJ (Tim) Cc: The Cygwin Mailing List Subject: Re: Updated: perl-5.8.7-2 Adye, TJ (Tim) wrote: Have you recompiled Win32::Shortcut? Do you use the standard perl linker wrapper ld2 / perlld? If not have you used the --enable-auto-image-base flag to link the DLL? No, I didn't recompile Win32::Shortcut. I guess I should repeat my earlier Please recompile, and ensure that you use --enable-auto-image-base to link your DLL. This should do the same like rebase besides a 'random' base address is used. --enable-auto-image-base is now default when building perl extensions with 'perl makefile.PL ...'. I can try this if it would help your tests. rebaseall is probably a simpler workaround for me at the moment, though of course it would be nice to eventually have something that works out of the box so people can use my script on other systems without having to run any special setup. Do you have a package for which I can use for tests (so I just need to call `make test` or `perl Makefile.PL make test` I was just using the test script I posted earlier. An even shorter alternative would be #!/usr/bin/perl use Win32::Shortcut; system 'pwd'; I guess an automated test package could require all the packages that have associated DLLs and then issue a fork. I guess I need to be patient and wait for an update to perl-libwin32 to fix the problem. Maintainer are busy, so don't count the days;) Check! Tim. Gerrit -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
RE: Updated: perl-5.8.7-2
Hi Gerrit, Thanks for the Perl update. Unfortunately this doesn't seem to fix the problem I reported earlier (Perl Win32::Shortcut screws up fork). My test script worked fine after rebaseall, but when I reinstalled Cygwin from scratch (including Perl 5.8.7-2) it dies with C:\cygwin\bin\perl.exe (3772): *** unable to remap C:\cygwin\lib\perl5\vendor_perl\5.8\cygwin\auto\Win32\Shortcut\Shortcut. dll to same address as parent(0x95) != 0xBF 17 [main] perl 3448 fork_parent: child 3772 died waiting for dll loading The addresses are now different, if that's any consolation (previously it reported parent(0xBF) != 0x111). Presumably rebaseall will fix it again, but I'll keep the pristine Cygwin installation for further tests if that's helpful. Apologies if I was being overoptimistic and this release (alone) wasn't expected to fix my problem. Tim. -Original Message- From: [EMAIL PROTECTED] On Behalf Of Gerrit P. Haase Sent: 10 July 2005 02:13 To: cygwin-announce@cygwin.com Subject: Updated: perl-5.8.7-2 Perl has been updated to 5.8.7-2 - Now using --enable-auto-image-base to link DLL and extensions. This should address the problem with loading extension DLLs in subprocesses. NEWS - New builtin functions: Cygwin::winpid_to_pid, Cygwin::pid_to_winpid - Configured with -Dusesitecustomize. See also -f in perlrun: http://search.cpan.org/~nwclark/perl-5.8.7/pod/perlrun.pod#%2Df Extensions already included in this distribution: Compress-Zlib-1.34 Compress-Bzip2-2.08 IO-Zlib-1.04 IO-String-1.06 Archive-Tar-1.24 MD5-2.03 Term-ReadLine-Perl-1.0203 Net-Telnet-3.03 TermReadKey-2.30 XML-Parser-2.34 Perl 5.8.7 announcement: http://dev.perl.org/perl5/news/2005/perl-5.8.7.html 5.8.7 is a maintenance release for perl 5.8, incorporating various minor bugfixes and optimisations. Please see the perldelta http://search.cpan.org/~nwclark/perl-5.8.7/pod/perl587delta.pod for the full details. Please report bugs using the perlbug utility. If the build or regression tests fail, make nok. If the build fails to early to run this, please mail perlbug at perl.org directly. DESCRIPTION === As always, you should conduct an appropriate level of testing before using any new product in your production environment. Canonical website: http://www.perl.org/ UPDATE == To update your installation, click on the Install Cygwin now link on the http://cygwin.com/ web page. This downloads setup.exe to your system. Save it and run setup, answer the questions and pick up 'perl' from the 'Interpreters' category, if you install it for the first time, click on the 'skip' field next to 'perl' until '5.8.7-2' is displayed. DOWNLOAD: = Note that downloads from sources.redhat.com (aka cygwin.com) aren't allowed due to bandwidth limitations. This means that you will need to find a mirror which has this update, please choose the one nearest to you: http://cygwin.com/mirrors.html QUESTIONS: == If you want to make a point or ask a question the Cygwin mailing list is the appropriate place. CYGWIN-ANNOUNCE UNSUBSCRIBE INFO: = To unsubscribe to the cygwin-announce mailing list, look at the List-Unsubscribe: tag in the email header of this message. Send email to the address specified there. It will be in the format: [EMAIL PROTECTED] If you need more information on unsubscribing, start reading here: http://sources.redhat.com/lists.html#unsubscribe-simple Please read *all* of the information on unsubscribing that is available starting at this URL. Gerrit P. Haase -- =^..^= -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
RE: readshortcut crashes with updated cygwin-1.5.18-1 (cygutils maintainer -- RFA patch enclosed)
Thanks! The cygutils-1.2.9-1 update fixes the problem.
Tim.
-Original Message-
From: Christopher Faylor
Sent: 07 July 2005 19:06
To: cygwin@cygwin.com
Subject: Re: readshortcut crashes with updated
cygwin-1.5.18-1 (cygutils maintainer -- RFA patch enclosed)
On Thu, Jul 07, 2005 at 05:29:25PM +0100, Adye, TJ (Tim) wrote:
Hi,
With cygwin-1.5.18-1, the |readshortcut| command crashes on exit if I
specify a Cygwin-style path name. The crash goes away if I
downgrade to
cygwin 1.5.17-1.
It's a readshortcut double free problem. As mentioned in another
message, cygwin is using a new version of malloc and it appears to be
more sensitive to these programming errors.
The patch below fixes it.
Chuck, ok to check in? If so, I'll also get rid of all of
the ^Ms in the
readshortcut files.
Btw, in case anyone is interested, I tracked this down by putting a
breakpoint on free, and printing the address being freed. Then I
cut/pasted that output to a file and sorted the file based on the
address. This unearthed a few potential candidates for this problem,
one of which turned out to be the the culprit. I think this is the
fastest I've ever found a double free problem.
So much for my lunch break...
cgf
2005-07-07 Christopher Faylor [EMAIL PROTECTED]
* src/readshortcut.c (readshortcut): Pass opts by
reference so that
changes made to the opts contents are reflected in the caller to
accommodate freeing of malloced fields.
Index: readshortcut.c
===
RCS file: /cvs/cygwin-apps/cygutils/src/readshortcut/readshortcut.c,v
retrieving revision 1.1
diff -d -u -p -r1.1 readshortcut.c
--- readshortcut.c5 Sep 2003 04:07:57 - 1.1
+++ readshortcut.c7 Jul 2005 17:57:28 -
@@ -216,7 +216,7 @@ exit:
return result;
}
-int readshortcut(optvals opts, poptContext optContext) {
+int readshortcut(optvals *opts, poptContext optContext) {
HRESULT hres;
IShellLink *shell_link;
IPersistFile *persist_file;
@@ -227,36 +227,36 @@ int readshortcut(optvals opts, poptConte
int result = ERR_NONE; /* the value to return on exit */
/* Add suffix to link name if necessary */
- if (strlen (opts.target_fname) 4) {
-int tmp = strlen (opts.target_fname) - 4;
-if (strncmp (opts.target_fname + tmp, .lnk, 4) != 0) {
- opts.target_fname = (char *)realloc(opts.target_fname,
strlen(opts.target_fname) + 1 + 4);
- if (opts.target_fname == NULL) {
+ if (strlen (opts-target_fname) 4) {
+int tmp = strlen (opts-target_fname) - 4;
+if (strncmp (opts-target_fname + tmp, .lnk, 4) != 0) {
+ opts-target_fname = (char
*)realloc(opts-target_fname, strlen(opts-target_fname) + 1 + 4);
+ if (opts-target_fname == NULL) {
fprintf(stderr, %s: memory allocation error\n,
program_name);
return (ERR_SYS);
}
- strcat (opts.target_fname, .lnk);
+ strcat (opts-target_fname, .lnk);
}
}
else {
-opts.target_fname = (char *)realloc(opts.target_fname,
strlen(opts.target_fname) + 1 + 4);
-if (opts.target_fname == NULL) {
+opts-target_fname = (char *)realloc(opts-target_fname,
strlen(opts-target_fname) + 1 + 4);
+if (opts-target_fname == NULL) {
fprintf(stderr, %s: memory allocation error\n, program_name);
return (ERR_SYS);
}
-strcat (opts.target_fname, .lnk);
+strcat (opts-target_fname, .lnk);
}
/* if there's no colon in the path, it's POSIX and we
should convert to win32 */
- if (strchr (opts.target_fname, ':') == NULL) {
+ if (strchr (opts-target_fname, ':') == NULL) {
char *strTmpPath = (char*)malloc(MAX_PATH);
if (strTmpPath == NULL) {
fprintf(stderr, %s: memory allocation error\n, program_name);
return (ERR_SYS);
}
-cygwin_conv_to_full_win32_path (opts.target_fname, strTmpPath);
-free (opts.target_fname);
-opts.target_fname = strTmpPath;
+cygwin_conv_to_full_win32_path (opts-target_fname, strTmpPath);
+free (opts-target_fname);
+opts-target_fname = strTmpPath;
}
hres = OleInitialize (NULL);
@@ -280,33 +280,33 @@ int readshortcut(optvals opts, poptConte
WCHAR wsz[MAX_PATH];
/* Ensure that the string is Unicode. */
-MultiByteToWideChar(CP_ACP, 0,
(LPCSTR)opts.target_fname, -1, wsz, MAX_PATH);
+MultiByteToWideChar(CP_ACP, 0,
(LPCSTR)opts-target_fname, -1, wsz, MAX_PATH);
/* Load the shortcut. */
hres = persist_file-lpVtbl-Load(persist_file, wsz, STGM_READ);
if (SUCCEEDED(hres)) {
/* read stuff from the link object and print it to the
screen */
- if (opts.show_all || opts.show_target) {
+ if (opts-show_all || opts-show_target) {
shell_link-lpVtbl-GetPath(shell_link, strPath,
MAX_PATH, NULL, SLGP_RAWPATH
readshortcut crashes with updated cygwin-1.5.18-1
Hi, With cygwin-1.5.18-1, the |readshortcut| command crashes on exit if I specify a Cygwin-style path name. The crash goes away if I downgrade to cygwin 1.5.17-1. % readshortcut C:/Documents and Settings/All Users/Start Menu/Programs/Accessories/Calculator /cygdrive/c/WINDOWS/system32/calc.exe % readshortcut /cygdrive/c/Documents and Settings/All Users/Start Menu/Programs/Accessories/Calculator /cygdrive/c/WINDOWS/system32/calc.exe Aborted (core dumped) % cat readshortcut.exe.stackdump Stack trace: Frame Function Args 0022E888 7C802542 (0658, EA60, 00A4, 0022E8C4) 0022E998 61088618 (, , 00240178, 0022EBCC) 0022EA88 610865FC (, 007C, 0022EF88, 7C90EE18) 0022EB08 61086B1B (0006, 0001, , ) 0022EBB8 61086CD3 (0748, 0006, 0022EBE8, 61086EC7) 0022EBC8 61086CFC (0006, , 0022EC08, 6104EC66) 0022EBE8 61086EC7 (10010200, 10010200, , 1001) 0022EC18 610AA8B2 (10010200, 0022EEFC, 0022EC7C, 6104F45B) 0022EC48 6104EC66 (100103D8, , , 0001) 0022EF18 610844FF (0002, 611584D0, 10010090, 7C919AF0) 0022EFD8 61004DD2 (0022EFF0, 004F004E, 00510050, 00530052) 0022FF88 6100594F (, , , ) End of stack trace I get the same crash if I cd to the directory and just specify Calculator or Calculator.lnk. It's not specific to that shortcut file either. Tim. -Original Message- From: [EMAIL PROTECTED] On Behalf Of Christopher Faylor Sent: 03 July 2005 03:08 To: cygwin-announce@cygwin.com Subject: Updated: cygwin-1.5.18-1 I've made a new version of the Cygwin DLL and associated utilities available for download. As usual, a list of what has changed is below. [...] -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Perl Win32::Shortcut screws up fork
Hi,
In an attempt to work round the problem with readshortcut I reported
earlier, I thought I'd use a Perl script. Unfortunately the
Win32::Shortcut package seems to cause problems with process forking
(unlike the readshortcut error, this one isn't specific to the latest
cygwin DLL). I get an error
C:\cygwin\bin\perl.exe (3088): *** unable to remap
C:\cygwin\lib\perl5\vendor_perl\5.8\cygwin\auto\Win32\Shortcut\Shortcut.
dll to same address as parent(0xBF) != 0x111
13 [main] perl 3716 fork_parent: child 3088 died waiting for dll
loading
Here's an example that demonstrates the problem.
#!/usr/bin/perl -w
use strict;
use Win32::Shortcut;
if (my $pid= open (my $pipe, '-|')) {
print forked child process $pid\n;
while ($pipe) { print from child: $_; }
close ($pipe) or die;
} elsif (defined $pid) {
print this is the child\n;
exit;
} else {
print fork failed: $!\n;
}
Without the use Win32::Shortcut, the script runs fine. With the
package the fork fails with the error message I gave. Win32::Shortcut
works fine if I don't fork or don't do it until after the package is
loaded (eg. I can eval require Win32::Shortcut after the fork). I see
this behaviour with Perl 5.8.6 and 5.8.7 and Cygwin 1.5.17-1 and
1.5.18-1.
This error makes it a tricky to convert the Win32::Shortcut output to
Cygwin-style paths with cygpath -u (without resorting to a separate
program to parse the results). Or is there a Perl module that can do the
cygpath conversion? That would be even nicer!
Thanks,
Tim.
== cut here ==
Tim Adye, BaBar Group, Particle Physics Dept., _ /|
Rutherford Appleton Laboratory, UK. \'o.O' Oop!
e-mail: [EMAIL PROTECTED]=(___)= Ack!
WWW: http://hepwww.rl.ac.uk/Delphi/Adye/homepage.htmlU Thphft!
--
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Problem reports: http://cygwin.com/problems.html
Documentation: http://cygwin.com/docs.html
FAQ: http://cygwin.com/faq/
RE: readshortcut crashes with updated cygwin-1.5.18-1 (cygutils maintainer -- RFA patch enclosed)
Christopher Faylor wrote: Btw, in case anyone is interested, I tracked this down by putting a breakpoint on free, and printing the address being freed. Then I cut/pasted that output to a file and sorted the file based on the address. This unearthed a few potential candidates for this problem, one of which turned out to be the the culprit. I think this is the fastest I've ever found a double free problem. Fast work indeed! Thanks, Tim. == cut here == Tim Adye, BaBar Group, Particle Physics Dept., _ /| Rutherford Appleton Laboratory, UK. \'o.O' Oop! e-mail: [EMAIL PROTECTED]=(___)= Ack! WWW: http://hepwww.rl.ac.uk/Delphi/Adye/homepage.htmlU Thphft! -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
RE: Perl Win32::Shortcut screws up fork
Hi Larry, Sorry, I assumed that the rebasing problem was ancient history, since I hadn't encountered it for so long (and remembered a long-ago comment about rebaseall being a stop-gap measure). Thanks for putting me right. Unfortunately I can't get rebaseall to work... running from a bash prompt in a DOS box (as the docs tell me to), I get % ps -a PIDPPIDPGID WINPID TTY UIDSTIME COMMAND 1668 11668 16680 22534 19:36:55 /usr/bin/bash 126816681268 18000 22534 19:45:04 /usr/bin/ps % rebaseall ReBaseImage (/usr/bin/cygiconv-2.dll) failed with last error = 6 cygiconv-2.dll is used by bash, but rebaseall is a bash script. What can I do? Thanks, Tim. -Original Message- From: Larry Hall Sent: 07 July 2005 19:09 To: Adye, TJ (Tim); cygwin@cygwin.com Subject: Re: Perl Win32::Shortcut screws up fork At 01:10 PM 7/7/2005, you wrote: In an attempt to work round the problem with readshortcut I reported earlier, I thought I'd use a Perl script. Unfortunately the Win32::Shortcut package seems to cause problems with process forking (unlike the readshortcut error, this one isn't specific to the latest cygwin DLL). I get an error C:\cygwin\bin\perl.exe (3088): *** unable to remap C:\cygwin\lib\perl5\vendor_perl\5.8\cygwin\auto\Win32\Shortcu t\Shortcut. dll to same address as parent(0xBF) != 0x111 13 [main] perl 3716 fork_parent: child 3088 died waiting for dll loading Sounds like a classic rebasing issue to me. Have you tried running 'rebaseall'? -- Larry Hall http://www.rfk.com RFK Partners, Inc. (508) 893-9779 - RFK Office 838 Washington Street (508) 893-9889 - FAX Holliston, MA 01746 -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
RE: Perl Win32::Shortcut screws up fork
Answering my own question cygiconv-2.dll is used by bash, but rebaseall is a bash script. What can I do? I found I could do this by saving the rebase command-line and file list that rebaseall generates and then running the rebase command directly from the DOS prompt. Now Perl's Win32::Shortcut and fork work together! Thanks for the hint. Nevertheless, there does seem to be a problem with the rebaseall. Tim. -Original Message- From: Adye, TJ (Tim) Sent: 07 July 2005 19:55 To: 'Cygwin List' Subject: RE: Perl Win32::Shortcut screws up fork Hi Larry, Sorry, I assumed that the rebasing problem was ancient history, since I hadn't encountered it for so long (and remembered a long-ago comment about rebaseall being a stop-gap measure). Thanks for putting me right. Unfortunately I can't get rebaseall to work... running from a bash prompt in a DOS box (as the docs tell me to), I get % ps -a PIDPPIDPGID WINPID TTY UIDSTIME COMMAND 1668 11668 16680 22534 19:36:55 /usr/bin/bash 126816681268 18000 22534 19:45:04 /usr/bin/ps % rebaseall ReBaseImage (/usr/bin/cygiconv-2.dll) failed with last error = 6 cygiconv-2.dll is used by bash, but rebaseall is a bash script. What can I do? Thanks, Tim. -Original Message- From: Larry Hall Sent: 07 July 2005 19:09 To: Adye, TJ (Tim); cygwin@cygwin.com Subject: Re: Perl Win32::Shortcut screws up fork At 01:10 PM 7/7/2005, you wrote: In an attempt to work round the problem with readshortcut I reported earlier, I thought I'd use a Perl script. Unfortunately the Win32::Shortcut package seems to cause problems with process forking (unlike the readshortcut error, this one isn't specific to the latest cygwin DLL). I get an error C:\cygwin\bin\perl.exe (3088): *** unable to remap C:\cygwin\lib\perl5\vendor_perl\5.8\cygwin\auto\Win32\Shortcu t\Shortcut. dll to same address as parent(0xBF) != 0x111 13 [main] perl 3716 fork_parent: child 3088 died waiting for dll loading Sounds like a classic rebasing issue to me. Have you tried running 'rebaseall'? -- Larry Hall http://www.rfk.com RFK Partners, Inc. (508) 893-9779 - RFK Office 838 Washington Street (508) 893-9889 - FAX Holliston, MA 01746 -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
RE: dlopen does not search the path
Hi Chris, Following your announcement in the cygwin-1.5.18-1 update cgf: Fix bug which stopped dlopen() from using standard Windows mechanism for finding a DLL. I can confirm that my problem is now fixed. Thanks! Tim. On 2 June 2005, Christopher Faylor wrote: On Fri, Jun 03, 2005 at 12:33:55AM +0100, Adye, TJ (Tim) wrote: Hi, On 26 May 2005, Christopher Faylor wrote: I've made a new version of the Cygwin DLL and associated utilities available for download. As usual, a list of what has changed is below. [...] cgf: Make dlopen search /usr/bin (for Windows compatibility) and /usr/lib (for UNIX compatibility). The change seems to be a bit more drastic than that implies to me. I believe that previously dlopen searched $PATH before, but it doesn't any more. I have a Cygwin program that loads a Windows DLL (afsauthent.dll) that it used to find via the $PATH (found in C:\Program Files\OpenAFS\Common, which OpenAFS adds to the Windows PATH, and is inherited by Cygwin). That stopped working recently (Win32 error 126), probably when I updated to cygwin-1.5.17-1 (I can check if this is in any doubt). I can get it working again if I add /cygdrive/c/Program Files/OpenAFS/Common to $LD_LIBRARY_PATH by hand. Is this change deliberate? I would have thought that Windows compatibility ought to include searching the PATH. It was not deliberate and, in fact, the change in behavior had nothing to do with the change to make dlopen search /usr/bin and /usr/lib. It was, however, another change of mine so I still have to take the blame. I've checked in a fix. It will be in the next snapshot. cgf == cut here == Tim Adye, BaBar Group, Particle Physics Dept., _ /| Rutherford Appleton Laboratory, UK. \'o.O' Oop! e-mail: [EMAIL PROTECTED]=(___)= Ack! WWW: http://hepwww.rl.ac.uk/Delphi/Adye/homepage.htmlU Thphft! -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
RE: Updated: cygwin-1.5.17-1
OK, I downgraded to cygwin 1.5.16-1 and the problem went away. I made a small test program, dltest (attached), that does a dlopen(file,RTLD_LAZY). The following shows that PATH was searched with 1.5.16-1, but not in 1.5.17-1. cygwin 1.5.16-1:- % export PATH=/usr/bin % ./dltest afsauthent.dll error opening afsauthent.dll: dlopen, Win32 error 126 % export PATH=/usr/bin:/cygdrive/c/Program Files/OpenAFS/Common % ./dltest afsauthent.dll opened afsauthent.dll cygwin 1.5.17-1:- % export PATH=/usr/bin:/cygdrive/c/Program Files/OpenAFS/Common % ./dltest afsauthent.dll error opening afsauthent.dll: dlopen, Win32 error 126 % type afsauthent.dll# just to be sure it's there afsauthent.dll is /cygdrive/c/Program Files/OpenAFS/Common/afsauthent.dll % export LD_LIBRARY_PATH=/cygdrive/c/Program Files/OpenAFS/Common % ./dltest afsauthent.dll opened afsauthent.dll Tim. -Original Message- From: Larry Hall Sent: 03 June 2005 01:05 To: Adye, TJ (Tim); The Cygwin Mailing List Subject: RE: Updated: cygwin-1.5.17-1 At 07:33 PM 6/2/2005, you wrote: Hi, On 26 May 2005, Christopher Faylor wrote: I've made a new version of the Cygwin DLL and associated utilities available for download. As usual, a list of what has changed is below. [...] cgf: Make dlopen search /usr/bin (for Windows compatibility) and /usr/lib (for UNIX compatibility). The change seems to be a bit more drastic than that implies to me. I believe that previously dlopen searched $PATH before, but it doesn't any more. I have a Cygwin program that loads a Windows DLL (afsauthent.dll) that it used to find via the $PATH (found in C:\Program Files\OpenAFS\Common, which OpenAFS adds to the Windows PATH, and is inherited by Cygwin). That stopped working recently (Win32 error 126), probably when I updated to cygwin-1.5.17-1 (I can check if this is in any doubt). Yes, please do and report back. -- Larry Hall http://www.rfk.com RFK Partners, Inc. (508) 893-9779 - RFK Office 838 Washington Street (508) 893-9889 - FAX Holliston, MA 01746 dltest.c Description: dltest.c -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
RE: Updated: cygwin-1.5.17-1
Hi, On 26 May 2005, Christopher Faylor wrote: I've made a new version of the Cygwin DLL and associated utilities available for download. As usual, a list of what has changed is below. [...] cgf: Make dlopen search /usr/bin (for Windows compatibility) and /usr/lib (for UNIX compatibility). The change seems to be a bit more drastic than that implies to me. I believe that previously dlopen searched $PATH before, but it doesn't any more. I have a Cygwin program that loads a Windows DLL (afsauthent.dll) that it used to find via the $PATH (found in C:\Program Files\OpenAFS\Common, which OpenAFS adds to the Windows PATH, and is inherited by Cygwin). That stopped working recently (Win32 error 126), probably when I updated to cygwin-1.5.17-1 (I can check if this is in any doubt). I can get it working again if I add /cygdrive/c/Program Files/OpenAFS/Common to $LD_LIBRARY_PATH by hand. Is this change deliberate? I would have thought that Windows compatibility ought to include searching the PATH. Regards, Tim. == cut here == Tim Adye, BaBar Group, Particle Physics Dept., _ /| Rutherford Appleton Laboratory, UK. \'o.O' Oop! e-mail: [EMAIL PROTECTED]=(___)= Ack! WWW: http://hepwww.rl.ac.uk/Delphi/Adye/homepage.htmlU Thphft! -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
