This is reducing nearby calls to TiGetClient() API when the value
can be looked up one time and stored in a local variable to make
other decisions about.
This is due to TiGetClient() potentially having a slightly higher
cost to call than previously, this is a kind of peephole
optimization approach (if I can see multiple getters used within
the window it got optmized).
'ticlient' was used for retrieval as ClientData so that future
greps across the codebase for `ti_client` should only match naked
access.
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*)
Guided by CodeQL static code analyser.
FileMayNotBeClosed.ql
FileMayNeverBeClosed.ql
The trick with "if(fp != stdout)" is problematic (to analyser) as
technically 'stdout' can be a global pointer that COULD be modified any
time, so it might have changed between the fopen() and fclose() calls so
the close MAY NEVER occurs (which is problem the analyzer can see).
So local state is maintained as a bool which will also clarify to the
compiler see the intention without concern for external stdout
modification.
Some items appear to be out and out leaks when certain commands are use.
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.
BD_xxxxx are a bitmask. So it makes sense due to equality check to
set to zero so it becomes a no-op situation.
I assume lb->dir not matching one of the 4 BD_xxxxx labels would be
a data error anyway and should never occur.
SonarCloud
The right operand of '==' is a garbage value
https://sonarcloud.io/project/issues?open=AZJB16p0NGfDNup0RiW9&id=dlmiles_magic
different planes of a device that are connected to a multi-tile
device. This is a more general solution than previously coded,
in which only the first tile of a device would be searched for
terminals on other planes, which was only guaranteed to work
if the device was represented by a single tile.
different from the device (i.e., gate) width, for devices that do
not define a MOS-like gate spanning the width of the device. This
is restricted to the assumption that the terminal is rectangular
and therefore a simple width and length can be derived from the
area and perimeter. Also, length is defined as the smaller
dimension and width as the larger dimension. For additional
restrictions, see the updated documentation. This was added to
allow correct width and length extraction of a bipolar emitter
window, but may be more generally useful.
previously ignoring the parameters of the entire cell including
the device being overridden by the property, causing the output
to be wrong. The parameters should always be written out to the
.ext file, including the device whose output is being overridden.
mismatch in the SkyWater sky130_fd_io__top_pwrdetv2 circuit
because a resistor with ends shorted together was being assigned
an incorrect length and width. This was due to the similarity
in characteristics of the boundary vector between a shorted
resistor and an annular resistor. The terminals need to be
checked for shorted ends to disambiguate the two cases.
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.
ExtBasic.c:408:7: warning: variable 'urx' is used uninitialized whenever '||' condition is true
ExtBasic.c:417:7: warning: variable 'ury' is used uninitialized whenever '||' condition is true
clang18 -Wall warning cleanup [-Wsometimes-uninitialized]
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)
The NodeRegion is an extended form of LabRegion (which is smaller) and
has the same layout. So we cast into the smaller type.
ExtBasic.c:1025:31: warning: incompatible pointer types passing 'NodeRegion *' (aka 'struct nreg *') to parameter of type 'LabRegion *' (aka 'struct lreg *')
ExtBasic.c:2291:29: warning: incompatible pointer types passing 'NodeRegion *' (aka 'struct nreg *') to parameter of type 'LabRegion *' (aka 'struct lreg *')
ExtBasic.c:2335:46: warning: incompatible pointer types passing 'NodeRegion *' (aka 'struct nreg *') to parameter of type 'LabRegion *' (aka 'struct lreg *')
ExtBasic.c:2339:47: warning: incompatible pointer types passing 'NodeRegion *' (aka 'struct nreg *') to parameter of type 'LabRegion *' (aka 'struct lreg *')
clang18 default warning cleanup [-Wincompatible-pointer-types]
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]
"extract unique notopports" both fail to work correctly because
an attempt some time ago to avoid issuing warnings about shorted
port names when using those options was changed in the wrong
line.
request #325 from Daryl Miles. Made a few simple style changes
to conform to (what is vaguely defined as) the overall programming
style for magic (passed down from John Ousterhout).
Fix code scanning alert no. 159: Wrong type of arguments to formatting function (#66)
Co-authored-by: Copilot Autofix powered by AI <62310815+github-advanced-security[bot]@users.noreply.github.com>
Fix code scanning alert no. 52: Multiplication result converted to larger type (#49)
Co-authored-by: Copilot Autofix powered by AI <62310815+github-advanced-security[bot]@users.noreply.github.com>
Fix code scanning alert no. 51: Multiplication result converted to larger type (#50)
Co-authored-by: Copilot Autofix powered by AI <62310815+github-advanced-security[bot]@users.noreply.github.com>
Fix code scanning alert no. 71: Wrong type of arguments to formatting function (#37)
Co-authored-by: Copilot Autofix powered by AI <62310815+github-advanced-security[bot]@users.noreply.github.com>
Fix code scanning alert no. 61: Too few arguments to formatting function (#35)
Co-authored-by: Copilot Autofix powered by AI <62310815+github-advanced-security[bot]@users.noreply.github.com>
Fix code scanning alert no. 60: Too few arguments to formatting function (#36)
Co-authored-by: Copilot Autofix powered by AI <62310815+github-advanced-security[bot]@users.noreply.github.com>
Fix code scanning alert no. 140: Incorrect return-value check for a 'scanf'-like function (#23)
Co-authored-by: Copilot Autofix powered by AI <62310815+github-advanced-security[bot]@users.noreply.github.com>
Fix code scanning alert no. 138: Incorrect return-value check for a 'scanf'-like function (#22)
Co-authored-by: Copilot Autofix powered by AI <62310815+github-advanced-security[bot]@users.noreply.github.com>
Fix code scanning alert no. 136: Incorrect return-value check for a 'scanf'-like function (#11)
* Create codeql.yml
* Fix code scanning alert no. 136: Incorrect return-value check for a 'scanf'-like 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. 149: Incorrect return-value check for a 'scanf'-like function (#10)
* Create codeql.yml
* Fix code scanning alert no. 149: Incorrect return-value check for a 'scanf'-like 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>
unique" on a flattened layout (some labels end up NULL and the
NULL condition needs to be checked). Also remembered to update
VERSION, which was missed on the last commit.
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.
depending on the order of extraction devices. Specifically, the
case of a source-drain tied FET was breaking out of a loop when
it should have been breaking out of a double loop.
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.
"unexpected asymmetric device" is printed prematurely, as it
is inside a loop checking over all device entries compatible
with a device type. Also: Flagged an issue with the "label"
keyword in the "cifinput" section of a tech file. The "label"
keyword cannot be used in conjunction with boolean operators.
It can only connect labels on a specific GDS type to one magic
type. Unfortunately, because this was not flagged before as
an error or warning, the incorrect usage has crept into a lot
of tech files. This uncovers an underlying issue that labels
must be allowed to automatically reconnect types, which is
undermined by the "no-reconnect-labels" cifinput option. That
issue will be addressed in an upcoming commit.
front of the list during extraction, except that after copying
they're not. Removed the expectation, although that causes the
entire linked list of labels to be parsed and may cause excessive
run-times in pathological situations. Keep an eye out for
unintended consequences.
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.
to be declared for each device model, so that different models can
be specified for different parameter ranges. For example, this
will simplify the definition of the high-sheet-rho poly resistors
and the bipolar transistors in sky130 by removing the need for ID
marker layers; it also allows the correct device model to be
extracted when reading data from GDS that does not contain the
extra (and not foundry-approved) ID markers.
list for output, but that the code in ExtRegion.c does not sort a
region's label list to keep ports at the beginning of the list. So
any net with multiple labels may end up with a non-port label as
the name of the node, which eventually becomes the name of the port.
A quick fix keeps these lists sorted.
Darryl L. Miles
Tim Edwards
Johan Euphrosine