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]
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.
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>
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.
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.
`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.
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.
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.
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.
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).
supported). Fixed the long-standing issue in which DRC does not
get stopped by the "drc off" command (the behavior for interrupting
the DRC was dependent on the DRC being turned on, and the "drc off"
command was turning it off before breaking, causing the interrupt
to be ignored).
This commit makes the code (mostly) C99-compatible, enabling to compile
it without the -Wno-error=implicit-function-declaration flag. This
way, Magic becomes usable on arm64 architectures, specifically on Apple
computers with M1/M2 SoC.
cell properties in natural sort order when writing a .mag file.
This should remove the last bit of indeterminism in the output
of magic database files.
time ago by cleaning up excess usage of "equiv" lines in the .ext
file output. The hierarchical extraction code did not distinguish
between node names which were output and those that were not,
requiring a setting "extract do aliases" to force all node aliases
to be output with "equiv" statements. So hierarchical names
might be any alias, whether output or not, and "merge" and "cap"
lines might contain references to nodes that were not output,
causing them to be disconnected nodes. This fix handles the
"extract no aliases" (default) case by flagging node names that
are redundant and not output, and not creating hierarchical names
with them.
underlying function from fprintf() to fputs(), which was changed for
gcc11 compatibility by Jean-Paul Chaput in github issue #123. Also
corrected a typo from the previous commit.
there was no distinction between a locked file and a new cell
(initial state) before writing to disk. This prevents any new cell
from being saved! Also: Revised the behavior of the "select short"
search, but this still has issues with long run-times on complex
layouts, so this is an ongoing effort.
whenever a process writes a cell to disk, it immediately releases the
file lock it had on that cell, which is clearly not the intent of file
locking. Fixed this issue. On a related topic, revised the "cellname
writeable" command so that it can make a cell editable even if the cell
has an advisory lock and cannot be made writeable. Perhaps there should
be a clearer distinction here between "writeable" and "editable". Also:
Reconsidered the previous commit, which removed the "--disable-locking"
from the configuration options. Because some operating systems may not
implement fnctl()-based file locking (Cygwin, for one, apparently doesn't),
it is still useful to be able to completely remove the function, in case
the operating system will fail to recognize the fnctl() values in the
code. Now, file locking behavior can be permanently removed through the
configuration option, or temporarily disabled from the command line.
this limited ports to 16384, which seemed reasonable at the time.
However, the sky130_sram_macro layouts connect power and ground in a
way that when coupled with "extract unique" can generate tens of
thousands of ports and overrun the bit field, showing that automation
can do the unexpected. The solution was to split out the port number
from the label record as its own 32-bit value.
work around the issue of loading a file containing references to
cells with the same name as cells already loaded. This is probably
going to cause additional headaches until a proper checksum method
is implemented.
when reading in a .mag file. The routine was not checking for
whether a "use" entry in the file was the first one encountered
or not. The path is only ever given for the first use of any cell
def, so for any cell after the first, the path should have already
been resolved. This fix avoids lots of unnecessary error messages
when reading a file in a different directory. Also, because the
routine now checks for the first use in a file, any error messages
that do occur will only be displayed for the first use, not all of
them.
and HOME substitution in filenames needs to watch for a NULL
cd_file, and (2) The routine that removes the (UNNAMED) cell when
another cell is loaded needs to NULL the boxRootDef pointer or else
it ends up pointing to deallocated memory.
This can be done now by reading a LEF file, followed by reading
a GDS file with the "noduplicates" option set. In addition,
annotation of either the LEF view or a read-only view follows the
same protocol as cell paths in the .mag file, which is to replace
leading path components matching Tcl variables for PDKPATH or
PDKROOT, and replace the home directory path with a tilde.
for saving on a cell which is completely unmodified. One of these
was due to the BPlane implementation, which forces an instance to be
deleted and re-placed on a bounding box recomputation, which should
not, in that case, be considered a modification. Another always runs
DRC on a subcell upon reading rather than relying on any checkplane
entries in the file itself; and the last one marking the timestamp
as modified stemming from an attempt to correct an O(N^2) check to
O(N). All three cases have now been corrected.
based on the contents of a .mag file being read in, assuming
compatibility with principles of open_pdks. The search paths
are not meddled with unless a file is read for which the technology
cannot be found (and a technology has not already been read, or at
least no database file exists in memory using any technology that
has already been read). If so, then variables PDK_PATH and PDK_ROOT
are searched for in both the shell environment and the local Tcl
environment. Also, if open_pdks has installed PDKs in the path
/usr/share/pdk/, then that path will be searched. If a corresponding
technology file is found, it will be loaded. If the path corresponds
to an open_pdks-style path, then the library paths in libs.ref will
also be added to the search paths for cells.
to stop the search whenever a cell is not found. Used this to implement
a new option for GDS writes, "gds undefined allow|disallow" (default
"disallow") controls whether or not GDS with undefined references will
be allowed to be written. Similarly affects CIF and LEF writes, extraction,
and DRC (when running "drc check" from the top).
to allow a "gds read" command to ignore cells in the GDS which already
exist in memory. This allows magic to be "pre-seeded" with specific
views of cells in the GDS. Default is false, which is backwards-
compatble behavior. (2) Changed the behavior of the the way the use
path is written to and read from a .mag file, checking the path prefix
against Tcl variables PDK_PATH, PDKPATH, PDK_ROOT, and PDKROOT, and
replacing any such leading path component with the variable name.
On reading a .mag file, any variable name at the start of the path
that matches a Tcl variable will be substituted.
unique" code. It was using DBEraseLabelsByContent() which would
erase all matching labels, and could potentially erase labels that
were still remaining on the list being processed, causing a segfault.
Also corrected minor errors identified by valgrind during debugging
the above-referenced problem.
easier to scan through a cell's ports. Used that capability in the
"readspice" script to handle case sensitivity problems, and to find
labels that are not ports and force them to be ports to match the
reference netlist.
Darryl L. Miles
Tim Edwards
Mohamed Gaber
Anton Blanchard
Alessandro De Laurenzis
Jean-Paul Chaput