Weirdness with %trimr

5580 pts.
Tags:
IBMi RPGLE
Bear with me on this... When i put the following code in debug, at the line containing the %trimR, hex nulls are injected into the string being checked - about position 100. Seems to be some sort of corruption of the field definition area. Tried redefining the fields - the stringing field is intended to be a varying length, reduced to 128 to make a debug watch work simply. Here's the code: H ** take some input and return details of its pathlike chara d p0return s 7 d dirout s 100 d docout s 100 d dirlen s 7 0 d doclen s 7 0 d stringin s 128 ** d slash s 7 0 d last s like(slash) ** c *ENTRY PLIST c PARM P0return c stringin PARM stringin c parm dirout c parm docout c parm dirlen c parm doclen c /free p0return = *blank ; clear dirout ; clear docout ; clear dirlen ; clear doclen ; if stringin ' ' ; slash = %scan ( '/' : stringin ) ; dow slash *zero ; last = slash ; slash = %scan ( '/' : stringin : last+1 ) ; enddo ; if last > 0 ; // last position +1 is the object name dirlen = last - 1 ; doclen = %len(%trimr(stringin)) ; doclen = doclen - dirlen - 1 ; dirout = %subst( stringin : 1 : last ) ; docout = %subst( stringin : last+ 1: doclen ) ; else ; // no data - error p0return = 'NODATA ' ; endif ; else ; // no data - error p0return = 'NODATA ' ; endif ; return ; (hope this emerges from the editor correctly. does anyone else get this - is the code hopeless? Thanks all

Software/Hardware used:
V7R1m0

Answer Wiki

Thanks. We'll let you know when a new response is added.
Send me notifications when members answer or reply to this question.

REGISTER or login:

Forgot Password?
By submitting you agree to receive email from TechTarget and its partners. If you reside outside of the United States, you consent to having your personal data transferred to and processed in the United States. Privacy

Discuss This Question: 14  Replies

 
There was an error processing your information. Please try again later.
Thanks. We'll let you know when a new response is added.
Send me notifications when members answer or reply to this question.

REGISTER or login:

