Re: DCL question (of the day)- null byte in string symbol
From: norm.raphael@metso.com
Date: 04/17/03
- Next message: briggs@encompasserve.org: "RE: DCL question (of the day)- null byte in string symbol"
- Previous message: Kyle: "DCL script to rename multiple versions of a file"
- Maybe in reply to: PRSTSC::DTL: "Re: DCL question (of the day)- null byte in string symbol"
- Next in thread: briggs@encompasserve.org: "Re: DCL question (of the day)- null byte in string symbol"
- Reply: briggs@encompasserve.org: "Re: DCL question (of the day)- null byte in string symbol"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ] [ attachment ]
From: norm.raphael@metso.com Date: Thu, 17 Apr 2003 10:39:59 -0400
John,
Thank you for clearing up what I was trying to determine, namely
that this _is_ a DCL bug (as you and I see it, as least).
"The fact that command verification reflects a truncated command line
is a smoking gun...."
Yes, indeed.
As to:
"It is not a programmer error
except inasmuch as the code that first demonstrated the misbehavior
was doing explicit symbol substitution where implicit expression
evaluation would have served. But that's a matter of taste rather
then an error per se."
I have pointed out that this code was just to show the bug, not the actual
code where the problem
was encountered. That code is in another thread about reading the ".exe"
file where in it is
explained that getting a 1-byte string with a null in it was not
anticipated and so not handled.
Now how and where do we report this bug, or is it worth reporting (that is,
will it occur enough to
spend resources on it)?
-Norm
From: briggs@encompasserve.org on 04/17/2003 09:48 AM
Please respond to briggs@encompasserve.org
To: Info-VAX@Mvb.Saic.Com
cc:
Subject: Re: DCL question (of the day)- null byte in string symbol
In article <3e9e7652$0$28765$626a54ce@news.free.fr>, PRSTSC::DTL
<Didier.Morandi.nospam@Free.fr> writes:
> norm.raphael@metso.com wrote:
>> Is this expected behavior?
>>
>> Note: I am having some difficulties in general with the fact that when
an
>> expression used as one term of a relation in an IF test fails to
evaluate,
>> the IF statement fails "ugly".
>>
>> $ type null_test.com
>> $ null1[0,8]=0
>> $ show symbol null1
>> $ if "''null1'" .eqs. "0" then write sys$output "null1 is zero"
>>
>> $ @null_test
>> NULL1 = "."
>> %DCL-E-INVIFNEST, invalid IF-THEN-ELSE nesting structure or data
>> inconsistency
>> $
>>
>> $ set verify
>> $ @null_test
>> $ null1[0,8]=0
>> $ sho sym null1
>> NULL1 = "."
>> $ if "
>> %DCL-E-INVIFNEST, invalid IF-THEN-ELSE nesting structure or data
>> inconsistency
>> $
>>
>> What is the real error here?
>
> And the real error is that you have garbage in [9,16]. Look:
No. He has nothing in [9,16]. The string isn't that long.
Note that [9,16] is 7 bits of the second character, 8 bits of
the third character and one bit of the fourth character in a
one character string. Not very meaningful.
> DTL02> null1[0,8]=0
> DTL02> sh symb null1
> NULL1 = "."
A one character string containing one zero byte.
> DTL02> null1=0
> DTL02> sh symb null1
> NULL1 = 0 Hex = 00000000 Octal = 00000000000
Now it's a 32 bit integer with all bits set to zero
> DTL02> null1[0,16]=0
> DTL02> sh symb null1
> NULL1 = 0 Hex = 00000000 Octal = 00000000000
Overlaying 16 bits of zeroes into 32 bits of zeroes. Which, as
you notice, does nothing.
> DTL02> if null1 .eq. 0 then sh time
> 17-APR-2003 11:37:43
And the resulting 32 bit integer is still zero.
The question at hand is why a particular string value doesn't work
in DCL. What is special about a leading null character in a string
that should cause IF to fail.
Expression evaluation shouldn't be a problem. That's what the
quotation marks are there for.
Lexical substitution is a possibility. When we re-scan the contents
of the quoted string after the first substitution looking for back
to back apostrophes, does the presence of a null character
screw things up?
The fact that command verification reflects a truncated command line
is a smoking gun pointing to an issue in lexical substitution.
The following test is revealing
$ NULL1 = ""
$ NULL1[0,8] = 0
$ SHOW SYM NULL1
NULL1 = "."
$ B := 'NULL1 asdf asdf asdf asdf
$ SHOW SYM B
B = ""
Lexical processing is screwed up (** DCL BUG **) to the point that it
is aborted and the remainder of the input line is ignored. Or perhaps
the input line is being processed as a null-terminated string (** DCL
BUG **) and the null byte in the offending symbol is being erroneously
interpreted as end-of-input.
The following test tends to confirm this:
$ NULL2 = "AB"
$ NULL2[8,8] = 0
$ SHOW SYM NULL2
NULL2 = "A."
$ B := 'NULL2 asdf asdf asdf
$ SHOW SYM B
B = "A"
Experimentation with command procedures in which the null byte appears
literally in a quoted string is somewhat revealing. In the absence
of apostrophe-based substitution, the logged input line includes
the null byte. But in no case does the null byte manifest in the
command results.
My best guess is that in the absence of apostrophe substitution, the
original line gets logged by descriptor and is then parsed as a null
terminated string. In the presence of apostrophe substitution, the
original line gets substituted as a null terminated string and
resulting truncated line is then logged and parsed.
This is most definitely a DCL bug. It is not a programmer error
except inasmuch as the code that first demonstrated the misbehavior
was doing explicit symbol substitution where implicit expression
evaluation would have served. But that's a matter of taste rather
then an error per se.
John Briggs
- Next message: briggs@encompasserve.org: "RE: DCL question (of the day)- null byte in string symbol"
- Previous message: Kyle: "DCL script to rename multiple versions of a file"
- Maybe in reply to: PRSTSC::DTL: "Re: DCL question (of the day)- null byte in string symbol"
- Next in thread: briggs@encompasserve.org: "Re: DCL question (of the day)- null byte in string symbol"
- Reply: briggs@encompasserve.org: "Re: DCL question (of the day)- null byte in string symbol"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ] [ attachment ]
Relevant Pages
|
