Re: [msysGit] [PATCH] mingw: redefine the wrapper macro after the corresponding function

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Am 06.06.2014 10:32, schrieb Stepan Kasal:
> Hello,
> 
> On Fri, Jun 06, 2014 at 12:00:51AM +0200, Karsten Blees wrote:
>> Am 05.06.2014 18:56, schrieb Johannes Sixt:
>>> Within mingw.c, if some other function inside mingw.c wants to use
>>> mingw_unlink, then it should be written as 'mingw_unlink(foo)', not
>>> 'unlink(foo)'.
>> I very much like this approach. In fact, we already do this for e.g. mingw_raise.
> 
> Hannes, this is consistent with your commit 06bc4b7.  Settled.
> 
>> Other callers would typically want the wrapped version (i.e.
>> mingw_*).
> 
> If this assumption were true, then we have to keep the wrapper macros
> defined, both above and below the wrapper function definition.

That's not what I meant. Assume all other callers are written 'mingw_foo', as suggested by Hannes, and no one except 'mingw_foo' has the need to call MSVCRT's 'foo' directly. Then its irrelevant whether the #undef is at the top or immediately before 'mingw_foo'. Having the #undef in close vicinity of the function definition helps removing it when its no longer needed.

Thinking about this some more, the best solution is probably to eliminate the problem altogether by adding inline-wrappers for required CRT-functions, e.g.:

mingw.h:

static inline int crt_gethostname(char *host, int namelen)
{
	return gethostname(host, namelen);
}
int mingw_gethostname(char *host, int namelen);
#define gethostname mingw_gethostname

mingw.c:

int mingw_gethostname(char *name, int namelen)
{
    ensure_socket_initialization();
    return crt_gethostname(name, namelen);
}

--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html




[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]