Experimental Physics and
Industrial Control System

"Jeff Hill" <[email protected]> · Tue, 14 Jun 2005 16:08:21 -0600

I revised my comments on the wiki as follows.

1) All of the readers here probably already know that I feel that the
unsigned types in C are useful. Well written code range checks operands, and
unsigned operands typically require less range checking. When problems occur
it's because users convert between signed and unsigned types without proper
range checking. Since data access has this range checking built in (after
considerable effort on mine and Ralph's part I will add) then conversion
problems are possibly no longer an issue.

2) You have created interface classes for buffers, arrays, enumerated,
strings etc. All of these interfaces are already in data access. Was there a
good justification to create new ones? In any case, it seems that we should
have the goal of using the same interfaces for each of the fundamental data
types?

3) These interfaces seem to require contiguous storage of random sized
blocks of characters. Doesn't this preclude use of fixed length buffer based
(free list based) memory allocation, and therefore almost guarantee
fragmentation of memory. Note that fragmentation isnt just a binary
condition (memory of a particular size is or isnt available). Fragmentation
is also an efficency isssue because most random sized block memory
allocators require searching for the best sized free block. Note that one of
my goals for V4 is to no longer require EPICS_CA_MAX_ARRAY_BYTES.

-----Original Message-----
From: Jeff Hill [mailto:[email protected]] 
Sent: Tuesday, June 14, 2005 3:44 PM
To: 'Andrew Johnson'; 'EPICS core-talk'
Subject: RE: Fundamental Types document

Here are my comments (I also entered them on the wiki)

1) As we are all already aware I feel that the unsigned types in C are
useful. When problems occur it's because users convert between signed and
unsigned types without proper range checking. Since data access has this
range checking built in (after considerable effort on mine and Ralph's part
I will add) then conversion problems are possibly no longer an issue.

2) You have created interface classes for buffers, arrays, enumerated,
strings etc. All of these interfaces are already in data access. Was there a
good justification to create new ones? In any case, it seems that we should
the goal of using the same interfaces for each type of commonly used data.

3) These interfaces seem to require contiguous storage of random sized
blocks of characters. Doesn't this preclude use of fixed length buffer based
(free list based) memory allocation, and therefore almost guarantee
fragmentation of memory.

Jeff

-----Original Message-----
From: Andrew Johnson [mailto:[email protected]] 
Sent: Tuesday, June 14, 2005 2:52 PM
To: EPICS core-talk
Subject: Fundamental Types document

Marty and I would appreciate feedback and comments on the following Wiki 
document, which defines the fundamental types we want to provide and use 
inside iocCore.

http://www.aps.anl.gov/epics/wiki/index.php/V4_Design:_epicsTypes

- Andrew
-- 
Podiabombastic: The tendency to shoot oneself in the foot.

Experimental Physics and Industrial Control System

Experimental Physics and
Industrial Control System