Possible Alpha BASIC compiler problem?
Neil Rieck
but the Alpha BASIC compiler did not catch. (See the comment "typo"
below). However, the call still failed at run time when triggered by
customer data.
So here is my question:
1) Since I was using "option type=explicit" is the Alpha compiler at
fault?
2) should I have declared "dt_stamp" as "dt_stamp()" ?
3) will using "dt_stamp()" be future-proof?
Neil Rieck
Waterloo, Ontario, Canada.
http://www3.sympatico.ca/n.rieck/OpenVMS.html
1000 !============================================================
! title : alpha_basic_16_compiler_problem.bas
! author : Neil Rieck
! created : 2010-02-19
! note : tested using "Alpha BASIC V1.6-000"
! dcl : $bas/optim=level=0/lis -
! alpha_basic_16_compiler_problem.bas
!============================================================
option type=explicit !
!
! should this next line be changed to: "dt_stamp()"
! and will it be future proof?
!
external string function dt_stamp !
ccyymmddhhmmss
external string function html_escape(string) !
external string function html_unescape(string) !
!
declare string buff1$, buff2$, buff3$ !
!
2000 while 1 !
print "enter something (blank to exit)"; !
linput buff1$ !
goto fini if buff1$ = "" ! exit on
blank
print "date+time>"; dt_stamp !
buff2$ = html_escape(buff1$) !
!~~~ buff3$ = html_unescape(buff2$) x intended
line
!
! this next line is not what I intended...
! ...but the compiler did not complain
!
buff3$ = dt_stamp(buff2$) ! typo line
if buff2$ <> buff3$ then !
print "-e- conversion error" !
print " Org: "+ buff1$ !
print " Esc: "+ buff2$ !
print " Une: "+ buff3$ !
end if !
next !
!
30000 fini: !
print "-i-exiting" !
end !
FrankS
> So here is my question:
> 1) Since I was using "option type=explicit" is the Alpha compiler at
> fault?
> 2) should I have declared "dt_stamp" as "dt_stamp()" ?
> 3) will using "dt_stamp()" be future-proof?
>
1) No.
You declared the function as string, so the compiler knew what data
type to expect as a return value.
2) Maybe.
There are two purposes in an external function declaration. First, to
tell the compiler the data type of the return value, and secondly to
tell the compiler how many parameters (and their data types) the
function is expecting.
If the DT_STAMP function takes no arguments then declaring it as
EXTERNAL STRING FUNCTION DT_STAMP() is appropriate.
3) Maybe.
The question is too ambiguous, really. Do you mean using DT_STAMP()
in the function declaration or in the code body?
If you declare the function as EXTERNAL STRING FUNCTION DT_STAMP()
then you can't use DT_STAMP() in the code body. The compiler will
validate that all uses of DT_STAMP specify no parameters.
If you declare the function as EXTERNAL STRING FUNCTION DT_STAMP then
you can use DT_STAMP() in the code body. However, in that case using
DT_STAMP() in the code body tells the compiler to send one omitted
parameter (zero, passed by value).
Just to be complete, the declaration you used, of EXTERNAL STRING
FUNCTION DT_STAMP, tells the compiler the data type of the function
but also tells it not to perform any checking of the parameter list.
You're essentially on your own for getting the parameters correct.
The number of parameters, data types, and passing mechanisms are all
your responsibility, and you can't get any help from the compiler (or
blame it for your mistakes).
The safest, as future-proof as possible method is to fully declare any
external functions or subroutines. That means including the full
parameter list and the data types and passing mechanisms of them all.
Tim E. Sneddon
> This week I ran into a problem which I caused three weeks ago (typo)
> but the Alpha BASIC compiler did not catch. (See the comment "typo"
> below). However, the call still failed at run time when triggered by
> customer data.
>
> So here is my question:
> 1) Since I was using "option type=explicit" is the Alpha compiler at
> fault?
No. That compiler option enforces you declaring all storage and
giving it a type. This is opposed to the used of $, % and other
mumbo-jumbo to determine variable types.
> 2) should I have declared "dt_stamp" as "dt_stamp()" ?
It depends on what you want to do.
> 3) will using "dt_stamp()" be future-proof?
>
Using dt_stamp(), the way I understand it, tells the compiler that
the dt_stamp function accepts no arguments. However, declaring it as
dt_stamp, with out "()" tells the compiler that you will take care of
exactly how many arguments are passed and which mechanisms are used.
I generally declare functions in BASIC without specifying argument
details so I can specify arguments and passing mechanisms myself when
I make the call.
Unfortunately there are a number of RTL and system service function
definitions in the BASIC header files that make it very difficult to
use them (CLI$ stuff jumps to mind) because of the types and mechanisms
generated by SDL.
Tim.
Neil Rieck
1) The external string function "dt_stamp" accepts no parameters. It
is a function used by all BASIC program on all my systems to return
the current date+time in the form: ccyymmddhhmmss.
2) In my example, I meant to enter "buff3$ = html_unescape(buff2$)"
but accidentally entered "buff3$ = dt_stamp(buff2$)" (how the human
brain does this, I'll never understand). Up until now (I've been
writing code like this for 20 years), I assumed that the declaration
statement "external string function dt_stamp" meant "no parameters in,
one string parameter back". So when I made my typo (by passing a
parameter to the wrong function), I assumed the compiler would flag
it. Now to be fair to the compiler writers, it may have been working
this way all along and it just took 20 years for this condition to
bite me.
3) So what I am asking is this: should I have appended an empty
parameter list to my external function declaration? (which would
indicate to the compiler that the external function accepts no
parameters). I am worried that some not-so-clever hack now might break
future compiles.
p.s. I have also posted this question into the forum at http://www11.itrc.hp.com
so let's hope someone from HP chimes in.
Neil Rieck
Kitchener/Waterloo/Cambridge,
Ontario, Canada.
http://www3.sympatico.ca/n.rieck/OpenVMS.html
Jan-Erik Soderholm
> 3) So what I am asking is this: should I have appended an empty
> parameter list to my external function declaration? (which would
> indicate to the compiler that the external function accepts no
> parameters).
From earlier posts I would say, yes.
That whould have trigged an error message.
FrankS
> 3) So what I am asking is this: should I have appended an empty
> parameter list to my external function declaration? (which would
> indicate to the compiler that the external function accepts no
> parameters). I am worried that some not-so-clever hack now might break
> future compiles.
>
Yes, and I thought it was addressed in my prior response. Perhaps I
got too wordy.
Declaring it as EXTERNAL STRING FUNCTION DT_STAMP() is not a hack.
That's exactly the correct declaration for a function which takes no
parameters. It's been that way for longer than I can remember, so I
would not be worried about it changing at any future date.
> p.s. I have also posted this question into the forum at http://www11.itrc.hp.com
> so let's hope someone from HP chimes in.
Oh darn, I guess I won't be getting any points by responding
here. :-)
Chris Townley
> On Feb 20, 2:42 pm, Neil Rieck <n.ri...@sympatico.ca> wrote:
>
> Declaring it as EXTERNAL STRING FUNCTION DT_STAMP() is not a hack.
> That's exactly the correct declaration for a function which takes no
> parameters. It's been that way for longer than I can remember, so I
> would not be worried about it changing at any future date.
>
Decalring an external function or sub without parameter list means the
compiler will not check paramters at all. Likewise not declaring a sub
will mean nocmopile time parameter checking - just run time errors.
I inherited a vast codebase that did that, and have been slowly
tightening it up as I am in there.
For system services, Library routines etc, I now include the relevant
modules from BASIC$STARLET
On a related note I found what would seem to be a bug in both Aklpha &
Integrity, in that it doesnt object to a missing END IF - so for
example the following compiles. Not sure what happens at run-time...
program bug$main
option type = explicit
declare long test1, test2
test1 = -1%
test2 = 0%
if test1
then
if test2
then
print "Both True"
else
print "True, False"
! Missing end if
else
print "False..."
end if
end program
--
Chris
FrankS
> Decalring an external function or sub without parameter list means the
> compiler will not check paramters at all. Likewise not declaring a sub
> will mean nocmopile time parameter checking - just run time errors.
>
You quoted me, which suggests you're replying to my post, yet both Tim
Sneddon and I already pointed this out in earlier posts.
> On a related note I found what would seem to be a bug in both Aklpha &
> Integrity, in that it doesnt object to a missing END IF - so for
> example the following compiles. Not sure what happens at run-time...
>
The END IF is optional.
IF
Syntax
Conditional:
IF cond-exp THEN {statement} [ELSE {statement...}] [END IF]
Neil Rieck
Then you and I are are on the same page. I have been doing code
cleanup (of programs written by other authors) for years now and my
main steps are these:
1) insert "option/type=explicit" to every program without it
2) moving commonly called modules into well-written external BASIC
functions and subs
3) rely on built-in definitions found in BASIC$STARLET like so:
%include "starlet" %from %library "sys$library:basic$starlet" !
system services
%include "$ssdef" %from %library "sys$library:basic$starlet" ! ss$
%include "$secdef" %from %library "sys$library:basic$starlet" ! sec
$
%include "$syidef" %from %library "sys$library:basic$starlet" ! syi
$
I guess I screwed up in mis-declaring BASIC functions and subs which
have no parameters.
Caveat: there are times when the OpenVMS documentation discs do not
match up with reality. In that case you need to peek directly into
STARLET like so:
http://www3.sympatico.ca/n.rieck/docs/openvms_notes_hacking_starlet.html
NSR