With gcc -std=gnu99 (present default) functions qualified
with plain 'inline' emit strong public symbols (nm says 'T')
in every compilation unit the definition appears.
This causes linking to fail in all cases where executable
are statically linked, and many where dynamic linking is used.
if the source array is empty, the index of the first element to copy (0) being equal
to the source array size (0) does not constitute an out-of-bounds condition
The windows shell doesn't like commands that start ../
Those commands are all found using TOOLS, so by making that
an absolute path we fix that problem.
However GNUmake doesn't recognize targets with relative paths
as being the same as their absolute path, so we have to fix up
some places that were using TOOLS in dependencies.
Major rewrites; the original epicsStrnRawFromEscaped() could read
beyond the end of the input buffer if the input count ended in the
middle of an octal or hex escape sequence. Zero termination did not
always match the return count, and hex escapes were always 2 digits,
contrary to the C standard.
New versions don't use epicsSnprintf() or sscanf() for hex and octal
conversions, so should be slightly faster.
Added 81 new tests to check the above issues.
VxWorks 6.9 deprecated several symFindBy...() routines, which
result in warning messages at build-time. I rewrote the code
that uses these to use the newer API on VxWorks 6.9.
Also deprecated the two epicsDynLink.h symFindByNameEPICS()
and symFindByNameAndTypeEPICS() routines; epicsFindSymbol() in
epicsFindSymbol.h is now available on most platforms instead.
Change menuGlobal.dbd and stdRecords.dbd to be generated
as a list of unexpanded include statements, not expanded
out as they have been recently on this branch. This means
any .dbd.pod files in those lists don't have to have been
filtered to remove the POD statements which significantly
simplifies the dependency graph. I had experienced build
loops at times, which this change should prevent.
An array field with a maximum size of 1 element would not be
treated as an array, so the record's rset::get_array_info()
routine wasn't being called. Fixed in dbAccess for both
dbGet() and dbPut() operations, and in dbEvent for monitors.
Fixes lp:1389298