From: Alfredo Ortega <ortegaalfredo@gmail.com>
Cc: gdb-patches@sourceware.org
Subject: Re: Use external editor in 'commands' command
Date: Fri, 16 Jan 2009 22:08:00 -0000 [thread overview]
Message-ID: <e598931c0901161408x5179b81fw113f4f9b0052e67b@mail.gmail.com> (raw)
In-Reply-To: <u4ozzwrg2.fsf@gnu.org>
2009/1/16 Eli Zaretskii <eliz@gnu.org>:
>> Date: Fri, 16 Jan 2009 05:38:41 -0200
>> From: Alfredo Ortega <ortegaalfredo@gmail.com>
>>
>> Thanks for the corrections. Here are are both changelogs and the
>> updated diff, I hope there are less errors now...
>> I promise that my next patches will be better!
>
> No one is born with this, so there's nothing wrong in making such
> minor mistakes.
>
> I have several comments to your code:
>
>> + char vitmp[50];
>
> vitmp[] is a file name, so 50 is not nearly enough characters to hold
> the longest possible name. At the very least, please use
> FILENAME_MAX, or (better) some dynamic code that grows it as needed,
> because some hosts (e.g., Hurd) don't have any limitations on file
> name length.
>
>> + char cmdline[100];
>
> Same here: 100 is not enough, because $EDITOR holds a file name.
>
>> + if (!strcmp(COMMANDS_EDCOMMAND,p)) {
>
> This is not GNU style of laying out brace-delimited blocks; please use
> the same style and indentation as elsewhere in GDB sources.
>
>> + strcpy(vitmp,"/tmp/.gdbXXXXXX");
>
> Please leave a blank between the function name and the left
> parenthesis, and also between the comma and the following argument in
> argument lists. Like this:
>
> strcpy (vitmp, "/tmp/.gdbXXXXXX");
>
> Btw, using "/tmp/.gdbXXXXXX" is non-portable to Windows, where there's
> no guarantee there will be a "/tmp" on the current drive, and it will
> not work at all in the DJGPP (a.k.a. DOS) port of GDB, because DOS
> filesystems do not allow file names with a leading dot.
>
>> + /* Generates the temporal file name*/
> ^^^^^^^^
> "temporary"
>
>> + /* vitmp = tempnam(NULL,".gdb"); this is more secure according to man mkstemp, but gcc complains... */
>
> What complaint do you see?
>
>> + if (mkstemp(vitmp)<0) return;
>
> Are you using mkstemp from libiberty? Because otherwise it may not be
> available on the host.
>
>> + if (fsize<strlen(l->line)+1) {
>> + fclose(tmpstream);
>> + unlink(vitmp);
>> + return;
>> + };
>
> Don't we want some error message in this case?
>
>> + if ((editor = (char *) getenv ("EDITOR")) == NULL)
>> + editor = "/bin/ex";
>
> This is likewise non-portable: "/bin/ex" is only guaranteed to exist
> on Posix platforms.
>
In the next patch I will adress all those issues (The fixed lenght
buffers are ugly but you can never overflow them, the mkstemp template
and the snprintf don't allow for it, but then some bad truncation and
unpredictable execution may happen).
gcc will complain about tmpnamp() like this:
test.c:(.text+0x13): warning: the use of `tempnam' is dangerous,
better use `mkstemp'
The man page of FreeBSD explains it much better than the Debian one,
now I know it's because a possible race condition.
About the "/bin/ex" issue, to maintain consistency I did it the same
way that the EDIT command, here:
gdb/cli/cli-cmds.c:695
if ((editor = (char *) getenv ("EDITOR")) == NULL)
editor = "/bin/ex";
BTW "/bin/ex" exists on solaris 9, but not Debian or *BSD (is
/usr/bin/ex there), as a result text editing won't work by default on
most systems.
It would be difficult to choose a portable editor...maybe with some #defines
next prev parent reply other threads:[~2009-01-16 22:08 UTC|newest]
Thread overview: 20+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <e598931c0901141343j79164cf6we2bc5307f41f41da@mail.gmail.com>
2009-01-14 21:48 ` Alfredo Ortega
2009-01-14 22:38 ` Eli Zaretskii
2009-01-15 1:55 ` Alfredo Ortega
2009-01-22 3:25 ` dgutson
[not found] ` <e598931c0901141632m4f124d85l2452f7e2870cad91@mail.gmail.com>
2009-01-15 4:21 ` Eli Zaretskii
2009-01-16 7:39 ` Alfredo Ortega
2009-01-16 9:07 ` Eli Zaretskii
2009-01-16 22:08 ` Alfredo Ortega [this message]
2009-01-16 23:38 ` Daniel Jacobowitz
2009-01-16 23:58 ` Tom Tromey
2009-01-17 9:27 ` Eli Zaretskii
2009-01-16 23:56 ` Tom Tromey
2009-01-17 9:29 ` Eli Zaretskii
2009-01-19 11:45 ` Alfredo Ortega
2009-02-02 22:18 ` Tom Tromey
2009-02-19 20:05 ` Alfredo Ortega
2009-02-19 20:26 ` Alfredo Ortega
2009-02-24 20:20 ` Tom Tromey
2009-08-28 23:17 ` Alfredo Ortega
2009-09-18 21:05 ` Tom Tromey
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=e598931c0901161408x5179b81fw113f4f9b0052e67b@mail.gmail.com \
--to=ortegaalfredo@gmail.com \
--cc=gdb-patches@sourceware.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox