headers
Buzz | 4 Sep 2005 05:06
Picon

Re: [patch] Don't append extra NUL to registry-strings.

Op Tue, 30 Aug 2005 11:33:16 +0100 schreef Dave Korn
in <SERRANO4brJta07SaZ600000362 <at> SERRANO.CAM.ARTIMI.COM>:
:  ----Original Message----
: > From: Corinna Vinschen

[dropping NUL from strings returned by RegQueryValueEx]

: > trailing \0.  First, the \0 is part of the "file content" in a way.
:
:    To me this is the even more important reason.  Some registry strings do
:  include the trailing zero, some don't;

I don't see how this could be. The (MS) windows API-reference
(win32api.hlp) entry for RegQueryValueEx states (a.o.)

| REG_EXPAND_SZ	A null-terminated string that contains unexpanded
| references to environment variables (for example, "%PATH%"). It will
| be a Unicode or ANSI string depending on whether you use the Unicode
| or ANSI functions.
[...]
| REG_MULTI_SZ	An array of null-terminated strings, terminated by
| two null characters.
[..]
| REG_SZ	A null-terminated string. It will be a Unicode or ANSI string
| depending on whether you use the Unicode or ANSI functions.
[...]
| If the data has the REG_SZ, REG_MULTI_SZ or REG_EXPAND_SZ type, then
| lpData will also include the size of the terminating null character. 

:   cygwin shouldn't tamper with it.  And
(Continue reading)

Permalink | Reply | 3 comments |
headers
Bas van Gompel | 4 Sep 2005 05:05
Picon

Re: [patch] Don't append extra NUL to registry-strings.

Op Mon, 29 Aug 2005 10:21:19 +0200 schreef Corinna Vinschen
in <20050829082119.GA24845 <at> calimero.vinschen.de>:
:  On Aug 28 22:49, Bas van Gompel wrote:
: > Hi,
: >
: > When RegQueryValueEx returns a string-type, the final NUL is included
: > in the returned size. I suggest dropping it.
:
:  I see what you're up to, but there would be two reasons not to drop the
:  trailing \0.  First, the \0 is part of the "file content" in a way.  

Don't file-systems have their own way of reporting ends (EOF)?

:  Second, it would break backward compatibility with applications using
:  /proc/registry.  This latter point concerns me a bit, though it can
:  naturally only affect Cygwin applications.

Hmmm... :( ... possibly the CYGWIN-environment-variable might have room
for something like ``registry:raw,data'' (default, for  now) to mean
``as is'', and other options might cause various levels of verbosity/
interpretation... (I know SHTDI, but would P be TC for such a thing?)

L8r,
--

-- 
  ) |  | ---/ ---/  Yes, this | This message consists of true | I do not
--  |  |   /    /   really is |   and false bits entirely.    | mail for
  ) |  |  /    /    a 72 by 4 +-------------------------------+ any1 but
--  \--| /--- /---  .sigfile. |   |perl -pe "s.u(z)\1.as."    | me. 4^re
(Continue reading)

Permalink | Reply | 1 comment |
headers
Corinna Vinschen | 5 Sep 2005 12:03
Favicon

Re: [patch] Don't append extra NUL to registry-strings.

On Sep  4 05:05, Bas van Gompel wrote:
> Op Mon, 29 Aug 2005 10:21:19 +0200 schreef Corinna Vinschen
> in <20050829082119.GA24845 <at> calimero.vinschen.de>:
> :  On Aug 28 22:49, Bas van Gompel wrote:
> : > Hi,
> : >
> : > When RegQueryValueEx returns a string-type, the final NUL is included
> : > in the returned size. I suggest dropping it.
> :
> :  I see what you're up to, but there would be two reasons not to drop the
> :  trailing \0.  First, the \0 is part of the "file content" in a way.  
> 
> Don't file-systems have their own way of reporting ends (EOF)?

Er... that doesn't matter, does it?  What we have here is a virtual file
system which allows access to the "file" content of registry keys.  The
_SZ keys contain what the type name suggests, zero-terminated strings.
The trailing \0 is part of the "file" content as defined by MS.  There's
no gain in just removing it without notice.

