The use of 'scount' in this function looks complex, it seems to be reset to
zero sometimes and incremented at others. Analysis shows there is a possible
path where is maybe used uninitialized.
Setting to zero seems like a good choice.
SonarCloud
grDStyle.c:514 The left operand of '<' is a garbage value
https://sonarcloud.io/project/issues?open=AZJB16zUNGfDNup0RiqE&id=dlmiles_magic
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
Adding ASSERT() to arguments to ensure passed arguments are non-NULL
better conveys API intent to both mitigate this false positive
but also allow analysis to inspect caller for correct usage.
SonarCloud
Null pointer passed as 1st argument to string length function
https://sonarcloud.io/project/issues?open=AZJB167jNGfDNup0RjGw&id=dlmiles_magic
Theoretical NULL pointer deref, assumes no iteration occurs.
Seems like false positive from incorrect caller use, from
passing suffix==NULL.
SonarCloud
Access to field 'hn_parent' results in a dereference of a null pointer (loaded from variable 'prev')
https://sonarcloud.io/project/issues?open=AZJB167jNGfDNup0RjGu&id=dlmiles_magic
In order for pname to be assigned a value the loop must have performed
an interation. The order of assignment and use of 'pname' is not the
natural order you'd expect. It also looks like the TxPrint message
may display the incorrect port name from the previous loop iteration.
The code block looks like the resolution of 'pname' has no side-effects.
So should be done first so the correct port name is output in the log message.
SonarCloud
2nd function call argument is an uninitialized value
https://sonarcloud.io/project/issues?open=AZJB17lqNGfDNup0Rk6f&id=dlmiles_magic
The -L option needs to be placed before the -l it needs to affect.
This maybe important on MacOSX where a nonstandard/optional package
provides X11 support so the locations are not in system locations.
Example build issue using MacOS 12 (Xcode 14.2 from MacOSX.platform).
In file included from grTk1.c:23:
In file included from ../utils/main.h:26:
In file included from ../windows/windows.h:26:
../utils/magic.h:143:13: warning: 'FREAD' macro redefined [-Wmacro-redefined]
#define FREAD(a,b,c,d) gzread(d,a,b*c)
^
/Applications/Xcode_14.2.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX.sdk/usr/include/sys/fcntl.h:110:9: note: previous definition is here
#define FREAD 0x00000001
time.h has existed since C89 so is a standard header expected
to always be available.
sys/time.h was an optional header that historically only some
platforms provided.
If there is a conflict on specific platforms it is better to
'#if !defined()' that specific niche platform with the problem
if both headers are included in the same compile unit. But I
don't think this is a problem in modern times.
So this results in a resolution that removes #ifdef around
time.h and the detection by configure for the availabiltiy
of sys/time.h.
K&R obsolete syntax removal for C23 compatibility series
"bloat-all" which is "bloat-all types1 types2 distance" where the
"distance" value is a maximum amount to grow. It is not (that I
know of) particularly useful for generating output GDS, but it is
very useful for generating temporary layers for DRC checks,
especially things like determining tap distance for latch-up
rules. The alternative (used in the sky130 tech file) is a
tedious step-by-step "grow" followed by "and-not". This rule
option is much cleaner to implement and computes faster (although
it is still a boolean operator and is much slower than an edge
rule).
identifies areas which meet the proper definition of run-length
(both edges are parallel for the run-length distance or more).
Previously, errors were getting triggered for geometry where
only one edge exceeded the run-length distance.
which has the same meaning as the "maxwidth" function ("both"
checks either tile dimension to see if it exceeds the maximum).
This is a simple per-tile check and assumes that violations do
not occur across multiple tiles. This should be sufficient for
most checks.
"angles"-type width rules when calculating the default metal
width DRC rule (this width when present will always be
larger than the minimum metal width), and (2) If an exiting
wire is larger than the contact size, then set the contact
size such that the contact PLUS the surrounding metal is the
width of the exiting wire. The existing code sets the
contact size itself to the width of the exiting wire, such
that when surrounding material is added, the contact is
larger than it needs to be. The fix to (1) will also fix
other places where the default DRC width rule is computed,
which includes LEF and DEF handling and computing rendered
text sizes when reading GDS.
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.
Darryl L. Miles
Carsten Wulff
Tim Edwards