- Community Home
- >
- Servers and Operating Systems
- >
- Operating Systems
- >
- Operating System - OpenVMS
- >
- Re: Possible Alpha BASIC 1.6 compiler problem?
Categories
Company
Local Language
Forums
Discussions
Forums
- Data Protection and Retention
- Entry Storage Systems
- Legacy
- Midrange and Enterprise Storage
- Storage Networking
- HPE Nimble Storage
Discussions
Discussions
Discussions
Forums
Forums
Discussions
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
- BladeSystem Infrastructure and Application Solutions
- Appliance Servers
- Alpha Servers
- BackOffice Products
- Internet Products
- HPE 9000 and HPE e3000 Servers
- Networking
- Netservers
- Secure OS Software for Linux
- Server Management (Insight Manager 7)
- Windows Server 2003
- Operating System - Tru64 Unix
- ProLiant Deployment and Provisioning
- Linux-Based Community / Regional
- Microsoft System Center Integration
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Community
Resources
Forums
Blogs
- Subscribe to RSS Feed
- Mark Topic as New
- Mark Topic as Read
- Float this Topic for Current User
- Bookmark
- Subscribe
- Printer Friendly Page
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО02-20-2010 06:20 AM
тАО02-20-2010 06:20 AM
Possible Alpha BASIC 1.6 compiler problem?
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 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.
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 !
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО02-20-2010 09:46 PM
тАО02-20-2010 09:46 PM
Re: Possible Alpha BASIC 1.6 compiler problem?
The question itself was not clear to me on first reading, but was later clarified in c.o.v.
The key is question #2.
Declaring a function without argument list, allows any argument list.
Declaring a function with an empty argument list, only allows it to be called without argument. If the program does provide an argument it'll get the error:
%BASIC-E-PAREXPFOR, 0 parameters expected for DT_STAMP
This is NOT documented, but seems perfectly natural.
1) Since I was using "option type=explicit" is the compiler at fault?
No, you did not articulate arguments, or the lack thereof, suggesting freedom of choice.
2) should I have declared "dt_stamp" as "dt_stamp()" ?
Yes, if it should not have an argument and you'd like the compiler to ensure that.
3) will using "dt_stamp()" be future-proof?
Yes.
a) the behavior makes sense.
b) there is no active development.
Basic has been in maintenance mode of a decade or more best I can tell.
Like you indicate in c.o.v, maybe an official HP person will give and unofficial answer here. That could happen, but I doubt it.
Cheers,
Hein
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО02-21-2010 01:10 PM
тАО02-21-2010 01:10 PM
Re: Possible Alpha BASIC 1.6 compiler problem?
When you want to report a problem, it's a good idea to post the actual behaviour you're observing, and what you're expecting.
Having done language support for several decades, I can tell you that it's fairly rare (but not impossible) that perceived misbehaviour is a compiler error. Compiler bugs therefore fall into the Carl Sagan category of "extraordinary claims".
Of all the languages available on OpenVMS, C and Basic tend to generate the most "compiler bug" reports, when it's really a misunderstanding of the language. Basic, although it's supposed to be a simple language, does LOTS of extra stuff you probably don't know about. Even the most innocuous statement can generate along sequence of type conversions and apparently extraneous operations. In almost all cases it's necessary to conform to the language definition, but it's not always what the programmer intended.
Next time you find something like this, please strip it down even further. Eliminate all I/O statements (they generate LOTS of code), and examine the output of /LIST/MACHINE to see what the compiler is really doing.
I don't have a Basic compiler, so I can't check, but I'd have thought something like:
1000 option type=explicit
external string function dt_stamp
declare string buff1$, buff2$
buff1$=dt_stamp
buff2$=dt_stamp(buff1$)
end
should show you what the compiler is really doing.
"BASIC compiler did not catch."
Don't expect BASIC to "catch" errors. The language is far more oriented towards "do what I (think you) mean" than "make sure the program is correct". If you want a compiler which keeps you on the straight and narrow, switch to Pascal or Ada.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО02-21-2010 01:22 PM
тАО02-21-2010 01:22 PM
Re: Possible Alpha BASIC 1.6 compiler problem?
To your question, since the external string function "dt_stamp" was declared without a parameter list -AND- I had invoked "option=type=explicit", I mistakenly assumed that the compiler would complain whenever I called this function with parameters. This did not happen which means I eventually encountered a run-time error.
From the feedback on comp.os.vms I think the only way out is to declare a null parameter list like so:
external string function dt_stamp()
and assume it will always be future proof.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО02-21-2010 08:45 PM
тАО02-21-2010 08:45 PM
Re: Possible Alpha BASIC 1.6 compiler problem?
I don't have a Basic compiler, so I can't check, but I'd have thought something like:
--
Then let me take this opportunity to suggest you get an account at eisner.decus.org
The signal-to-noise ration cannot be beat, although the signal count isn't really high these days
-- Rob
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО02-21-2010 11:22 PM
тАО02-21-2010 11:22 PM
Re: Possible Alpha BASIC 1.6 compiler problem?
http://groups.google.com/group/comp.os.vms/browse_thread/thread/50ae37fbba5bc8a0/499391ac94515b99
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО02-22-2010 08:53 AM
тАО02-22-2010 08:53 AM
Re: Possible Alpha BASIC 1.6 compiler problem?
Your explanation is correct, but in fact there is an exceptional case which I believe ought be caught by the compiler and is not.
Given:
! BUG.BAS
external string function external_function( string )
declare string s
s = external_function()
end
function string external_function( string s )
end function s
I 'd expect to get a compiler error about the wrong number of arguments. Instead I get a run-time memory management error.
If I add an argument to the external function:
! BUG2.BAS
external string function external_function( string, string )
declare string s
s = external_function()
end
function string external_function( string s, string s2 )
end function s
I get the expected compiler error:
s = external_function()
............^
%BASIC-E-PAREXPFOR, 2 parameters expected for EXTERNAL_FUNCTION
at line number 5 in file BUG2.BAS;3
I SPR'ed this, but the response interpreted my SPR as complaining about the run-time error, not the failure of the compiler to report the error. My mail explaining this got no response...
Jonathan
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО02-22-2010 09:11 AM
тАО02-22-2010 09:11 AM
Re: Possible Alpha BASIC 1.6 compiler problem?
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО02-22-2010 11:12 AM
тАО02-22-2010 11:12 AM
Re: Possible Alpha BASIC 1.6 compiler problem?
Nope, that makes no difference. I always use type=explicit, I just was trimming the bug code to the minimal code that produced the bug.
AFAIK, type = explicit only affects whether BASIC will assume variable type information, including individual parameters, but not parameter type checking. That is, it checks using the assumed types.
Jonathan
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО02-22-2010 01:32 PM
тАО02-22-2010 01:32 PM