Re: [bug-gnulib] New GNULIB glob module?

[Paul Eggert]

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:
>   
> .
>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.

Is (2) independent of (3)?  (Please see below for why this is important.)


>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
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 
  #include 

  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.

Have you investigated with FreeBSD glob does?  It seems to use
gl_lstat, which our glob doesn't.  That's odd.  What's the point of
having a gl_lstat if it's never used?


___
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]

Hi Derek,

> From: Derek Price
> 
> I think renaming this file "sys_types.h", starting it with `#include
> ', then defining what else you need would be an easier
> interface to maintain.

Are you implying changing all #include  in CVS? I assume no.

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.

Microsoft's implementation is so lame it's acquired the virtue of brevity.
I might change my approach after reviewing the .NET  file.

> Regards,

Ditto,

> Derek

File diff\diffrun.h:
24  #include 
File diff\system.h:
27  #include 
File lib\dev-ino.h:
4   # include 
File lib\getline.h:
27  # include 
File lib\getndelim2.h:
24  #include 
File lib\getnline.h:
23  #include 
File lib\openat.h:
24  #include 
File lib\regex.h:
24  #include 
File lib\system.h:
49  #include 
File lib\timespec.h:
24  # include 
File lib\wait.h:
15  #include   /* For pid_t. */
File windows-NT\ndir.h:
19  #include   /* ino_t definition */
File windows-NT\pwd.h:
19  #include 
File windows-NT\unistd.h:
30  #include 
File zlib\zconf.h:
282 #  include  /* for off_t */
File lib\cycle-check.c:
26  #include 
File lib\fseeko.c:
19  #include 
File lib\ftello.c:
19  #include 
File lib\ftruncate.c:
8   #include 
File lib\getcwd.c:
28  #include 
File lib\gettimeofday.c:
32  #include 
File lib\glob.c:
26  #include 
File lib\mkdir.c:
29  #include 
File lib\mktime.c:
36  #include   /* Some systems define `time_t' here.  
*/
File lib\nanosleep.c:
28  #include 
File lib\readlink.c:
23  #include 
File lib\rpmatch.c:
27  # include 
File lib\sighandle.c:
36  #include 
File lib\stat.c:
31  #include 
File lib\strftime.c:
38  #include   /* Some systems define `time_t' here.  
*/
File lib\sunos57-select.c:
39  #include 
File lib\tempname.c:
24  #include 
File lib\xreadlink.c:
31  #include 
File os2\popen.c:
11  #include
File os2\rcmd.c:
20  #include 
File os2\run.c:
23  #include 
File src\expand_path.c:
16  #include 
File windows-NT\ndir.c:
24  #include 
File windows-NT\rcmd.c:
26#include 
File zlib\minigzip.c:
29  #  include 
File zlib\contrib\minizip\minizip.c:
18  # include 
File zlib\contrib\puff\puff.c:
789 #include 


___
Bug-cvs mailing list
Bug-cvs@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-cvs

RE: CVS update: /ccvs/windows-NT/

[Conrad T. Pino]

Hi Derek,

