DBTreeCountPaint(def, count, hiercount, cleanup, cdata)
callback hiercount()
The K&R function prototype syntax in the documentation might confuse
reader into which argument order is correct (as a modern developer
might be out of practice with interpreting K&R syntax)
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
This direction was chosen due to #define integer use of special values
instead of TRUE/FALSE. This makes the prototype and use consistent
removing compiler warning from recent K&R removal.
Beware of the MISMATCH with the prototype found in original
source, with the type declaration below.
External call sites checked to confirm argument order is
correct with the argument name order.
// nedges <> dir
bool
cifOrient(edges, nedges, dir)
CIFPath *edges[], /* Array of edges to be categorized. */
int dir[], /* Array to hold directions. */
int nedges) /* Size of arrays. */
// spacing <> border
int
CIFGetContactSize(type, edge, spacing, border)
TileType type,
int *edge,
int *border,
int *spacing)
K&R obsolete syntax removal for C23 compatibility series
The data types CIFPath and CIFReadStyle are part of CIFread.h
and all users outside include CIFread.h already.
K&R obsolete syntax removal for C23 compatibility series
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
Darryl L. Miles