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

Groups > comp.lang.forth > #15314 > unrolled thread

Buffer access with bounds checking...

Back to article view | Back to comp.lang.forth

Contents

  Buffer access with bounds checking... Mark Wills <markrobertwills@yahoo.co.uk> - 2012-08-31 06:51 -0700
    Re: Buffer access with bounds checking... Andrew Haley <andrew29@littlepinkcloud.invalid> - 2012-08-31 11:04 -0500
    Re: Buffer access with bounds checking... Alex McDonald <blog@rivadpm.com> - 2012-08-31 09:20 -0700
      Re: Buffer access with bounds checking... Mark Wills <markrobertwills@yahoo.co.uk> - 2012-08-31 12:57 -0700
        Re: Buffer access with bounds checking... "Rod Pemberton" <do_not_have@notemailnot.cmm> - 2012-08-31 18:46 -0400
          Re: Buffer access with bounds checking... Andrew Haley <andrew29@littlepinkcloud.invalid> - 2012-09-01 04:05 -0500
            Re: Buffer access with bounds checking... "Rod Pemberton" <do_not_have@notemailnot.cmm> - 2012-09-01 13:45 -0400
              Re: Buffer access with bounds checking... Andrew Haley <andrew29@littlepinkcloud.invalid> - 2012-09-02 04:19 -0500
                Re: Buffer access with bounds checking... "Rod Pemberton" <do_not_have@notemailnot.cmm> - 2012-09-02 16:15 -0400
                  Re: Buffer access with bounds checking... Andrew Haley <andrew29@littlepinkcloud.invalid> - 2012-09-04 12:02 -0500
    Re: Buffer access with bounds checking... Doug Hoffman <glidedog@gmail.com> - 2012-08-31 14:15 -0400
      Re: Buffer access with bounds checking... Mark Wills <markrobertwills@yahoo.co.uk> - 2012-08-31 12:56 -0700
      Re: Buffer access with bounds checking... Paul Rubin <no.email@nospam.invalid> - 2012-08-31 13:32 -0700
        Re: Buffer access with bounds checking... Doug Hoffman <glidedog@gmail.com> - 2012-08-31 17:45 -0400
          Re: Buffer access with bounds checking... Paul Rubin <no.email@nospam.invalid> - 2012-08-31 15:07 -0700
            Re: Buffer access with bounds checking... Mark Wills <forthfreak@gmail.com> - 2012-09-01 00:49 -0700
              Re: Buffer access with bounds checking... Paul Rubin <no.email@nospam.invalid> - 2012-09-01 14:06 -0700
                Re: Buffer access with bounds checking... Andrew Haley <andrew29@littlepinkcloud.invalid> - 2012-09-02 04:21 -0500
                Re: Buffer access with bounds checking... anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2012-09-02 10:27 +0000
            Re: Buffer access with bounds checking... Doug Hoffman <glidedog@gmail.com> - 2012-09-01 06:59 -0400
    Re: Buffer access with bounds checking... humptydumpty <ouatubi@gmail.com> - 2012-08-31 14:21 -0700
    Re: Buffer access with bounds checking... "Rod Pemberton" <do_not_have@notemailnot.cmm> - 2012-08-31 18:48 -0400
    Re: Buffer access with bounds checking... Bernd Paysan <bernd.paysan@gmx.de> - 2012-09-01 01:41 +0200
      Re: Buffer access with bounds checking... Bernd Paysan <bernd.paysan@gmx.de> - 2012-09-01 02:37 +0200
      Re: Buffer access with bounds checking... mhx@iae.nl (Marcel Hendrix) - 2012-09-01 11:11 +0200

Page 1 of 2  [1] 2  Next page →

#15314 — Buffer access with bounds checking...

While writing about memory buffer overruns in a different thread
earlier today, I was inspired to have a bash at writing some
code that would allow safe read/write access to memory buffers.

I came up with the code and wonder if it could be simplified or
improved any.