> From: Derek Price
> 
> >Log:
> > * unistd.c, unistd.c: Add new "usleep" function using "my_usleep"
> > logic taken from "woe32.c" file.
> > * woe32.c, woe32.h: Add new (woe32_home_dir,woe32_shell) functions.
> > * woe32.c: Modify "woe32_nanosleep" to use "unistd.h" "usleep".
> 
> Glancing at lib/nanosleep.c, the usleep() implementation in
> windows-NT/unistd.c, and based on the fact that signal() and select()
> appear to be used elsewhere in windows-NT/*.c, it looks like
> lib/nanosleep.c would compile on Windows with the right config.h.in.in
> definitions.  Then the woe32_nanosleep and unistd.c usleep could be
> removed in favor of the rpl_nanosleep in lib/nanosleep.c.

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.

* I don't know how to verify the change is no worse than current.

* Even though CVS doesn't use "usleep" I'd like to keep it for now as the
  best candidate to implement the millisecond resolution Windows supports
  in case Microsoft's "select" implementatino is ill behaved.

* I haven't proven to myself the actual time out granularity of Microsoft's
  "select" implementation and some cases I've contemplated suggest another
  choice.

Let me share some things I've learned about Windows and process delays:

* Windows native API "Sleep" call is a real time programming joke.  It
  specifies millisecond resolution but always surrenders balance of the
  current time slice:
  http://msdn.microsoft.com/library/en-us/dllproc/base/sleep.asp
  On a busy system your process runs at the hardware timer tick rate
  which is the standard PC BIOS rate of 18+ ticks per second.

* 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.

Can you share some ideas on what I need to do to get "sanity.sh" to run
on Windows 2000?

Does the MKS Tool Kit "sh" implementation help any?

Is Windows 2000 "bash" combined with MKS Took Kit a better start?

> > * 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?

* 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.

Windows NT and kin implement environment variables in three layers:

1. System environment variabiles require Administrator privilege to
   modify and most users are workstation Administrators.  These are
   persisted in the system registry

2. User environment variables.  These are persisted in the user
   profile registry.

3. Process environment variables.

The process set is built from System and User values preferring the
User value in some cases or concatenating others like %PATH% placing
the User value before the System value.  The process is then free to
mangle with no restrictions.  Child processes inherent from parent
when spawned.

My suggestions are:

   - Remove "login_strings" support altogether
OR
   - Leave "USERNAME" since it subtracts nothing and adds a bit.

What does CVS do with "getlogin" value that raise security threats?

> Regards,

Ditto,

> Derek

Conrad


___
Bug-cvs mailing list
Bug-cvs@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-cvs

Re: OpenBSD 3.6 sparc64 stable crash

[Derek Price]

Alexander Taler wrote:

>+2005-05-31  Alexander Taler <[EMAIL PROTECTED]>
>+
>+  * rcscmds.c: Change type of call_diff_argc_allocated from int to
>+  size_t, to match the prototype of run_add_arg_p().  This fixes a
>+  bus error in OpenBSD 3.6 sparc64.
>  
>

Makes sense.  int & size_t probably have different sizes on this 64 bit
platform, which could explain the bus error.  Thanks for the patch! 
I've committed it on stable and feature.

Regards,

Derek




___
Bug-cvs mailing list
Bug-cvs@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-cvs

RE: Windows 2000 - HOMEDRIVE,HOMEPATH vs. USERPROFILE

[Conrad T. Pino]

Hi Derek,

> From: Derek Price
> 
> It sounds to me like we probably want to ignore USERPROFILE, then, and
> just use the home dir settings.

The commit characteristics of network profiles are indeed scary.

Home directory commit characteristics are common to UNIX & Windows and
seems the only choice to guarantee consistent behavior.

The patch I'm working on supports compile time configuration and I recommend
CVS Project not enable USERPROFILE support.

> How does the home directory get set to
> something other than "undefined" in your examples?

The user interface is a dialog box tab sheet common to the workstation
"Computer Management" and domain controller "Active Directory Users and
Computer" Microsoft Management Console (MMC) applications.  See the JPEG
file attachment for the workstation dialog box.

> Is there an API to
> read it from the system or must all applications rely on malleable
> environment variables for this information?

An API must exist to support the MMC applications.

I don't know if the API is public and it's querying security requirements.

Local Administrator group membership is extremely common on workstations.
Domain Administrator group membership is extremely rare.

> Cheers,

> Derek
___
Bug-cvs mailing list
Bug-cvs@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-cvs

Re: OpenBSD 3.6 sparc64 stable crash

[Alexander Taler]

[resend of message, unsigned because the gpg signing corrupted
the patch.]

  Alex> Core was generated by `cvs'.  Program terminated with signal 10, Bus
  Alex> error.
  Alex> #0 0x0014f148 in run_add_arg_p (iargc=0x7a8000,
  Alex> iarg_allocated=0x7a8004, iargv=0x7a7ff8, s=0x293838 "diff") at
  Alex> /home/cvstest/cvs-nightly-cvs1-11-x-branch/src/run.c:81 81 if (*iargc >=
  Alex> *iarg_allocated)

  Derek> Can you be a little more specific about the problem?

Not really, but I can provide a patch which fixes it.  It
successfully passed make check, and even includes a ChangeLog.

Alex


Index: src/ChangeLog
===
RCS file: /cvs/ccvs/src/ChangeLog,v
retrieving revision 1.2336.2.377
diff -u -u -r1.2336.2.377 ChangeLog
--- src/ChangeLog   28 May 2005 06:53:24 -  1.2336.2.377
+++ src/ChangeLog   31 May 2005 23:20:07 -
@@ -1,3 +1,9 @@
+2005-05-31  Alexander Taler <[EMAIL PROTECTED]>
+
+   * rcscmds.c: Change type of call_diff_argc_allocated from int to
+   size_t, to match the prototype of run_add_arg_p().  This fixes a
+   bus error in OpenBSD 3.6 sparc64.
+
 2005-05-27  Conrad T. Pino  <[EMAIL PROTECTED]>
 
* cvs.h: Replace "run_arg" function with "#define run_arg run_add_arg",
Index: src/rcscmds.c
===
RCS file: /cvs/ccvs/src/rcscmds.c,v
retrieving revision 1.52.4.6
diff -u -u -r1.52.4.6 rcscmds.c
--- src/rcscmds.c   27 May 2005 16:25:11 -  1.52.4.6
+++ src/rcscmds.c   31 May 2005 23:20:07 -
@@ -76,7 +76,7 @@
 
 static char **call_diff_argv;
 static int call_diff_argc;
-static int call_diff_argc_allocated;
+static size_t call_diff_argc_allocated;
 
 static void call_diff_add_arg PROTO ((const char *));
 static void call_diff_setup PROTO ((const char *prog,


-- 
https://savannah.gnu.org/projects/libcvs-specAccess CVS through a library.
PGP:  ID: 0x23DC453B  FPR: 42D0 66C2 9FF8 553A 373A  B819 4C34 93BA 23DC 453B
convince your customer that pserver access to a CVS server is, if not
*actually* the work of the devil, then pretty similar -- Derek Price


___
Bug-cvs mailing list
Bug-cvs@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-cvs

Re: OpenBSD 3.6 sparc64 stable crash

[Alexander Taler]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Tue, 31 May 2005 19:26:43 EDT
Tue, 31 May 2005 19:26:30 EDT
  Alex> Core was generated by `cvs'.  Program terminated with signal 10, Bus
  Alex> error.
  Alex> #0 0x0014f148 in run_add_arg_p (iargc=0x7a8000,
  Alex> iarg_allocated=0x7a8004, iargv=0x7a7ff8, s=0x293838 "diff") at
  Alex> /home/cvstest/cvs-nightly-cvs1-11-x-branch/src/run.c:81 81 if (*iargc >=
  Alex> *iarg_allocated)

  Derek> Can you be a little more specific about the problem?

Not really, but I can provide a patch which fixes it.  It
successfully passed make check, and even includes a ChangeLog.

Alex


Index: src/ChangeLog
===
RCS file: /cvs/ccvs/src/ChangeLog,v
retrieving revision 1.2336.2.377
diff -u -u -r1.2336.2.377 ChangeLog
- --- src/ChangeLog 28 May 2005 06:53:24 -  1.2336.2.377
+++ src/ChangeLog   31 May 2005 23:20:07 -
@@ -1,3 +1,9 @@
+2005-05-31  Alexander Taler <[EMAIL PROTECTED]>
+
+   * rcscmds.c: Change type of call_diff_argc_allocated from int to
+   size_t, to match the prototype of run_add_arg_p().  This fixes a
+   bus error in OpenBSD 3.6 sparc64.
+
 2005-05-27  Conrad T. Pino  <[EMAIL PROTECTED]>
 
* cvs.h: Replace "run_arg" function with "#define run_arg run_add_arg",
Index: src/rcscmds.c
===
RCS file: /cvs/ccvs/src/rcscmds.c,v
retrieving revision 1.52.4.6
diff -u -u -r1.52.4.6 rcscmds.c
- --- src/rcscmds.c 27 May 2005 16:25:11 -  1.52.4.6
+++ src/rcscmds.c   31 May 2005 23:20:07 -
@@ -76,7 +76,7 @@
 
 static char **call_diff_argv;
 static int call_diff_argc;
- -static int call_diff_argc_allocated;
+static size_t call_diff_argc_allocated;
 
 static void call_diff_add_arg PROTO ((const char *));
 static void call_diff_setup PROTO ((const char *prog,


- -- 
https://savannah.gnu.org/projects/libcvs-specAccess CVS through a library.
PGP:  ID: 0x23DC453B  FPR: 42D0 66C2 9FF8 553A 373A  B819 4C34 93BA 23DC 453B
convince your customer that pserver access to a CVS server is, if not
*actually* the work of the devil, then pretty similar -- Derek Price
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.2.2 (OpenBSD)
Comment: Processed by Mailcrypt 3.5.8 

iD8DBQFCnPK6TDSTuiPcRTsRArPjAKCbPVx1Nicany0tWKIkJCCkOwtl4QCeI8A0
54UcXlN2ODjiAntxg7BhQtM=
=TG3C
-END PGP SIGNATURE-


___
Bug-cvs mailing list
Bug-cvs@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-cvs

RE: windows-NT/pwd.c - struct passwd - Home Directory

[Conrad T. Pino]

Hi Derek,

> From: Derek Price
> 
> >What I don't understand is why "." is a reasonable home directory according
> >to the "getpwuid" implementation:
> >
> > static char *home_dir = "."; /* we feel (no|every)where at home */
> 
> I don't agree that it is.  I think it was a poor, arbitrary
> implementation decision at some point in the past before Windows had the
> concept of a home dir, which did not show up until NT, I believe.

