Re: CVS update: /ccvs/windows-NT/
Conrad T. Pino wrote: The timer code in lib/nanosleep.c looks very good but I'm uncomfortable making a commitment to making the change because: * I don't understand UNIX style signal behavior well. Basically, signals normally cause a process to exit unless a handler is installed. * Millisecond resolution delays without surrendering the time slice are possible by creating an unsignaled Event then waiting for that Event with a time out value. This feature requires hardware support in CPU otherwise behavior reverts to the PC BIOS rate. I'll work up a test program to measure select time out granularity in the next few days. I'll support you to the best I can should you choose to make the change. This was just a suggestion as I thought it might simplify things. You can make the call. I would argue that the signal handling is no argument since windows-NT/run.c is making calls to signal, I would assume that the API is likely similar to UNIX and whoever wrote lib/nanosleep.c knew what they were doing until we discover problems. Your timer granularity argument sounds reasonable, however. If you need to reimplement usleep anyhow, then you can't really compuile lib/nanosleep.c on Windows without rewriting it anyhow. I found this thread where we discussed this previously: http://lists.gnu.org/archive/html/bug-cvs/2004-05/msg00161.html. Jim Hyslop suggests that NTP (www.ntp.org) uses QueryPerformanceCounter() and QueryPerformanceFrequency() to hack around the problem with about a 300ns granularity. Can you share some ideas on what I need to do to get sanity.sh to run on Windows 2000? I have had it up and running before using a version of CVS built with cygwin (http://cygwin.com), using the bash and other tools from cygwin. Most of the hacks I made to get that to work should still be in sanity.sh. IIRC, however, testing an executable built with MSVC is a different story because it can sometimes use \ and sometimes / as a file separator. No one has ever installed the machinery in sanity.sh to handle that. It might be possible to make a small change in dotest_internal() that seds the program output and replaces all backslashes with forward slashes before the text goes to expr for the comparison. That is where I think I would start trying to get this running. Does the MKS Tool Kit sh implementation help any? Is Windows 2000 bash combined with MKS Took Kit a better start? Like I said, I started with Cygwin and the Cygwin bash. Don't know what the differences are between MKS and Cygwin. sanity.sh requires a working /bin/sh and a few standards compatible tools: expr, id, tr, and sed are the most sensitive tools, I believe. If you are attached to MKS but one of those tools is broken, you might get sanity.sh running by building and installing the GNU versions there. The TESTS file describes where to get them. * filesubr.c: Modify get_homedir to use woe32_home_dir. * pwd.c: Modify getpwuid to use woe32_home_dir woe32_shell. Append USERNAME to login_strings array. Again, unless USERNAME is a read-only env var, if there is a Windows API for retrieving these sorts of values, it should probably be used in the POSIX replacements in favor of writable environment variables. I agree in principle but several things indicate this is a non-issue: * Microsoft's workstation security practices commonly grant the CVS user root equivalent privilege on the executing platform. Why infringe on the user's right to destroy local resources since they're effectively all owned by the workstation user? One more time: 1. I think a POSIX-compliant getpwuid function, or as near as we can get on Windows, should not use environment variables if at all possible if you wish to implement it in such a way that it complies as closely as possible with the POSIX spec so that it may be shared with other projects. 2. I think there is no harm in the CVS get_homedir function using env variables. CVS does that on UNIX on exactly the principle you state. If the user set it then we will presume they knew what they were doing and let system security measures take care of things if the user is asking us to do something we shouldn't. * The better security route indicates we should remove login_strings altogether since the addition/removal of a single variable doesn't close the security vulnerability. This is exactly what I was advocating. To meet the POSIX specs, these functions should try to obtain the login name securely. The POSIX argument stands regardless, but a get_homedir-like wrapper would be wrong here for CVS as well. This value is entered in the repository as the author of a commit and I would rather know that the user had to have a password for the userid being used. At the least, it shouldn't be so easy to forge the author of a commit by setting an env var. Regards, Derek
Re: windows-NT/pwd.c - struct passwd - Home Directory
Conrad T. Pino wrote: My ideas for the API are UNIX/POSIX specifications are non-negotiable and internal APIs below that are discardable upon discovery of the better way. Basically. In theory, you could take up desired changes with the POSIX spec with IEEE. Of course, if you did get some changes through, it would likely be years before we could support them fully in CVS and GNULIB - that doesn't happen until it is determined that hosts which require older (i.e. POSIX2) specifications are no longer reasonable porting targets. As an example, GNULIB and CVS both still support ANSI C89 specifications. I would not hazard a guess as to when C99 will be judged a reasonable assumption. GNULIB just finally dropped support for SunOS 4.1.4, about a year and a half after Sun did. Of course, the official policy of GNULIB is to drop support when the provider of the OS does, but it isn't always noticed right away. Also, for a traget like Windows, compliance may be as close as possible to the POSIX spec. Sometimes a POSIX spec will make reference to other POSIX specs, and if, for instance, the getpwuid spec referenced the /etc/passwd file directly, we might only be able to approximate the desired result. What you and I are debating, I think, is what is morally closest to the POSIX spec on Windows. As an aside, it might sometimes be interesting to look at what Cygwin did in some of these cases. Their code is GPL'd. Of course, I've looked at it before, and it tends to be much too involved to import into CVS easily - they have their own userid system overlaid on top of Windows, for instance, which would likely make getpwuid a challenge to import, and similar things happen with their file descriptor implementation, but something like their implementation of usleep() or nanosleep() might not have so many internal dependencies. Cheers, Derek ___ Bug-cvs mailing list Bug-cvs@gnu.org http://lists.gnu.org/mailman/listinfo/bug-cvs
Re: CVS update: /ccvs/windows-NT/sys/
Conrad T. Pino wrote: Hi Derek, From: Derek Price I think renaming this file sys_types.h, starting it with `#include sys/types.h', then defining what else you need would be an easier interface to maintain. Are you implying changing all #include sys/types.h in CVS? I assume no. Well, it may be an option if necessary, similar things have been proposed for GNULIB modules, but none has turned out to be necessary yet. In this case I was thinking that the Windows config.h.in.footer could #include sys_types.h and get the effect you are looking for. I intend the windows-NT version be used in all locations cited at the end of this message. My first try was your suggestion with the current name only to discover VC6 reopens the windows-NT file because windows-NT is in the include path. Which is why I proposed renaming the Windows include to sys_types.h. I also dislike polluting the windows-NT source directory space with a directory structure mimicing a standard C89/POSIX include structure with no differentiation from the other source files if you can avoid it. If you must, I might prefer moving your sys directory under a windows-NT/include directory and making the other changes you needed to to accomodate that, but I still prefer avoiding the sys directory entirely in favor of the sys_types.h file. Regards, Derek ___ Bug-cvs mailing list Bug-cvs@gnu.org http://lists.gnu.org/mailman/listinfo/bug-cvs
Re: [bug-gnulib] New GNULIB glob module?
Paul Eggert wrote:
Derek Price [EMAIL PROTECTED] writes:
1. Corrects an incorrect check for a successful return from
getlogin_r to assume only 0 means success, per the POSIX2 spec:
http://www.opengroup.org/onlinepubs/009695399/functions/getlogin_r.html.
2. Moves the check for GLOB_MARK directory status (and the append of
`/') into glob_in_dir, where it is more efficient than performing
a second pass and sometimes calling stat a second time on each
file or directory. All calls to stat are avoided when
dirent-d_type is available. No call to realloc of the directory
name is ever necessary since room for the slash can be allocated
in the first pass.
These changes sound reasonable, though we should submit them as
separate patches.
The attached glibc-understand-getlogin_r.diff may come off as a little
fuzzy, but it should work for (1). I've also reattached the patch for 2
3 minus the above chunk, as glibc-glob-list-links2.diff.
Is (2) independent of (3)? (Please see below for why this is important.)
(2) could be separated with a little more work, but lets finish the
discussion below before I provide a second patch.
3. Ignores broken links only when GLOB_ONLYDIR is set. With glibc
versions 2.3.3 through 2.3.5, the following in an empty directory
would return nothing:
ln -s doesnt-exist linkname
glob (*, ...)
This fix syncs with the comments in the file, syncs with the
POSIX2 spec, restores the pre-glibc-2.3.3 behavior, and simply
makes more sense - why should `ls *' fail to list broken links?
This change sounds controversial to me. glibc 2.3.5 behaves similarly
It may be. It looks like the change was intentional
(http://sources.redhat.com/cgi-bin/cvsweb.cgi/libc/sysdeps/generic/glob.c?rev=1.52content-type=text/x-cvsweb-markupcvsroot=glibc),
but I still disagree.
to Solaris 8 and to Solaris 10 -- I just checked, with the following
program and with the working directory containing only a dangling
symlink:
#include glob.h
#include stdio.h
int
main (void)
{
glob_t g;
int r = glob (*, 0, NULL, g);
int i;
if (r != 0)
{
fprintf (stderr, glob failed (%s)\n,
r == GLOB_NOMATCH ? GLOB_NOMATCH
: r == GLOB_NOSPACE ? GLOB_NOSPACE
: other glob failure);
return 1;
}
for (i = 0; i g.gl_pathc; i++)
puts (g.gl_pathv[i]);
return 0;
}
Solaris 8 and 10 both report glob failed (GLOB_NOMATCH).
Let's separate (3) into a separate patch and think about it more
carefully before submitting it.
This would involve creating at least one new function for (2) which
would just need to be removed again for (3), and the POSIX2 glob spec
states that glob returns GLOB_NOMATCH only when, the pattern does not
match any existing pathname, and GLOB_NOCHECK was not set in flags.
(http://www.opengroup.org/onlinepubs/009695399/functions/glob.html)
Nowhere does the POSIX2 glob spec specify that a broken symlink should
not be considered an existing pathname. After all, the link exists,
only its target does not. Interpreted in this way, glob cannot be used
by a program which, for instance, wished to verify that all links
matching a pattern had valid targets since the broken links would not be
returned by glob.
If glob is only going to consider a link as if it is its target, then
what about the case where a matching link points to a file in the same
directory that also matches the pattern? Should glob only return one or
the other?
Perhaps a GNU extension similar to GLOB_ONLYDIR is in order
(GLOB_VERIFY_SYMLINKS?), but I do not think glob should be making these
value judgements when the user did not request it. It certainly does
not appear to be implied by the POSIX spec as I read it.
Have you investigated with FreeBSD glob does?
No, but I ran your test program on NetBSD 1.6.1 and it does return the
broken symlink.
I copied and pasted most of my above commentary on why this should be
considered a bug into
https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=126460, where I
found the discussion that apparently caused the original bug fix that
broke this.
Cheers,
Derek
--- ../glob-glibc2gnulib/lib/glob.c 2005-05-31 18:12:01.0 -0400
+++ lib/glob.c 2005-05-27 13:52:28.0 -0400
@@ -538,7 +539,7 @@ glob (const char *pattern, int flags,
buflen = 20;
name = __alloca (buflen);
- success = getlogin_r (name, buflen) = 0;
+ success = getlogin_r (name, buflen) == 0;
if (success)
{
struct passwd *p;
--- ../glob-glibc2gnulib/lib/glob.c 2005-05-31 18:12:01.0 -0400
+++ lib/glob.c 2005-05-27 13:52:28.0 -0400
@@ -175,6 +175,7 @@
# define __glob_pattern_p glob_pattern_p
#endif /* _LIBC */
+#include stdbool.h
#include fnmatch.h
RE: Build CVS (TRUNK) failed.
Hi, Please test for the existence of: directory: windows-NT/sys new file: windows-NT/sys/types.h I hope this is an update oversight that: cvs update -dP windows-NT will correct. If none of the above is true then please send me Microsoft's sys/types.h file from your compiler INCLUDE path. At a command prompt run: cl /? out.txt 2 err.txt send the err.txt file and delete out.txt. Thank you, Conrad Pino -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Sent: Wednesday, June 01, 2005 00:01 To: [EMAIL PROTECTED]; [EMAIL PROTECTED] Subject: Build CVS (TRUNK) failed. ..\windows-NT\unistd.h(34) : error C2282: 'pid_t' is followed by 'getpid' (missing ','?) ..\windows-NT\unistd.h(37) : error C2146: syntax error : missing ')' before identifier 'microseconds' ..\windows-NT\unistd.h(37) : error C2501: 'microseconds' : missing decl-specifiers dup-safer.c(51) : fatal error C1004: unexpected end of file found [snip] ___ Bug-cvs mailing list Bug-cvs@gnu.org http://lists.gnu.org/mailman/listinfo/bug-cvs
Re: GZip level restriction
Derek Price wrote: On the other hand, it would be nice if there were a way to specify a default compression level or range of levels (both for the server and the client) that could be used in the absence of any explicit specification by the user. Of course, reconciling conflicting defaults could be an interesting challenge. To some extent this would be happening with my proposed change. A client that had requested -z9 on a fast machine would always compress their data at level 9, but the server would only compress its data at whatever maximum level had been set, limiting the load on its CPU. Similarly for a client -z3 and a server with a min level of 9. The client would compress at 3 and the server at 9, saving most the bandwidth and not bombing the client CPU. Hey Larry, Can I assume that no comment for almost two weeks means you have no further objections to this patch going into feature? Cheers, Derek ___ Bug-cvs mailing list Bug-cvs@gnu.org http://lists.gnu.org/mailman/listinfo/bug-cvs
