search

Perl / perl5

🐪 The Perl programming language
https://dev.perl.org/perl5/
Other
2.14k stars 587 forks source link

Unreachable value in a search list logical name #2992

Closed p5pRT closed 21 years ago

p5pRT commented 24 years ago

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

Searchable as RT4918$

p5pRT commented 24 years ago

From coucoureux.p@fr.ibm.com

This is a bug report for perl from coucoureux.p@​fr.ibm.com\, generated with the help of perlbug 1.28 running under perl v5.6.0.

In a search list logical name with more than 7 values\, the last values are not reachable.

Example​: $ Define STORY once\,upon\,a\,time\,there\,was\,a\,little\,girl\,with $ perl -e "for ($i = 0; $i \<= 9; $i++) " - _$ -e "{ print $ENV{'story;'.$i}\,' '}" once upon a time there was a little

Flags​:   category=core   severity=low

Site configuration information for perl v5.6.0​:

Configured by system at Mon Nov 20 16​:27​:22 UTC+1​:00 2000.

Summary of my perl5 (revision 5.0 version 6 subversion 0) configuration​:   Platform​:   osname=VMS\, osvers=V7.2-1\, archname=VMS_AXP   uname='VMS piano V7.2-1 COMPAQ AlphaServer DS10 466 MHz'   config_args=''   hint=none\, useposix=false\, d_sigaction=define   usethreads=undef use5005threads=undef useithreads=undef usemultiplicity=undef   useperlio=undef d_sfio=undef uselargefiles=undef   use64bitint=undef use64bitall=undef uselongdouble=undef usesocks=undef   Compiler​:   cc='CC/DECC'\, optimize=''\, gccversion=undef   cppflags='undef'   ccflags ='/Include=[]/Standard=Relaxed_ANSI/Prefix=All/Obj=.obj/NoList/NOANSI_ALIAS'   stdchar='char'\, d_stdstdio=define\, usevfork=true   intsize=4\, longsize=4\, ptrsize=4\, doublesize=8   d_longlong=define\, longlongsize=8\, d_longdbl=define\, longdblsize=16   ivtype='long'\, ivsize=4\, nvtype='double'\, nvsize=undef\, Off_t='int'\, lseeksize=4   alignbytes=8\, usemymalloc=N\, prototype=define   Linker and Libraries​:   ld='Link'\, ldflags ='/NoTrace/NoMap'   libpth=/sys$share /sys$library   libs=   libc=(DECCRTL)\, so=exe\, useshrplib=undef\, libperl=undef   Dynamic Linking​:   dlsrc=dl_vms.c\, dlext=exe\, d_dlsymun=undef\, ccdlflags=''   cccdlflags=''\, lddlflags='/Share'

Locally applied patches​:   VMSPIPE010 - combined VMS piping revamp   VMSMISC001 - misc VMS fixes\, combined patch

@​INC for perl v5.6.0​:   perl_root​:[lib.VMS_AXP.5_6_0]   perl_root​:[lib]   perl_root​:[lib.site_perl.VMS_AXP]   perl_root​:[lib.site_perl]   /perl_root/lib/site_perl   .

Environment for perl v5.6.0​:   HOME=disk$usr​:[ptpc]   LANG (unset)   LANGUAGE (unset)   LD_LIBRARY_PATH (unset)   LOGDIR (unset)   PATH=RTSCUR​:[runmqtst]   PERLSHR=PERL_ROOT​:[000000]PERLSHR.EXE   PERL_BADLANG (unset)   PERL_ROOT=DKA0​:[SYS0.SYSCOMMON.TOOLS.PERL.]   SHELL (unset)

p5pRT commented 24 years ago

From [Unknown Contact. See original ticket]

In a recent perlbug report listed at​:

http​://www.xray.mpe.mpg.de/mailing-lists/perl5-porters/2000-12/msg00755.html

coucoureux.p@​fr.ibm.com noted that​:

In a search list logical name with more than 7 values\, the last values are not reachable.

Example​: $ Define STORY once\,upon\,a\,time\,there\,was\,a\,little\,girl\,with $ perl -e "for ($i = 0; $i \<= 9; $i++) " - _$ -e "{ print $ENV{'story;'.$i}\,' '}" once upon a time there was a little

Which I can reproduce even with older perls. It seems as though this is a limitation that DECC imposes on its interface to the $trnlnm() system service. The translation done by perl is carried out in the my_trnlnm() routine in perl_root​:[vms]vms.c. Where you'll note that search list translation does not exceed LNM$_MAX_INDEX translations. That parameter is defined in lnmdef.h (a module to be found in the SYS$LIBRARY​:SYS$STARLET_C.TLB header library) on my older V5.5-002 I have this definition​:

#define LNM$_MAX_INDEX 7 /* Maximum translation index */

I am not sure why DECC imposes this limitation. Obviously DCL's SHOW LOGICAL command can access the remaining search list items​:

$ show log story   "STORY" = "ONCE" (LNM$PROCESS_TABLE)   = "UPON"   = "A"   = "TIME"   = "THERE"   = "WAS"   = "A"   = "LITTLE"   = "GIRL"   = "WITH"