Thank you.  We agree "." is arbitrary and not particularly useful.

> >My thought was along the lines of:
> >
> > struct passwd *
> > getpwuid (int uid)
> > {
> > pw.pw_name = getlogin ();
> >- pw.pw_dir = home_dir;
> >+ pw.pw_dir = get_homedir ();
> > pw.pw_shell = login_shell;
> > pw.pw_uid = 0;
> >
> > return &pw;
> > }

I concluded "get_homedir" wasn't suitable in the above case because
"get_homedir" in "src/filesubr.c" processed the "HOME" variable.

I created "woe32_home_dir" in "windows-NT/woe32.c" to provide only
the Windows view of the home directory and kept the delegation of
"HOME" processing within "get_homedir".  The "windows-NT" versions
of "getpwuid" and "get_homedir" both rely upon "woe32_home_dir".

> If the getpwuid function in windows-NT/pwd.c worked, then the
> get_homedir in src/filesubr.c might be moved into src/subr.c and shared
> with the Windows implementation, or so I was thinking.

We agree on the implied goal of reducing code redundancy.

I wasn't aware "src/subr.c" was a possibility for merging back code.
I'll consider "src/subr.c" when making future prospsals.  Thanks

The commits I've bring a "get_homedir" migration to "src/subr.c" within
the possible on Windows.  The issue then becomes:

