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 2025 | 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 2025 |
<== Date ==> | <== Thread ==> |
---|
Subject: | Re: Macro max size is 256 |
From: | Andrew Johnson via Tech-talk <tech-talk at aps.anl.gov> |
To: | TZVETKOV Stephane <stephane.tzvetkov at cea.fr>, "tech-talk at aps.anl.gov" <tech-talk at aps.anl.gov> |
Date: | Fri, 7 Jul 2023 10:47:19 -0500 |
Hi Stéphane, On 7/7/23 4:49 AM, TZVETKOV Stephane
via Tech-talk wrote:
I somehow found out that the associated NORD field was always limited to 256, and that my string was always cropped to 256 characters. It took me some time to actually understand that the limitation was that an EPICS macro has a maximum size of 256 characters. I'm not aware of any unwanted side-effects of doing that, the macLib code uses that setting internally, and the API ensures the code always knows the capacity of any buffer it's writing into so it won't overrun external buffers.(by the way, I also discovered that the name of a macro is also limited to 256 characters) In order to work around this limitation, I just recompiled the EPICS base with a minor modification in `modules/libcom/src/macLib/macLib.h`. E.g., changing the maximum size from 256 to 65535: ``` vi modules/libcom/src/macLib/macLib.h > ... ~ > #define MAC_SIZE 65535 > ... ``` As far as I have tested, this modification didn't seem to cause any problem. But, I wonder if more experienced EPICS developers have comments about this. Maybe increasing macro size has side effects that I didn't anticipated. Maybe there is a cleaner/better way to do this. However I don't think using 65535 there would allow for that size of string values in the database as there are some other places in the code that still use smaller fixed-size buffers, for example: 1. The modules/database/src/ioc/dbStatic/dbLexRoutines.c code that parses and loads .db and .dbd files uses fixed-size 1024-byte buffers (change MY_BUFFER_SIZE in that file). 2. The msi program uses 4096-byte buffers, you'd need to change MAX_BUFFER_SIZE in modules/database/src/ioc/dbtemplate/msi.cpp to increase them if you use msi to expand substitution files with large strings. 3. The lexical scanners generated by flex seem to use 8192 and 16384 byte buffers by default, thus the largest string that the .db file parser can read might be a few characters less than one of those two sizes. There might be some other places too, if you try fixing the ones above please let us know any more that you come across — it would be good to at least document where our code limits the string sizes, and the idea of unifying them all could be interesting. HTH, - Andrew -- Complexity is free, it's Simplicity that takes work. |