This is the mail archive of the
gdb-patches@sourceware.cygnus.com
mailing list for the GDB project.
Re: Shell escape in the DJGPP port of GDB
- To: Fernando Nasser <fnasser@cygnus.com>
- Subject: Re: Shell escape in the DJGPP port of GDB
- From: Eli Zaretskii <eliz@gnu.org>
- Date: Sun, 22 Aug 1999 06:14:04 -0400
- CC: DJ Delorie <dj@delorie.com>, gdb-patches@sourceware.cygnus.com, Michael Snyder <msnyder@cygnus.com>
- References: <37BDA912.4AA1190D@cygnus.com> <199908201917.PAA26278@envy.delorie.com> <37BDAD71.510A96A1@cygnus.com> <199908202005.QAA26613@envy.delorie.com> <37BDB5E2.4318@cygnus.com> <199908202013.QAA26688@envy.delorie.com>
> One more question: is it really necessary to put the chdir() call under
> ifdef __DJGPP__ or is it just for saving time when it is not necessary?
Actually, I *did* have a reason for #ifdef'ing that call to chdir.
But it wasn't performance what I was thinking about. My reason was
that on all DOS/Windows systems chdir doesn't change the current
drive. So, if GDB called `system' when the current working directory
was "d:/foo/bar", and whatever program(s) that were run by `system'
changed to a directory "c:/usr/bin", then calling chdir won't return
you to "d:/foo/bar" without an additional system call which switches
to drive D: as well. DJGPP's chdir does that automagically.
I didn't want this problem to be swept under the carpet when (and if)
the source is compiled with anything other than DJGPP. If I left
chdir there for non-DJGPP environments, they would only see the bug in
the rare cases that the drive is changed during `system', which makes
the bug much less visible and harder to debug.
Of course, if DJGPP is the only environment that is supposed to use
this branch of code, then the #ifdef can be safely removed.