bpMain.c:265:11: warning: suggest parentheses around assignment used as truth value
CmdSubrs.c:413:12: warning: suggest parentheses around assignment used as truth value
CmdSubrs.c:759:13: warning: suggest parentheses around assignment used as truth value
CmdFI.c:1600:12: warning: suggest parentheses around assignment used as truth value
DBcell.c:109:12: warning: suggest parentheses around assignment used as truth value
DBcellname.c:2512:9: warning: suggest parentheses around assignment used as truth value
DBcellsrch.c:95:12: warning: suggest parentheses around assignment used as truth value
DBio.c:3998:9: warning: suggest parentheses around assignment used as truth value
DBlabel2.c:228:9: warning: suggest parentheses around assignment used as truth value
DBWelement.c:195:12: warning: suggest parentheses around assignment used as truth value
DBWelement.c:197:13: warning: suggest parentheses around assignment used as truth value
DBWelement.c:295:12: warning: suggest parentheses around assignment used as truth value
DBWelement.c:297:13: warning: suggest parentheses around assignment used as truth value
DBWelement.c:637:12: warning: suggest parentheses around assignment used as truth value
DBWelement.c:639:13: warning: suggest parentheses around assignment used as truth value
DBWelement.c:679:12: warning: suggest parentheses around assignment used as truth value
DBWelement.c:681:13: warning: suggest parentheses around assignment used as truth value
DRCtech.c:1219:17: warning: suggest parentheses around assignment used as truth value
DRCtech.c:1368:17: warning: suggest parentheses around assignment used as truth value
DRCtech.c:1471:17: warning: suggest parentheses around assignment used as truth value
DRCtech.c:1543:17: warning: suggest parentheses around assignment used as truth value
DRCtech.c:1676:17: warning: suggest parentheses around assignment used as truth value
DRCtech.c:1772:21: warning: suggest parentheses around assignment used as truth value
DRCtech.c:1919:17: warning: suggest parentheses around assignment used as truth value
DRCtech.c:2099:17: warning: suggest parentheses around assignment used as truth value
DRCtech.c:2324:17: warning: suggest parentheses around assignment used as truth value
DRCtech.c:2713:17: warning: suggest parentheses around assignment used as truth value
DRCtech.c:2830:17: warning: suggest parentheses around assignment used as truth value
DRCtech.c:2944:17: warning: suggest parentheses around assignment used as truth value
DRCtech.c:3097:21: warning: suggest parentheses around assignment used as truth value
DRCtech.c:3144:21: warning: suggest parentheses around assignment used as truth value
DRCtech.c:3181:21: warning: suggest parentheses around assignment used as truth value
DRCtech.c:3215:9: warning: suggest parentheses around assignment used as truth value
DRCtech.c:3227:21: warning: suggest parentheses around assignment used as truth value
DRCtech.c:3261:21: warning: suggest parentheses around assignment used as truth value
DRCtech.c:3459:17: 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]
Give compiler the extra braces it recommends.
DBio.c edited as my original change was caught out by the incorrect
indention of the 'else' keyword and my modification would have caused a
NULL deref. Exactly the kind of issue this warning is trying to prevent.
CmdTZ.c:417:20: warning: suggest explicit braces to avoid ambiguous 'else'
DBio.c:1422:12: warning: suggest explicit braces to avoid ambiguous 'else'
DBpaint2.c:285:12: warning: suggest explicit braces to avoid ambiguous 'else'
DBpaint2.c:384:12: warning: suggest explicit braces to avoid ambiguous 'else'
GCC14 -Wall cleanup series [-Wdangling-else]
it claimed to fix, but caused an incorrect DRC maxwidth check
instead. The problem appears to be correctly resolved now.
Also: Tracked down a recently-introduced minor issue in which
the interactive DRC stops running after issuing "drc check" and
does not resume until another key or mouse even occurs. This
turned out to be caused by the work on the "logcommands" command,
which should have used "*bypass" before "logcommands suspend"
and "logcommands resume", since the "*bypass" indicates that
the command has no impact on layout and should not interrupt
the DRC checker.
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).
The main cause of the crash was the path for UNDO_CELL_PLACE this was
trigged by performing a number of cell create/move operations (unknown
exactly what sequence). Then a large number of "undo" operations.
There is an ASSERT in findUse() but that does not seem built into the
release (or debug CFLAGS=-g3) builds.
Fix code scanning alert no. 30: Multiplication result converted to larger type (#55)
Co-authored-by: Copilot Autofix powered by AI <62310815+github-advanced-security[bot]@users.noreply.github.com>
Fix code scanning alert no. 132: Redundant null check due to previous dereference (#39)
* Update DBio.c
* AI wanted to move guard 'pathptr != NULL' up to 1953, but it is assigned to guaranteed non-null in every assignment above and only incremented or dereferenced.
---------
Co-authored-by: Copilot Autofix powered by AI <62310815+github-advanced-security[bot]@users.noreply.github.com>
Fix code scanning alert no. 66: Wrong type of arguments to formatting function (#33)
Co-authored-by: Copilot Autofix powered by AI <62310815+github-advanced-security[bot]@users.noreply.github.com>
Fix code scanning alert no. 10: Call to function with fewer arguments than declared parameters (#14)
Co-authored-by: Copilot Autofix powered by AI <62310815+github-advanced-security[bot]@users.noreply.github.com>
Fix code scanning alert no. 9: Call to function with fewer arguments than declared parameters (#15)
Co-authored-by: Copilot Autofix powered by AI <62310815+github-advanced-security[bot]@users.noreply.github.com>
Fix code scanning alert no. 135: Incorrect return-value check for a 'scanf'-like function (#12)
* Create codeql.yml
* Fix code scanning alert no. 135: 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>
the same: (1) If the inodes of the filename are the same, then the
cells are the same. This avoids treating symbolic links as
different paths with different files; (2) If both layouts are in
git repositories and the git repository commit hashes are the same,
then the cells are considered to be the same. This allows projects
to be cloned into other projects as dependencies and used in
multiple places without magic treating them as different layouts.
in the .mag file "properties" list are not handled as being in
database units during .mag file reading and writing (although they
do track internally), making them subject to being scaled incorrectly
and change between a read and a write. Thanks to Sylvain Munaut for
identifying the problem.
is erased. In cases where magic would previously unattach the
label from the material and attach it to "space", now magic will
instead adjust the size of the label to stay entirely on the
material. That avoids a common error of losing label or port
connections when the material is trimmed back. Thanks to Philipp
Guhring for suggesting this implementation (github issue #305).
a .mag file to include the original system path. This restores the
ability to find the tech file for any cell created using the old
SCMOS technologies. This method is as problematic as is the way
all SCMOS tech files used the same name "scmos". But at least it
preserves backwards-compatible behavior (behavior prior to 8.3.471).
This commit corrects github issue #306.
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.
reduce the amount of redundant painting done by the connectivity
search algorithm, but which was preventing composed types (such
as FET gates) from getting added to a net if one of the composing
types (such as poly) was drawn over the device in an ancestor
cell. Removing the "if" statement does not appear to have any
significant performance impact, so this change is being adopted.
contains brackets which are not indicating a cell array. Also
fixed a related issue with the PDK toolkit code, in which the
gencell routines fail if an instance name contains brackets which
are not indicating a cell array.
name. The instance search routine was not rejecting internal cells,
and so would choose, e.g., a selection cell and reject it because it
was not the edit cell.
`magic/database/DBio.c::DBOpenOnly` calls `dbReadOpen(CellDef *, bool, bool, int)` with a pointer for the second argument. While technically valid C, newer compilers (Clang 16) have recently frowned upon implicit pointer-to-int conversion, requiring the flag `-Wno-int-conversion` or else an error is raised.
Given that there is one such instance in the codebase, I think fixing it would be the simplest solution.
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).
all of its time running area searches on zero-area rectangles,
which was causing simple extractions to run hours. Checking for
a zero area rectangle and conditionally skipping the area search
resulted in a massive speed-up in parasitic extraction.
because commands issued during initialization set the DRC status
in a way that causes DRCContinuous() to return immediately.
Also: Implemented a slightly different method when automatically
finding the tech file from the input .mag file that loads a
technology .magicrc file if one exists. If not, just the .tech
file is loaded. This replaces the method of a previous commit
that loads the technology .tcl script. The .magicrc file will
include the .tcl script but does other things as well.
out where to find the technology corresponding to a file given on
the command line: (1) Changed the default search location from
/usr/share/pdk to /usr/local/share/pdk, which is the actual default
for open_pdks (can still be overridden by environment variable
PDK_ROOT). (2) Made the PDK name by itself preferable to the PDK
name plus any extension when searching (e.g., "sky130A" is preferred
over "sky130A_backup"). (3) Check the located directory for any
file <tech_name>.tcl and source it if it exists. (4) Run any tag
callbacks on the "tech load" command, which rebuilds the tool icons.
unrelated nets to be captured in the same selection, due to the
use of the label bounding box instead of the label rectangle.
The bounding box is used for display only and should not be used
for connectivity.
argument, which is supposed to flatten all selected instances.
After flattening, instead of deleting the instance from the
cell, it deleted the instance from the selection, leaving the
one in the cell.
and would keep files open (even though they were not marked as
locked) and not close them, causing an open file descriptor overflow
when too many files are read for the same design.
perimeter are not initialized, and if a terminal perimeter/area
calculation is missed (which is happening on devices with terminals
in planes other than the plane of the identifying type), then the
perimeter/area of a previously handled device will get output.
(2) Corrected an error with "flatten -inplace" in which the command
fails to deal with instance arrays.
previous behavior that had inadvertently been changed. In recent
versions, "load <absolute_path> -dereference" would incorrectly
apply the dereferencing to <absolute_path> rather than just its
subcells. Cleaned up the code around DBCellRead() in the process,
so everything is more straightforward (although probably more
could be done in that regard).
of the cell. This will greatly help in diagnosing issues when
reading cells from multiple locations including cwd, relative
paths, PDK libraries, and the search path. Also: Reworked
the timestamp update message so that it prints all at once at
the end of processing, not printing output for every cell
processed as it is being processed. That prevents output from
the file read routine from getting interleaved with the
timestamp processing output.
labels that are not connected to their declared layers. It's the
latter type that need additional processing in ExtSubtree.
Limiting this processing significantly cuts down on processing
time when there are many labels in a layout, as happens with the
"def read -labels" command option.
dereferencing, and making the behavior of "load" on the command
line (i.e., loading a cell from a file) the same as the
behavior of loading a cell as a result of expanding an unloaded
instance. In both cases, if "load -dereference" is used, and
a cell does not exist in any search path but does exist in the
original location, without dereferencing, then the cell will be
loaded from the original location. Also: Corrected an error
that has existed since adding the capability to read compressed
files, which causes magic to crash when attempting to run the
"crash recover" command (because that routine was mixing
compressed and regular file stream calls).
check was too aggressive and would delete coincident instances
based on cell def and bounding box only. If the cells were at
different orientation or mirrored, they would be incorrectly
flagged as coincident. Instances read from GDS could be
deleted due to this issue.
natural sort instead of ASCII-based sorting, so that ports that
are numbered arrays will be indexed properly by count. Also:
Modified the "extresist" handling of substrate to draw the default
substrate type over the entire cell area (less areas of nwell or
other conflicting type). This allows extresist to extract the
entire substrate as a resistive network. The result is ugly and
may warrant some aggressive network simplification, but it should
at least be realistic.
isolate the terminal areas of a device (e.g., source and drain)
and calculate their area and perimeter individually for the
device (in addition to the traditional method of calculating
area and perimeter of each resistance class for the entire node).
Also: Reworked the SPICE syntax output to generate SI values
in the range 1-1000 with the appropriate suffix (e.g., "20u")
instead of defaulting to "u" for lengths and "p" for areas.
This prevents it from producing weird units like "150000u" when
a process definition already includes a scalefactor.
Reworked the "extresist" code to use the device terminal area
and perimeter. This fixes an error in which "extresist" would
lose these values and "ext2spice" with option "extresist on"
would generate a new netlist output with zero terminal areas
and perimeters.
Darryl L. Miles
Tim Edwards
Mohamed Gaber
Anton Blanchard