Mailing-List: contact cygwin-developers-help AT cygwin DOT com; run by ezmlm
List-Subscribe: <mailto:cygwin-developers-subscribe AT cygwin DOT com>
List-Archive: <http://sources.redhat.com/ml/cygwin-developers/>
List-Post: <mailto:cygwin-developers AT cygwin DOT com>
List-Help: <mailto:cygwin-developers-help AT cygwin DOT com>, <http://sources.redhat.com/ml/#faqs>
Sender: cygwin-developers-owner AT cygwin DOT com
Delivered-To: mailing list cygwin-developers AT cygwin DOT com
Message-Id: <3.0.5.32.20030125204634.00802ad0@mail.attbi.com>
X-Sender: phumblet AT mail DOT attbi DOT com
Date: Sat, 25 Jan 2003 20:46:34 -0500
To: cygwin-developers AT cygwin DOT com
From: "Pierre A. Humblet" <Pierre DOT Humblet AT ieee DOT org>
Subject: passwd/group parsing
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"

Chris,

I had a quick look at your changes and have a few comments:
- soon the uid/gid will be __uid32_t and the code should support it. 
  It is legal for next_int () to return negative values, even -1.
  That's why the original code was using another error detection
  method.
- It looks like fields such as pw_gecos, pw_dir, etc.. could be set
  to NULL when a line is incomplete. That is a new behavior, not 
  expected by internal code nor by programs such as login (I only 
  checked that one).
  It comes from the code in next_str. By the way, why do you add 
  two \0 in "search" used by strpbrk? The second never has any effect.
- 99.99% of /etc/group lines at cygwin installations have an empty
  last field. That's why when that was detected (dp == NULL with your 
  new code, *dp == 0 with the old or new) gr_mem was set to null_ptr
  rather than pointing dp to a static empty string, scanning it twice 
  and calling calloc.
  I believe the old code was also setting gr_mem to a non-NULL legal 
  value in the unlikely event where calloc failed.
  Incidentally setting namearray[i] = NULL is useless, calloc has
  already done it (that may be legacy code).

Pierre