Re: [MinGW-w64]Build gdb/ctf.c failed

[Kai Tietz <ktietz70@googlemail.com>]

2013/3/25 Eli Zaretskii <eliz@gnu.org>:
>> Date: Mon, 25 Mar 2013 13:42:52 +0100
>> From: Kai Tietz <ktietz70@googlemail.com>
>> Cc: asmwarrior@gmail.com, tromey@redhat.com, yao@codesourcery.com,
>>       gdb-patches@sourceware.org
>>
>> So, you claimed MinGW-w64 did something wrong ... well, if we wouldn't
>> declare mkdir here, indeed it would be worth a bug-report ...
>
> Actually, Posix says mkdir should be in sys/stat.h, not in unistd.h.
> And it looks like MinGW64 does indeed have mkdir in stat.h, not in
> unistd.h.  Which IMO is another unfortunate incompatibility with
> mingw.org.

Well, our sys/stat.h header depends on io.h and by this it gets also
the mkdir prototype.  From our POV this is the proper thing to do
here.

>> So what differences you were talking about?
>
> The difference that caused the warning -- the fact that _mkdir's
> prototype was not visible after including unistd.h.

Right, and it isn't something POSIX requests.  So well, we could
prototype it in io.h header, too.  But well, I can put apple-juice
into a milk-bottle, and technical it is ok, but logical people
wouldn't expect it there.  It is an MS extension, so include proper
header for it ...

>> The function mkdir is declared for MinGW.org, and for MinGW-w64.  It
>> is the POSIX compliant API name and both ventures are declaring it
>> in an POSIX-helper header.
>
> Yes (but see below about its Posix nature).
>
>>  So you mean yet _mkdir?
>
> Yes, of course.  _mkdir was the reason for the compiler warning.  If
> it were declared in io.h, then the warning would not have been
> emitted.

And here is the confusion.  See aboive that _mkdir is an MS extension
and you shouldn't expect that declared as side-effect.  Actual that
you get it by mingw.org's unistd.h is an implementation detail you
should never rely on.

>> if you want to use a posix function, include the corresponding posix
>> header; if you want to a MS API, use the header MS defines the
>> function/interface lives in.  it wouldn't really help portability
>> (in either direction) to support including a posix header, and
>> getting a MS API function, so mingw doesn't lay its headers that
>> way.
>
> Unfortunately, this isn't so simple, as MS API offers mkdir as well
> (see direct.h in any MS SDK), albeit while discouraging/deprecating
> its use:

Well, we are pretty aware about that, but it doesn't make it more
reasonable why _mkdir should be declared by unistd.h header (or io.h
header).  Actual mingw-w64 even provides a feature to warn about his
deprecated API, if you are eager to see that.

>   http://msdn.microsoft.com/en-us/library/vstudio/ms235326%28v=vs.100%29.aspx
>
> Thus, mkdir is both a Posix API and an MS API.  Moreover, the Posix
> mkdir accepts 2 arguments, not one.  So what MinGW provides is not
> really a Posix API, but rather a slightly incompatible variant
> thereof.

Yeah, that is something created by history ... I admit that unistd.h
should better do actual the define for mkdir ... not sure how many
ventures might get affected for their Windows port here.  Additional a
define has the disadvantage of not providing proper function-point
feature, but a static function in header might cause other issues ...

>> The header io.h isn't a POSIX one, and therefore you should just
>> expect what actual is documented by vendor (in msdn) for it and not
>> what one implementation mightz does.
>
> MinGW's unistd.h includes io.h, and thus gets both mkdir and _mkdir.
Yeah, and that's an implementation detail and IMHO even a bug, because
msdn is documenting it differently ... but well that is in this case
just nit-picking.
> One could perhaps argue that this is or isn't a mistake, but given the
> precedence, having a different arrangement in MinGW64 is unfortunate,
> since it will mean more #ifdef'ing in the projects that want to
> support both.  For yet another example of such incompatibilities, see

Yeah, therefore don't rely on implementation details.

>   http://lists.gnu.org/archive/html/emacs-devel/2013-03/msg00611.html

Yeah, saw that too.