Discussion:
String Manipulation
Add Reply
HCorte
2021-10-13 10:54:56 UTC
Reply
Permalink
Have a string named MILLCON that contain "," as delimiter to split in two substrings have two aproches:

1º using routine ELEMENT from STR$

STR$ELEMENT(MESSCON,0,",",MILLCON)
STR$ELEMENT(IP_ADDRESS,1,",",MILLCON)

2º using routine INDEX and LEN from LIB$

POS_AUX = LIB$INDEX(MILLCON,",")
MESSCON = MILLCON(1:POS_AUX-1)
IP_ADDRESS = MILLCON(POS_AUX+1:LIB$LEN(MILLCON)-(POS_AUX+1))

is either aproach good or is there one bether and if so why?
Arne Vajhøj
2021-10-13 12:35:27 UTC
Reply
Permalink
Post by HCorte
1º using routine ELEMENT from STR$
STR$ELEMENT(MESSCON,0,",",MILLCON)
STR$ELEMENT(IP_ADDRESS,1,",",MILLCON)
2º using routine INDEX and LEN from LIB$
POS_AUX = LIB$INDEX(MILLCON,",")
MESSCON = MILLCON(1:POS_AUX-1)
IP_ADDRESS = MILLCON(POS_AUX+1:LIB$LEN(MILLCON)-(POS_AUX+1))
is either aproach good or is there one bether and if so why?
STR$ELEMENT way seems to be the cleanest code by far.

Also note that (assuming Fortran) LIB$INDEX and LIB$LEN
could be replaced by INDEX and LEN.

Arne
Bob Gezelter
2021-10-13 13:16:40 UTC
Reply
Permalink
Post by HCorte
1º using routine ELEMENT from STR$
STR$ELEMENT(MESSCON,0,",",MILLCON)
STR$ELEMENT(IP_ADDRESS,1,",",MILLCON)
2º using routine INDEX and LEN from LIB$
POS_AUX = LIB$INDEX(MILLCON,",")
MESSCON = MILLCON(1:POS_AUX-1)
IP_ADDRESS = MILLCON(POS_AUX+1:LIB$LEN(MILLCON)-(POS_AUX+1))
is either aproach good or is there one bether and if so why?
HCorte,

Caution is recommended. This approach is extremely brittle in the face of text errors.

Both coding sequences presume that the input string is valid, without verifying that fact.

More information concerning the source string would be helpful.

- Bob Gezelter, http://www.rlgsc.com
Stephen Hoffman
2021-10-13 14:32:56 UTC
Reply
Permalink
Post by Bob Gezelter
Post by HCorte
Have a string named MILLCON that contain "," as delimiter to split in
1º using routine ELEMENT from STR$
STR$ELEMENT(MESSCON,0,",",MILLCON)
STR$ELEMENT(IP_ADDRESS,1,",",MILLCON)
2º using routine INDEX and LEN from LIB$
POS_AUX = LIB$INDEX(MILLCON,",")
MESSCON = MILLCON(1:POS_AUX-1)
IP_ADDRESS = MILLCON(POS_AUX+1:LIB$LEN(MILLCON)-(POS_AUX+1))
is either aproach good or is there one bether and if so why?
Caution is recommended. This approach is extremely brittle in the face of text errors.
Both coding sequences presume that the input string is valid, without verifying that fact.
More information concerning the source string would be helpful.
As Bob states... Wider views are better. Then narrow the view as
necessary. Starting out narrow can miss both potential problems and
potential solutions.

With solely what you've posted above, it really doesn't matter which
sequence is chosen, other than for code clarity and maintenance.

if you're doing enough of these that the performance of these
operations really matters, profile one or more of the solutions and see
which meet your requirements, and preferably profile the full code to
see where the wall-clock is going.

If you're doing enough of these, a parser is a better and more robust
approach. Options here can include lib$table_parse or—given the
commas—potentially language-specific wrappers around a libcsv port.

If this is possibly involving CSV as it might appear, CSV itself looks
simple for the myriad edge cases it comprises.

If there's even a whiff of a possibility of untrusted data arising
around here, an app-isolated parser is a much more robust approach.

Parsers are also recommended if there's a whiff of a possibility that
the arriving data formats will be extended or modified. In-line string
parsing in procedural languages is, as Bob mentions, decidedly brittle.

