commit 86b5d591d from 20241004 by me, modified return type of
GrTextSize API in the graphics from 'void' to 'int' to convey
and error scenario to indicate when 'r' was not filled in for
the caller, but this is a multi graphics driver API interface
so requires all downstream graphics engines to also support
the return type change.
This API can error and indicates when 'Rect *r' was
successfully updated.
The old code would only work is the fileno(stream) returned an fd
in the range 0 <= 19. It would silently fail, if the fd was in
the range 20..1023 because FD_SET() would work and syscall select()
would be limited to only look at the first 20 fd's. Ignoring any
fd's higher even if set.
This would theoretically cause high CPU usage due to select()
never blocking because there are no active fd's in the fd_set
as far as the kernel interprets the request and the kernel would
immediately return.
But reading the code the 1st argument to select() seems self
limiting for no good reason. It should be fileno(stream)+1 as
documented in man select(2).
Added the assertion as well, because we are trying to allow magic
to use fd's beyond the standard environmental limits. So it
becomes an assertion condition if the fd is outside the range
0..1023 because the FD_SET() macro will not operate correctly /
undefined-behaviour.
I can't find any user of this func in the codebase right now.
If you look at sim/SimRsim.c and the use of select() there, it is
correctly using select() to wait on a single fd over there. This
commit changes this code to match this correct usage.
created use of 'alloc' local variable to track when an allocation occurred
so exit path logic is more straight forward for compiler/analyser to see
potential optimisations.
the previous version was probably working just fine
ourgl local variable is set to a non-NULL value (first initialization)
in code that is in lines below where it is dereferenced in a loop.
Somewhere in the loop there is a point where the precondition of ourgl
being set to non-null is expected.
ASSERT added.
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.
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
Darryl L. Miles
Tim Edwards