Remove limited use HAVE_ZLIB wrapper API into separate header as
utils.h is used in many places and most source files don't need
to drag in the header file from this external dependency.
Copyright date(s) taken from original source file / git blame.
rename symlink(s) use phony targets, delegate the symlink creation
management command sequence to a single point in the project inside
the readline/Makefile
When global <sys/mman.h> was removed from tile.h it also removed
<unistd.h> nearby. This exposes the lack of <unistd.h> being
included where needed using APIs like close()/read()/unlink()/isatty()
the WASM build seems to show this as the header file set is structured
differently.
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.
interactive wiring into coordinate-based commands. Added new
command extensions for "wire leg", "wire vertical", "wire type",
and "wire horizontal". Modified the command logging such that
"wire show" (which does not modify layout) does not get logged,
which avoids unnecessary logging of mouse movement.
In the TCL8 to TCL9 porting information it was indicated the
sentinal NULL termination should be cast (char *) with API
call Tcl_AppendResult().
This was already in place for most of the codebase this
resolves the last few places.
Argument order and type declaration mismatches:
Label *
portFindLabel(editDef, port, unique, nonEdit)
CellDef *editDef;
bool unique;
bool port; // If TRUE, only look for labels that are ports
bool *nonEdit; // TRUE if label is not in the edit cell
This warrants inspection at call site CmdLQ.c:1712 as both types are bool
is it not so straightforward to check.
It looks like when PORT_MAKE is the option 'port make [index] [dir...]'
port=FALSE is this the correct intention ? This looks ok in that
we're searching for labels to make (upgrade) into ports.
Where as all other 'port ....' commands are operating on items that are
already ports, and ignoring labels.
So the K&R argument name order is also how the call-sites are using it.
void
cmdStatsHier(parent, nuses, child)
CellDef *parent, *child;
int nuses;
This was checked and found ok as callback to ../database/DBcount.c
DBTreeCountPaint(... hiercount, ...)
Due to this not-obvious K&R style also being used in the documentation
this was changed as well (in another commit0.
K&R obsolete syntax removal for C23 compatibility series
Functions do not appear to exist:
extern MagWindow *CmdGetRootBox();
extern void CmdAddSlop();
extern void CmdDoMacro();
K&R obsolete syntax removal for C23 compatibility series
CmdCD.c:3693:14: warning: variable 'option' is used uninitialized whenever 'if' condition is false
CmdCD.c:3691:9: warning: variable 'option' is used uninitialized whenever 'if' 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)
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]
Wrong type of arguments to formatting function
Looks like SPICE comment, change maintains hex without 0x prefix in portable way.
Copilot Autofix rejected: TxPrintf("%p\n", tp);
CodeQL: https://github.com/dlmiles/magic/security/code-scanning/65
No AI resolution.
The NULL added is cdata which looks to be opaque callback user-defined-pointer,
this is not used in the method printPropertiesFunc() as a possible 3rd argument.
CodeQL: https://github.com/dlmiles/magic/security/code-scanning/157
which prevents the "Ctrl-P" key from raising the .params window;
the underlying error is that the original error in the "property"
command was a disagreement about where "argstart" is placed. The
command was fixed to make the "property" command work correctly.
However, the solution made "argstart" wrong when using the command
"cellname property". Now both uses are handled correctly.
added fairly recently when getting rid of crashes related to
commands operating on non-edit cells. The lack of a cast was
prevening compilation on systems with more rigorous error
checking.
assign the result to anything, causing later uses of variable
"lobj" to have an unitialized value and potentially causing a
crash condition. Thanks to Risto Bell for pointing out the
error.
some of the "select" command syntax; the code change caused the
"select top cell" command to behave the same as "select cell".
There was no specific code for handling "top", so now there is.
method of messing with the argument count when using qualifiers
like "less" and "more". Now it keeps a separate count of the
number of non-qualifier arguments.
behavior when a child coordinate is not specified; otherwise,
the original code's setting of the child reference point to the
bounding box lower left causes the lower left point to be
used always, which is not how the getcell command is supposed to
function.
to place a cell in a meaningless position for any rotation and flip
combination other than zero. The issue was that the reference point
was not rotated along with the cell.
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).
"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.
so that it does not fail if an edit cell is not loaded, but
simply loads the default unnamed edit cell. This is somewhat bad
behavior in the case of reading GDS, since if the GDS is a library
and does not have a top level cell that matches the name of the
GDS library, then the edit cell that is loaded when the "gds read"
command is issued remains unchanged, so it didn't need to be there
in the first place. Fixing this to behave better would require a
bit of additional work.
the time the option was implemented), and also implemented (and
documented!) a similar command option "extract stepsize" for
reporting or changing the extraction step size.
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.
Darryl L. Miles
Tim Edwards
Carsten Wulff