From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail4-relais-sop.national.inria.fr (mail4-relais-sop.national.inria.fr [192.134.164.105]) by walapai.inria.fr (8.13.6/8.13.6) with ESMTP id q25D6eS9025290 for ; Mon, 5 Mar 2012 14:06:40 +0100 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Aj0DANC5VE9KfVM0k2dsb2JhbAApGrReCCIBAQEBCQkLCRQEI4F9AQEBBBICLAEbHQEDDAYFCw0jCyEBAREBBQEOAQ0GEwgMDodlCymhcAqLcoJxhGg/gQwBBQuJImqGRgSNb4dPhxuEAoMXPYQFgVQ X-IronPort-AV: E=Sophos;i="4.73,533,1325458800"; d="scan'208";a="134417527" Received: from mail-ee0-f52.google.com ([74.125.83.52]) by mail4-smtp-sop.national.inria.fr with ESMTP/TLS/RC4-SHA; 05 Mar 2012 14:06:34 +0100 Received: by eekd4 with SMTP id d4so1645197eek.39 for ; Mon, 05 Mar 2012 05:06:34 -0800 (PST) Received-SPF: pass (google.com: domain of camaradetux@gmail.com designates 10.14.120.210 as permitted sender) client-ip=10.14.120.210; Authentication-Results: mr.google.com; spf=pass (google.com: domain of camaradetux@gmail.com designates 10.14.120.210 as permitted sender) smtp.mail=camaradetux@gmail.com; dkim=pass header.i=camaradetux@gmail.com Received: from mr.google.com ([10.14.120.210]) by 10.14.120.210 with SMTP id p58mr11088294eeh.98.1330952794033 (num_hops = 1); Mon, 05 Mar 2012 05:06:34 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=cyUqimVXiYunPcAxXLq2oxGBoJ779+7Gxr5VsDldHSk=; b=04WtPuzUhzthpOWt7B0QtHW+KNdQqH1/1mZTriJIm9GuAGC2LccfzsvG0ST5DFOsR6 D0sGrffhPMNbPfqhg+WAuv/BnbF1emn98QHs4hKViKWnbrgCM1hDznyCwYkxlC2VvKpe knBN3OjRxCj5KzmnQdGWyKw5i7Vn9B749DGx5VN4xu5opI3n0nsuGjvfZCzKNLP9SP84 aY0kxAFmiYcV0Z903cc/qQYxSVb2XpiOspGgmavqqzmRkkTvWgOvnNsLEIq+QySYDJav UfT6lLv+9+y+VfO73z63J2l8wd2m69WmxQmBYoK9kIfHI2M3lzL6bcK6yyEE1VYXgrex qp1A== MIME-Version: 1.0 Received: by 10.14.120.210 with SMTP id p58mr8450602eeh.98.1330952793952; Mon, 05 Mar 2012 05:06:33 -0800 (PST) Received: by 10.213.3.76 with HTTP; Mon, 5 Mar 2012 05:06:33 -0800 (PST) In-Reply-To: References: Date: Mon, 5 Mar 2012 14:06:33 +0100 Message-ID: From: Adrien To: Gabriel Scherer Cc: caml-list caml-list Content-Type: text/plain; charset=ISO-8859-1 Subject: Re: [Caml-list] [community poll for PR#5312] Do some OCaml Windows users still use the @responsefile feature? On 05/03/2012, Gabriel Scherer wrote: > In the process of discussing bug #5312, the caml team would like to > know if people still have use of the @responsefile feature under > windows. If not, it could be removed from the runtime -- that is from > all OCaml programs. > > http://caml.inria.fr/mantis/view.php?id=5312 > > @responsefile is a feature/convention under Windows to provide files > containing command-line argument options; when a tool parses > command-line options and encounters a file name prefixed by a '@' > character, it expands its contents as if it were part of the > command-line invocation. This is used to circumvent the historically > fairly ridiculous limit on command-line length in the old 'cmd.com'. > > The OCaml toolchain copes with @responsefile in two places -- as far > as I know, but I'm not familiar with anything Windows. First, when the > compiler invokes external tools (linkers, etc.) under Windows, it uses > a @responsefile if the command-line length exceeds a fixed limit -- > curently 4096, used to be 256 and annoy users. > > Second, under Windows only, the OCaml runtime considers @-prefixed > arguments as responsefile file names, and expands them during its > initialization phase. This is silently done by the OCaml *runtime*, so > all OCaml programs are affected; the compilers, but also the user > programs. Did you know that you shouldn't use '@' in your command-line > parameters syntax if you want your program to work on Windows? > > The first use has been problematic in the past because some of the > underlying toolchains (Cygwin, mingw...) did not support > @responsefiles. The second case is now problematic as the @-syntax > conflicts with the warning-as-error syntax of the compiler: as > reported by Dmitry Grebeniuk, "-w @a" under windows complains about > a missing file "a", while it really should mark all warnings as > errors -- a very bad idea for future compatibility when new warnings > are added, by the way; don't use that in released OCaml software. > > According to our Windows spies, the command-line restrictions are > nowadays very reasonable: 8K for cmd.com, and 32K internally. Maybe > the @responsefile feature has outlived its use, and this bug could be > fixed by simply removing the @-files expansion phase of the runtime. As far as I can see on msdn, 8K for cmd.exe has started with Windows XP. It was 2047 bytes on Windows 2000. In other words, do we still want to build on 2000 or 9x/Me? I don't think that was event supposed to be supported, even without this @responsefile issue and I think I remember some issues running ocaml programs on win9x. Moreover, noone is going to be able to support that; i.e. win9x support has probably already bitrot a lot. By the way, I had only known of reponse files a pretty long time ago because Cygwin and/or MSYS didn't handle it. I guess the only way to make sure noone uses it is to break response files and wait until someone shouts. Regards, Adrien Nader