Recent changes to bugs

BUILD FAIL: configure cannot guess build type

Jimmy Tian — Mon, 30 Jan 2023 06:57:42 -0000

Hi,

This is Jimmy from the ArchLinux RISC-V Team.

The config.guess file contained in the source code is too old to build on the latest architecture, such as RISC-V.

This can be fixed by generating new tarball by latest autotools.

We propose a one-time fix for this via upstream, which benefits all downstream package maintainers.

Thanks.

Jimmy

asn_bits.c:348: bad compare ?

dcb — Thu, 09 Jul 2020 13:06:03 -0000

asn_bits.c:348:64: warning: self-comparison always evaluates to true [-Wtautological-compare]

Source code is

return ( (b1->bitLen == b2->bitLen) &&
         (memcmp(b1->bits, b2->bits, octetsLessOne) == 0) &&
         (( b1->bits[octetsLessOne] & (0xFF << octetBits)) ==
          ( b1->bits[octetsLessOne] & (0xFF << octetBits))));

Maybe better code:

return ( (b1->bitLen == b2->bitLen) &&
         (memcmp(b1->bits, b2->bits, octetsLessOne) == 0) &&
         (( b1->bits[octetsLessOne] & (0xFF << octetBits)) ==
          ( b2->bits[octetsLessOne] & (0xFF << octetBits))));

#24 bad macro defn CHECK() in sapequal.c

chas williams — Wed, 24 Apr 2019 16:17:36 -0000

Some of are still here. I will look into fixing this. Thanks for the bug report!

#24 bad macro defn CHECK() in sapequal.c

Nick Briggs — Tue, 23 Apr 2019 23:18:36 -0000

Obviously, the fix is
if (!(CONSTRAINT)) return 0;

bad macro defn CHECK() in sapequal.c

Nick Briggs — Tue, 23 Apr 2019 20:11:25 -0000

Seems pretty dead around here... but just in case: Compiling OpenWRT, which included linux-atm-2.5.2, generated the following warning -- a result of missing parentheses in the macro definition for CHECK:

sapequal.c: In function 'match_blli':
sapequal.c:65:42: warning: logical not is only applied to the left hand side of comparison [-Wlogical-not-parentheses]
CHECK(l2.itu.window,a.l2.itu.window > b.l2.itu.window);
^
sapequal.c:46:10: note: in definition of macro 'CHECK'
if (!CONSTRAINT) return 0; \ ^~~~~~~~~~
sapequal.c:46:9: note: add parentheses around left hand side expression to silence this warning
if (!CONSTRAINT) return 0; \ ^~~~~~~~~~~~~~~~~~~~~~~~
if (res) res->FIELD = a.FIELD < b.FIELD ? a.FIELD : b.FIELD; \ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
}
~

#23 linux-atm-2.5.1/src/lane/ldb.c:89: possible bad if test ?

chas williams — Fri, 25 Oct 2013 11:30:07 -0000

status: open --> accepted
Group: -->

#23 linux-atm-2.5.1/src/lane/ldb.c:89: possible bad if test ?

chas williams — Fri, 25 Oct 2013 11:23:06 -0000

That does appear to be the correct fix. I will merge it and produce a new release (eventually).

linux-atm-2.5.1/src/lane/ldb.c:89: possible bad if test ?

dcb — Wed, 23 Oct 2013 20:09:50 -0000

I just compiled linux-atm-2.5.1 with extra compiler flag -Wlogical-op

It said

ldb.c:89:3: warning: logical 'or' of collectively exhaustive tests is always true [-Wlogical-op]

Source code is

return ((test >= '0' && test <= '9') || (test >= 'a' || test <= 'f') ||
(test >= 'A' && test <= 'F') || test == 'x' || test == 'X');

This bit looks wrong

(test >= 'a' || test <= 'f')

Suggest swap || for &&.

linux-atm-2.5.1/src/lane/ldb.c:89: possible bad if test ?

dcb — Wed, 23 Oct 2013 20:09:50 -0000

Ticket 23 has been modified: linux-atm-2.5.1/src/lane/ldb.c:89: possible bad if test ?
Edited By: chas williams (chas3)
Status updated: u'open' => u'accepted'

When cross-compiling, can't pass in separate target CFLAGS

Philip Prindeville — Fri, 31 Jul 2009 05:39:22 -0000

Like many projects, linux-atm has a complex build process which contains both binaries for the target install and intermediate binaries which get run during the build to generate transient data which gets preprocessed (e.g. src/qgen).

Unfortunately, there is no way to designate one set of CFLAGS to the host compiler (CC_FOR_BUILD) and another set of CFLAGS to the target compiler (CC/TARGET_CC).

Further, the compiler $(CC) is used interchangeably in different directories to mean the target compiler in most places, and the host compiler in src/qgen. This is confusing to say the least for package/distro maintainers.

CC should *always* imply the target compiler, and $(CC_FOR_BUILD) should only be used when generating binaries to run on the build host itself.

Similarly, consistent naming for target and host CFLAGS need to be employed.