Experimental Physics and
Industrial Control System

Eric Norum <[email protected]> · Thu, 10 Sep 2009 09:31:45 -0500

Andrew and I have squashed all those warnings in the code now in the

subversion repository, I believe.

But anyone that wants to make the changes mentioned in the recent

flurry of messages is welcome to to so....

On Sep 10, 2009, at 9:17 AM, Mark Rivers wrote:

If someone is fixing the sequencer it would be good to eliminate as

many

of the following warnings when building on 64-bit Linux as possible:

[epics@localhost 2-0-12]$ make > /dev/null
../devSequencer.c: In function 'seqShowScanPvtInit':
../devSequencer.c:191: warning: comparison between pointer and integer
../devSequencer.c:198: warning: comparison between pointer and integer
../devSequencer.c:199: warning: assignment makes integer from pointer
without a cast
../phase2.c: In function 'gen_defn_c_code':
../phase2.c:432: warning: format '%s' expects type 'char *', but
argument 2 has type 'struct expression *'
../phase2.c: In function 'gen_global_c_code':
../phase2.c:450: warning: format '%s' expects type 'char *', but
argument 2 has type 'struct expression *'
../phase2.c: In function 'assign_next_delay_id':

../phase2.c:592: warning: cast to pointer from integer of different

size

../gen_ss_code.c: In function 'eval_delay':

../gen_ss_code.c:263: warning: cast from pointer to integer of

different

size
../gen_ss_code.c: In function 'gen_action_func':
../gen_ss_code.c:302: warning: format '%s' expects type 'char *', but
argument 2 has type 'struct expression *'
../gen_ss_code.c: In function 'eval_expr':
../gen_ss_code.c:569: warning: format '%s' expects type 'char *', but
argument 2 has type 'struct expression *'
../gen_ss_code.c: In function 'special_func':

../gen_ss_code.c:633: warning: cast from pointer to integer of

different

size
../gen_ss_code.c: In function 'gen_pv_func':
../gen_ss_code.c:769: warning: 'ep3' may be used uninitialized in this
function
/corvette/usr/local/epics/base-3.14.11/bin/linux-x86_64/antelope: 474
shift/reduce conflicts, 270 reduce/reduce conflicts.
In file included from ../snc.y:476:
../snc_lex.l: In function 'yy_get_next_buffer':
../snc_lex.l:446: warning: implicit declaration of function 'read'
y.tab.c: In function 'yyparse':
y.tab.c:1100: warning: implicit declaration of function 'yyerror'
../snc.y:113: warning: implicit declaration of function 'program'
../snc.y:117: warning: implicit declaration of function 'snc_err'
../snc.y:121: warning: implicit declaration of function 'program_name'

../snc.y:144: warning: implicit declaration of function

'assign_single'

../snc.y:146: warning: implicit declaration of function

'assign_subscr'

../snc.y:149: warning: implicit declaration of function 'assign_list'
../snc.y:164: warning: implicit declaration of function 'monitor_stmt'
../snc.y:173: warning: implicit declaration of function
'set_debug_print'
../snc.y:179: warning: implicit declaration of function 'decl_stmt'
../snc.y:224: warning: implicit declaration of function 'sync_stmt'
../snc.y:229: warning: implicit declaration of function 'syncq_stmt'
../snc.y:239: warning: implicit declaration of function 'defn_c_stmt'
../snc.y:243: warning: implicit declaration of function 'option_stmt'
../snc.y:256: warning: implicit declaration of function 'entry_code'
../snc.y:258: warning: implicit declaration of function 'exit_code'
../snc.y:456: warning: implicit declaration of function 'pp_code'

../snc.y:468: warning: implicit declaration of function

'global_c_stmt'

y.tab.c: At top level:
../snc_lex.l:554: warning: 'yyunput' defined but not used
../snc_lex.l:661: warning: 'yyrestart' defined but not used
../snc_lex.l:673: warning: 'yy_switch_to_buffer' defined but not used
../snc_lex.l:597: warning: 'input' defined but not used

Mark

-----Original Message-----
From: [email protected]
[mailto:[email protected]] On Behalf Of Eric Norum
Sent: Thursday, September 10, 2009 9:10 AM
To: Dirk Zimoch
Cc: [email protected]
Subject: Re: sequencer feature request

Yeah, I thought about that, but 200 bytes isn't that much, and this
code is not too far down a call chain, so I thought that things would
be o.k.
FWIW, stacks sizes small, medium and large on RTEMS are 5000, 8000,
and 11000 bytes, respectively.

On Sep 10, 2009, at 8:46 AM, Dirk Zimoch wrote:

Hi Mr. Small IOC,

What is the stack size of your small IOC? Is allocating 200 bytes on
the stack OK? Apart from that, I cannot find any impact on the rest
of the sequencer code.

There are other occurrences of MAX_STRING_SIZE but they are probably
OK:

seq/seq_main.c line 98:
#define      SCRATCH_SIZE    (MAX_MACROS*(MAX_STRING_SIZE+1)*12)
But SCRATCH_SIZE is never used. It should be deleted.