Parsers are a shade harder to write up front (for those that haven't
met lib$table_parse or other such), and vastly easier to maintain and
update and secure. And are less code.
--
Pure Personal Opinion | HoffmanLabs LLC
Dave Froble
2021-10-13 15:03:47 UTC
Reply
Permalink
Post by Stephen Hoffman
Post by Bob Gezelter
Post by HCorte
Have a string named MILLCON that contain "," as delimiter to split in
1º using routine ELEMENT from STR$
STR$ELEMENT(MESSCON,0,",",MILLCON)
STR$ELEMENT(IP_ADDRESS,1,",",MILLCON)
2º using routine INDEX and LEN from LIB$
POS_AUX = LIB$INDEX(MILLCON,",")
MESSCON = MILLCON(1:POS_AUX-1)
IP_ADDRESS = MILLCON(POS_AUX+1:LIB$LEN(MILLCON)-(POS_AUX+1))
is either aproach good or is there one bether and if so why?
Caution is recommended. This approach is extremely brittle in the face of text errors.
Both coding sequences presume that the input string is valid, without
verifying that fact.
More information concerning the source string would be helpful.
As Bob states... Wider views are better. Then narrow the view as
necessary. Starting out narrow can miss both potential problems and
potential solutions.
With solely what you've posted above, it really doesn't matter which
sequence is chosen, other than for code clarity and maintenance.
if you're doing enough of these that the performance of these operations
really matters, profile one or more of the solutions and see which meet
your requirements, and preferably profile the full code to see where the
wall-clock is going.
If you're doing enough of these, a parser is a better and more robust
approach. Options here can include lib$table_parse or—given the
commas—potentially language-specific wrappers around a libcsv port.
If this is possibly involving CSV as it might appear, CSV itself looks
simple for the myriad edge cases it comprises.
If there's even a whiff of a possibility of untrusted data arising
around here, an app-isolated parser is a much more robust approach.
Parsers are also recommended if there's a whiff of a possibility that
the arriving data formats will be extended or modified. In-line string
parsing in procedural languages is, as Bob mentions, decidedly brittle.
Parsers are a shade harder to write up front (for those that haven't met
lib$table_parse or other such), and vastly easier to maintain and update
and secure. And are less code.
Not getting out much, I didn't under either example. Here's what I've
used for like, almost forever ...

100 !************************************************************
! Parse a String
!************************************************************
!
SUB PARSE( STG$ , DELIM$ , FRONT$ , BACK$ )
!
! STG$ - String to parse
! DELIM$ - Delimiter string
! FRONT$ - Segment of string preceeding delimiter
! BACK$ - Segment of string following delimiter
!
!************************************************************
!
OPTION SIZE=( INTEGER WORD , REAL DOUBLE )

Z% = INSTR( 1% , STG$ , DELIM$ ) ! Search for
delimiter
Z% = LEN(STG$)+1% UNLESS Z% ! Not found,
whole string
FRONT$ = LEFT( STG$ , Z%-1% ) ! Preceeding
segment
BACK$ = RIGHT( STG$ , Z%+LEN(DELIM$) ) ! Following
segment
!
SUBEND

Implemented in Basic, of course ...
--
David Froble Tel: 724-529-0450
Dave Froble Enterprises, Inc. E-Mail: ***@tsoft-inc.com
DFE Ultralights, Inc.
170 Grimplin Road
Vanderbilt, PA 15486
HCorte
2021-10-13 16:30:07 UTC
Reply
Permalink
Gona use STR$ELEMENT since allows to split more easly multiple substrings, the string will alls be valid since I am the one defining that string into a logical name.
Stephen Hoffman
2021-10-13 16:53:07 UTC
Reply
Permalink
Post by HCorte
Gona use STR$ELEMENT since allows to split more easly multiple
substrings, the string will alls be valid since I am the one defining
that string into a logical name.
Logical names solely translated from privileged modes probably, but
there have been exploits against OpenVMS and apps involving
translations of untrusted translations.

With the knowledge that the exploit referenced in the following SPR
involved faulty logical name translation, which logical name and how
the exploit worked should be obvious...


OPERATING SYSTEM: VAX/VMS V2.1
PRODUCT: VAX/VMS
COMPONENT: LOGINOUT


GRPNAM SECURITY HOLE IN LOGIN

PROBLEM STATEMENT:

The GRPNAM privilege is an evil demon, allowing the user to
invoke its secret entrance for all manner of nefarious
purposes not originally intended.


RESPONSE FROM DEC:

The great wizard VMS confronted the demon, raised his great
oaken staff carved in ancient runes, and spoke the magic
incantation:
"$SETPRV IMAGEACTIVATIONENHANCEDPRIVILEGES $CMKRNL!!"
There was a blinding flash of light and puff of smoke, and
the demon, reduced to harmlessness, scurried off into the
distance.

Where his secret entrance had been was naught but a little
pile of ashes, which the wind slowly drifted into letters
spelling the words "FIXED IN V2.3".
--
Pure Personal Opinion | HoffmanLabs LLC
chris
2021-10-13 17:30:05 UTC
Reply
Permalink
Post by Stephen Hoffman
Post by HCorte
Gona use STR$ELEMENT since allows to split more easly multiple
substrings, the string will alls be valid since I am the one defining
that string into a logical name.
Logical names solely translated from privileged modes probably, but
there have been exploits against OpenVMS and apps involving translations
of untrusted translations.
With the knowledge that the exploit referenced in the following SPR
involved faulty logical name translation, which logical name and how the
exploit worked should be obvious...
OPERATING SYSTEM: VAX/VMS V2.1
PRODUCT: VAX/VMS
COMPONENT: LOGINOUT
GRPNAM SECURITY HOLE IN LOGIN
The GRPNAM privilege is an evil demon, allowing the user to
invoke its secret entrance for all manner of nefarious
purposes not originally intended.
The great wizard VMS confronted the demon, raised his great
oaken staff carved in ancient runes, and spoke the magic
"$SETPRV IMAGEACTIVATIONENHANCEDPRIVILEGES $CMKRNL!!"
There was a blinding flash of light and puff of smoke, and
the demon, reduced to harmlessness, scurried off into the
distance.
Where his secret entrance had been was naught but a little
pile of ashes, which the wind slowly drifted into letters
spelling the words "FIXED IN V2.3".
Rofl. At least the world still had a sense of humour in those
days...

