When constifying there is this inconsistent quirk in this API returning
'filename' or a malloced storage. When special handling needs to be
made by the caller to detect this to decide if it needs a free.
This appears to done to save a strdup().
Make it always return a malloc block so the API contract is
strightforward to the caller. A non-NULL return requires
free() by the caller.
This commit related to the dynamic creation of data that is used
to parse commands and options via Lookup.
windows/windows.h: Lookup() constify call-site
tcltk/tclmagic.c: Lookup() constify call-site
graphics/W3Dmain.c: Lookup() constify call-site
windows/windSend.c: Lookup() constify call-site
windows/windMain.c: Lookup() constify call-site
windows/windInt.h: Lookup() constify call-site
textio/txMain.c: Lookup() constify call-site
ext2spice/ext2spice.c: Lookup() constify call-site
ext2sim/ext2sim.c: Lookup() constify call-site
windows/windCmdAM.c: Lookup() constify call-site
Tcl_SetResult() uses cast to remove 'const' from type, the pointer
is only used to take a copy of the data, the lack of 'const' is due
to Tcl heritage when supporting C89 era compilers.
TCL9 appears to fix this, in that the macro used ends up at
Tcl_NewStringObj() which has 'const' here.
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
Darryl L. Miles