Removes 1312 warning lines from build output due to inline nature of use.
bplane/bpEnum.h:509:10: warning: suggest parentheses around assignment used as truth value
bplane/bpEnum.h:513:10: warning: suggest parentheses around assignment used as truth value
bplane/bpEnum.h:517:10: warning: suggest parentheses around assignment used as truth value
bplane/bpEnum.h:521:10: warning: suggest parentheses around assignment used as truth value
bbplane/bpEnum.h:525:10: warning: suggest parentheses around assignment used as truth value
GCC14 -Wall cleanup series [-Wparentheses]
Compiler is expressing range concern with the warning mitigated by using
unsigned C array offsets. This also draws attention to the range concern
when reading the code and making changes.
DBundo.c:263:45: warning: array subscript has type 'char'
DBundo.c:279:49: warning: array subscript has type 'char'
DBundo.c:317:52: warning: array subscript has type 'char'
DBundo.c:318:64: warning: array subscript has type 'char'
DBundo.c:324:52: warning: array subscript has type 'char'
DBundo.c:325:64: warning: array subscript has type 'char'
DBundo.c:329:50: warning: array subscript has type 'char'
DBundo.c:330:58: warning: array subscript has type 'char'
DBundo.c:338:52: warning: array subscript has type 'char'
DBundo.c:339:64: warning: array subscript has type 'char'
DBundo.c:345:52: warning: array subscript has type 'char'
DBundo.c:346:64: warning: array subscript has type 'char'
DBundo.c:350:50: warning: array subscript has type 'char'
DBundo.c:351:58: warning: array subscript has type 'char'
DBundo.c:371:52: warning: array subscript has type 'char'
DBundo.c:372:64: warning: array subscript has type 'char'
DBundo.c:378:52: warning: array subscript has type 'char'
DBundo.c:379:64: warning: array subscript has type 'char'
DBundo.c:383:50: warning: array subscript has type 'char'
DBundo.c:384:58: warning: array subscript has type 'char'
DBundo.c:392:52: warning: array subscript has type 'char'
DBundo.c:393:57: warning: array subscript has type 'char'
DBundo.c:399:52: warning: array subscript has type 'char'
DBundo.c:400:57: warning: array subscript has type 'char'
DBundo.c:403:53: warning: array subscript has type 'char'
DBundo.c:407:50: warning: array subscript has type 'char'
DBundo.c:408:58: warning: array subscript has type 'char'
EFbuild.c:1048:32: warning: array subscript has type 'char'
EFbuild.c:1056:32: warning: array subscript has type 'char'
ExtBasic.c:2358:43: warning: array subscript has type 'char'
ExtBasic.c:2493:43: warning: array subscript has type 'char'
ExtBasic.c:2519:43: warning: array subscript has type 'char'
ExtBasic.c:2644:43: warning: array subscript has type 'char'
ExtBasic.c:2678:43: warning: array subscript has type 'char'
ResPrint.c:143:43: warning: array subscript has type 'char'
plotRutils.c:713:34: warning: array subscript has type 'char'
plotRutils.c:786:29: warning: array subscript has type 'char'
GCC14 -Wall cleanup series [-Wchar-subscripts]
Give compiler the extra braces it recommends.
DBio.c edited as my original change was caught out by the incorrect
indention of the 'else' keyword and my modification would have caused a
NULL deref. Exactly the kind of issue this warning is trying to prevent.
CmdTZ.c:417:20: warning: suggest explicit braces to avoid ambiguous 'else'
DBio.c:1422:12: warning: suggest explicit braces to avoid ambiguous 'else'
DBpaint2.c:285:12: warning: suggest explicit braces to avoid ambiguous 'else'
DBpaint2.c:384:12: warning: suggest explicit braces to avoid ambiguous 'else'
GCC14 -Wall cleanup series [-Wdangling-else]
Added pointer casts to hint to compiler the programmer intention
is to compare as pointers to the start of the array (and not be
concerned the programmer is overlooking the contents of the array).
GCC14 -Wall cleanup series [-Warray-compare]
False positive.
Added no-op case statement, but code above looks the case should never
execute due return from function.
GCC14 -Wall cleanup series [-Wswitch]
Use of macro idiom: if(1) { ... } else
which has dangling else keyword to allow trailing semicolon at
use site, is not a good pattern.
Replaced with idiom: do { ... } while(0)
which should achieve the same purpose but now cause compile
error when used incorrectly at use site.
GCC14 -Wall cleanup series [-Wmisleading-indentation]
Use of macro idiom: if(1) { ... } else
which has dangling else keyword to allow trailing semicolon at
use site, is not a good pattern.
Replaced with idiom: do { ... } while(0)
which should achieve the same purpose but now cause compile
error when used incorrectly at use site.
GCC14 -Wall cleanup series [-Wmisleading-indentation]
Looks like logic error hiding behind warning
DRCtech.c:4365:22: warning: use of logical '&&' with constant
operand [-Wconstant-logical-operand]
DRCtech.c:4365:22: note: remove constant to silence this warning
clang18 default warning cleanup
Looks like a logic bug, hiding behind this compiler warning
lefTech.c:507:21: warning: suggest parentheses around assignment used as truth value
lefTech.c:509:21: warning: suggest parentheses around assignment used as truth value
GCC14 -Wall cleanup series [-Wparentheses]
It is a requirement to define feature_test_macros(7) as soon as possible
before including any files, otherwise the headers may not allow further
configuration, as reconfiguration maybe denied. You need to pick the
standard you wish to work with for the compilation unit (the file).
This can be seen with an error for lack of symbol `wcwidth()` from wchar.h
Moving the order slightly fixes the compile failure issue.
See feature_test_macros(7) for more info.
GCC14 --without-tk --without-tcl (without system libreadline-dev)
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
"extract unique notopports" both fail to work correctly because
an attempt some time ago to avoid issuing warnings about shorted
port names when using those options was changed in the wrong
line.
angled edges. This is a rare case and so has never come up before,
but can happen especially on transistors with gate or diffusion
with 45 degree chamfers or flanges. Thanks to Mark Martin for
providing the use case.
it claimed to fix, but caused an incorrect DRC maxwidth check
instead. The problem appears to be correctly resolved now.
Also: Tracked down a recently-introduced minor issue in which
the interactive DRC stops running after issuing "drc check" and
does not resume until another key or mouse even occurs. This
turned out to be caused by the work on the "logcommands" command,
which should have used "*bypass" before "logcommands suspend"
and "logcommands resume", since the "*bypass" indicates that
the command has no impact on layout and should not interrupt
the DRC checker.
respect to using the 3rd mouse button to hide a layer, and
indicating the layer is hidden by blanking the icon (which works
better with the new scrollable icon list, but got broken by the
same). Also: Added a previously missing behavior, which is to
correctly update the icon settings based on using the command
"see" and "see no" with layer aliases (e.g., "allm1").
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).
The main cause of the crash was the path for UNDO_CELL_PLACE this was
trigged by performing a number of cell create/move operations (unknown
exactly what sequence). Then a large number of "undo" operations.
There is an ASSERT in findUse() but that does not seem built into the
release (or debug CFLAGS=-g3) builds.
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.
Darryl L. Miles
Tim Edwards