So the "stop at 7" bug in DECC ought to be worked around by vmsperl.

If you are in an especially adventurous mood you might try adding a redefinition​:

#undef LNM$_MAX_INDEX #define LNM$_MAX_INDEX 21

at some point in vms.c then recompile your perl binary (although you may invoke access violations that way too so caution with such an experimental binary would be highly advised).

I have Cced this reply to the vmsperl list where some discussion of logical name translation has recently been discussed.

Peter Prymmer

p5pRT commented 24 years ago

From @craigberry

At 12​:11 PM -0800 12/14/00\, Peter Prymmer wrote​:

coucoureux.p@​fr.ibm.com noted that​:

In a search list logical name with more than 7 values\, the last values are not reachable.

Which I can reproduce even with older perls. It seems as though this is a limitation that DECC imposes on its interface to the $trnlnm() system service. The translation done by perl is carried out in the my_trnlnm() routine in perl_root​:[vms]vms.c. Where you'll note that search list translation does not exceed LNM$_MAX_INDEX translations. That parameter is defined in lnmdef.h (a module to be found in the SYS$LIBRARY​:SYS$STARLET_C.TLB header library) on my older V5.5-002 I have this definition​:

#define LNM$_MAX_INDEX 7 /* Maximum translation index */

I am not sure why DECC imposes this limitation.

It doesn't. This turns out to be a bona fide bug in Perl on VMS. We are using LNM$_MAX_INDEX as if it were the largest allowable index value\, but instead it is an item code which tells sys$trnlnm "Give me the value of the highest current index\," or\, in other words\, give me the index of the last one in the list if it is a search list logical. For more details see the OpenVMS System Services Reference Manual entry for $TRNLNM located here​:

\<http​://www.openvms.compaq.com​:8000/72final/4527/4527pro_094.html#index_x_1128>

You'll also find there that the valid index values are 0 through 127. It's possible all we'll need is what follows\, though my build directory is in a bit of disarray at the moment so I haven't tested it yet.

Inline Patch ```diff --- vms/vms.c;-0 Fri Dec 8 14:28:19 2000 +++ vms/vms.c Thu Dec 14 15:06:44 2000 @@ -152,7 +152,7 @@ } #endif - if (!lnm || !eqv || idx > LNM$_MAX_INDEX) { + if (!lnm || !eqv || idx > 127) { set_errno(EINVAL); set_vaxc_errno(SS$_BADPARAM); return 0; } for (cp1 = (char *)lnm, cp2 = uplnm; *cp1; cp1++, cp2++) { ```
p5pRT commented 24 years ago

From @jhi

--- vms/vms.c;-0 Fri Dec 8 14​:28​:19 2000 +++ vms/vms.c Thu Dec 14 15​:06​:44 2000 @​@​ -152\,7 +152\,7 @​@​ } #endif

- if (!lnm || !eqv || idx > LNM$_MAX_INDEX) { + if (!lnm || !eqv || idx > 127) {

*cough* Changing a nice symbolic value to a naughty hardcoded value? *cough* :-)

(I do understand what's the bug but I dislike naked numbers without explanations...)

p5pRT commented 24 years ago

From [Unknown Contact. See original ticket]

On Thu\, 14 Dec 2000\, Craig A. Berry wrote​:

It doesn't. This turns out to be a bona fide bug in Perl on VMS. We are using LNM$_MAX_INDEX as if it were the largest allowable index value\, but instead it is an item code which tells sys$trnlnm "Give me the value of the highest current index\," or\, in other words\, give me the index of the last one in the list if it is a search list logical. For more details see the OpenVMS System Services Reference Manual entry for $TRNLNM located here​:

\<http​://www.openvms.compaq.com​:8000/72final/4527/4527pro_094.html#index_x_1128>

You'll also find there that the valid index values are 0 through 127. It's possible all we'll need is what follows\, though my build directory is in a bit of disarray at the moment so I haven't tested it yet.

Heh "bug in DECC indeed :-)"

--- vms/vms.c;-0 Fri Dec 8 14​:28​:19 2000 +++ vms/vms.c Thu Dec 14 15​:06​:44 2000 @​@​ -152\,7 +152\,7 @​@​ } #endif

- if (!lnm || !eqv || idx > LNM$_MAX_INDEX) { + if (!lnm || !eqv || idx > 127) { set_errno(EINVAL); set_vaxc_errno(SS$_BADPARAM); return 0; } for (cp1 = (char *)lnm\, cp2 = uplnm; *cp1; cp1++\, cp2++) {

OK I've had a chance to test it against a patched @​8102 kit (we need to modify vms specific Makefile.PL files and IO.xs - I'll send in a separate message). But with your patch Craig I do obtain this result​:

$ Define STORY once\,upon\,a\,time\,there\,was\,a\,little\,girl\,with $ perl -e "for ($i = 0; $i \<= 9; $i++) { print $ENV{'story;'.$i}\,' '}" ONCE UPON A TIME THERE WAS A LITTLE GIRL WITH $ perl -v

This is perl\, v5.7.0 built for VMS_AXP (with 1 registered patch\, see perl -V for more detail)

The `mms test` result returned these glitches​:

[.lib]filehand..........FAILED on test 4

[.lib]vmsish............FAILED on test 14

Failed 2/265 tests\, 94.72% okay. u=34.42 s=0 cu=0 cs=0 scripts=253 tests=13349

But the filehand.t failure is an ungetc() problem??? and the vmsish was a bad SYS$TIMEZONE_DIFFERENTIAL (yet another​: why don't we have daylight savings automated around here? :-) BTW it passes with​:

$ sho log sys$timezone_differential   "SYS$TIMEZONE_DIFFERENTIAL" = "-28800" (LNM$SYSTEM_TABLE)

At any rate it looks like your patch is just the ticket (modulo any /* comments on $TRNLNM */ you might want to add to appease Jarkko :-)

Thanks.

Peter Prymmer

p5pRT commented 24 years ago

From @craigberry

At 3​:33 PM -0600 12/14/00\, Jarkko Hietaniemi wrote​:

*cough* Changing a nice symbolic value to a naughty hardcoded value? *cough* :-)

Get something for that cough :-).

(I do understand what's the bug but I dislike naked numbers without explanations...)

Yes\, I suppose the fact that the vendor supplied a confusing symbolic name for the value we didn't want (leading us to believe we wanted it) and none at all for the one we did want is no excuse\, though laziness can be contagious (clearly you've never been exposed) :-). Thanks to Peter for testing. This against 8102 puts clothes on the naked number​:

