From: Eli Zaretskii <eliz@gnu.org>
To: "pedro alves" <alves.ped@gmail.com>
Cc: gdb-patches@sourceware.org
Subject: Re: [New WinCE support] [patch 4/4] The bulk of the code.
Date: Sat, 17 Mar 2007 11:18:00 -0000 [thread overview]
Message-ID: <uslc4nmmu.fsf@gnu.org> (raw)
In-Reply-To: <4053daab0703160803s3edf1294sfcdf4f8319787ab7@mail.gmail.com> (alves.ped@gmail.com)
> Date: Fri, 16 Mar 2007 15:03:21 +0000
> From: "pedro alves" <alves.ped@gmail.com>
> Cc: gdb-patches@sourceware.org
>
> > Instead of using an arbitrary size 1024 (btw, you don't check whether
> > FormatMessageW indicated that it needed more than 1024), isn't it
> > better to use FORMAT_MESSAGE_ALLOCATE_BUFFER? As a bonus, it would
> > avoid overwriting the static buffer on each call, which is not a nice
> > API, IMHO.
>
> I'm using the same api as strerror, which returns a pointer into a
> static buffer.
In that case, I guess it's okay to use a static buffer. But please at
least check inside the function that the buffer size was enough, by
comparing the value returned by FormatMessageW with the size of the
buffer you passed to it.
> Hummm, I don't know how is it that I specified a buffer of size 0,
> and Windows (at least CE) still fills the buffer.
I think it fills the buffer because the buffer is larger than 0. The
return value tells you how many characters it _really_ needed to
format the message. By comparing that value with the size of the
buffer, you can find out whether the buffer was large enough.
> > > +#ifdef __MINGW32CE__
> > > + err = strwinerror (GetLastError ());
> > > +#else
> > > err = strerror (errno);
> > > +#endif
>
> > Why not call strwinerror strerror and avoid the ifdef?
>
> Because then I would have to:
>
> #ifdef __MINGW32CE__
> #define errno (GetLastError ())
> #endif
>
> err = strerror (errno);
>
> That means I still must have an #ifdef somewhere.
But that ifdef would be in only one place, while with a different
function you need an ifdef each time you use the function.
> Since there is only one instance of it (the #ifdef) in gdbserver, I
> thought it is better to have strwinerror explicit.
There's only one instance _today_. Tomorrow we could have more of
them.
Btw, I see in your patch two instances of strwinerror and two places
that call it: one in gdbreplay.c, the other in utils.c. Why did you
need two almost identical functions?
> When someone later uses errno as an lvalue, it breaks WinCE again.
I think such usage of errno is a bad idea anyway, since on many
platforms errno is a function already (to support multi-threading).
> The other place I used strwinerror is in:
>
> if (!ret)
> {
> - error ("Error creating process %s, (error %d): %s\n", args,
> - (int) GetLastError (), strerror (GetLastError ()));
> + error ("Error creating process \"%s%s\", (error %d): %s\n",
> + program, args,
> + (int) GetLastError (), strwinerror (GetLastError ()));
> }
>
> On Window 9x/NT it is wrong to do:
> strerror (GetLastError ())
>
> The errno values and the windows error codes are not the same.
This is not a problem: errno should not be used with any literal
values anyway, only with symbolical constants.
> Would you prefer to have that? That is, rewrite this last hunk to use
> FormatMessage
> directly, and rename strwinerror to strerror, put it wincecompat.c, and have a:
>
> #ifdef __MINGW32CE__
> #define errno (GetLastError ())
> #endif
Yes, I'd prefer that solution. gdbserver/win32-low.c is already
Windows specific, so it's okay to use FormatMessage there.
> > > doc/ChangeLog
> > >
> > > * gdb.texinfo (WinCE): Delete subsection.
> >
> > Why? Is that subsection incorrect in some ways?
> >
>
> It is correct for the current WinCE support, using gdb/wince.c and
> gdb/wince-stub.c, which implements a custom remote protocol. This
> patch removes those files, removing the functionality that
> subsection is documenting.
Are there any WinCE-specific commands or features left after your
patch? If there are, please describe them in this section. If not,
then it's okay to delete the section.
Thanks.
next prev parent reply other threads:[~2007-03-17 11:18 UTC|newest]
Thread overview: 19+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <20070315235008.243411000@portugalmail.pt>
2007-03-16 2:07 ` [New WinCE support] [patch 1/4] : mv win32-i386-low.c win32-low.c Pedro Alves
2007-03-27 19:11 ` Daniel Jacobowitz
2007-03-16 2:09 ` [New WinCE support] [patch 3/4] : bfd config Pedro Alves
2007-03-16 2:09 ` [New WinCE support] [patch 2/4] : s/thread_info/win32_thread_info/g Pedro Alves
2007-03-27 19:12 ` Daniel Jacobowitz
2007-03-16 2:10 ` [New WinCE support] [patch 4/4] The bulk of the code Pedro Alves
2007-03-16 12:52 ` Eli Zaretskii
2007-03-16 15:03 ` pedro alves
2007-03-17 11:18 ` Eli Zaretskii [this message]
2007-03-17 11:35 ` Andreas Schwab
2007-03-19 1:53 ` Pedro Alves
2007-03-19 4:21 ` Eli Zaretskii
2007-03-19 12:34 ` Daniel Jacobowitz
2007-03-27 19:20 ` Daniel Jacobowitz
2007-03-29 3:18 ` Pedro Alves
2007-03-29 3:51 ` Pedro Alves
2007-03-30 11:56 ` Pierre Muller
2007-03-30 12:23 ` pedro alves
2007-03-30 20:35 ` pedro alves
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=uslc4nmmu.fsf@gnu.org \
--to=eliz@gnu.org \
--cc=alves.ped@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