seq/seq_main.c line 563:
} typeMap[] = {
...
	{
	"string",	 pvTypeSTRING,	pvTypeTIME_STRING,
	MAX_STRING_SIZE, OFFSET(pvTimeString, value[0])
	},

snc/phase2.c line 153:
  printf("#define MAX_STRING_SIZE 40\n");

snc/phase2.c line 400:
			printf("[MAX_STRING_SIZE]");

These occurrences are related to string variables and seem to be OK
for the moment.

I also looked for other hard coded limits and found:

seq/seq_mac.c line 47:
	char		name[50], *pValue, *pTmp;

This limits the length of a macro name (not its value) to 49 chars.
Probably not a serious problem but still quite unnecessary. A
dynamic solution would be to temporarily allocate memory of the size
of the substitution sting.

The number of macros is limited to 50 by
seq/seqPvt.h line 226:
#define    MAX_MACROS      50
This can be made dynamic by replacing the table with a linked list
of macros.

In principle, it is not necessary to use a macro table. Whenever a
macro is referenced, it can be looked up in the substitution string.
The performance loss should be negligible. Macros are only looked up
during initialization.

Dirk

Eric Norum wrote:

MACRO_STR_LEN is used only in that one function -- here's my
suggestion
/*
* Evaluate channel names by macro substitution.
*/
#define     MACRO_STR_LEN   200
LOCAL void seqChanNameEval(pSP)
SPROG       *pSP;
{
  CHAN        *pDB;
  int     i;
  pDB = pSP->pChan;
  for (i = 0; i < pSP->numChans; i++, pDB++)
  {
      char cbuf[MACRO_STR_LEN+1];
      seqMacEval(pDB->dbAsName, cbuf, MACRO_STR_LEN, pSP->pMacros);
      pDB->dbName = epicsStrDup(cbuf);
#ifdef  DEBUG
      printf("seqChanNameEval: \"%s\" evaluated to \"%s\"\n",
          pDB->dbAsName, pDB->dbName);
#endif  /*DEBUG*/
  }
}
On Sep 9, 2009, at 12:54 PM, Chestnut, Ronald P. wrote:

Mr. Expedient here.

With any luck, all the code in the sequencer uses MACRO_STR_LEN,
and a change to something larger but static (perhaps 61 or 100?)
might just work after a recompile. Doing something dynamic
requires actual thinking and more extensive testing. How about an
initial static bump with a subsequent dynamic solution?

Ron Chestnut

-----Original Message-----
From: [email protected]

[mailto:[email protected]

] On Behalf Of Eric Norum
Sent: Wednesday, September 09, 2009 6:15 AM
To: [email protected] Techtalk
Subject: Re: sequencer feature request

Mr. Small IOC here.
Rather than allocating the maximum-sized space for every single
name,

why not expand the name into a 'big-enough' buffer and then

allocate

only the required size and copy the result?

On Sep 9, 2009, at 5:13 AM, Dirk Zimoch wrote:

I found several places in the code where the sequencer uses
MAX_STRING_SIZE+1 for string lengths of PV names and macros. In
EPICS base MAX_STRING_SIZE is defined as 40. For example in
seq_main.c:

/*
* Evaluate channel names by macro substitution.
*/
#define        MACRO_STR_LEN    (MAX_STRING_SIZE+1)
LOCAL void seqChanNameEval(pSP)
SPROG        *pSP;
{
  CHAN        *pDB;
  int        i;

  pDB = pSP->pChan;
  for (i = 0; i < pSP->numChans; i++, pDB++)
  {
      pDB->dbName = calloc(1, MACRO_STR_LEN);
      seqMacEval(pDB->dbAsName, pDB->dbName, MACRO_STR_LEN, pSP-

pMacros);

#ifdef    DEBUG
      printf("seqChanNameEval: \"%s\" evaluated to \"%s\"\n",
          pDB->dbAsName, pDB->dbName);
#endif    /*DEBUG*/
  }
}

It might help to replace those uses of MAX_STRING_SIZE+1 with
PVNAME_STRINGSZ.

Dirk

Dirk Zimoch wrote:

I tested the sequencer with a long name and it seems that it
truncates the PV name to 41 chars.

A seqChanShow shows the difference between the name used in

assign

and the actual name used in CA:
Channel name: "DZ:45678901234567890123456789012345678901"
Unexpanded (assigned) name: "DZ:
456789012345678901234567890123456789012345678901234567890"
Dirk
Mark Rivers wrote:

EPICS base defines the maximum length of the PV name to be
PVNAME_STRINGSZ, which is currently 61 including the nil
terminator.
What length limitation does the sequencer impose?  Is it more
restrictive than this?
Mark

________________________________

From: [email protected] on behalf of Patrick Thomas
Sent: Thu 9/3/2009 6:29 PM
To: [email protected]
Subject: sequencer feature request

Hi,

I was wondering if I could ask for a feature request for the

next

version of the sequencer? Is there any chance that it would be
possible
to use unlimited length record names in assign to statements?

Thank you,
Patrick

--Dr. Dirk Zimoch
Paul Scherrer Institut, WBGB/006
5232 Villigen PSI, Switzerland
Phone +41 56 310 5182

--Eric Norum <[email protected]>
Advanced Photon Source
Argonne National Laboratory
(630) 252-4793

--Eric Norum <[email protected]>
Advanced Photon Source
Argonne National Laboratory
(630) 252-4793

--
Dr. Dirk Zimoch
Paul Scherrer Institut, WBGB/006
5232 Villigen PSI, Switzerland
Phone +41 56 310 5182

--
Eric Norum <[email protected]>
Advanced Photon Source
Argonne National Laboratory
(630) 252-4793

--
Eric Norum <[email protected]>
Advanced Photon Source
Argonne National Laboratory
(630) 252-4793

Experimental Physics and Industrial Control System

Experimental Physics and
Industrial Control System