Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]


Groups > comp.sys.acorn.programmer > #556 > unrolled thread

A$= $ptr% Test

Started bycferris@freeRemoveuk.com.invalid
First post2011-07-14 09:02 +0100
Last post2011-07-14 15:32 +0100
Articles 12 — 7 participants

Back to article view | Back to comp.sys.acorn.programmer


Contents

  A$= $ptr% Test cferris@freeRemoveuk.com.invalid - 2011-07-14 09:02 +0100
    Re: A$= $ptr% Test Steve Drain <steve@kappa.me.uk> - 2011-07-14 11:19 +0100
      Re: A$= $ptr% Test cferris@freeRemoveuk.com.invalid - 2011-07-14 12:57 +0100
        Re: A$= $ptr% Test Paul Sprangers <Paul@sprie.nl> - 2011-07-14 14:14 +0200
          Re: A$= $ptr% Test "Ste (news)" <steve@revi11.plus.com> - 2011-07-14 13:46 +0100
        Re: A$= $ptr% Test Gazza <usenet@garethlock.com> - 2011-08-14 04:54 -0700
          Re: A$= $ptr% Test Martin <News03@avisoft.f9.co.uk> - 2011-08-14 15:34 +0100
            Re: A$= $ptr% Test Gazza <usenet@garethlock.com> - 2011-08-14 08:39 -0700
              Re: A$= $ptr% Test Gazza <usenet@garethlock.com> - 2011-08-14 17:11 -0700
                Re: A$= $ptr% Test Steve Drain <steve@kappa.me.uk> - 2011-08-15 12:30 +0100
    Re: A$= $ptr% Test Martin Wuerthner <spamtrap@mw-software.com> - 2011-07-14 13:16 +0200
    Re: A$= $ptr% Test Martin <News03@avisoft.f9.co.uk> - 2011-07-14 15:32 +0100

#556 — A$= $ptr% Test

Fromcferris@freeRemoveuk.com.invalid
Date2011-07-14 09:02 +0100
SubjectA$= $ptr% Test
Message-ID<ecf590f251.cferris@cferris.freeuk.com>
With ref to 'A$ = $Ptr%'

Is there anyway of test before using this to make sure - it is not
trying to work with rubish information?

Thanks
-- 
Colin Ferris Cornwall UK

[toc] | [next] | [standalone]


#557

FromSteve Drain <steve@kappa.me.uk>
Date2011-07-14 11:19 +0100
Message-ID<xpzTp.30253$Ll1.2098@newsfe24.ams2>
In reply to#556
cferris wrote:
> With ref to 'A$ = $Ptr%'
>
> Is there anyway of test before using this to make sure - it is not
> trying to work with rubish information?

I think this question needs more background.

The indirection operator '$' works with whatever is stored at Ptr%, but 
remember it reads a string up to the first carriage return (&0D) only. 
If the string of printable characters you are expecting is not there 
then you may get control characters in your A$ which can have all sorts 
of effects when it is printed. If you are trying to read a string 
terminated by NULL (0) or LF (&0A) from a SWI, for instance, A$ may 
start with the printable characters, but can be followed by control 
characters that make the printed output look like rubbish.

I think the answer is: know how your buffer, at Ptr%, is terminated 
before you read from it; '$' may not be the right method.

Refer back to recent threads about reading SWI buffers for some help.

Steve

[toc] | [prev] | [next] | [standalone]


#559

Fromcferris@freeRemoveuk.com.invalid
Date2011-07-14 12:57 +0100
Message-ID<786aa6f251.cferris@cferris.freeuk.com>
In reply to#557
In message <xpzTp.30253$Ll1.2098@newsfe24.ams2>
          Steve Drain <steve@kappa.me.uk> wrote:

> cferris wrote:
> > With ref to 'A$ = $Ptr%'
> >
> > Is there anyway of test before using this to make sure - it is not
> > trying to work with rubish information?
[snip[

> A$ may start with the printable characters, but can be followed by
> control  characters that make the printed output look like rubbish.
> 

On the Iyonix using 'Reporter' with '*ReportLogOn' enabled the final
moments of the program/lockup - a =USRN% is called. Then 'ReportLogEnd'
then a few lines (different each try) and then rubbish.

So trying to backtrace the USR - replaced the small bit of ARM code with
BASIC.

Put in *report $Ptr%
the output on the RPC looks ok except there are some lines of what
looks like Rubbish.

So thought to use the following :-

From another prog :-
**********
DEF FNmGetString(ptr%)
LOCAL i%,n$   :REM Init i% n$

WHILE (ptr%?i%>=32) AND (i%<255)

  n$+=CHR$ (ptr%?i%)
  i%+=1

ENDWHILE
=n$

Hope this makes some sense.
-- 
Colin Ferris Cornwall UK

[toc] | [prev] | [next] | [standalone]


#560

FromPaul Sprangers <Paul@sprie.nl>
Date2011-07-14 14:14 +0200
Message-ID<51f2a80224Paul@sprie.nl>
In reply to#559
In article <786aa6f251.cferris@cferris.freeuk.com>,
   <cferris@freeRemoveuk.com.invalid> wrote:


> WHILE (ptr%?i%>=32) AND (i%<255)
>   n$+=CHR$ (ptr%?i%)

Apart from skipping the control characters (0 - 31), you should perhaps
also filter out 127 (the delete-character).
Thus:

WHILE (ptr%?i%>=32) AND (ptr%?i% <> 127) AND (i%<255)
etc.

Normally, ASC127 doesn't slip easily into a string, but if there are
reasons for expecting rubbish, as you say, you better be sure.

Kind regards,
Paul Sprangers

[toc] | [prev] | [next] | [standalone]


#561

From"Ste (news)" <steve@revi11.plus.com>
Date2011-07-14 13:46 +0100
Message-ID<51f2aaf6b4steve@revi11.plus.com>
In reply to#560
In article <51f2a80224Paul@sprie.nl>,
   Paul Sprangers <Paul@sprie.nl> wrote:
> In article <786aa6f251.cferris@cferris.freeuk.com>,
>    <cferris@freeRemoveuk.com.invalid> wrote:
>
> > WHILE (ptr%?i%>=32) AND (i%<255)
> >   n$+=CHR$ (ptr%?i%)
>
> Apart from skipping the control characters (0 - 31), you should perhaps
> also filter out 127 (the delete-character).
> Thus:
>
> WHILE (ptr%?i%>=32) AND (ptr%?i% <> 127) AND (i%<255)
> etc.
>
> Normally, ASC127 doesn't slip easily into a string, but if there are
> reasons for expecting rubbish, as you say, you better be sure.

Always, _always_ check ptr%<>0 before doing anything else...

Steve

-- 
Steve Revill @ Home
Note: All opinions expressed herein are my own.

[toc] | [prev] | [next] | [standalone]


#617

FromGazza <usenet@garethlock.com>
Date2011-08-14 04:54 -0700
Message-ID<7c10654e-6e0d-41df-952a-d5185b831cae@t7g2000vbv.googlegroups.com>
In reply to#559
On Jul 14, 12:57 pm, cfer...@freeRemoveuk.com.invalid wrote:
> So thought to use the following :-
>
> From another prog :-
> **********
> DEF FNmGetString(ptr%)
> LOCAL i%,n$   :REM Init i% n$
>
> WHILE (ptr%?i%>=32) AND (i%<255)
>
>   n$+=CHR$ (ptr%?i%)
>   i%+=1
>
> ENDWHILE
> =n$
>
> Hope this makes some sense.
> --
> Colin Ferris Cornwall UK

Another routine where you can specify what the terminator you're
looking for is...

DEFFNstring_from_buffer(buff%,trm%)
 LOCAL i%,out$:out$=""
 FOR i%=0 TO 254
  IF buff%?i%<>trm% THEN
   IF buff%?i%>=32 AND buff%?i%<>127 THEN out$+=CHR$(buff%?i%)
  ENDIF
 NEXT
=out$

Form what I understand, this does exactly the same job in this context
as the $ operator, but with the advantage that it will work with any
terminator. You just pass the ASCII code of the terminator you're
expecting as the second parameter.

[toc] | [prev] | [next] | [standalone]


#623

FromMartin <News03@avisoft.f9.co.uk>
Date2011-08-14 15:34 +0100
Message-ID<5202abc059News03@avisoft.f9.co.uk>
In reply to#617
On 14 Aug, in article
<7c10654e-6e0d-41df-952a-d5185b831cae@t7g2000vbv.googlegroups.com>,
   Gazza <usenet@garethlock.com> wrote:

> Another routine where you can specify what the terminator you're
> looking for is...

> DEFFNstring_from_buffer(buff%,trm%)
>  LOCAL i%,out$:out$=""
>  FOR i%=0 TO 254
>   IF buff%?i%<>trm% THEN
>    IF buff%?i%>=32 AND buff%?i%<>127 THEN out$+=CHR$(buff%?i%)
>   ENDIF
>  NEXT
> =out$

> Form what I understand, this does exactly the same job in this context
> as the $ operator, but with the advantage that it will work with any
> terminator.

No, that is not correct. Your routine ONLY includes in the string any
codes above 32, excluding 127.

I believe =$var%  will include ANY character apart from 13, which
terminates the string.

Martin

-- 
Martin Avison 
Note that unfortunately this email address will become invalid
without notice if (when) any spam is received. 

[toc] | [prev] | [next] | [standalone]


#625

FromGazza <usenet@garethlock.com>
Date2011-08-14 08:39 -0700
Message-ID<b2a1318e-2978-4cce-b755-a5390cf03afc@y24g2000yqb.googlegroups.com>
In reply to#623
On Aug 14, 3:34 pm, Martin <New...@avisoft.f9.co.uk> wrote:
> On 14 Aug, in article
> <7c10654e-6e0d-41df-952a-d5185b831...@t7g2000vbv.googlegroups.com>,
>    Gazza <use...@garethlock.com> wrote:
>
> > Form what I understand, this does exactly the same job in this context
> > as the $ operator, but with the advantage that it will work with any
> > terminator.
>
> No, that is not correct. Your routine ONLY includes in the string any
> codes above 32, excluding 127.
>
> I believe =$var%  will include ANY character apart from 13, which
> terminates the string.
>
> Martin
>

Stuff on csap is indeed not tested, all I was doing was providing a
slightly improved version of what I saw in Steve's post...
I could reduce it to this...

DEFFNbuff_to_string(buff%,trm%)
 LOCAL ptr%,out$
 WHILE (buff%?ptr%>=32) AND (buff%?ptr%<>127) AND (buff%?ptr%<>trm%)
AND (ptr%<255)
  out$=CHR$(buff%?ptr%):ptr%+=1
 ENDWHILE
=out$

... Of course this could be classed as un-safe as you're not checking
to see if you've passed the end of the buffer. But then it's not that
easy to deal with that unless you're using some sort of heap manager
to allocate the buffer in the first place.

[toc] | [prev] | [next] | [standalone]


#631

FromGazza <usenet@garethlock.com>
Date2011-08-14 17:11 -0700
Message-ID<56ed3b09-f864-4e0c-aded-5b33c74ed6f6@h7g2000yqm.googlegroups.com>
In reply to#625
On Aug 14, 4:39 pm, Gazza <use...@garethlock.com> wrote:
> On Aug 14, 3:34 pm, Martin <New...@avisoft.f9.co.uk> wrote:
>
>
>
>
>
> > On 14 Aug, in article
> > <7c10654e-6e0d-41df-952a-d5185b831...@t7g2000vbv.googlegroups.com>,
> >    Gazza <use...@garethlock.com> wrote:
>
> > > Form what I understand, this does exactly the same job in this context
> > > as the $ operator, but with the advantage that it will work with any
> > > terminator.
>
> > No, that is not correct. Your routine ONLY includes in the string any
> > codes above 32, excluding 127.
>
> > I believe =$var%  will include ANY character apart from 13, which
> > terminates the string.
>
> > Martin
>
> DEFFNbuff_to_string(buff%,trm%)
>  LOCAL ptr%,out$
>  WHILE (buff%?ptr%>=32) AND (buff%?ptr%<>127) AND (buff%?ptr%<>trm%)
> AND (ptr%<255)
>   out$=CHR$(buff%?ptr%):ptr%+=1
>  ENDWHILE
> =out$
>
Just correcting a bug in my own code...

out$=CHR$(buff%?ptr%):ptr%+=1

... should of course read...

out$+=CHR$(buff%?ptr%):ptr%+=1

Like others have said, code provided on csap is largely AS IS,
untested.

[toc] | [prev] | [next] | [standalone]


#634

FromSteve Drain <steve@kappa.me.uk>
Date2011-08-15 12:30 +0100
Message-ID<8s72q.180632$fl.117926@newsfe23.ams2>
In reply to#631
On 15/08/2011 01:11, Gazza wrote:
> On Aug 14, 4:39 pm, Gazza<use...@garethlock.com>  wrote:
>> DEFFNbuff_to_string(buff%,trm%)
>>   LOCAL ptr%,out$
>>   WHILE (buff%?ptr%>=32) AND (buff%?ptr%<>127) AND (buff%?ptr%<>trm%)
>> AND (ptr%<255)
>>    out$=CHR$(buff%?ptr%):ptr%+=1
>>   ENDWHILE
>> =out$
>>
> Just correcting a bug in my own code...
>
> out$=CHR$(buff%?ptr%):ptr%+=1
>
> ... should of course read...
>
> out$+=CHR$(buff%?ptr%):ptr%+=1
>
> Like others have said, code provided on csap is largely AS IS,
> untested.

Hmm. I think we should always /try/ to test what we post, but I will 
admit to incomplete testing and to transcription mistakes, as you have made.

This post is to point out how inefficient it is to build a string by 
concatenating single characters. This makes BASIC copy the whole of the 
string to the string accumulator and then back each time. Far better to 
use a temporary buffer and copy bytes.

Temporary buffers have been much discussed in the past, but this 
(almost) works to get a string from an arbitrarily terminated buffer:

  DEFFNbuff_to_string(buff%,term%)
   LOCAL temp%,i%
   temp%=END
   FOR i%=0 TO 254
    IF buff%?i%=term% THEN
     temp%?i%=13
     =$temp%
    ELSE
     temp%?i%=buff%?i%
    ENDIF
   NEXT i%
   temp%?i%=13
  =$temp%

Note that this will not work if the string actually contains a CR. If 
that matters, then you are forced to use strings, but it is still not 
necessary to concatenate single characters:

  DEFFNbuff_to_string(buff%,term%)
   LOCAL temp$,i%
   temp$=STRING$(255," ")
   FOR i%=0 TO 254
    IF buff%?i%=term% THEN
     =LEFT$(temp$,i%)
    ELSE
     MID$(temp$,i%+1)=CHR$buff%?i%
    ENDIF
   NEXT i%
  =temp$

Tested, but not exhaustively. ;-)

[toc] | [prev] | [next] | [standalone]


#558

FromMartin Wuerthner <spamtrap@mw-software.com>
Date2011-07-14 13:16 +0200
Message-ID<e5a4a2f251.martin@bach.planiverse.com>
In reply to#556
In message <ecf590f251.cferris@cferris.freeuk.com>
          cferris@freeRemoveuk.com.invalid wrote:

> With ref to 'A$ = $Ptr%'

> Is there anyway of test before using this to make sure - it is not
> trying to work with rubish information?

The meaning of "rubbish" depends very much on where you got Ptr% from 
and what you expect to find at Ptr%, so this question cannot really be 
answered without a bit more context.

-- 
Martin
---------------------------------------------------------------------
Martin Wuerthner         MW Software      http://www.mw-software.com/
        RISC OS Software for Design, Printing and Publishing
---------------------------------------------------------------------

[toc] | [prev] | [next] | [standalone]


#563

FromMartin <News03@avisoft.f9.co.uk>
Date2011-07-14 15:32 +0100
Message-ID<51f2b4a922News03@avisoft.f9.co.uk>
In reply to#556
On 14 Jul, in article <ecf590f251.cferris@cferris.freeuk.com>,
   <cferris@freeRemoveuk.com.invalid> wrote:
> With ref to 'A$ = $Ptr%'

> Is there anyway of test before using this to make sure - it is not
> trying to work with rubish information?

Not sure what you are asking. The statement WILL work with whatever you
give it (assuming ptr% is a valid pointer to accessible memory), and read
a string from ptr% to the first &D, whatever is in that string.

For example, with !Reporter running, the little program
    10 : ptr% = PAGE+1:REM test
    20 : A$ = $ptr%
    30 : *Report ~ptr% A$

will show in the Reporter window

~ptr%=&8F01 A$="[00][0A][13]ptr%=+1:ô test"

which is just what the 'string' is at ptr%. The [] enclose unprintable
hex.

If you need the string to be all normal characters, then either you need
to be careful when the string is written, of validate it when you read it.

Martin

-- 
Martin Avison 
Note that unfortunately this email address will become invalid
without notice if (when) any spam is received. 

[toc] | [prev] | [standalone]


Back to top | Article view | comp.sys.acorn.programmer


csiph-web