> :  Second, it would break backward compatibility with applications using
> :  /proc/registry.  This latter point concerns me a bit, though it can
> :  naturally only affect Cygwin applications.
> 
> Hmmm... :( ... possibly the CYGWIN-environment-variable might have room
> for something like ``registry:raw,data'' (default, for  now) to mean
> ``as is'', and other options might cause various levels of verbosity/
> interpretation... (I know SHTDI, but would P be TC for such a thing?)

That sounds like a lot of trouble for... what exactly?  What are you
(Continue reading)

Permalink | Reply | 0 comments |
headers
Dave Korn | 5 Sep 2005 12:31
Favicon

RE: [patch] Don't append extra NUL to registry-strings.

----Original Message----
>From: Buzz
>Sent: 04 September 2005 04:06

>>    To me this is the even more important reason.  Some registry strings
>>  do include the trailing zero, some don't;
> 
> I don't see how this could be.

  Because internally (native API) the registry stores NT-style
UNICODE_STRING structures, which have an explicit length count.  See also 

http://www.sysinternals.com/Information/TipsAndTrivia.html#HiddenKeys

http://blogs.msdn.com/oldnewthing/archive/2004/08/24/219444.aspx

    cheers,
      DaveK
--

-- 
Can't think of a witty .sigline today....
Permalink | Reply | 2 comments |
headers
Eric Blake | 6 Sep 2005 17:37
Gravatar

fix ARG_MAX

Even though cygexec mountpoints can have a larger argument space, we might as 
well make ARG_MAX and sysconf(_SC_ARG_MAX) work correctly in the common case of 
non-cygexec mountpoints.  POSIX defines ARG_MAX as the max number of bytes to 
an exec*() call, including the environment, and requires a minimum of 4k.  This 
patch is slightly conservative, since the CreateProcess limitation of 32k does 
not include the environment, but any bigger number would be problemetic.  This 
was discovered by the recent breakage in xargs 4.2.25-1, where 1M was too big.

For further justification of this patch, see the thread at 
http://lists.gnu.org/archive/html/bug-findutils/2005-09/msg00039.html

2005-09-06  Eric Blake  <ebb9 <at> byu.net>

	* include/limits.h (ARG_MAX): New limit.
	* sysconf.cc (sysconf): _SC_ARG_MAX: Use it.

Index: sysconf.cc
===================================================================
RCS file: /cvs/src/src/winsup/cygwin/sysconf.cc,v
retrieving revision 1.40
diff -u -r1.40 sysconf.cc
--- sysconf.cc  13 Apr 2005 16:41:33 -0000      1.40
+++ sysconf.cc  6 Sep 2005 15:32:41 -0000
 <at>  <at>  -1,6 +1,6  <at>  <at> 
 /* sysconf.cc

-   Copyright 1996, 1997, 1998, 1999, 2000, 2001, 2002, 2003, 2004 Red Hat, Inc.
+   Copyright 1996, 1997, 1998, 1999, 2000, 2001, 2002, 2003, 2004, 2005 Red 
Hat, Inc.
(Continue reading)

Permalink | Reply | 9 comments |
headers
Bas van Gompel | 7 Sep 2005 23:27
Picon

Re: [patch] Don't append extra NUL to registry-strings.

Op Mon, 5 Sep 2005 11:31:28 +0100 schreef Dave Korn
in <SERRANOF2fPmsSVhGOD000000e6 <at> SERRANO.CAM.ARTIMI.COM>:
:  ----Original Message----
: > From: Buzz
[Dave Korn:]
: >>    To me this is the even more important reason.  Some registry strings
: >>  do include the trailing zero, some don't;
: >
: > I don't see how this could be.
:
:    Because internally (native API) the registry stores NT-style
:  UNICODE_STRING structures, which have an explicit length count.  See also 

I see.

:  http://www.sysinternals.com/Information/TipsAndTrivia.html#HiddenKeys
[Names of registry-strings can contain \0.]

This is not relevant, as it concerns the names of registry-keys, not
their value. As we're using RegQueryValueEx, we won't be seeing those
hidden entries.

:  http://blogs.msdn.com/oldnewthing/archive/2004/08/24/219444.aspx
[Actually anything in the registery turns out to be a counted array of
bytes, and the type-indicator is just a hint... :-( ]

This, however is to the point, and another reason to regret ever using
MS software.

Patch retracted.
(Continue reading)

Permalink | Reply | 1 comment |
headers
Corinna Vinschen | 8 Sep 2005 11:24
Favicon

Re: [patch] Don't append extra NUL to registry-strings.

On Sep  7 23:27, Bas van Gompel wrote:
> 2005-09-07  Bas van Gompel  <cygwin-patch.buzz <at> bavag.tmfweb.nl>
> 
> 	* regtool.cc: Extend copyright-years.
> 	(print_version): Ditto.
> 	(cmd_list): Don't depend on terminating '\0' being present on
> 	string-values.
> 	(cmd_get): Don't attempt to read more than present, but keep
> 	extra space for terminating '\0'. Really output REG_BINARY.
> 	Don't leak memory.
> 	(cmd_set): Include trailing '\0' in string's length.

Applied.

Thanks,
Corinna

--

-- 
Corinna Vinschen                  Please, send mails regarding Cygwin to
Cygwin Project Co-Leader          mailto:cygwin <at> cygwin.com
Red Hat, Inc.
Permalink | Reply | 0 comments |
headers
Eric Blake | 10 Sep 2005 16:55
Gravatar

PING: fix ARG_MAX

Eric Blake <ebb9 <at> byu.net> writes:

Just making sure this patch didn't fall through the cracks...

> 
> 2005-09-06  Eric Blake  <ebb9 <at> byu.net>
> 
> 	* include/limits.h (ARG_MAX): New limit.
> 	* sysconf.cc (sysconf): _SC_ARG_MAX: Use it.

Even with your recent patches to make cygwin programs receive longer command
lines, whether or not they are not mounted cygexec, ARG_MAX should still reflect
the worst case limit so that programs (like xargs) that use ARG_MAX will work
reliably even when invoking non-cygwin programs that are really bound by the 32k
limit.

Maybe it is worth adding _PC_ARG_MAX as an extension to the standards for
pathconf(), so that programs that are aware of cygwin's dependence on the path
being executed determining the length of the max command line can use pathconf()
instead of sysconf() to obtain a more accurate limit.  Something like this:
sysconf(_SC_ARG_MAX) --> 32k
pathconf("notepad", _PC_ARG_MAX) --> 32k (performs PATH search if /, \ not in
filename)
pathconf("/bin/echo", _PC_ARG_MAX) --> 8M (or whatever limit can be determined)
pathconf("nonesuch", _PC_ARG_MAX) --> -1, errno = ENOENT

Then xargs could use this non-standard extension to allow larger command lines
when the target utility is a known cygwin executable, rather than penalizing all
cygwin programs to the safe 32k limit of ARG_MAX.
(Continue reading)

Permalink | Reply | 8 comments |
headers
Corinna Vinschen | 12 Sep 2005 17:22
Favicon

Re: PING: fix ARG_MAX

Eric,

On Sep 10 14:55, Eric Blake wrote:
> Eric Blake <ebb9 <at> byu.net> writes:
> 
> Just making sure this patch didn't fall through the cracks...
> 
> > 
> > 2005-09-06  Eric Blake  <ebb9 <at> byu.net>
> > 
> > 	* include/limits.h (ARG_MAX): New limit.
> > 	* sysconf.cc (sysconf): _SC_ARG_MAX: Use it.
> 
> Even with your recent patches to make cygwin programs receive longer command
> lines, whether or not they are not mounted cygexec, ARG_MAX should still reflect
> the worst case limit so that programs (like xargs) that use ARG_MAX will work
> reliably even when invoking non-cygwin programs that are really bound by the 32k
> limit.

I had a short talk with Chris and we both agree that it doesn't make
overly sense to go down to the lowest limit just to accomodate
non-Cygwin applications.  Users of those apps can easily use xargs -s
so why penalize Cygwin apps?

Corinna

--

-- 
Corinna Vinschen                  Please, send mails regarding Cygwin to
Cygwin Project Co-Leader          cygwin AT cygwin DOT com
Red Hat, Inc.
(Continue reading)

Permalink | Reply | 7 comments |
headers
Eric Blake | 13 Sep 2005 06:09
Gravatar

Re: PING: fix ARG_MAX


According to Corinna Vinschen on 9/12/2005 9:22 AM:
>>Even with your recent patches to make cygwin programs receive longer command
>>lines, whether or not they are not mounted cygexec, ARG_MAX should still reflect
>>the worst case limit so that programs (like xargs) that use ARG_MAX will work
>>reliably even when invoking non-cygwin programs that are really bound by the 32k
>>limit.
> 
> 
> I had a short talk with Chris and we both agree that it doesn't make
> overly sense to go down to the lowest limit just to accomodate
> non-Cygwin applications.  Users of those apps can easily use xargs -s
> so why penalize Cygwin apps?

Well, for now, xargs in findutils-4.2.25-2 is already hardcoded to 32k
max; attempting to use -s to get a larger value will fail, because of the
POSIX rules placed on xargs.  If, on the other hand, cygwin added
pathconf(_PC_ARG_MAX) as a legal extension to POSIX, then xargs could use
its preferred 128k default when calling cygwin apps, while using 32k for
windows apps without even requiring users to supply -s; not to mention the
fact that -s could then be used to obtain larger command lines than even
the default 128k for cygwin apps.  With that extension in place,
sysconf(_SC_ARG_MAX) at 32k is not much of a limit for applications that
know about cygwin's extension.

Also, the argument brought up on the findutils mailing list was that
beyond a certain size, the cost of processing each argument starts to
outweigh the benefits of forking fewer tasks, to the point that the
difference between a 32k ARG_MAX vs. a 1M ARG_MAX falls in the noise when
the same amount of data is divided by xargs to as few runs as possible, so
(Continue reading)

Permalink | Reply | 6 comments |

Gmane