H:\Conrad\Projects\cvs-1.12-edit>grep -dn "get_homedir" filesubr.c
File emx\filesubr.c:
703 get_homedir ()
File os2\filesubr.c:
755 get_homedir ()
File src\filesubr.c:
803 get_homedir (void)
File vms\filesubr.c:
907 get_homedir ()
File windows-NT\filesubr.c:
767 get_homedir (void)

H:\Conrad\Projects\cvs-1.12-edit>

what to do about "(emx,os2,vms)/filesubr.c" versions.  Unless you know
these are a slam dunk right now, I suggest deferral until I complete
the items I've begun.

> Regardless, I do think this basic idea is correct.  My reconsideration
> is that perhaps all user-settable environment variable references,
> should be in get_homedir, and getpwuid would need to return the "secure"
> home directory, as it is defined to on UNIX, where it is often read from
> the /etc/passwd file, for instance.  The closest thing might be the
> value from the registry on Windows.  Windows must read this from
> somewhere in order to set USERPROFILE, HOMEDRIVE, and HOMEPATH on boot. 
> You need to read the Windows specifications and determine where these
> values are coming from to implement this correctly.  Is there no
> equivalent to this function on Windows, where the home dir value may
> have come from a domain server or whatever?

I believe this is the Windows research starting point:

http://msdn.microsoft.com/library/en-us/dnanchor/html/securityanchor.asp

As you might surmise it's a substantial amount of material.

I suggest finishing the "simple" reorganizing I have in progress and I'll
make sure your suggestion is implementable.  