Forgot Password?
By submitting you agree to receive email from TechTarget and its partners. If you reside outside of the United States, you consent to having your personal data transferred to and processed in the United States. Privacy
  • philpl1jb
    My first question concerns the call.  If you call a program with a field 128 long you must pass it atleast 128 characters and or spaces or a 128 or longer character field.  So what are you passing for stingin and what type is that data.
    50,860 pointsBadges:
    report
  • philpl1jb
    The discussion maybe on the way. Check the input side of stringin Since it's 128 in this program, it must be passed as a value of 128 characters or more.  We often see issues during testing where the value in is too short.
    50,860 pointsBadges:
    report
  • TomLiotta
    What does the calling code look like? What is meant by "the stringing field is intended to be a varying length"? What's the purpose of the stringin PARM statement? I can't think of a purpose in doing it that way. And why not use the strrchr() C library function or the basename and/or dirname Qshell functions? What exactly is this routine supposed to do? I can (more or less) read it okay, but knowing the purpose would help. And the LAST variable apparently isn't initialized which leaves a potential hole. Finally, how can you tell from this code that %trimr() injects nulls? -- Tom
    125,585 pointsBadges:
    report
  • philpl1jb
    tried to answer this twice .. after I answer it again the original answers will suddenly appear -- like magic.    Anyway look at how you are populating the input field  d stringin s 128, it's often the case that errors appear when populating fields longer than 32 characters on the AS/400, especially in test.  You must provide a character value that is at least 128 characters in length.  
    50,860 pointsBadges:
    report
  • TomLiotta
    My previous comment disappeared, so I'll try to remember everything I thought about.   What is the purpose of the routine? I can read the code more or less okay, but a clear description might help.   What does the calling code look like? And what is meant by "the stringin[g] field is intended to be a varying length"? Why isn't it varying here? What's in the calling code?   What is the purpose of the stringin PARM statement? I can't think of a reason for doing it that way, and I have a hard time imagining anything but trouble coming from it.   Why not use the strrchr() C library function or the basename and/or dirname Qshell utilities? Those aren't important for your question, but they might be worth considering.   How did you determine that %trimr() was injecting nulls? (Rather than a combination of debug together with the PARM oddity.)   Tom
    125,585 pointsBadges:
    report
  • TomLiotta
    Sheesh... responding to this is tricky. BTW, ignore my comment about the LAST variable. I've been doing too much work in a couple other languages. And my later comment drops it. -- Tom
    125,585 pointsBadges:
    report
  • Yorkshireman
    Thanks for piling in here, answers all after I'd left for the weekend.   I should have mentioned the calls For testing, STRDBG, call with empty or zero parameters, then EVAL the fields to insert a valid value in the stringin.  What you say is correct of course about parm length, so I'll run up a cmd as per my normal practice. Didn't think I'd need to .   my expectation is that the compiler allocates the 128 byte field regardless of what is passed in, and recall that it is only at the TRIMR instruction that the target field is corrupted.  That suggests that the length TRIMR discovers is being placed in memory (of course it is) but that it is overlaying the memory allocated to a standalone field.  I tried altering the sequence of allocation - same thing. STRINGIN was originally 1024 bytes - correupted at the same position within the field.  reduced length to 128 so that a WATCH placed on the field flags up the change.   - right - off to write the cmd and investigate some more.                
    5,580 pointsBadges:
    report
  • TomLiotta
    Since it's referenced as a PARM field, I don't know what I'd expect the compiler to allocate due to the unusual PARM statement structure. Actually, I wouldn't expect it to allocate anything. It should simply assign a definition to the memory pointed to by the address in the PARM list. If you call with zero parms or empty parms, it's somewhat unpredictable what you'll get. I'm a little surprised you don't get a null pointer error with zero parms. With empty parms, you'll get what ever is in memory, and that will cause trouble. -- Tom
    125,585 pointsBadges:
    report
  • Yorkshireman
    Hmmmm Definitely a Friday afternoon brainfart.   Run from a command, all behaves as intended, so this is a case closed.   However, I am still bemused by the seeming anomoly of the behaviour in debug. Given that the compiler correctly allocates storage for the fields, then i expect  the field stringin to be unsullied from the actions of everything which does not reference it as a target by name or by pointer. Perhaps I'm being too literal minded about this.  !  
    5,580 pointsBadges:
    report
  • Yorkshireman
    Tom, catching up on your note, arrived with mine.   I expect the compiler to see a standalone field and allocate 'x' number of bytes to it, and for it to be unaltered unless I change its content, referencing it either by name, or indirectly via a pointer operation.  If I attempted to, say move  10 bytes to a 5 byte field adjacent, then the compiler doesnt allow the excess to overlay an adjacent field.   Where memory is allocated as a table. array, DS and so on, this may not apply of course.   so starting the program by calling with empty parms will initialise all the allocated memory, and EVAL in debug will apply suitable values - surely that is a valid requirement of debug. Enquiring minds need to know, though, so I'll dig around some more via RDP, which has only recently arrived on site (at last) and isn't quite armwrestled into submission for quick, simple debugging yet. As with so much of what we do, the day job needs the code to be installed, and time goes by... I quite take your point about the parms - indeed the parms on this fragment are not the ones needed for it when in service)
    5,580 pointsBadges:
    report
  • philpl1jb
    I expect the compiler to see a standalone field and allocate ‘x’ number of bytes,  Stand alone fields yes, but not passed parameters.  Here it receives an address from the calling program and uses the number of bytes required from that point forward.  If the calling program passes a shorter field then the called program needs the additional bytes maybe part of the next variable or other stuff in your memory area.
    50,860 pointsBadges:
    report
  • TomLiotta
    This parm variable isn't allocated in the called program; it's allocated in the calling program. The called program only supplies a definition, not an allocation. If the called program modifies the variable, the change happens in the memory of the calling program. The parm is a 'by reference' variable. -- Tom
    125,585 pointsBadges:
    report
  • Yorkshireman
    Yes of course that all makes sense, the missing link being that the system makes the assumption about field length when called direct.  That'll teach me to break the habits of a lifetime about making commands to use for quick tests.  You just forget why you do some stuff!   Thanks guys.   R    
    5,580 pointsBadges:
    report
  • TomLiotta
    The "system makes the assumption" for undeclared arguments on the outside. It needs to store argument values somewhere, so it allocates a default memory area. On the PARM side, the only thing that happens is that instructions that reference a parameter use any supplied definition. It's the developer's responsibility to ensure that the appropriate definition is used over any allocation. BTW, note that this is facilitated (though not totally guaranteed) by using prototypes rather than PARM lists. -- Tom
    125,585 pointsBadges:
    report

Forgot Password

No problem! Submit your e-mail address below. We'll send you an e-mail containing your password.

Your password has been sent to:

To follow this tag...

There was an error processing your information. Please try again later.

REGISTER or login:

Forgot Password?
By submitting you agree to receive email from TechTarget and its partners. If you reside outside of the United States, you consent to having your personal data transferred to and processed in the United States. Privacy

Thanks! We'll email you when relevant content is added and updated.

Following