Eric,
OK, I did an SVN update and many of the warnings are gone, but not all.
Here is the output on 64-bit Linux:
[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 'assign_next_delay_id':
../phase2.c:584: 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 'special_func':
../gen_ss_code.c:632: warning: cast from pointer to integer of different
size
/corvette/usr/local/epics/base-3.14.11/bin/linux-x86_64/antelope: 474
shift/reduce conflicts, 270 reduce/reduce conflicts.
../snc_lex.l:555: warning: 'yyunput' defined but not used
../snc_lex.l:662: warning: 'yyrestart' defined but not used
../snc_lex.l:674: warning: 'yy_switch_to_buffer' defined but not used
../snc_lex.l:598: warning: 'input' defined but not used
Here is the output on 32-bit Linux and vxWorks:
corvette:~/devel/seq/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
/corvette/usr/local/epics/base-3.14.11/bin/linux-x86/antelope: 474
shift/reduce conflicts, 270 reduce/reduce conflicts.
../snc_lex.l:555: warning: 'yyunput' defined but not used
../snc_lex.l:662: warning: 'yyrestart' defined but not used
../snc_lex.l:674: warning: 'yy_switch_to_buffer' defined but not used
../snc_lex.l:598: warning: 'input' defined but not used
Mark
-----Original Message-----
From: Eric Norum [mailto:[email protected]]
Sent: Thursday, September 10, 2009 9:32 AM
To: Mark Rivers
Cc: Dirk Zimoch; [email protected]
Subject: Re: sequencer feature request
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
- 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
- Re: sequencer feature request Eric Norum
- Navigate by Date:
- Prev:
Re: sequencer feature request Eric Norum
- Next:
Re: "buffer over-write" problem with StringIn record Ralph Lange
- 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 Eric Norum
- Next:
Problems with installing EPICS Csaba Gajo
- 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
·