This is needed to allow K&R to be removed and struct prototypes to
exist that have fully declared (argument) types.
It maybe necessary (in the future) to have public types and module
internal type in separate header files, but it is unclear if such a
clear split exists.
Copyright plate taken from extflat.h
EFint.t has an ugly ifndef _DATABASE_H that is very include order
dependent (brittle to failure) so this moves the (struct ArrayInfo) type
definition into its own file, which has standard ifndef once file guards.
So include file order no longer matters.
Copyright plate taken from database.h.in
This has a knock on effect of causing EFvisit.c to require database.h
to be defined BEFORE the EFint.h due to an identical copy of ArrayInfo
type being present in both files.
Maybe there should be database_arrayinfo.h ? To remove the copy.
Support gcc -Werror=format-security which is used by default on Fedora.
ext2spice/ext2spice.c: format not a string literal and no format arguments
extflat/EFargs.c: likewise
windows/windCmdNR.c: likewise
Adding ASSERT() to arguments to ensure passed arguments are non-NULL
better conveys API intent to both mitigate this false positive
but also allow analysis to inspect caller for correct usage.
SonarCloud
Null pointer passed as 1st argument to string length function
https://sonarcloud.io/project/issues?open=AZJB167jNGfDNup0RjGw&id=dlmiles_magic
Theoretical NULL pointer deref, assumes no iteration occurs.
Seems like false positive from incorrect caller use, from
passing suffix==NULL.
SonarCloud
Access to field 'hn_parent' results in a dereference of a null pointer (loaded from variable 'prev')
https://sonarcloud.io/project/issues?open=AZJB167jNGfDNup0RjGu&id=dlmiles_magic
with zero gate error (and was reporting an infinite antenna ratio).
For now, just ignoring the zero-area case. However, since the
procedure is supposed to be looping through nets connected to
specific devices in the .ext file, then every entry is supposed to
have non-zero area, so there is some underlying problem here that
needs to be fixed.
surrounding a device tile may cause the device to be extracted
with the wrong node (picking up the node from the wrong side of
the diagonal tile). Added extra handling to capture the case
where two ports on two different nets are merged when using
"ext2spice short" (previously it was handling only ports on the
same net). Also: Removed the redundant readline-4.3 from the
readline/ directory; only readline/readline is left, which is
version 4.3.
I think the warning is bringing to attention the hidden fall-thru
case situation.
EFvisit.c:897:50: warning: misleading indentation; statement is not part of the previous 'if'
clang18 -Wall warning cleanup [-Wmisleading-indentation]
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)
EFdef.c:110:12: warning: suggest parentheses around assignment used as truth value
EFdef.c:154:12: warning: suggest parentheses around assignment used as truth value
EFdef.c:167:12: warning: suggest parentheses around assignment used as truth value
EFflat.c:546:17: warning: suggest parentheses around assignment used as truth value
EFflat.c:798:12: warning: suggest parentheses around assignment used as truth value
EFflat.c:930:13: warning: suggest parentheses around assignment used as truth value
EFflat.c:1152:12: warning: suggest parentheses around assignment used as truth value
EFflat.c:1157:13: warning: suggest parentheses around assignment used as truth value
EFhier.c:84:12: warning: suggest parentheses around assignment used as truth value
EFhier.c:261:12: warning: suggest parentheses around assignment used as truth value
EFhier.c:489:12: warning: suggest parentheses around assignment used as truth value
EFhier.c:682:12: warning: suggest parentheses around assignment used as truth value
EFname.c:325:12: warning: suggest parentheses around assignment used as truth value
EFname.c:584:13: warning: suggest parentheses around assignment used as truth value
EFname.c:632:16: warning: suggest parentheses around assignment used as truth value
EFname.c:765:16: warning: suggest parentheses around assignment used as truth value
EFname.c:977:12: warning: suggest parentheses around assignment used as truth value
EFsym.c:113:13: warning: suggest parentheses around assignment used as truth value
EFsym.c:164:9: warning: suggest parentheses around assignment used as truth value
EFvisit.c:322:12: warning: suggest parentheses around assignment used as truth value
EFvisit.c:627:12: warning: suggest parentheses around assignment used as truth value
EFvisit.c:881:16: warning: suggest parentheses around assignment used as truth value
EFvisit.c:917:12: warning: suggest parentheses around assignment used as truth value
grTk1.c:1325:9: warning: suggest parentheses around assignment used as truth value
grTk1.c:1342:9: warning: suggest parentheses around assignment used as truth value
grTk1.c:1757:9: warning: suggest parentheses around assignment used as truth value
grTk1.c:1766:9: warning: suggest parentheses around assignment used as truth value
grTk5.c:177:12: warning: suggest parentheses around assignment used as truth value
grTOGL1.c:1095:9: warning: suggest parentheses around assignment used as truth value
grTOGL1.c:1111:9: warning: suggest parentheses around assignment used as truth value
grTOGL1.c:1542:13: warning: suggest parentheses around assignment used as truth value
grTOGL1.c:1551:13: warning: suggest parentheses around assignment used as truth value
grTOGL5.c:201:12: warning: suggest parentheses around assignment used as truth value
grTCairo1.c:1093:13: warning: suggest parentheses around assignment used as truth value
grTCairo1.c:1109:13: warning: suggest parentheses around assignment used as truth value
grTCairo1.c:1493:21: warning: suggest parentheses around assignment used as truth value
grTCairo1.c:1502:21: warning: suggest parentheses around assignment used as truth value
grTCairo5.c:202:16: warning: suggest parentheses around assignment used as truth value
GCC14 -Wall cleanup series [-Wparentheses]
EFbuild.c:466:9: warning: suggest parentheses around assignment used as truth value
EFbuild.c:662:20: warning: suggest parentheses around assignment used as truth value
EFbuild.c:682:24: warning: suggest parentheses around assignment used as truth value
EFbuild.c:690:24: warning: suggest parentheses around assignment used as truth value
EFbuild.c:1760:12: warning: suggest parentheses around assignment used as truth value
EFbuild.c:1973:9: warning: suggest parentheses around assignment used as truth value
EFbuild.c:2062:12: warning: suggest parentheses around assignment used as truth value
EFbuild.c:2063:13: warning: suggest parentheses around assignment used as truth value
EFbuild.c:2091:12: warning: suggest parentheses around assignment used as truth value
EFbuild.c:2134:12: warning: suggest parentheses around assignment used as truth value
EFbuild.c:2135:13: warning: suggest parentheses around assignment used as truth value
EFread.c:673:12: warning: suggest parentheses around assignment used as truth value
ExtArray.c:693:12: warning: suggest parentheses around assignment used as truth value
ExtArray.c:800:13: warning: suggest parentheses around assignment used as truth value
ExtBasic.c:4569:9: warning: suggest parentheses around assignment used as truth value
ExtBasic.c:4949:13: warning: suggest parentheses around assignment used as truth value
ExtBasic.c:5032:12: warning: suggest parentheses around assignment used as truth value
ExtCell.c:218:13: warning: suggest parentheses around assignment used as truth value
ExtCouple.c:222:12: warning: suggest parentheses around assignment used as truth value
ExtCouple.c:278:12: warning: suggest parentheses around assignment used as truth value
ExtCouple.c:467:9: warning: suggest parentheses around assignment used as truth value
ExtHard.c:379:12: warning: suggest parentheses around assignment used as truth value
ExtHard.c:458:12: warning: suggest parentheses around assignment used as truth value
ExtHier.c:740:16: warning: suggest parentheses around assignment used as truth value
ExtHier.c:831:12: warning: suggest parentheses around assignment used as truth value
ExtHier.c:841:13: warning: suggest parentheses around assignment used as truth value
ExtHier.c:851:17: warning: suggest parentheses around assignment used as truth value
ExtHier.c:865:34: warning: suggest parentheses around assignment used as truth value
ExtLength.c:264:12: warning: suggest parentheses around assignment used as truth value
ExtLength.c:276:12: warning: suggest parentheses around assignment used as truth value
ExtLength.c:878:9: warning: suggest parentheses around assignment used as truth value
ExtMain.c:499:12: warning: suggest parentheses around assignment used as truth value
ExtMain.c:970:12: warning: suggest parentheses around assignment used as truth value
ExtNghbors.c:298:13: warning: suggest parentheses around assignment used as truth value
ExtSubtree.c:683:12: warning: suggest parentheses around assignment used as truth value
ExtTest.c:457:21: warning: suggest parentheses around assignment used as truth value
ExtTest.c:466:21: warning: suggest parentheses around assignment used as truth value
ExtTimes.c:216:12: warning: suggest parentheses around assignment used as truth value
ExtTimes.c:226:12: warning: suggest parentheses around assignment used as truth value
ExtTimes.c:235:12: warning: suggest parentheses around assignment used as truth value
ExtYank.c:236:34: warning: suggest parentheses around assignment used as truth value
ExtYank.c:238:42: warning: suggest parentheses around assignment used as truth value
GCC14 -Wall cleanup series [-Wparentheses]
Compiler is expressing range concern with the warning mitigated by using
unsigned C array offsets. This also draws attention to the range concern
when reading the code and making changes.
DBundo.c:263:45: warning: array subscript has type 'char'
DBundo.c:279:49: warning: array subscript has type 'char'
DBundo.c:317:52: warning: array subscript has type 'char'
DBundo.c:318:64: warning: array subscript has type 'char'
DBundo.c:324:52: warning: array subscript has type 'char'
DBundo.c:325:64: warning: array subscript has type 'char'
DBundo.c:329:50: warning: array subscript has type 'char'
DBundo.c:330:58: warning: array subscript has type 'char'
DBundo.c:338:52: warning: array subscript has type 'char'
DBundo.c:339:64: warning: array subscript has type 'char'
DBundo.c:345:52: warning: array subscript has type 'char'
DBundo.c:346:64: warning: array subscript has type 'char'
DBundo.c:350:50: warning: array subscript has type 'char'
DBundo.c:351:58: warning: array subscript has type 'char'
DBundo.c:371:52: warning: array subscript has type 'char'
DBundo.c:372:64: warning: array subscript has type 'char'
DBundo.c:378:52: warning: array subscript has type 'char'
DBundo.c:379:64: warning: array subscript has type 'char'
DBundo.c:383:50: warning: array subscript has type 'char'
DBundo.c:384:58: warning: array subscript has type 'char'
DBundo.c:392:52: warning: array subscript has type 'char'
DBundo.c:393:57: warning: array subscript has type 'char'
DBundo.c:399:52: warning: array subscript has type 'char'
DBundo.c:400:57: warning: array subscript has type 'char'
DBundo.c:403:53: warning: array subscript has type 'char'
DBundo.c:407:50: warning: array subscript has type 'char'
DBundo.c:408:58: warning: array subscript has type 'char'
EFbuild.c:1048:32: warning: array subscript has type 'char'
EFbuild.c:1056:32: warning: array subscript has type 'char'
ExtBasic.c:2358:43: warning: array subscript has type 'char'
ExtBasic.c:2493:43: warning: array subscript has type 'char'
ExtBasic.c:2519:43: warning: array subscript has type 'char'
ExtBasic.c:2644:43: warning: array subscript has type 'char'
ExtBasic.c:2678:43: warning: array subscript has type 'char'
ResPrint.c:143:43: warning: array subscript has type 'char'
plotRutils.c:713:34: warning: array subscript has type 'char'
plotRutils.c:786:29: warning: array subscript has type 'char'
GCC14 -Wall cleanup series [-Wchar-subscripts]
Fix code scanning alert no. 50: Multiplication result converted to larger type (#51)
Co-authored-by: Copilot Autofix powered by AI <62310815+github-advanced-security[bot]@users.noreply.github.com>
missing from a netlist generated by ext2spice with the "extresist"
option enabled. The first had to do with some parts of nets being
given alias names for a net, and the second was caused during
"extresist" and would also result in error messages about devices
missing terminals.
can provide a delta offset such as "l+0.06", indicating that
the extraction model has a length larger than the drawn device.
Previously the value was assumed to be in microns but did not
scale between the .ext file and the SPICE netlist. Corrected
so that it scales like the other parameter values, being
converted to internal units and tracking the internal grid
scale.
".res.ext" file from "extresist" after using "extract do local" (and
probably with "extract path" as well). Fixed this, and also made
sure that "extresist" writes the ".res.ext" file to the same location
as ".ext" always, so that handling is consistent throughout the
full R-C extraction process, across the use of "extract", "ext2sim",
"extresist", and "ext2spice".
to catch cases where a device terminal is connected to the global
substrate node even when the terminal is not specifically a substrate
terminal (e.g., diode cathode or bipolar collector) and mark them with
the "substrate is port" flag.
warning messages about ports being electrically connected when
those ports have names that match under rules of case-insensitivity,
and the .ext file is being read for the purpose of generating a
SPICE netlist, which is case-insensitive. Also: Corrected a crash
condition when using "extract path <name>" when directory <name>
does not exist.
of the "edit" command that takes an instance name as an argument.
This is the first of a small series of command extensions to
provide the capability to replace any command that is dependent on
the pointer position with an equivalent command that is not, for
the purpose of removing pointer and screen coordinate dependencies
from the log file created by "logcommands".
the assumption of case insensitivity (e.g., VSS, Vss, and vss)
are kept separate even when writing SPICE netlists, which are
case insensitive. The code fix both avoids flagging these ports
when running ext2spice, and more importantly, allows the use of
"ext2spice short" without these ports ending up separate in the
output netlist.
be output twice for scaled devices (such as diodes in the sky130
process). Above and beyond the typo, though, the implementation
of offsets is not very well thought out and needs to be revised.
For one, the +/- notation can be confused with signs in the
parameter expression; that is also fixed in this commit. But
there is currently no way to express both a scale and an offset
for a device parameter.
'+' and '-' in the same way that '*' is currently used for specifying
a parameter scaling. The combination of a scale and offset for the
same parameter has not (yet) been implemented.
with "extract do local" now being equivalent to "extract path .".
This allows extraction files to be put in a subdirectory and not
clog up the current working directory. Also: Fixed some behavior
around the use of "ext2spice -p <path>" so that it (1) works, and
(2) is compatible with the new "extract path". Since the ext2spice
and ext2sim commands are effectively independent of the primary
extraction, the "-p" option is needed to correspond to the use of
"extract path". Hopefully this is seen as only a minor inconvenience.
from ext2spice due to "equiv" statements in the .ext file. The
algorithm was not properly keeping the port as the preferred
name of the node, resulting in the non-preferred name being
used instead of the port name in the output. This would happen
only if there was a label on a net that had a different name than
the port name. The error became much more prevalent after changing
the extract behavior to make "extract do aliases" default. Also
fixed a somewhat related minor error in which magic would print an
error message about ports being shorted together on the same kind
of net where both a port and a (different) label were attached to
the net. Since the non-port label is not a preferred name, then
there should be no warning message. The warning is only intended
for cases where two (or more) ports are truly shorted together.
when reading .ext files with "equiv" statements in them. The
generation of "equiv" statements was expanded recently, making it
more likely for this issue to show up. There may be devices in
a file that have a terminal node pointing to the node that gets
removed, and these must be updated to point to the node that
remains after merging. This requires a full loop over all
devices and so could have a potentially large impact; but in
general there are not many equiv statements (implying multiple
different labels attached to the same node) and so it is unlikely
that there would be a noticeable performance hit in practice.
can result in negative resistors due to integer overflow. In all
cases, the target was floating-point and it was only necessary to
recast everything to float first.
Darryl L. Miles
Tim Edwards
Mamoru TASAKA