From: Christopher Faylor <cgf-use-the-mailinglist-please@sourceware.org>
To: gdb-patches@sourceware.org, Joel Brobecker <brobecker@adacore.com>
Subject: Re: [RFA/win32] Avoid a couple of name collisions in win32-nat.c
Date: Wed, 14 Jan 2009 15:08:00 -0000 [thread overview]
Message-ID: <20090114150730.GC6423@ednor.casa.cgf.cx> (raw)
In-Reply-To: <20090114062228.GC24105@adacore.com>
On Wed, Jan 14, 2009 at 10:22:28AM +0400, Joel Brobecker wrote:
>> > >2009-01-07 Joel Brobecker <brobecker@adacore.com>
>> > >
>> > > * win32-nat.c (kernel32_DebugSetProcessKillOnExit): Renames
>> > > DebugSetProcessKillOnExit. Update all uses in this file.
>> > > (kernel32_DebugActiveProcessStop): Renames DebugActiveProcessStop.
>> > > Update all uses in this file.
>>
>> This one is now in. I will review ASAP all the names we are using
>> when importing routines from DLLs, to see if there are others that
>> might need an adjustment.
>
>Just for the record, Chris asked:
>
>| Yes. I guess that means that the rename to prefix kernel32_ is approved
>| too but I'd appreciate it if you would universally add the kernel32_ prefix
>| to everything that is dynamically derived from kernel32.
>
>I double-checked every call to GetProcAddress, and the kernel32_
>prefix is already added to all the function pointers related to
>kernel32 routines.
>
>There are a bunch of function pointers whose name is still identical
>to the function name:
>
> static BOOL WINAPI (*OpenProcessToken)(HANDLE, DWORD, PHANDLE);
> static BOOL WINAPI (*LookupPrivilegeValue)(LPCSTR, LPCSTR, PLUID);
> static BOOL WINAPI (*AdjustTokenPrivileges)(HANDLE, BOOL, PTOKEN_PRIVILEGES,
> DWORD, PTOKEN_PRIVILEGES, PDWORD);
>
>But these routines are from advapi32.dll, and are declared inside
>a function (set_process_priviledge).
>
>I don't think you really wanted me to rename this variables too,
>since local variables should not cause a collision (they should just
>hide the global names, if any). And because everything is local,
>the addition of the advapi32_ prefix does make the reading of the
>code a little harder, IMO. But just in case, here is the corresponding
>patch. It's untested for now, but I can test it before checking in.
>It does compile, though.
>
>2009-01-14 Joel Brobecker <brobecker@adacore.com>
>
> * windows-nat.c (set_process_privilege): Rename OpenProcessToken,
> LookupPrivilegeValue and AdjustTokenPrivileges by prefixing them
> with "advapi32_". Adjust the code accordingly.
I think you're right. It does make the code harder to read. I've been toying
with putting guards around the windows header files which define the other
functions so that they can just be used like you would normally without the
kernel32_ prefix but I haven't been able to convince myself that this would
be a big improvement.
I don't think we need the advapi32_ here though since it isn't causing problems.
Thanks for researching this.
cgf
prev parent reply other threads:[~2009-01-14 15:08 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-01-07 11:24 Joel Brobecker
2009-01-07 16:57 ` Christopher Faylor
2009-01-08 12:53 ` Joel Brobecker
2009-01-09 10:42 ` Joel Brobecker
2009-01-14 6:23 ` Joel Brobecker
2009-01-14 15:08 ` Christopher Faylor [this message]
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=20090114150730.GC6423@ednor.casa.cgf.cx \
--to=cgf-use-the-mailinglist-please@sourceware.org \
--cc=brobecker@adacore.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