Inline Patch ```diff --- vms/vms.c;-0 Fri Dec 8 14:28:19 2000 +++ vms/vms.c Thu Dec 14 17:07:01 2000 @@ -98,6 +98,9 @@ #define expand_wild_cards(a,b,c,d) mp_expand_wild_cards(aTHX_ a,b,c,d) #define getredirection(a,b) mp_getredirection(aTHX_ a,b) +/* see system service docs for $TRNLNM -- NOT the same as LNM$_MAX_INDEX */ +#define PERL_LNM_MAX_ALLOWED_INDEX 127 + static char *__mystrtolower(char *str) { if (str) for (; *str; ++str) *str= tolower(*str); @@ -152,7 +155,7 @@ } #endif - if (!lnm || !eqv || idx > LNM$_MAX_INDEX) { + if (!lnm || !eqv || idx > PERL_LNM_MAX_ALLOWED_INDEX) { set_errno(EINVAL); set_vaxc_errno(SS$_BADPARAM); return 0; } for (cp1 = (char *)lnm, cp2 = uplnm; *cp1; cp1++, cp2++) { [end of patch] ```
p5pRT commented 24 years ago

From @jhi

On Thu\, Dec 14\, 2000 at 07​:10​:49PM -0600\, Craig A. Berry wrote​:

At 3​:33 PM -0600 12/14/00\, Jarkko Hietaniemi wrote​:

*cough* Changing a nice symbolic value to a naughty hardcoded value? *cough* :-)

Get something for that cough :-).

The below patch is exactly what my cough needed :-)

(I do understand what's the bug but I dislike naked numbers without explanations...)

Yes\, I suppose the fact that the vendor supplied a confusing symbolic name for the value we didn't want (leading us to believe we wanted it) and none at all for the one we did want is no excuse\, though laziness can be contagious (clearly you've never been exposed) :-). Thanks to Peter for testing. This against 8102 puts clothes on the naked number​:

--- vms/vms.c;-0 Fri Dec 8 14​:28​:19 2000 +++ vms/vms.c Thu Dec 14 17​:07​:01 2000 @​@​ -98\,6 +98\,9 @​@​ #define expand_wild_cards(a\,b\,c\,d) mp_expand_wild_cards(aTHX_ a\,b\,c\,d) #define getredirection(a\,b) mp_getredirection(aTHX_ a\,b)

+/* see system service docs for $TRNLNM -- NOT the same as LNM$_MAX_INDEX */ +#define PERL_LNM_MAX_ALLOWED_INDEX 127 + static char *__mystrtolower(char *str) { if (str) for (; *str; ++str) *str= tolower(*str); @​@​ -152\,7 +155\,7 @​@​ } #endif

- if (!lnm || !eqv || idx > LNM$_MAX_INDEX) { + if (!lnm || !eqv || idx > PERL_LNM_MAX_ALLOWED_INDEX) { set_errno(EINVAL); set_vaxc_errno(SS$_BADPARAM); return 0; } for (cp1 = (char *)lnm\, cp2 = uplnm; *cp1; cp1++\, cp2++) { [end of patch] -- ____________________________________________ Craig A. Berry mailto​:craig.berry@​psinetcs.com

p5pRT commented 24 years ago

From [Unknown Contact. See original ticket]

Thanks all for your quick response. I have tested your patch on v5.6.0. All is OK.

Pierre Coucoureux IBM\, Paris Laboratory Application & Integration Middleware Division 69\, rue de la Vecquerie - 44600 Saint-Nazaire Phone : +33 (0)2-51-16-4053 Fax : -4001 Email : coucoureux.p@​fr.ibm.com