A trivial API change, to avoid the need for const-casts.
2012-05-06 Bruno Haible
sh-quote: Improve shell_quote_argv's signature.
* lib/sh-quote.h (shell_quote_argv): Make argument array a 'const *'.
* lib/sh-quote.c (shell_quote_argv): Likewise.
--- lib/sh-quote.h.ori
Paul Eggert wrote:
> Thanks. Either of those would work.
Good. I'll concentrate on option 4 in the next few days. This part is
needed for option 3 as well.
> I prefer option 3
> (popenv / systemv) as it offers more opportunity for
> optimization on GNUish hosts, which can use vfork or the
> equi
On 05/06/2012 12:38 PM, Niels Möller wrote:
But in the particular case of SunOS, the types are defined by system
headers in release 5.10 (and presumably nailed down by the ABI spec),
Hmm, well, the latter point is dubious. SunOS 5.10 standard headers do not
mention int_fast*_t, except in stdi
On 05/06/2012 12:34 PM, Bruno Haible wrote:
Here are two more proposals, designed to avoid the drawbacks of the
previous ones:
Thanks. Either of those would work. I prefer option 3
(popenv / systemv) as it offers more opportunity for
optimization on GNUish hosts, which can use vfork or the
eq
Eli Zaretskii wrote:
> So on Posix hosts, this new API will probably simply call the
> shell-style quoting, while on non-Posix hosts it will use separate
> code, is that right?
Right.
Bruno
> From: Bruno Haible
> Cc: bug-gnulib@gnu.org, egg...@cs.ucla.edu, bug-gnu-ut...@gnu.org
> Bcc: br...@haible.de
> Date: Sun, 06 May 2012 22:25:12 +0200
>
> /* Identifier for the kind of interpreter of the command. */
> enum system_command_interpreter
> {
> /* The interpreter used by the system
Eli Zaretskii wrote:
> use a different set of styles: a "shell command-line argument" quoting
> style and a "file-name" quoting style. The former would be used for
> producing shell commands, and will use platform-dependent quoting,
> similar to the patch I sent. The latter would be used for quot
Eli Zaretskii wrote:
> if you have % characters in a string, each such character should
> be quoted separately. Thus, %Path% is quoted as "%"Path"%".
Perfect. Thanks.
> From: Bruno Haible
> Cc: Paul Eggert , Eli Zaretskii ,
> bug-gnu-ut...@gnu.org
> Bcc: br...@haible.de
> Date: Sun, 06 May 2012 20:33:05 +0200
>
> Whereas for my proposal I see the following drawbacks:
>
> * The programmer has to explicitly write code with #if for native Windows.
This drawb
> From: Bruno Haible
> Cc: egg...@cs.ucla.edu, bug-gnulib@gnu.org, bug-gnu-ut...@gnu.org
> Bcc: br...@haible.de
> Date: Sun, 06 May 2012 20:56:54 +0200
>
> Eli Zaretskii wrote:
> > When % does need to be quoted, it cannot be in the way on which
> > quotearg's design is based, because "%FOO%" will
Paul Eggert writes:
> Intuitively, it's because the int_fast* types are so fragile: they
> depend so much on choice of compiler and compiler option.
Short version: I think gnulib should either make an effort to define
int_fast*_t in the common way on each system (always doing the same as
gcc wou
Here are two more proposals, designed to avoid the drawbacks of the
previous ones:
3) A new API
/* Constructs a command line for the platform's command interpreter
that executes argv[0] with the arguments argv[1...] and invokes
popen() on it. */
FILE *popenv (const char
Bruno Haible scripsit:
> How does % need to be quoted, then? Can you find out, please? This info
> would be useful both for Paul's proposal and for mine.
Strings of the form %FOO% in cmd.exe commands are expanded iff FOO is
an existing environment variable; otherwise, the string is left alone.
Al
On 05/06/2012 10:29 AM, Eli Zaretskii wrote:
You will break gobs of programs that use gnulib
Not at all. Only programs that specifically ask
for the new module, such as diffutils, would get
the proposed requoting behavior.
Eli Zaretskii wrote:
> When % does need to be quoted, it cannot be in the way on which
> quotearg's design is based, because "%FOO%" will still expand the
> variable.
How does % need to be quoted, then? Can you find out, please? This info
would be useful both for Paul's proposal and for mine.
Bru
Paul Eggert wrote:
> The idea here is not to reimplement popen from scratch in gnulib,
> or to have gnulib popen support every feature that POSIX requires.
> The idea is only to have a popen wrapper that works assuming that
> its argument is quoted for the POSIX shell, using quotearg.
> Such argume
Paul Eggert wrote:
> Sorry, there still seems to be a misunderstanding here.
> In src/diff3.c the pattern is this:
>
> #if HAVE_WORKING_FORK
> ...
> #else
> ...
> fpipe = popen (command, "r");
> ...
> #endif
>
> which means that popen is not invoked on Unix.
Y
On 05/06/2012 10:29 AM, Bruno Haible wrote:
This would add (by my count) 72 source files to diff
So what? It is no maintenance burden, because "gnulib-tool --update"
does all a maintainer needs.
Yes and no. gnulib-tool imports the files automatically,
but the maintainer still needs to deal
> From: Bruno Haible
> Cc: egg...@cs.ucla.edu, bug-gnulib@gnu.org, bug-gnu-ut...@gnu.org
> Bcc: br...@haible.de
> Date: Sun, 06 May 2012 19:41:39 +0200
>
> Eli Zaretskii wrote:
> > The rare situation where it doesn't (described by "cmd /?")
>
> Rare or not - the text that you refer to mentions t
Eli Zaretskii wrote:
> The rare situation where it doesn't (described by "cmd /?")
Rare or not - the text that you refer to mentions that the following
characters need to be quoted as well when passing through cmd.exe:
&()[]{}^=;!'+,`~
And they forgot to mention at least % which also has an inte
> Date: Sun, 06 May 2012 10:13:13 -0700
> From: Paul Eggert
> CC: bug-gnulib@gnu.org, bug-gnu-ut...@gnu.org
>
> > There was never such an implementation of popen on any non-Posix
> > platform (nor can there be, at least on Windows, because of the need
> > to support native file names with backsla
Hi Paul,
> > use the gnulib modules 'execute' and 'spawn-pipe'
>
> This would add (by my count) 72 source files to diff
So what? It is no maintenance burden, because "gnulib-tool --update"
does all a maintainer needs.
> > - If you apply these changes also to the HAVE_WORKING_FORK
On 05/06/2012 12:13 AM, Niels Möller wrote:
Paul Eggert writes:
> Generally speaking, it's unwise to use
> the int_fast*_t types in a public header file.
Why (feel free to point to the relevant section of gnulib docs, if it's
explained well there)?
Intuitively, it's because the int_fast*
On 05/06/2012 09:52 AM, Eli Zaretskii wrote:
But since 'diff' output can be fed to a shell or to another program,
It's a judgment call, but in this particular case the output of
diff is intended more for the user than for other programs, and
there is a good argument for consistency in output fo
> Date: Sun, 06 May 2012 09:41:50 -0700
> From: Paul Eggert
> CC: bug-gnulib@gnu.org, bug-gnu-ut...@gnu.org
>
> On 05/06/2012 09:26 AM, Eli Zaretskii wrote:
> > a MinGW program running on Windows does not
> > need to cater to Posix shells
>
> It's not a question of catering to Posix shells, it's
> From: Bruno Haible
> Cc: bug-gnulib@gnu.org, bug-gnu-ut...@gnu.org
> Bcc: br...@haible.de
> Date: Sun, 06 May 2012 13:49:14 +0200
>
> diff3 receives the arguments as expected
Yes, of course: it receives them from the command line, correctly
quoted.
> But on native Windows, there are two ways t
On 05/06/2012 09:26 AM, Eli Zaretskii wrote:
a MinGW program running on Windows does not
need to cater to Posix shells
It's not a question of catering to Posix shells, it's
a question of what the output from 'diff' looks like.
It's better to have 'diff' output be consistent on
all platforms.
> Date: Sat, 05 May 2012 23:22:13 -0700
> From: Paul Eggert
> CC: bug-gnulib@gnu.org, bug-gnu-ut...@gnu.org
>
> Unfortunately quotearg is used not just to quote
> strings for the shell, but also to quote strings POSIX-shell-style
> for stdout. That is, in practice shell_quoting_style doesn't mea
On 05/06/2012 04:49 AM, Bruno Haible wrote:
1) Change the three locations in src/diff3.c, src/sdiff.c, src/util.c to
use the gnulib modules 'execute' and 'spawn-pipe'
This would add (by my count) 72 source files to diff, and would
add some complexity to diffutils proper. I'd rather ke
Bruno Haible writes:
> It doesn't exist so far. But it is feasible. - On the other hand, it
> looks like nettle-stdint.h can already be easily trimmed in this way,
> by undefining _STDINT_NEED_INT_LEAST_T and _STDINT_NEED_INT_FAST_T ?
I think that makes sense. I just need someone (Dagobert Miche
Nikos Mavrogiannopoulos wrote:
> > libunistring installs a trimmed-down version of
> > gnulib's stdint.h, that defines only the int{8,16,32}_t types and not
> > all the rest (int64_t, int_least*_t, int_fast*_t, etc.). [1]
>
> Is there a gnulib module that only provides the basic types?
It doesn't
Eli Zaretskii wrote:
> D:\gnu\diffutils-3.2\src>.\diff3 ../../diffutils-2.8.7/src/system.h
> system.h "sys tem.$h$"
> diff: extra operand `tem.$h$''
> diff: Try `diff --help' for more information.
> D:\gnu\diffutils-3.2\src/./diff3.exe: subsidiary program `diff' failed
> (exit status 2)
On 05/06/2012 12:34 PM, Bruno Haible wrote:
> Niels Möller wrote:
>> One possibility might be to not define the types at all, unless the
>> gnulib application explicitly asks for them. Lots of applications want
>> uint32_t, and I imagine a lot fewer have any need for int_fast*_t.
> Yes. For this r
Niels Möller wrote:
> One possibility might be to not define the types at all, unless the
> gnulib application explicitly asks for them. Lots of applications want
> uint32_t, and I imagine a lot fewer have any need for int_fast*_t.
Yes. For this reason, libunistring installs a trimmed-down version
Hi Niels,
Am 06.05.2012 um 07:02 schrieb Paul Eggert:
> On 05/05/2012 12:19 PM, Niels Möller wrote:
>> So code which uses the int_fast*_t types and relies on gnulib will get a
>> slightly different ABI
>
> Generally speaking, it's unwise to use
> the int_fast*_t types in a public header file.
> T
Paul Eggert writes:
> Generally speaking, it's unwise to use
> the int_fast*_t types in a public header file.
Why (feel free to point to the relevant section of gnulib docs, if it's
explained well there)?
Maybe nobody uses these types so it's an academic issue, but if these
types are used in th
36 matches
Mail list logo