> The UNIX specification for getpwuid is here:
> .
> 
> >Another thought can take use one step closer to using "src/filesubr.c"
> instead
> >of "windows-NT/filesubr.c" by defining "wnt_homedir" in "woe32.c":

Already implemented as "woe32_home_dir" in "woe32.c" file.

> This would be fine if we decide the proper place for all env var lookups
> is in get_homedir.

This question is on the border between CVS and platform.  I don't know CVS
internals well enough to risk an opinion.  I look to you and CVS developers
to impose requirements the platform compatability layer must meet.

I've seen enough to conclude that non UNIX/POSIX compliant expedient hacks 
eventually become problematic later.  Your work with "GNULib" has focused
my ideas for contributing towards using "windows-NT" project to fill in the
missing UNIX/POSIX functionality "GNULib" requires and Microsoft doesn't
provide.

> >A grep of "get_homedir" usage (below) leads me to believe that whichever way
> >we choose, functions "getpwuid" and "get_homedir" should present a
> consistent
> >view of where the home directory is on a given platform.
> 
> Once again, to summarize, if getpwuid is to be implemented,
> functionality should be divided as follows:
> 
> getpwuid: to POSIX spec as much as possible, secure source if possible,
> output not user settable
> get_homedir: to CVS requirements, uses env vars, possibly set by user

I accept the requirement in principle but I don't see the path to a complete
implementation right now.  I'm sure I'll see more as we move forward.  I will
review your reply to 

Re: [bug-gnulib] New GNULIB glob module?

[Derek Price]

Paul Eggert wrote:

>Derek Price <[EMAIL PROTECTED]> writes:
>  
>
>>submission part.  Perhaps it would be smoother if someone already known
>>to the glibc team introduced me and this patch?
>>
>>
>
>Yes, probably.  I'm willing to have a go at it.
>
>I suggest submitting two patches.
>
>(1) the part that makes it work with gnulib.
>  
>

glob-glibc2gnulib11.diff attached:

2005-05-31  Derek Price  <[EMAIL PROTECTED]>
Paul Eggert  <[EMAIL PROTECTED]>

* glob.c:  Update copyright.  Assume freestanding C89 compiler.
Simplify cruft that may be replaced with GNULIB modules.  Make no
attempt to find 64-bit versions of file access functions
directly when
!_LIBC.  Move definitions of GLOB_* macros to glob_.h.
(DIRENT_MUST_BE, DIRENT_MIGHT_BE_SYMLINK, DIRENT_MIGHT_BE_DIR): New
macros to abstract dirent->d_type access.
(GETPW_R_SIZE_MAX, LOGIN_NAME_MAX): New macros to abstract sysconf
access.
* glob.h: Protect/define contents as necessary to coexist with
GNULIB.


>(2) the bug fix.
>
>It's OK for (2) to assume that (1) has already been applied.
>  
>

glibc-glob-list-links.diff attached.  Despite its name, it actually does
three things:

   1. Corrects an incorrect check for a successful return from
  getlogin_r to assume only 0 means success, per the POSIX2 spec:
  .
   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.
   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?


2005-05-31  Derek R. Price  <[EMAIL PROTECTED]>

* glob.c: #include 
(glob): Only 0 return from getlogin_r means success, according
to POSIX
2.  Move GLOB_MARK rescan into...
(glob_in_dir): ...here - it improves efficiency.  Don't fail to
return
broken links when GLOB_ONLYDIR is not set.
(link_exists_p): Rename to...
(is_dir_p): ...this and update functionality accordingly.



Regards,

Derek
--- ../glibc-2.3.5/sysdeps/generic/glob.c   2004-10-27 14:21:02.0 
-0400
+++ lib/glob.c  2005-05-31 18:12:01.0 -0400
@@ -1,4 +1,4 @@
-/* Copyright (C) 1991-2002, 2003, 2004 Free Software Foundation, Inc.
+/* Copyright (C) 1991-2002, 2003, 2004, 2005 Free Software Foundation, Inc.
This file is part of the GNU C Library.
 
The GNU C Library is free software; you can redistribute it and/or
@@ -16,23 +16,16 @@
Software Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA
02111-1307 USA.  */
 
-/* AIX requires this to be the first thing in the file.  */
-#if defined _AIX && !defined __GNUC__
- #pragma alloca
-#endif
-
 #ifdef HAVE_CONFIG_H
 # include 
 #endif
 
