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>
that no nets will be checked for antenna gate and diffusion area,
and no antenna properties will be output to the LEF file. This can
greatly speed up LEF output file generation for a large design.
Thank you to Tamas Hubai for the code patch.
report it after "Failure to read in entire sub-tree". This will
not report every failing cell (since it quits reading after the
first failure) but will avoid the existing issue of printing
nothing and leaving the user with no feedback as to which cell
was the problem.
previously, MASTERSLICE layers would not be added to obstruction
layers made by "-hide". However, an nwell, for example, that
stuck outside of a prBoundary *would* be recorded, which was
inconsistent. Resolved this by allowing MASTERSLICE layers
in the OBS block, but only for layers that are not a substrate
type. NOTE: It may be better to just insist that a MASTERSLICE
layer define an obstruction type in the "lef" section of the
tech file, and treat it like routing obstructions. Alternatively,
one may question whether special obstruction types are needed at
all, as one could simply define an obstruction as a type without
a port label.
did not need to be changed, but the line below it that depended
on the layer being a contact type was wrong; the contact had
to be identified independently of the last layer type, which
might not be the contact cut type.
non-default rule. The code was first failing to identify the via
cut type from the generated via record, and then it was failing
to return to the non-default rule width after the route exits the
via. Both issues have been fixed. Thanks to Sylvain Munaut for
providing a reproducible test case.
new port labels are created for an existing port, then they must
take the existing port number. The code was previously causing
collisions between port numbers on different pins.
without SelectRootDef being set, which causes SelectClear() to
return without doing anything. However---question is why
SelectClear() needs SelectRootDef to be non-NULL since it is
clearing the selection, not the selection source. For now, just
patching the failing case, not trying to mess with the whole
selection mechanism.
lefLayer's "via" record even when the layer might not be a via,
causing potential issues with uninitialized variables. Not sure
if this is related to the bug that started this investigation,
but it was the only thing that looked relevant.
no way to implement boolean operators on labels, so any "label"
statement in the section can apply only to one magic layer. This
is regularly violated in most (all?) techfiles (due mainly to lack
of explanation and guidance). The addition of the "no-reconnect-
labels" option for cifinput made it worse, as it can cause a label
to be attached to the wrong layer and be stuck that way. Even
without the option, an attachment to a non-connecting type is a
problem; DIFF cannot simultaneously have a connection to both
ndiff and pdiff, so it will be one or the other, and the one not
connected can easily get labels moved to other nets. To avoid
this: (1) removed the "no-reconnect-labels" option, and (2) made
the automatic label reconnection smarter, as well as splitting it
into two different behaviors based on whether a label is being
created or manipulated from the command line (more or less the
original behavior) vs. being read from GDS or LEF. The new rules
assume that labels attached to a GDS type will all map to the
same plane in magic. To avoid excessive error messages from
existing tech files, a warning is issued only if "labels" changes
the plane of the target layer (a realistic solution rather than
the preferred one). Also: Fixed an error that causes a crash on
the "wizard" command "*watch" if the cell being observed is
read-only (see github issue #271).
in DEF read and write. The NONDEFAULT LAYER WIREEXT was assumed
to refer to the default wire extension at segments, when instead
it refers to the wire extension only at vias. The wire
extension at segments is presumably defined by the nondefault
segment (and wire extension at vias remains unimplemented, which
is probably not a big issue because everyone puts the wire
extensions into the via definitions anyway).
output as blockages. That allows obstruction layers to be placed
in a layout specifically for the purpose of being output as a
blockage. Otherwise, an obstruction layer is generally considered
non-electrical and will not show up as a node in the extraction
file, so obstruction layers were being missed entirely by "def
write". Also: Where "def write" complains about floating labels,
made an exception for labels on non-electrical layers (like
"comment").
Darryl L. Miles
Tim Edwards
Kareem Farid