From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 7481 invoked by alias); 25 Mar 2013 13:30:27 -0000 Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sourceware.org Received: (qmail 7463 invoked by uid 89); 25 Mar 2013 13:30:20 -0000 X-Spam-SWARE-Status: No, score=-1.4 required=5.0 tests=AWL,BAYES_00,FREEMAIL_ENVFROM_END_DIGIT,FREEMAIL_FROM,FREEMAIL_REPLY,RCVD_IN_DNSWL_LOW autolearn=no version=3.3.1 Received: from mail-ia0-f181.google.com (HELO mail-ia0-f181.google.com) (209.85.210.181) by sourceware.org (qpsmtpd/0.84/v0.84-167-ge50287c) with ESMTP; Mon, 25 Mar 2013 13:30:16 +0000 Received: by mail-ia0-f181.google.com with SMTP id o25so5513264iad.12 for ; Mon, 25 Mar 2013 06:30:15 -0700 (PDT) MIME-Version: 1.0 X-Received: by 10.50.7.242 with SMTP id m18mr11412599iga.53.1364218215536; Mon, 25 Mar 2013 06:30:15 -0700 (PDT) Received: by 10.64.14.129 with HTTP; Mon, 25 Mar 2013 06:30:15 -0700 (PDT) In-Reply-To: <83wqsv1v4b.fsf@gnu.org> References: <83ip4s4ixc.fsf@gnu.org> <1363407692-18959-1-git-send-email-yao@codesourcery.com> <1363407692-18959-4-git-send-email-yao@codesourcery.com> <51492077.30307@codesourcery.com> <83sj3qyogk.fsf@gnu.org> <87vc8m7z1d.fsf@fleche.redhat.com> <514FA117.9030604@gmail.com> <83hajz3oef.fsf@gnu.org> <83boa73mty.fsf@gnu.org> <837gkv3maf.fsf@gnu.org> <8338vj3i1w.fsf@gnu.org> <83wqsv1v4b.fsf@gnu.org> Date: Mon, 25 Mar 2013 16:14:00 -0000 Message-ID: Subject: Re: [MinGW-w64]Build gdb/ctf.c failed From: Kai Tietz To: Eli Zaretskii Cc: asmwarrior@gmail.com, tromey@redhat.com, yao@codesourcery.com, gdb-patches@sourceware.org Content-Type: text/plain; charset=ISO-8859-1 X-SW-Source: 2013-03/txt/msg00932.txt.bz2 2013/3/25 Eli Zaretskii : >> Date: Mon, 25 Mar 2013 13:42:52 +0100 >> From: Kai Tietz >> 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.