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
- Replies:
- RE: sequencer feature request Mark Rivers
- References:
- sequencer feature request Patrick Thomas
- RE: sequencer feature request Mark Rivers
- Re: sequencer feature request Dirk Zimoch
- Re: sequencer feature request Dirk Zimoch
- Re: sequencer feature request Eric Norum
- RE: sequencer feature request Chestnut, Ronald P.
- Re: sequencer feature request Eric Norum
- Re: sequencer feature request Dirk Zimoch
- Re: sequencer feature request Eric Norum
- RE: sequencer feature request Mark Rivers
- Navigate by Date:
- Prev:
RE: Access security problem GOURNAY Jean-Francois
- Next:
RE: sequencer feature request Mark Rivers
- Index:
1994
1995
1996
1997
1998
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: sequencer feature request Mark Rivers
- Next:
RE: sequencer feature request Mark Rivers
- Index:
1994
1995
1996
1997
1998
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
|
·
Home
·
News
·
About
·
Base
·
Modules
·
Extensions
·
Distributions
·
Download
·