EPICS Controls Argonne National Laboratory

Experimental Physics and
Industrial Control System

1994  1995  1996  <19971998  1999  2000  2001  2002  2003  2004  2005  2006  2007  2008  2009  2010  2011  2012  2013  2014  2015  2016  2017  2018  2019  2020  2021  2022  2023  2024  Index 1994  1995  1996  <19971998  1999  2000  2001  2002  2003  2004  2005  2006  2007  2008  2009  2010  2011  2012  2013  2014  2015  2016  2017  2018  2019  2020  2021  2022  2023  2024 
<== Date ==> <== Thread ==>

Subject: Re: change in promotion of types from database to channel access
From: Chip Watson <[email protected]>
To: [email protected] (Ned Arnold)
Cc: [email protected], [email protected]
Date: Thu, 17 Jul 1997 12:02:28 -0400
[email protected] said:
> > Is anyone aware of a use of ULONG to hold a number larger than 2^31 
> > which  would fail if the value were contained in a 32 bit int?

> I think I'll stand up for the "less sophisticated" EPICS Application 
> Developer (of which there are many !) and respond  "I don't know what 
> you mean by a ULONG. Does that mean my system will break ? I got all 
> my stuff from  Epics_Genius_such_and_such. Should I be worried ? ". 

OK, a bit of education and editorializing: 

A ULONG is a 32 bit integer which is always positive.  I.e. the most 
significant
bit does not hold the sign, but instead holds 2^31 (=~ 2 x 10^9).  Anyone
out there using numbers that large? Fields in EPICS records effected are:

	1) fields specifying number of elements & offsets
	   (array records, waveform, subArray, etc.)
	   no problem here, as no one works with array of length 2,000,000,000.
	2) fields holding raw values & masks for bi, bo, mbbi*, mbbo*, pal records
	   IMHO no problem since these do not represent integers anyway, only
	   bits
	3) pulse counter record -- I can believe that an application may eventually
	   count more than 2^31 pulses, so care should be taken here, perhaps by
	   converting this field type to double to prevent overflows. In this
	   case no channel access client would be effected since they are fetching
	   this data as a double already.

(Info gleaned from *.ascii files).

The use of ULONG instead of the C type int on 32 bit machines is partly a 
purist
approach of declaring numbers which you know to be positive (lengths of arrays)
to be of a datatype which by definition is positive. However, having an array 
of length
2^32 (=gigabytes) will likely cause as much trouble as an array of length 
minus 2^31
for any control system application.

Chip



References:
Re: change in promotion of types from database to channel access Ned Arnold

Navigate by Date:
Prev: Re: change in promotion of types from database to channel access Ned Arnold
Next: EPICS fd registration problem Firmin Oliveira
Index: 1994  1995  1996  <19971998  1999  2000  2001  2002  2003  2004  2005  2006  2007  2008  2009  2010  2011  2012  2013  2014  2015  2016  2017  2018  2019  2020  2021  2022  2023  2024 
Navigate by Thread:
Prev: Re: change in promotion of types from database to channel access Ned Arnold
Next: database check in R3.13.0 Rolf Keitel
Index: 1994  1995  1996  <19971998  1999  2000  2001  2002  2003  2004  2005  2006  2007  2008  2009  2010  2011  2012  2013  2014  2015  2016  2017  2018  2019  2020  2021  2022  2023  2024 
ANJ, 10 Aug 2010 Valid HTML 4.01! · Home · News · About · Base · Modules · Extensions · Distributions · Download ·
· Search · EPICS V4 · IRMIS · Talk · Bugs · Documents · Links · Licensing ·