This value appears to be initialised at only one spot in the codebase
(under very narrow conditions) but extresist will read it and make
branching decisions based on the uninitialised state.
This 'X' state propagation appears to eventually get processed in
ResWriteExtFile() near where final output formatting is occurring.
It is unclear (at this time) if it perturbs output values in a
problematic way, or if due to algorithmic reasons the data is
discarded before output anyway. I have at least one trace run (with
multiple triggers) of printf formatters handling uninitialised data
in ResWriteExtFile().
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.
Darryl L. Miles
Tim Edwards