-/* Enable GNU extensions in glob.h.  */
-#ifndef _GNU_SOURCE
-# define _GNU_SOURCE   1
-#endif
+#include 
 
 #include 
 #include 
 #include 
+#include 
 
 /* Outcomment the following line for production quality code.  */
 /* #define NDEBUG 1 */
@@ -40,30 +33,7 @@
 
 #include  /* Needed on stupid SunOS for assert.  */
 
-
-/* Comment out all this code if we are using the GNU C Library, and are not
-   actually compiling the library itself.  This code is part of the GNU C
-   Library, but also included in many other GNU distributions.  Compiling
-   and linking in this code is a waste when using the GNU C library
-   (especially if it is a shared library).  Rather than having every GNU
-   program understand `configure --with-gnu-libc' and omit the object files,
-   it is simpler to just do this in the source for each such file.  */
-
-#define GLOB_INTERFACE_VERSION 1
-#if !defined _LIBC && defined __GNU_LIBRARY__ && __GNU_LIBRARY__ > 1
-# include 
-# if _GNU_GLOB_INTERFACE_VERSION == GLOB_INTERFACE_VERSION
-#  define ELIDE_CODE
-# endif
-#endif
-
-#ifndef ELIDE_CODE
 #if !defined _LIBC || !defined GLOB_ONLY_P
-
-#if defined STDC_HEADERS || defined __GNU_LIBRARY__
-# include 
-#endif
-
 #if defined HAVE_UNISTD_H || defined _LIBC
 # include 
 # ifndef POSIX
@@ -73,22 +43,13 @@
 # endif
 #endif
 
-#if !defined _AMIGA && !defined VMS && !defined WINDOWS32
-# include 
-#endif
+#include 
 
-#if !defined __GNU_LIBRARY__ && !defined STDC_HEADERS
-extern int errno;
-#endif
+#inclu

Re: CVS update: /ccvs/windows-NT/

[Derek Price]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

[EMAIL PROTECTED] wrote:

>Log:
> * unistd.c, unistd.c: Add new "usleep" function using "my_usleep"
> logic taken from "woe32.c" file.
> * woe32.c, woe32.h: Add new (woe32_home_dir,woe32_shell) functions.
> * woe32.c: Modify "woe32_nanosleep" to use "unistd.h" "usleep".


Glancing at lib/nanosleep.c, the usleep() implementation in
windows-NT/unistd.c, and based on the fact that signal() and select()
appear to be used elsewhere in windows-NT/*.c, it looks like
lib/nanosleep.c would compile on Windows with the right config.h.in.in
definitions.  Then the woe32_nanosleep and unistd.c usleep could be
removed in favor of the rpl_nanosleep in lib/nanosleep.c.

> * 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.

Regards,

Derek
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.0 (Cygwin)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

iD8DBQFCnLXVLD1OTBfyMaQRAqR1AJ9b7K8yExwUCc0EIj4jUrersoSyJQCgsjec
sHEymcNNNjRzXscCVdl36pY=
=1rqH
-END PGP SIGNATURE-




___
Bug-cvs mailing list
Bug-cvs@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-cvs

Re: CVS update: /ccvs/windows-NT/sys/

[Derek Price]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

[EMAIL PROTECTED] wrote:

>#ifdef _MSC_VER
>
>#pragma once
>
>/* Compatable with Visual C++ 6.0 - cl.exe 12.00 */
>#if _MSC_VER != 1200
>#pragma message ( "Please email Microsoft's " )
>#pragma message ( "file to <[EMAIL PROTECTED]>" )
>#endif /* _MSC_VER != 1200 */
>
>/***/
>/* Mimic what Micrsoft defines in their  */


