Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Not OK: perl 5.00561 on PA-RISC1.1 10.20 #651

Closed
p5pRT opened this issue Sep 21, 1999 · 3 comments
Closed

Not OK: perl 5.00561 on PA-RISC1.1 10.20 #651

p5pRT opened this issue Sep 21, 1999 · 3 comments

Comments

@p5pRT
Copy link

@p5pRT p5pRT commented Sep 21, 1999

Migrated from rt.perl.org#1527 (status was 'resolved')

Searchable as RT1527$

@p5pRT
Copy link
Author

@p5pRT p5pRT commented Sep 21, 1999

From lewart@www.cvm.uiuc.edu


Perl5-Porters,

getpwent and getpwuid are broken, but getpwnam is okay​:
1) getpwent returns the last entry in /etc/passwd .
2) getpwuid($num) returns the last entry in /etc/passwd if $num is
  a valid UID; otherwise it returns an empty string.

Why didn't "make test" catch such egregious errors? Because of the
following stanza from t/op/pwent.t​:
  94​: # Protect against one-to-many and many-to-one mappings.
  95​: if ($name_s ne $name) {
  96​: @​n = getpwnam($name_s);
  97​: ($name,$passwd,$uid,$gid,$quota,$comment,$gcos,$home,$shell) = @​n;
  98​: next if $name_s ne $name;
  99​: }
What is the point of the above clause?

Cheers,
Daniel Lewart
d-lewart@​uiuc.edu



Site configuration information for perl 5.00561​:

Configured by lewart at Mon Sep 6 14​:01​:38 CDT 1999.

Summary of my perl5 (revision 5.0 version 5 subversion 61) configuration​:
  Platform​:
  osname=hpux, osvers=10.20, archname=PA-RISC1.1
  uname='hp-ux www b.10.20 a 9000715 2013547832 two-user license '
  config_args='-de -Dcc=gcc -Dprefix=/ext/perl5.005_61'
  hint=recommended, useposix=true, d_sigaction=define
  usethreads=undef useperlio=undef d_sfio=undef
  use64bits=undef usemultiplicity=undef
  Compiler​:
  cc='gcc', optimize='-O', gccversion=2.95.1 19990816 (release)
  cppflags='-D_HPUX_SOURCE -I/usr/local/include'
  ccflags ='-D_HPUX_SOURCE -I/usr/local/include'
  stdchar='unsigned char', d_stdstdio=define, usevfork=false
  intsize=4, longsize=4, ptrsize=4, doublesize=8
  d_longlong=define, longlongsize=8, d_longdbl=define, longdblsize=8
  alignbytes=8, usemymalloc=y, prototype=define
  Linker and Libraries​:
  ld='ld', ldflags =' -L/usr/local/lib'
  libpth=/usr/local/lib /lib/pa1.1 /lib /usr/lib /usr/ccs/lib
  libs=-lnsl_s -lndbm -lgdbm -ldb -ldld -lm -lc -lndir -lcrypt -lsec
  libc=/lib/libc.sl, so=sl, useshrplib=false, libperl=libperl.a
  Dynamic Linking​:
  dlsrc=dl_hpux.xs, dlext=sl, d_dlsymun=undef, ccdlflags='-Wl,-E -Wl,-B,deferred '
  cccdlflags='-fpic', lddlflags='-b -L/usr/local/lib'

Locally applied patches​:
 


@​INC for perl 5.00561​:
  /ext/perl5.005_61/lib/5.00561/PA-RISC1.1
  /ext/perl5.005_61/lib/5.00561
  /ext/perl5.005_61/lib/site_perl/5.00561/PA-RISC1.1
  /ext/perl5.005_61/lib/site_perl
  .


Environment for perl 5.00561​:
  HOME=/home/lewart
  LANG (unset)
  LANGUAGE (unset)
  LD_LIBRARY_PATH (unset)
  LOGDIR (unset)
  PATH=/usr/local/bin​:/usr/bin​:/usr/ccs/bin​:/usr/contrib/bin​:/opt/nettladm/bin​:/opt/pd/bin​:/usr/bin/X11​:/usr/contrib/bin/X11​:/opt/upgrade/bin
  PERL_BADLANG (unset)
  SHELL=/usr/bin/ksh
  SHLIB_PATH (unset)

@p5pRT
Copy link
Author

@p5pRT p5pRT commented Sep 21, 1999

From @jhi

Daniel S. Lewart writes​:

getpwent and getpwuid are broken, but getpwnam is okay​:
1) getpwent returns the last entry in /etc/passwd .
2) getpwuid($num) returns the last entry in /etc/passwd if $num is
a valid UID; otherwise it returns an empty string.

Huh? This sounds so weird that I have to check​: getpwent() *always*
returns only the last entry in /etc/passwd()? After
endpwent()+setpwent(), too?

Ditto for getpwuid($valid_num).

The "empty string" case of getpwuid($invalid_num) is as it should be.
If you look closer you'll notice it's the undef (or an empty list
in array context).

(I checked almost-_62 in Digital UNIX and getpwent() and getpwuid()
work okay. I'll try compiling the same Perl tomorrow--but I don't
have HP-UX 10.20 anymore, I have 11.0, but I don't have gcc in there,
only the HP ANSI cc.)

Why didn't "make test" catch such egregious errors? Because of the
following stanza from t/op/pwent.t​:
94​: # Protect against one-to-many and many-to-one mappings.
95​: if ($name_s ne $name) {
96​: @​n = getpwnam($name_s);
97​: ($name,$passwd,$uid,$gid,$quota,$comment,$gcos,$home,$shell) = @​n;
98​: next if $name_s ne $name;
99​: }
What is the point of the above clause?

The passwd file might have both one username -> many uids mappings
(illegal but possible) and one uid -> many usernames mappings (slightly
less illegal, but sometimes useful). We cannot do many (any?) useful
checks if we have any many-mappings.

I must be slow but could you elaborate on how the above test makes
getpw*() tests to fail (to give a false positive)?

--
$jhi++; # http​://www.iki.fi/jhi/
  # There is this special biologist word we use for 'stable'.
  # It is 'dead'. -- Jack Cohen

@p5pRT
Copy link
Author

@p5pRT p5pRT commented Sep 23, 1999

From @jhi

Daniel S. Lewart writes​:

This is a build failure report for perl from d-lewart@​uiuc.edu,
generated with the help of perlbug 1.27 running under perl 5.00561.

-----------------------------------------------------------------
Perl5-Porters,

getpwent and getpwuid are broken, but getpwnam is okay​:
1) getpwent returns the last entry in /etc/passwd .
2) getpwuid($num) returns the last entry in /etc/passwd if $num is
a valid UID; otherwise it returns an empty string.

Soon-to-be-62 in HP-UX 11.0 compiled with gcc 2.8.1​: getpwent() most
certainly doesn't return the last entry in /etc/passwd -- not until
the last one is supposed to be returned.
getpwuid($valid_num) works okay, too.

--
$jhi++; # http​://www.iki.fi/jhi/
  # There is this special biologist word we use for 'stable'.
  # It is 'dead'. -- Jack Cohen

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Linked pull requests

Successfully merging a pull request may close this issue.

None yet
1 participant