for the DEF file contents, and loads the cell into the layout
window when done. That makes it consistent with other similar
functions such as "gds read". Existing scripts which create (by
loading) a new cell before reading the DEF should not be affected
by the change.
PIN entry in a DEF file when read by "def read". Previously,
"PLACED" and "FIXED" were handled, but "COVER" was missed. Magic
treats all three the same way.
When global <sys/mman.h> was removed from tile.h it also removed
<unistd.h> nearby. This exposes the lack of <unistd.h> being
included where needed using APIs like close()/read()/unlink()/isatty()
the WASM build seems to show this as the header file set is structured
differently.
keyword in LEF. FOREIGN may take an origin offset, but it is
optional. The routine to check that there were no offset values
in the statement incorrectly checked for a NULL token instead of
a value ";" which would indicate an end-of-statement.
All naked access to `ti_client` now uses the function-like-macro
to encapsulate this action. This macro existed before this just
makes all sites utilize it.
Added additional INT and PTR variants to remove the programmer
load on thinking about casing and casts polluting the point
of use. So the use now looks cleaner.
Equivalent prototypes:
void TiSetClient(Tile*, ClientData)
void TiSetClientINT(Tile*, intptr_t) /* pointertype */
void TiSetClientPTR(Tile*, void*)
ClientData TiGetClient(Tile*)
intptr_t TiGetClientINT(Tile*) /* pointertype */
void *TiGetClientPTR(Tile*)
macro. Based on observation of cells in PDKs where ORIGIN and/or
FOREIGN are non-zero, added code that forces a correction of LEF
macro coordinates to match the GDS coordinates, with an
equivalent negative shift of the LEF macro ORIGIN to compensate.
Normally, both ORIGIN and FOREIGN will be zero and the added code
will do nothing. Note that this code does not handle the
additional optional orientation. A LEF macro with a different
coordinate system than its GDS is already weird; a LEF macro
with a different rotation than its GDS is hopefully something
that nobody ever does in practice. If needed, I'll cross that
bridge when I come to it.
LefHelper_DBTechNameType_LefLower() identified and introduced during
conversion to const data usage.
Only side-effect is some log messages will use original verbatim token
now instead of lowercase version (but this seems ok when file parsing,
to quote the problematic information source verbatim)
Some function parameters (char *sname) have been made const due
referencing const data sources.
K&R obsolete syntax removal for C23 compatibility series
Due to use of strcasecmp() or similar C API.
Maybe HAVE_STRINGS_H is needed ? If so which platforms needs this ?
clang18 default warning cleanup (strict)
lefTech.c:107:16: warning: suggest parentheses around assignment used as truth value
lefTech.c:160:16: warning: suggest parentheses around assignment used as truth value
lefTech.c:426:16: warning: suggest parentheses around assignment used as truth value
lefTech.c:453:16: warning: suggest parentheses around assignment used as truth value
lefTech.c:486:16: warning: suggest parentheses around assignment used as truth value
lefWrite.c:190:9: warning: suggest parentheses around assignment used as truth value
lefWrite.c:303:12: warning: suggest parentheses around assignment used as truth value
lefWrite.c:315:12: warning: suggest parentheses around assignment used as truth value
lefWrite.c:377:16: warning: suggest parentheses around assignment used as truth value
lefWrite.c:439:16: warning: suggest parentheses around assignment used as truth value
lefWrite.c:1222:12: warning: suggest parentheses around assignment used as truth value
lefWrite.c:2246:12: warning: suggest parentheses around assignment used as truth value
defWrite.c:415:12: warning: suggest parentheses around assignment used as truth value
defWrite.c:447:12: warning: suggest parentheses around assignment used as truth value
defWrite.c:2039:16: warning: suggest parentheses around assignment used as truth value
defWrite.c:2104:16: warning: suggest parentheses around assignment used as truth value
defWrite.c:2478:16: warning: suggest parentheses around assignment used as truth value
defWrite.c:2498:20: warning: suggest parentheses around assignment used as truth value
defWrite.c:3066:16: warning: suggest parentheses around assignment used as truth value
defWrite.c:3084:28: warning: suggest parentheses around assignment used as truth value
defWrite.c:3111:28: warning: suggest parentheses around assignment used as truth value
lefRead.c:651:12: warning: suggest parentheses around assignment used as truth value
GCC14 -Wall cleanup series [-Wparentheses]
Looks like a logic bug, hiding behind this compiler warning
lefTech.c:507:21: warning: suggest parentheses around assignment used as truth value
lefTech.c:509:21: warning: suggest parentheses around assignment used as truth value
GCC14 -Wall cleanup series [-Wparentheses]
Fix code scanning alert no. 53: Multiplication result converted to larger type (#48)
Co-authored-by: Copilot Autofix powered by AI <62310815+github-advanced-security[bot]@users.noreply.github.com>
Fix code scanning alert no. 23: Call to function with fewer arguments than declared parameters (#38)
Co-authored-by: Copilot Autofix powered by AI <62310815+github-advanced-security[bot]@users.noreply.github.com>
Fix code scanning alert no. 63: Too few arguments to formatting function (#3)
* Create codeql.yml
* Fix code scanning alert no. 63: Too few arguments to formatting function
Co-authored-by: Copilot Autofix powered by AI <62310815+github-advanced-security[bot]@users.noreply.github.com>
---------
Co-authored-by: Copilot Autofix powered by AI <62310815+github-advanced-security[bot]@users.noreply.github.com>
Fix code scanning alert no. 62: Too few arguments to formatting function (#1)
* Create codeql.yml
* Fix code scanning alert no. 62: Too few arguments to formatting function
Co-authored-by: Copilot Autofix powered by AI <62310815+github-advanced-security[bot]@users.noreply.github.com>
---------
Co-authored-by: Copilot Autofix powered by AI <62310815+github-advanced-security[bot]@users.noreply.github.com>
R. Timothy Edwards
Darryl L. Miles
Kareem Farid