I think renaming this file "sys_types.h", starting it with `#include
', then defining what else you need would be an easier
interface to maintain.

Regards,

Derek
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.0 (Cygwin)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

iD8DBQFCnLbULD1OTBfyMaQRArmUAKD8v6H424DG0POXEl7sNAfC3GKWzwCdF4U7
Zzt7J1nnG24jYChR8DKE7Jg=
=3dJw
-END PGP SIGNATURE-




___
Bug-cvs mailing list
Bug-cvs@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-cvs

Re: Windows 2000 - HOMEDRIVE,HOMEPATH vs. USERPROFILE

[Derek Price]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

It sounds to me like we probably want to ignore USERPROFILE, then, and
just use the home dir settings.  How does the home directory get set to
something other than "undefined" in your examples?  Is there an API to
read it from the system or must all applications rely on malleable
environment variables for this information?

Cheers,

Derek
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.0 (Cygwin)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

iD8DBQFCnK6RLD1OTBfyMaQRAnWqAKC/KHPySouyvYPIcS+eCfXAOnRXWgCfbjT0
whrOdCPGQpoGKGn1J85SME8=
=4gdk
-END PGP SIGNATURE-




___
Bug-cvs mailing list
Bug-cvs@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-cvs

Re: Feature Branch - windows-NT/pwd.h & windows-NT/unistd.h

[Derek Price]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Conrad T. Pino wrote:

>Hi Derek,
>
>File "windows-NT/pwd.h" declares several functions that
>are declared in "unistd.h" according to the NetBSD man
>pages.
>
>Since I created "windows-NT/unistd.c" do you object in
>principle to migrations from "pwd.c" to "unistd.c"?
>
>If you agree, I'll enumerate the functions to migrate
>for review before actually doing so.


That's fine.  If the function has a counterpart in  on UNIX, I
likely won't have a problem with any such migration you propose.

Cheers,

Derek
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.0 (Cygwin)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

iD8DBQFCnI+kLD1OTBfyMaQRAjtUAJ9pdcUy4+wWBcQ3itMPrT61EUyraQCg10oF
idmDhjfxUlMKzCTHeOW/l4Q=
=5rNC
-END PGP SIGNATURE-




___
Bug-cvs mailing list
Bug-cvs@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-cvs

Re: windows-NT/pwd.c - struct passwd - Home Directory

[Derek Price]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Conrad T. Pino wrote:

>What I don't understand is why "." is a reasonable home directory according
>to the "getpwuid" implementation:
>
> static char *home_dir = "."; /* we feel (no|every)where at home */


I don't agree that it is.  I think it was a poor, arbitrary
implementation decision at some point in the past before Windows had the
concept of a home dir, which did not show up until NT, I believe.

>My thought was along the lines of:
>
> struct passwd *
> getpwuid (int uid)
> {
> pw.pw_name = getlogin ();
>- pw.pw_dir = home_dir;
>+ pw.pw_dir = get_homedir ();
> pw.pw_shell = login_shell;
> pw.pw_uid = 0;
>
> return &pw;
> }


If the getpwuid function in windows-NT/pwd.c worked, then the
get_homedir in src/filesubr.c might be moved into src/subr.c and shared
with the Windows implementation, or so I was thinking.

Regardless, I do think this basic idea is correct.  My reconsideration
is that perhaps all user-settable environment variable references,
should be in get_homedir, and getpwuid would need to return the "secure"
home directory, as it is defined to on UNIX, where it is often read from
the /etc/passwd file, for instance.  The closest thing might be the
value from the registry on Windows.  Windows must read this from
somewhere in order to set USERPROFILE, HOMEDRIVE, and HOMEPATH on boot. 
You need to read the Windows specifications and determine where these
values are coming from to implement this correctly.  Is there no
equivalent to this function on Windows, where the home dir value may
have come from a domain server or whatever?

The UNIX specification for getpwuid is here:
.

>Another thought can take use one step closer to using "src/filesubr.c"
instead
>of "windows-NT/filesubr.c" by defining "wnt_homedir" in "woe32.c":


This would be fine if we decide the proper place for all env var lookups
is in get_homedir.

>A grep of "get_homedir" usage (below) leads me to believe that whichever way
>we choose, functions "getpwuid" and "get_homedir" should present a
consistent
>view of where the home directory is on a given platform.


Once again, to summarize, if getpwuid is to be implemented,
functionality should be divided as follows:

getpwuid: to POSIX spec as much as possible, secure source if possible,
output not user settable
get_homedir: to CVS requirements, uses env vars, possibly set by user

You should be able to get POSIX specs for the other functions in
windows-NT/pwd.c from opengroup.org as well.  Try changing the
"getpwuid" in the URL above to other function names as needed.

:)

Regards,

-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.0 (Cygwin)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

iD8DBQFCnI8ILD1OTBfyMaQRArjFAKCEmq0ApQTuiZKSjEIAsR/q2D/DNQCfW6sq
hERtcrUGiZhhgTBwUBWNhKE=
=62BD
-END PGP SIGNATURE-




___
Bug-cvs mailing list
Bug-cvs@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-cvs

RE: Windows 2000 - HOMEDRIVE,HOMEPATH vs. USERPROFILE

[Conrad T. Pino]

Hi Derek,

A few more observations follow:

> From: Conrad T. Pino [mailto:[EMAIL PROTECTED]
> 
> 
> Based on these observations, how do Windows and UNIX differ to CVS?
> 
> UNIX user profile (.profile,.bash_profile) files are always in $HOME.
> 
> UNIX user profile changes are effective AND committed when changed.

UNIX $HOME changes are effective AND committed when changed.
> 
> Windows user profile is always local and independent of Home Folder.
> 
> Windows Home Folder is synchronized with the user profile only when:
> 
>   Home Folder is undefined
>   Home Folder local path == %USERPROFILE%
> 
> Windows user profile changes are effective when changed and committed
> ONLY when user the logs off.

The last sentence above needs clarification as follows:

Windows local user profile changes are effective AND committed
when changed.

Windows network user profile changes are effective when changed
and committed ONLY when user the logs off.

Windows network user profile commits may not persist as expected when
used on multiple machines:

Login to workstation one, copy network profile to local drive.
Login to workstation two, copy network profile to local drive.

Modify user profile on workstation two.

Logoff workstation two, copy local drive to network profile,
network profile has workstation two modification.

Logoff workstation one, copy local drive to network profile,
workstation two modification to network profile is lost
since the Microsoft help file says:

If you use a roaming profile on more than one computer
simultaneously, it will preserve the settings from the
last computer that logs off.

Windows Home Folder changes are effective AND committed when changed.
> 

Conrad



___
Bug-cvs mailing list
Bug-cvs@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-cvs

Windows 2000 - HOMEDRIVE,HOMEPATH vs. USERPROFILE

[Conrad T. Pino]

Hi Derek,

I ran tests on Windows 2000 and here's what I've learned so far:

* User accounts have two flavors:  "Local" and "Domain"

* Both user account types support local or network user profiles
* Both user account types support "Home folder" options

* User profile type ("local" vs. "network") seems irrelevant to CVS because
  network profiles are copied to a local drive and USERPROFILE always points
  to the local copy located in the machine specific profile root directory.

* Home Folder options are "undefined", "local folder", "network folder" and
  these are visible to CVS as follows:

Home Folder Environment Variables

undefined   %HOMEDRIVE%%HOMEPATH% set to %USERPROFILE%
HOMESHARE does not exist

local folder%HOMEDRIVE% set to local folder drive, no path
%HOMEPATH% set to local folder path, no drive
HOMESHARE does not exist

network folder  %HOMEDRIVE% set to network drive
%HOMEPATH% set to "\"
%HOMESHARE% set to network folder

* Network folder values look like: \\ServerName\ShareName\OptionalPath

Based on these observations, how do Windows and UNIX differ to CVS?

UNIX user profile (.profile,.bash_profile) files are always in $HOME.

UNIX user profile changes are effective AND committed when changed.

Windows user profile is always local and independent of Home Folder.

Windows Home Folder is synchronized with the user profile only when:

Home Folder is undefined
Home Folder local path == %USERPROFILE%

Windows user profile changes are effective when changed and committed
ONLY when user the logs off.

Best regards,

Conrad Pino


___
Bug-cvs mailing list
Bug-cvs@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-cvs

Feature Branch - windows-NT/pwd.h & windows-NT/unistd.h

[Conrad T. Pino]

Hi Derek,

File "windows-NT/pwd.h" declares several functions that
are declared in "unistd.h" according to the NetBSD man
pages.

Since I created "windows-NT/unistd.c" do you object in
principle to migrations from "pwd.c" to "unistd.c"?

If you agree, I'll enumerate the functions to migrate
for review before actually doing so.

Best regards,

Conrad



___
Bug-cvs mailing list
Bug-cvs@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-cvs