It's very simple. When a buffer is created, the first four cells
are reserved for the following:
* The pfa of the buffer (i'll explain in a minute)
* The size of the buffer in bytes
* The lowest legally accessible address
* The highest legally accessible address

It's possible to compute the last two items on the fly of
course, but I chose to do the math once and store the computed
result, rather than compute it on each buffer access, for
performance reasons.

The pfa of the buffer is stored so that accesses to the *same*
buffer can be detected, thus the buffer management variables
do not have to be re-computed.

I think the code below is portable (gave it a quick spin in
MINOS and it ran fine (disclaimer: my system doesn't have
CELLS+)

It struck me after writing it that if one used an offset to
reference a buffers' contents rather than an absolute address
then the code could be simplified somewhat.

-------------------------

variable _bufPfa
variable _bufSize
variable _lowBound
variable _topBound

: cells+ compile cells compile + ; immediate

: buffer ( int: size "name" --    children: -- address)
  create here ,         \ compile pfa
  dup dup ,             \ compile buffer size
  here 2 cells+ ,       \ pre-computed lower bound
  here 1 cells+ + 1- ,  \ pre-computed upper bound
  allot
  does>
  dup @ _bufPfa @ <> if
    dup @ _bufPfa !
    dup 1 cells+ @ _bufSize !
    dup 2 cells+ @ _lowBound !
    dup 3 cells+ @ _topBound !
  then
  4 cells+ ;

: sizeOf ( buffer -- u)
  \ report size of buffer
  drop _bufSize @ ;

: <>bounds ( address -- address flag)
  \ check if address is within buffer bounds
  dup dup  _lowBound @ >=  swap  _topBound @ <=  AND ;

: b@ ( address -- u)
  \ fetch a cell from the buffer address
  <>bounds if @ else true abort" Out of bounds in B@" then ;

: b! ( u address -- )
  \ write a cell to the buffer address
  <>bounds if ! else true abort" Out of bounds in B!" then ;

: bc@ ( address -- u)
  \ fetch a char from the buffer address
  <>bounds if c@ else true abort" Out of bounds in BC@" then ;

: bc! ( u address -- )
  \ write a char to the buffer address
  <>bounds if c! else true abort" Out of bounds in BC!" then ;

-------------------------
Tests:

100 buffer fred
: test
  fred dup sizeOf 0 do
    i  over i + bc!
  loop drop ;

999 fred 50 + b!
fred 50 + b@ .
999 ok

fred 104 + bc@ .
Out of bounds in BC@

[toc] | [next] | [standalone]

#15316

Mark Wills <markrobertwills@yahoo.co.uk> wrote:
> While writing about memory buffer overruns in a different thread
> earlier today, I was inspired to have a bash at writing some
> code that would allow safe read/write access to memory buffers.
> 
> I came up with the code and wonder if it could be simplified or
> improved any.
> 
> It's very simple. When a buffer is created, the first four cells
> are reserved for the following:
> * The pfa of the buffer (i'll explain in a minute)
> * The size of the buffer in bytes
> * The lowest legally accessible address
> * The highest legally accessible address
> 
> It's possible to compute the last two items on the fly of
> course, but I chose to do the math once and store the computed
> result, rather than compute it on each buffer access, for
> performance reasons.
> 
> The pfa of the buffer is stored so that accesses to the *same*
> buffer can be detected, thus the buffer management variables
> do not have to be re-computed.
> 
> I think the code below is portable (gave it a quick spin in
> MINOS and it ran fine (disclaimer: my system doesn't have
> CELLS+)
> 
> It struck me after writing it that if one used an offset to
> reference a buffers' contents rather than an absolute address
> then the code could be simplified somewhat.

Indeed, then all that b@ and b! have to do is check the bounds and
then do the right thing.

So:

: buffer ( size -)   create dup 1- , allot ;

88 constant bounds-error

: index ( buffer offset - a)
   over @  over u<  bounds-error and throw 
   cell+ + ;

: b@ ( buffer offset - x)   index @ ;

... etc.
   
Andrew.

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

#15318

On Aug 31, 2:51 pm, Mark Wills <markrobertwi...@yahoo.co.uk> wrote:
> While writing about memory buffer overruns in a different thread
> earlier today, I was inspired to have a bash at writing some
> code that would allow safe read/write access to memory buffers.
>
> I came up with the code and wonder if it could be simplified or
> improved any.
>
> It's very simple. When a buffer is created, the first four cells
> are reserved for the following:
> * The pfa of the buffer (i'll explain in a minute)
> * The size of the buffer in bytes
> * The lowest legally accessible address
> * The highest legally accessible address
>
> It's possible to compute the last two items on the fly of
> course, but I chose to do the math once and store the computed
> result, rather than compute it on each buffer access, for
> performance reasons.
>
> The pfa of the buffer is stored so that accesses to the *same*
> buffer can be detected, thus the buffer management variables
> do not have to be re-computed.
>
> I think the code below is portable (gave it a quick spin in
> MINOS and it ran fine (disclaimer: my system doesn't have
> CELLS+)
>
> It struck me after writing it that if one used an offset to
> reference a buffers' contents rather than an absolute address
> then the code could be simplified somewhat.
>
> -------------------------
>
> variable _bufPfa
> variable _bufSize
> variable _lowBound
> variable _topBound
>
> : cells+ compile cells compile + ; immediate
>
> : buffer ( int: size "name" --    children: -- address)
>   create here ,         \ compile pfa
>   dup dup ,             \ compile buffer size
>   here 2 cells+ ,       \ pre-computed lower bound
>   here 1 cells+ + 1- ,  \ pre-computed upper bound
>   allot
>   does>
>   dup @ _bufPfa @ <> if
>     dup @ _bufPfa !
>     dup 1 cells+ @ _bufSize !
>     dup 2 cells+ @ _lowBound !
>     dup 3 cells+ @ _topBound !
>   then
>   4 cells+ ;
>
> : sizeOf ( buffer -- u)
>   \ report size of buffer
>   drop _bufSize @ ;
>
> : <>bounds ( address -- address flag)
>   \ check if address is within buffer bounds
>   dup dup  _lowBound @ >=  swap  _topBound @ <=  AND ;
>
> : b@ ( address -- u)
>   \ fetch a cell from the buffer address
>   <>bounds if @ else true abort" Out of bounds in B@" then ;
>
> : b! ( u address -- )
>   \ write a cell to the buffer address
>   <>bounds if ! else true abort" Out of bounds in B!" then ;
>
> : bc@ ( address -- u)
>   \ fetch a char from the buffer address
>   <>bounds if c@ else true abort" Out of bounds in BC@" then ;
>
> : bc! ( u address -- )
>   \ write a char to the buffer address
>   <>bounds if c! else true abort" Out of bounds in BC!" then ;
>
> -------------------------
> Tests:
>
> 100 buffer fred
> : test
>   fred dup sizeOf 0 do
>     i  over i + bc!
>   loop drop ;
>
> 999 fred 50 + b!
> fred 50 + b@ .
> 999 ok
>
> fred 104 + bc@ .
> Out of bounds in BC@

You might want to reconsider B@ B! and so on; iirc they've been
proposed as byte equivalents of C@ C!.

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

#15329

On Aug 31, 5:20 pm, Alex McDonald <b...@rivadpm.com> wrote:
> On Aug 31, 2:51 pm, Mark Wills <markrobertwi...@yahoo.co.uk> wrote:
>
>
>
>
>
>
>
>
>
> > While writing about memory buffer overruns in a different thread
> > earlier today, I was inspired to have a bash at writing some
> > code that would allow safe read/write access to memory buffers.
>
> > I came up with the code and wonder if it could be simplified or
> > improved any.
>
> > It's very simple. When a buffer is created, the first four cells
> > are reserved for the following:
> > * The pfa of the buffer (i'll explain in a minute)
> > * The size of the buffer in bytes
> > * The lowest legally accessible address
> > * The highest legally accessible address
>
> > It's possible to compute the last two items on the fly of
> > course, but I chose to do the math once and store the computed
> > result, rather than compute it on each buffer access, for
> > performance reasons.
>
> > The pfa of the buffer is stored so that accesses to the *same*
> > buffer can be detected, thus the buffer management variables
> > do not have to be re-computed.
>
> > I think the code below is portable (gave it a quick spin in
> > MINOS and it ran fine (disclaimer: my system doesn't have
> > CELLS+)
>
> > It struck me after writing it that if one used an offset to
> > reference a buffers' contents rather than an absolute address
> > then the code could be simplified somewhat.
>
> > -------------------------
>
> > variable _bufPfa
> > variable _bufSize
> > variable _lowBound
> > variable _topBound
>
> > : cells+ compile cells compile + ; immediate
>
> > : buffer ( int: size "name" --    children: -- address)
> >   create here ,         \ compile pfa
> >   dup dup ,             \ compile buffer size
> >   here 2 cells+ ,       \ pre-computed lower bound
> >   here 1 cells+ + 1- ,  \ pre-computed upper bound
> >   allot
> >   does>
> >   dup @ _bufPfa @ <> if
> >     dup @ _bufPfa !
> >     dup 1 cells+ @ _bufSize !
> >     dup 2 cells+ @ _lowBound !
> >     dup 3 cells+ @ _topBound !
> >   then
> >   4 cells+ ;
>
> > : sizeOf ( buffer -- u)
> >   \ report size of buffer
> >   drop _bufSize @ ;
>
> > : <>bounds ( address -- address flag)
> >   \ check if address is within buffer bounds
> >   dup dup  _lowBound @ >=  swap  _topBound @ <=  AND ;
>
> > : b@ ( address -- u)
> >   \ fetch a cell from the buffer address
> >   <>bounds if @ else true abort" Out of bounds in B@" then ;
>
> > : b! ( u address -- )
> >   \ write a cell to the buffer address
> >   <>bounds if ! else true abort" Out of bounds in B!" then ;
>
> > : bc@ ( address -- u)
> >   \ fetch a char from the buffer address
> >   <>bounds if c@ else true abort" Out of bounds in BC@" then ;
>
> > : bc! ( u address -- )
> >   \ write a char to the buffer address
> >   <>bounds if c! else true abort" Out of bounds in BC!" then ;
>
> > -------------------------
> > Tests:
>
> > 100 buffer fred
> > : test
> >   fred dup sizeOf 0 do
> >     i  over i + bc!
> >   loop drop ;
>
> > 999 fred 50 + b!
> > fred 50 + b@ .
> > 999 ok
>
> > fred 104 + bc@ .
> > Out of bounds in BC@
>
> You might want to reconsider B@ B! and so on; iirc they've been
> proposed as byte equivalents of C@ C!.

Oh no! That's the great "a char is the same as a byte" debate re-
ignited ;-)

For the record: A char is the same as a byte.

I'll get my coat.

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

#15341

"Mark Wills" <markrobertwills@yahoo.co.uk> wrote in message
news:ca821896-0ed0-4314-9e1b-00d8276d7820@r4g2000vbn.googlegroups.com...
[...]

> For the record: A char is the same as a byte.

Is that apparently open-ended claim _just_ for Forth because this is c.l.f.?

Because, if the open-ended claim is for other languages too, like C, then
you're just wrong.  In C, a byte must be the same size as or larger than a
char.  There is a minimum size the char must be in bits too.  C's strings
are terminated by a nul (all bits cleared) byte.  I.e., on a 16-bit word
addressable machine, the terminating sting nul could be 16-bits, while the
characters could be 8-bits or 9-bits etc.  In such a situation, C ignores
those upper bits for a char, but not for the nul.  I.e., C's "nul character"
string terminator is not a character at all, but a C byte.  C doesn't define
a byte as 8-bits per ASCII or EBCDIC.


Rod Pemberton

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

#15357

Rod Pemberton <do_not_have@notemailnot.cmm> wrote:
> "Mark Wills" <markrobertwills@yahoo.co.uk> wrote in message
> news:ca821896-0ed0-4314-9e1b-00d8276d7820@r4g2000vbn.googlegroups.com...
> [...]
> 
>> For the record: A char is the same as a byte.
> 
> Is that apparently open-ended claim _just_ for Forth because this is c.l.f.?
> 
> Because, if the open-ended claim is for other languages too, like C, then
> you're just wrong.  In C, a byte must be the same size as or larger than a
> char.

Eh?  In C a char is the same size as a byte.  The number of bits in a
byte is implementation-dependent.  A char is large enough to store any
member of the basic execution character set.

Andrew.

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

#15369

"Andrew Haley" <andrew29@littlepinkcloud.invalid> wrote in message
news:55OdnX4ccq1aUtzNnZ2dnUVZ8rednZ2d@supernews.com...
> Rod Pemberton <do_not_have@notemailnot.cmm> wrote:
> > "Mark Wills" <markrobertwills@yahoo.co.uk> wrote in message
> > news:ca821896-0ed0-4314-9e1b-00d8276d7820@r4g2000vbn.googlegroups.com...
> > [...]
> >
> >> For the record: A char is the same as a byte.
> >
> > Is that apparently open-ended claim _just_ for Forth because this is
> > c.l.f.?
> >

Actually, Forth-94 doesn't define a byte, but it says Forth-83 defines it as
8-bits.  A C byte is what the Forth specifications call an "address unit".

> > Because, if the open-ended claim is for other languages too, like C,
> > then you're just wrong.  In C, a byte must be the same size as or larger
> > than a char.
>
> Eh?  In C a char is the same size as a byte.

No, it's not.  I just explained it to you.  Read the C specifications some
time.

For C, a char fits into a byte.  A byte is comprised of one or more
addressable units of bits sufficiently large to contain a character.  On
modern 8-bit byte-addressable machines, they are usually implemented as the
same size.

E.g., let's take a 16-bit word addressable machine with 9-bit characters.
In this case, a char in C is 9-bits and C's byte is 16-bits, not 8-bits.
The size for the char returned by sizeof() will be one(1) by definition even
though the char is 9-bits and consumes two 8-bit bytes.  That's because C
defines a byte to a non 8-bit definition.  It defines a byte as the address
unit or units large enough to contain a character.  The null character in C
is a C byte, 16-bits not 9-bits, with all bits cleared.  I.e., 0x0000 would
be a null, but 0xFE00 (lower 9-bits cleared) would not be.  I.e., a null
character is not a character in C but a byte.  The higher bits are ignored
for non-null characters, e.g., 0x004, 0xFE41, 0xA541, etc, would all be an
ASCII 'A'.  Now, if for some reason a C implementation implemented 9-bit
characters on an 8-bit machine word addressable machine, the same would hold
true.  The difference being that then a C byte would be comprised of two
8-bit address units.  The C byte must be large enough to contain the C
character.


Rod Pemberton

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

#15386

Rod Pemberton <do_not_have@notemailnot.cmm> wrote:
> "Andrew Haley" <andrew29@littlepinkcloud.invalid> wrote in message
> news:55OdnX4ccq1aUtzNnZ2dnUVZ8rednZ2d@supernews.com...
>> Rod Pemberton <do_not_have@notemailnot.cmm> wrote:
>> > "Mark Wills" <markrobertwills@yahoo.co.uk> wrote in message
>> > news:ca821896-0ed0-4314-9e1b-00d8276d7820@r4g2000vbn.googlegroups.com...
>> > [...]
>> >
>> >> For the record: A char is the same as a byte.
>> >
>> > Is that apparently open-ended claim _just_ for Forth because this is
>> > c.l.f.?
>> >
> 
> Actually, Forth-94 doesn't define a byte, but it says Forth-83 defines it as
> 8-bits.  A C byte is what the Forth specifications call an "address unit".
> 
>> > Because, if the open-ended claim is for other languages too, like C,
>> > then you're just wrong.  In C, a byte must be the same size as or larger
>> > than a char.
>>
>> Eh?  In C a char is the same size as a byte.
> 
> No, it's not.  I just explained it to you.  Read the C specifications some
> time.
>
> For C, a char fits into a byte. 

No, a _character_ fits into a byte.  chars and characters are not the
same thing.

> A byte is comprised of one or more addressable units of bits
> sufficiently large to contain a character.  On modern 8-bit
> byte-addressable machines, they are usually implemented as the same
> size.
> 
> E.g., let's take a 16-bit word addressable machine with 9-bit characters.
> In this case, a char in C is 9-bits and C's byte is 16-bits, not 8-bits.

No.  A char on such a system is 16 bits.  A character may be 9 bits,
but a char isn't.

> The size for the char returned by sizeof() will be one(1) by
> definition even though the char is 9-bits and consumes two 8-bit
> bytes.

No.  On such a system a byte is 16 bits; there are no 8-bit bytes.

All objects in C can be accessed as arrays of chars.  When you copy
one object to another a char at a time, all of the bits of the object
are copied.  This is a fundamental property of C.

> That's because C defines a byte to a non 8-bit definition.  It
> defines a byte as the address unit or units large enough to contain
> a character.  The null character in C is a C byte, 16-bits not
> 9-bits, with all bits cleared.

Correct.

> I.e., 0x0000 would be a null, but 0xFE00 (lower 9-bits cleared)
> would not be.  I.e., a null character is not a character in C but a
> byte.  The higher bits are ignored for non-null characters, e.g.,
> 0x004, 0xFE41, 0xA541, etc, would all be an ASCII 'A'.

Would 

  char foo = 0xFE41;
  ('A' == foo)

return 1 on such a system?  I don't think so.  The upper bits of a
char are not "ignored".

Andrew.

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

#15395

"Andrew Haley" <andrew29@littlepinkcloud.invalid> wrote in message
news:0fWdnfhfNvUYud7NnZ2dnUVZ7tKdnZ2d@supernews.com...
> Rod Pemberton <do_not_have@notemailnot.cmm> wrote:
> > "Andrew Haley" <andrew29@littlepinkcloud.invalid> wrote in message
> > news:55OdnX4ccq1aUtzNnZ2dnUVZ8rednZ2d@supernews.com...
> >> Rod Pemberton <do_not_have@notemailnot.cmm> wrote:
> >> > "Mark Wills" <markrobertwills@yahoo.co.uk> wrote in message
> >> >
news:ca821896-0ed0-4314-9e1b-00d8276d7820@r4g2000vbn.googlegroups.com...
> >> > [...]
> >> >
> >> >> For the record: A char is the same as a byte.
> >> >
> >> > Is that apparently open-ended claim _just_ for Forth because this is
> >> > c.l.f.?
> >> >
> >
> > Actually, Forth-94 doesn't define a byte, but it says Forth-83 defines
> > it as 8-bits.  A C byte is what the Forth specifications call an
> > "address unit".
> >
> >> > Because, if the open-ended claim is for other languages too, like C,
> >> > then you're just wrong.  In C, a byte must be the same size as or
> >> > larger than a char.
> >>
> >> Eh?  In C a char is the same size as a byte.
> >
> > No, it's not.  I just explained it to you.  Read the C specifications
> > some time.
> >
> > For C, a char fits into a byte.
>
> No, a _character_ fits into a byte.  chars and characters are not the
> same thing.
>

Wrong.  'char' is the C keyword declaring an object to be of type character.

> > A byte is comprised of one or more addressable units of bits
> > sufficiently large to contain a character.  On modern 8-bit
> > byte-addressable machines, they are usually implemented as the same
> > size.
> >
> > E.g., let's take a 16-bit word addressable machine with 9-bit
> > characters.  In this case, a char in C is 9-bits and C's byte is
> > 16-bits, not 8-bits.
>
> No.  A char on such a system is 16 bits.  A character may be 9 bits,
> but a char isn't.
>

Wrong.  That's a byte, not a char.

> > The size for the char returned by sizeof() will be one(1) by
> > definition even though the char is 9-bits and consumes two 8-bit
> > bytes.
>
> No.  On such a system a byte is 16 bits; there are no 8-bit bytes.

I said the C byte is 16-bits.  What you mean is that C doesn't have 8-bit
bytes but has 16-bit bytes.  That's true.  However, the host machine does
have 8-bit bytes, where a C byte of 16-bits consumes two of them.

> All objects in C can be accessed as arrays of chars.  When you copy
> one object to another a char at a time, all of the bits of the object
> are copied.  This is a fundamental property of C.
>

No.  You're _almost_ correct though.

If you replace your use 'char' here with 'byte', you will be.  I.e., all C
objects are arrays of bytes.  I can quote for you the C specification, C
Rationale, Johnson & Ritchie, Douglas Gwyn, etc.  I.e., none mention
'char' while all mention 'byte'.

> > I.e., 0x0000 would be a null, but 0xFE00 (lower 9-bits cleared)
> > would not be.  I.e., a null character is not a character in C but a
> > byte.  The higher bits are ignored for non-null characters, e.g.,
> > 0x004, 0xFE41, 0xA541, etc, would all be an ASCII 'A'.
>
> Would
>
>   char foo = 0xFE41;
>   ('A' == foo)
>
> return 1 on such a system?  I don't think so.  The upper bits of a
> char are not "ignored".

You're confusing what is accessible in the C context with what is outside
it.  Within the C context, you can't set foo equal to 0xFE41.  C's context
only allows 9-bits to be set.  Those upper bits are inaccesable from C.


Rod Pemberton

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

#15455

Rod Pemberton <do_not_have@notemailnot.cmm> wrote:
> "Andrew Haley" <andrew29@littlepinkcloud.invalid> wrote in message
> news:0fWdnfhfNvUYud7NnZ2dnUVZ7tKdnZ2d@supernews.com...
>> All objects in C can be accessed as arrays of chars.  When you copy
>> one object to another a char at a time, all of the bits of the object
>> are copied.  This is a fundamental property of C.
> 
> No.  You're _almost_ correct though.

LOL!  Thank you for your kindness.

> If you replace your use 'char' here with 'byte', you will be.  I.e.,
> all C objects are arrays of bytes.  I can quote for you the C
> specification, C Rationale, Johnson & Ritchie, Douglas Gwyn, etc.
> I.e., none mention 'char' while all mention 'byte'.

And how would you access this array of bytes, if not via a character
type?

>> > I.e., 0x0000 would be a null, but 0xFE00 (lower 9-bits cleared)
>> > would not be.  I.e., a null character is not a character in C but a
>> > byte.  The higher bits are ignored for non-null characters, e.g.,
>> > 0x004, 0xFE41, 0xA541, etc, would all be an ASCII 'A'.
>>
>> Would
>>
>>   char foo = 0xFE41;
>>   ('A' == foo)
>>
>> return 1 on such a system?  I don't think so.  The upper bits of a
>> char are not "ignored".
> 
> You're confusing what is accessible in the C context with what is outside
> it.  Within the C context, you can't set foo equal to 0xFE41.  C's context
> only allows 9-bits to be set.  Those upper bits are inaccesable from C.

Consider this routine:

void memcopy(char *dest, char *src, size_t n) {
  int i;
  for (i = 0; i < n; i++)
    dest[i] = src[i];
}

Used like this:

  some_object a, b;

  ...

  memcopy((char *)&a, (char *)&b, sizeof a);

Are you trying to tell us that this is not portable C?  And if it is
not, how would you go about writing it?

Andrew.

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

#15321

I'm a proponent of error checking during development such as your buffer 
bounds checking.  I zealously use array index checking.  Of course for 
final (debugged/tested) code the checks can be bypassed for efficiency.

-Doug

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

#15328

On Aug 31, 7:15 pm, Doug Hoffman <glide...@gmail.com> wrote:
> I'm a proponent of error checking during development such as your buffer
> bounds checking.  I zealously use array index checking.  Of course for
> final (debugged/tested) code the checks can be bypassed for efficiency.
>
> -Doug

That's a great idea, Doug. Bypassing the checks could be done using
immediate words. For example:

variable checkBounds
true checkBounds !

: bounds checkBounds @ if compile (bounds) then ; immediate


When you're happy that your code is debugged, set checkBounds to false
in the source code and re-compile. Bounds checking won't be compiled
into the program at all.

Regards

Mark

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

#15330

Doug Hoffman <glidedog@gmail.com> writes:
> for final (debugged/tested) code the checks can be bypassed for
> efficiency.

The checks should probably be left in, except in the specific places
where the efficiency hit is really noticable in the overall program
performance, or if there is some other self-checking and program restart
capability in case of something going wrong.

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

#15336

On 8/31/12 4:32 PM, Paul Rubin wrote:
> Doug Hoffman <glidedog@gmail.com> writes:
>> for final (debugged/tested) code the checks can be bypassed for
>> efficiency.
>
> The checks should probably be left in, except in the specific places
> where the efficiency hit is really noticable in the overall program
> performance

Why?

-Doug

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

#15337

Doug Hoffman <glidedog@gmail.com> writes:
>> The checks should probably be left in, except in the specific places
>> where the efficiency hit is really noticable in the overall program
>> performance
>
> Why?

To misquote Kernighan and Plauger from a while back: having the checks
during testing and taking them out for production is like wearing a
parachute on the ground, but taking it off once you're in the air.

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

#15354

On Aug 31, 11:07 pm, Paul Rubin <no.em...@nospam.invalid> wrote:
> Doug Hoffman <glide...@gmail.com> writes:
> >> The checks should probably be left in, except in the specific places
> >> where the efficiency hit is really noticable in the overall program
> >> performance
>
> > Why?
>
> To misquote Kernighan and Plauger from a while back: having the checks
> during testing and taking them out for production is like wearing a
> parachute on the ground, but taking it off once you're in the air.

Why is that? If your program has been properly tested then there
shouldn't be a problem.

The argument you quoted reminded me of an argument we had at work
(well, it wasn't really an *argument*) about detecting buffer over/
under flows in a serial protocol converter. I advocated removing error
checking once the embedded software had been fully tested (when I say
tested I mean tested by test engineers who's full time job it is to
find a way to break your code! Not testing it by the dude that wrote
the code!). The test guys said that buffer overflows should be
trapped, logged, and the system halt. I said "Please prove it is
possible to overrun the serial input and output buffers". I also
argued that a halt was useless - from the users perspective (who would
be some 1800 meters above the embedded device, in the warmth and
dryness of a nice drilling rig) a halt was a crash. It's not like he's
going to send an ROV down to retrieve the device, bring it to the
surface and dump the logs. Best you can is re-start the thing.

Of course, there are situations where that wouldn't be appropriate;
flight systems on aircraft for example. I don't know what the strategy
is with those types of software (I presume they are somewhere at
SIL-3?)... I mean, okay, you've detected a run-time fault, for example
dereferencing null memory. Now what? Trapping the condition only gets
you halfway! I guess all you can do is fail over to the redundant
device (which should be running *different* software) and reset.
That's what we do in the subsea industry - we fail over to the
redundant device - but the devices tend to be identical. Though we're
mostly in the non SIL or SIL-1 territory.

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

#15377

Mark Wills <forthfreak@gmail.com> writes:
> The test guys said that buffer overflows should be
> trapped, logged, and the system halt. I said "Please prove it is
> possible to overrun the serial input and output buffers". 

But that's backwards.  They shouldn't have to prove something is
possible.  If you're asserting the checks should be removed, you are the
one who has to prove overruns are impossible.

> I also argued that a halt was useless - from the users perspective
> (who would be some 1800 meters above the embedded device, in the
> warmth and dryness of a nice drilling rig) a halt was a crash.

If there is a buffer overrun, the result might be much worse than a mere
crash (where the thing stops operating).  It gadget might keep operating
while doing something completely crazy, setting itself on fire,
whatever.

> Best you can is re-start the thing.

Yes.  That sounds better than letting the program keep running into the
weeds.  It's no longer under the programmer's control, so it's better to
shut it off.

> I mean, okay, you've detected a run-time fault, for example
> dereferencing null memory.

If the fault didn't show up during testing, chances are it was caused by
some weird, non-deterministic condition unlikely to repeat.  So log the
error, restart the program, and analyze the log later.

Erlang is written around this idea, that software failures are
inevitable, so there are extensive provisions for recovering from them.
Programs are organized into isolated processes and there is a
supervision tree that restarts crashed ones.

> That's what we do in the subsea industry - we fail over to the
> redundant device - but the devices tend to be identical. Though we're
> mostly in the non SIL or SIL-1 territory.

Yeah, I gather that ultra-critical stuff has backups using completely
different hardware and software developed by separate teams.

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

#15387

Paul Rubin <no.email@nospam.invalid> wrote:
> Mark Wills <forthfreak@gmail.com> writes:
>> The test guys said that buffer overflows should be
>> trapped, logged, and the system halt. I said "Please prove it is
>> possible to overrun the serial input and output buffers". 
> 
> But that's backwards.  They shouldn't have to prove something is
> possible.  If you're asserting the checks should be removed, you are the
> one who has to prove overruns are impossible.
> 
>> I also argued that a halt was useless - from the users perspective
>> (who would be some 1800 meters above the embedded device, in the
>> warmth and dryness of a nice drilling rig) a halt was a crash.
> 
> If there is a buffer overrun, the result might be much worse than a mere
> crash (where the thing stops operating).  It gadget might keep operating
> while doing something completely crazy, setting itself on fire,
> whatever.

How do you know that?

>> Best you can is re-start the thing.
> 
> Yes.  That sounds better than letting the program keep running into the
> weeds.  It's no longer under the programmer's control, so it's better to
> shut it off.

Maybe it isn't.  That depends on the application area.  You can't
possibly know until you know what it's doing.

Andrew.

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

#15389

Paul Rubin <no.email@nospam.invalid> writes:
>Mark Wills <forthfreak@gmail.com> writes:
>> I also argued that a halt was useless - from the users perspective
>> (who would be some 1800 meters above the embedded device, in the
>> warmth and dryness of a nice drilling rig) a halt was a crash.
>
>If there is a buffer overrun, the result might be much worse than a mere
>crash (where the thing stops operating).  It gadget might keep operating
>while doing something completely crazy, setting itself on fire,
>whatever.
...
>Yes.  That sounds better than letting the program keep running into the
>weeds.  It's no longer under the programmer's control, so it's better to
>shut it off.

That thinking blew up the Ariane 5.  It would have been totally safe
to ignore the overflow, but the default was to do something that some
people considered better (IIRC it sent error messages on the
internal bus), probably because it's a better-defined result.

Oh, and the software in the Ariane 5 had been proven to be correct.

>Erlang is written around this idea, that software failures are
>inevitable, so there are extensive provisions for recovering from them.
>Programs are organized into isolated processes and there is a
>supervision tree that restarts crashed ones.

That sounds much more sensible for this kind of stuff than just
stopping.  OTOH, if the failover works well, the bugs never get fixed.

- anton
-- 
M. Anton Ertl  http://www.complang.tuwien.ac.at/anton/home.html
comp.lang.forth FAQs: http://www.complang.tuwien.ac.at/forth/faq/toc.html
     New standard: http://www.forth200x.org/forth200x.html
   EuroForth 2012: http://www.euroforth.org/ef12/

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

#15360

On 8/31/12 6:07 PM, Paul Rubin wrote:
> Doug Hoffman <glidedog@gmail.com> writes:
>>> The checks should probably be left in, except in the specific places
>>> where the efficiency hit is really noticable in the overall program
>>> performance
>>
>> Why?
>
> To misquote Kernighan and Plauger from a while back: having the checks
> during testing and taking them out for production is like wearing a
> parachute on the ground, but taking it off once you're in the air.

As Mark Wills points out, the checks are not fail-safe mechanisms (like 
a parachute).  They are there only to assist writing software that does 
not fail.  The checks are not required even during development. 
Properly debugged and tested programs should not fail, whether or not 
they were developed with bounds/index/message/etc. checks.  Having the 
checks during development can only only reduce possible headaches for 
the programmer.

A check in a production program could at best flag a condition for a 
fail-safe if the debugging/testing was inadequate, but still doesn't 
help the end user.  Creating that fail-safe (or parachute) is another 
topic altogether.  Leaving the checks in *will* give the end user a 
larger and slower program.

-Doug

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

Page 1 of 2  [1] 2  Next page →

Back to top | Article view | comp.lang.forth

csiph-web