Chris
Dave Froble
2021-10-13 20:35:18 UTC
Reply
Permalink
Post by chris
Post by Stephen Hoffman
Post by HCorte
Gona use STR$ELEMENT since allows to split more easly multiple
substrings, the string will alls be valid since I am the one defining
that string into a logical name.
Logical names solely translated from privileged modes probably, but
there have been exploits against OpenVMS and apps involving translations
of untrusted translations.
With the knowledge that the exploit referenced in the following SPR
involved faulty logical name translation, which logical name and how the
exploit worked should be obvious...
OPERATING SYSTEM: VAX/VMS V2.1
PRODUCT: VAX/VMS
COMPONENT: LOGINOUT
GRPNAM SECURITY HOLE IN LOGIN
The GRPNAM privilege is an evil demon, allowing the user to
invoke its secret entrance for all manner of nefarious
purposes not originally intended.
The great wizard VMS confronted the demon, raised his great
oaken staff carved in ancient runes, and spoke the magic
"$SETPRV IMAGEACTIVATIONENHANCEDPRIVILEGES $CMKRNL!!"
There was a blinding flash of light and puff of smoke, and
the demon, reduced to harmlessness, scurried off into the
distance.
Where his secret entrance had been was naught but a little
pile of ashes, which the wind slowly drifted into letters
spelling the words "FIXED IN V2.3".
Rofl. At least the world still had a sense of humour in those
days...
Chris
Yes, they did. And Stan Robonowski (can't spell) SPR on why is year
2000 not a leap year was a real gem.
--
David Froble Tel: 724-529-0450
Dave Froble Enterprises, Inc. E-Mail: ***@tsoft-inc.com
DFE Ultralights, Inc.
170 Grimplin Road
Vanderbilt, PA 15486
Simon Clubley
2021-10-14 17:50:48 UTC
Reply
Permalink
Post by Dave Froble
Yes, they did. And Stan Robonowski (can't spell) SPR on why is year
2000 not a leap year was a real gem.
Don't forget the one about a day in the life of the image activator. :-)

Simon.
--
Simon Clubley, ***@remove_me.eisner.decus.org-Earth.UFP
Walking destinations on a map are further away than they appear.
David Jones
2021-10-13 19:24:33 UTC
Reply
Permalink
Post by Stephen Hoffman
With the knowledge that the exploit referenced in the following SPR
involved faulty logical name translation, which logical name and how
the exploit worked should be obvious...
I forget the details, but I once bypassed an application's license enforcement
by exploiting that part of the code used $TRNLNM and part was still using
$TRNLOG.
V***@SendSpamHere.ORG
2021-10-13 19:27:37 UTC
Reply
Permalink
Have a string named MILLCON that contain "," as delimiter to split in two s=
1=C2=BA using routine ELEMENT from STR$
STR$ELEMENT(MESSCON,0,",",MILLCON)
STR$ELEMENT(IP_ADDRESS,1,",",MILLCON)=20
2=C2=BA using routine INDEX and LEN from LIB$
POS_AUX =3D LIB$INDEX(MILLCON,",")
MESSCON =3D MILLCON(1:POS_AUX-1)
IP_ADDRESS =3D MILLCON(POS_AUX+1:LIB$LEN(MILLCON)-(POS_AUX+1))
is either aproach good or is there one bether and if so why?
Three:

LIB$TABLE_PARSE
--
VAXman- A Bored Certified VMS Kernel Mode Hacker VAXman(at)TMESIS(dot)ORG

I speak to machines with the voice of humanity.
Lawrence D’Oliveiro
2021-10-14 00:17:03 UTC
Reply
Permalink
Post by HCorte
STR$ELEMENT(MESSCON,0,",",MILLCON)
STR$ELEMENT(IP_ADDRESS,1,",",MILLCON)
    messcon, ip_address = millcon.split(",", 1)
Arne Vajhøj
2021-10-14 00:22:02 UTC
Reply
Permalink
Post by Lawrence D’Oliveiro
Post by HCorte
STR$ELEMENT(MESSCON,0,",",MILLCON)
STR$ELEMENT(IP_ADDRESS,1,",",MILLCON)
    messcon, ip_address = millcon.split(",", 1)
Not in the noble language he is using ...

:-)

Arne
Loading...