HP3000-L Archives

April 2005, Week 3

HP3000-L@RAVEN.UTC.EDU

Options: Use Monospaced Font
Show Text Part by Default
Show All Mail Headers

Message: [<< First] [< Prev] [Next >] [Last >>]
Topic: [<< First] [< Prev] [Next >] [Last >>]
Author: [<< First] [< Prev] [Next >] [Last >>]

Print Reply
Subject:
From:
Rich Trapp <[log in to unmask]>
Reply To:
Rich Trapp <[log in to unmask]>
Date:
Fri, 15 Apr 2005 08:43:35 -0600
Content-Type:
text/plain
Parts/Attachments:
text/plain (117 lines)
Peter,

</At least I'm not bitter/former HPRCE ALERT ON>

   There's nothing more fun in the life of a <insert 3GL of choice here>
support person than trying to convince a programmer whose ego depends on
how great his code is that they've been getting really lucky for the
last <insert long time span here> because they really never initialized
a variable and it just happened to be zero before.

</Alert OFF>

But seriously :)

    There is a ;ZERODB option on the :PREP command that would do a
decent job of initializing to zero everything in DB that hadn't been
expressly initialized on it's definition.  Of course that doesn't apply
to local variables in procedures since they're Q-relative as I recall.
Using the ;ZERODB option fixed many "bugs in the new version of MPE"
that appeared mysteriously (in their programs) after an upgrade.

 
(sorry...I get cranky before coffee)

Happy Tax Day (US)

RAT


Rich Trapp
Technical Solutions Architect
Managed Business Solutions

970.494.4980
http://www.mbshome.com
 
CONFIDENTIALITY NOTICE: The information in this email and subsequent
attachments is intended solely for the person or entity to which it is
addressed and may contain confidential and/or privileged information.
Any review, dissemination, copying, printing or other use of this e-mail
by persons or entities other than the addressee is prohibited. If you
have received this e-mail in error, please contact the sender
immediately and delete the material from your computer. 

-----Original Message-----
From: HP-3000 Systems Discussion [mailto:[log in to unmask]] On
Behalf Of Peter Smithson
Sent: Friday, April 15, 2005 7:48 AM
To: [log in to unmask]
Subject: SPL - intialising variables (again)

Hi,

I know everyone was very clear that they don't get initialised.  I think
that either this customer was very lucky that his code worked or maybe
there's a different rule for arrays?  Last time they were assuming an
INTEGER was zero but this time I've got -

PROCEDURE blah
...
BEGIN
INTEGER ARRAY
...
    ,DATA'SEG        (0:LAST'INDEX)
   ,MASK'CONT       (*)=DATA'SEG(MASK'CONTENTS)
   ,MASK'LEN        (*)=MASK'CONT(1)
...
IF MASK'CONT <> 0 THEN

I think that's bad as I can't see how MASK'CONT got set (well, it's set
to
an element of DATA'SEG but that's not set either).

In C I'd understand that to be

int
...
   ,DATA_SEG        [LAST_INDEX+1]
   ,*MASK_CONT = &DATA_SEG[MASK_CONTENTS]
   ,*MASK_LEN = &MASK_CONT[1]
...
if (*MASK_CONT != 0)


Is that an accurate translation?  The only reason I can think that the
original SPL code is valid is that -

1) Local arrays are initialised.  (which I doubt given that other local
variables are not)
2) The line ",MASK'LEN        (*)=MASK'CONT(1)" has some other meaning
than
I understand.
3) It's not valid - they've just been lucky.

I get these kind of problems all the time porting C code as
uninitialised
data often only shows up on another compiler/platform.  I suppose with
SPL
code, it's never been moved around much so now that it's been translated
to
C, these kind of issues are coming out.

Cheers

Peter



--
http://www.beluga.freeserve.co.uk

* To join/leave the list, search archives, change list settings, *
* etc., please visit http://raven.utc.edu/archives/hp3000-l.html *

* To join/leave the list, search archives, change list settings, *
* etc., please visit http://raven.utc.edu/archives/hp3000-l.html *

ATOM RSS1 RSS2