Legacy compiler support macro provided by TCL from a time when 'const'
did not exist.
This looks like it was put in place around the time of TCL 8.4
(from 2002 until 2013) which introduced APIs with 'const' types,
that were previously non-const. Probably due to legacy compiler
support across target platforms at the time.
Since the minimum TCL level is hardwired to 8.5 (from 2007 until
2016) it does not seem like that compatiblity is a current
requirement.
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
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
grTOGL3.c:230:5: warning: variable 'font' is used uninitialized whenever switch default is taken
clang18 -Wall warning cleanup [-Wsometimes-uninitialized]
grTk3.c:203:5: warning: variable 'font' is used uninitialized whenever switch default is taken
clang18 -Wall warning cleanup [-Wsometimes-uninitialized]
EFdef.c:110:12: warning: suggest parentheses around assignment used as truth value
EFdef.c:154:12: warning: suggest parentheses around assignment used as truth value
EFdef.c:167:12: warning: suggest parentheses around assignment used as truth value
EFflat.c:546:17: warning: suggest parentheses around assignment used as truth value
EFflat.c:798:12: warning: suggest parentheses around assignment used as truth value
EFflat.c:930:13: warning: suggest parentheses around assignment used as truth value
EFflat.c:1152:12: warning: suggest parentheses around assignment used as truth value
EFflat.c:1157:13: warning: suggest parentheses around assignment used as truth value
EFhier.c:84:12: warning: suggest parentheses around assignment used as truth value
EFhier.c:261:12: warning: suggest parentheses around assignment used as truth value
EFhier.c:489:12: warning: suggest parentheses around assignment used as truth value
EFhier.c:682:12: warning: suggest parentheses around assignment used as truth value
EFname.c:325:12: warning: suggest parentheses around assignment used as truth value
EFname.c:584:13: warning: suggest parentheses around assignment used as truth value
EFname.c:632:16: warning: suggest parentheses around assignment used as truth value
EFname.c:765:16: warning: suggest parentheses around assignment used as truth value
EFname.c:977:12: warning: suggest parentheses around assignment used as truth value
EFsym.c:113:13: warning: suggest parentheses around assignment used as truth value
EFsym.c:164:9: warning: suggest parentheses around assignment used as truth value
EFvisit.c:322:12: warning: suggest parentheses around assignment used as truth value
EFvisit.c:627:12: warning: suggest parentheses around assignment used as truth value
EFvisit.c:881:16: warning: suggest parentheses around assignment used as truth value
EFvisit.c:917:12: warning: suggest parentheses around assignment used as truth value
grTk1.c:1325:9: warning: suggest parentheses around assignment used as truth value
grTk1.c:1342:9: warning: suggest parentheses around assignment used as truth value
grTk1.c:1757:9: warning: suggest parentheses around assignment used as truth value
grTk1.c:1766:9: warning: suggest parentheses around assignment used as truth value
grTk5.c:177:12: warning: suggest parentheses around assignment used as truth value
grTOGL1.c:1095:9: warning: suggest parentheses around assignment used as truth value
grTOGL1.c:1111:9: warning: suggest parentheses around assignment used as truth value
grTOGL1.c:1542:13: warning: suggest parentheses around assignment used as truth value
grTOGL1.c:1551:13: warning: suggest parentheses around assignment used as truth value
grTOGL5.c:201:12: warning: suggest parentheses around assignment used as truth value
grTCairo1.c:1093:13: warning: suggest parentheses around assignment used as truth value
grTCairo1.c:1109:13: warning: suggest parentheses around assignment used as truth value
grTCairo1.c:1493:21: warning: suggest parentheses around assignment used as truth value
grTCairo1.c:1502:21: warning: suggest parentheses around assignment used as truth value
grTCairo5.c:202:16: warning: suggest parentheses around assignment used as truth value
GCC14 -Wall cleanup series [-Wparentheses]
Solution is to make the grX11thread.c and grX11su1[5].c versions
the official location. Another solution maybe to split them into
their own file grX11common.c that would be shared.
Multiple configurations tested, tested configurations assume X11
is available. The configuration wording indicates X11 must be
available for all graphics enabled build configurations.
Affected symbols appear to have multiple definitions:
grCursors
grXdpy
grXscrn
pipeRead
pipeWrite
Xhelper
grVisual
GCC14 and linker will not link the final executable due to this.
GCC14 --without-tk --without-tcl
Related issue: https://github.com/RTimothyEdwards/magic/issues/323
request #325 from Daryl Miles. Made a few simple style changes
to conform to (what is vaguely defined as) the overall programming
style for magic (passed down from John Ousterhout).
This is a defensive fix, might cause unexpected program exit if triggered.
The loop will iterate at least once when nbytes==0, but this value
indicates XLookupString did not fill in any data, so the entire buffer
is undefined.
Using memset() before or inChar[0]=0 after XLookupString did not fix
the issue. Using inChar[0]=0 immediately before the loop did fix as
well. But this patch seems to be the best approach.
This is technically a false positive as grClipPoints() will always
initializes a value to ok1 and ok2 when called. The function is in
the same compile unit, so probably the compiler can see this as well
and potentially not perform the initiailization begin performed in
this commit.
But to quieten and remove this item from the analysis report
assigning an initialization value.
SonarCloud
graphics/grClip.c:451 Branch condition evaluates to a garbage value
https://sonarcloud.io/project/issues?open=AZJB160MNGfDNup0Rit4&id=dlmiles_magic
Looks like old code. Looks like local variable 'j' could be removed.
Initialization lowers the severity of concern in this area.
The 'j' variable is now written but never read.
SonarCloud
graphics/cairo_orig/grTCairo3.c:492
The left expression of the compound assignment is an uninitialized value. The computed value will also be garbage
https://sonarcloud.io/project/issues?open=AZJB16voNGfDNup0Rig_&id=dlmiles_magic
Fix code scanning alert no. 98: Wrong type of arguments to formatting function (#44)
Co-authored-by: Copilot Autofix powered by AI <62310815+github-advanced-security[bot]@users.noreply.github.com>
Fix code scanning alert no. 150: Incorrect return-value check for a 'scanf'-like function (#8)
* Create codeql.yml
* Fix code scanning alert no. 150: Incorrect return-value check for a 'scanf'-like function
Co-authored-by: Copilot Autofix powered by AI <62310815+github-advanced-security[bot]@users.noreply.github.com>
* Update grCMap.c
* AI suggested '< 1', DLM edited to '<= 0' easier for a human to reason about ?
---------
Co-authored-by: Copilot Autofix powered by AI <62310815+github-advanced-security[bot]@users.noreply.github.com>
Fix code scanning alert no. 151: Incorrect return-value check for a 'scanf'-like function (#7)
* Create codeql.yml
* Fix code scanning alert no. 151: Incorrect return-value check for a 'scanf'-like function
Co-authored-by: Copilot Autofix powered by AI <62310815+github-advanced-security[bot]@users.noreply.github.com>
* Update grDStyle.c
* AI suggested '< 1', DLM edited to '<= 0' easier for a human to reason about ?
---------
Co-authored-by: Copilot Autofix powered by AI <62310815+github-advanced-security[bot]@users.noreply.github.com>
a filename causes an error instead of generating a trash filename
or crashing, while (2) "plot pnm" with a filename that has the ".pnm"
extension does not add another ".pnm" extension to the end of it.
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).
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).
Alessandro De Laurenzis. That pull request cleaned up the vast
majority of compiler warnings. However, that cleanup exposed a
few additional warnings pointing to errors in the code that needed
fixing. The code now compiles cleanly except for one warning
about redefined CAD_DIR that I have not looked into.
Tim Edwards
Darryl L. Miles
Alessandro De Laurenzis