Re: [dmidecode] A lot of compile time warnings on ia64

[Petter Reinholdtsen]

[Jean Delvare]
> Well, if the ia64 dmidecode binary was failing, I guess you'd have
> had quite a few reports in the Debian bug tracking system aleady. As
> long as nobody complains, I guess we can assume it just works.

I am reluctant to interpret silence as anything but silence.  I am not
sure if anyone actually used dmidecode on ia64 in debian, and do not
believe it is safe to assume that silence means that everything is ok.

> Precisely, I have seen -ansi and -pedantic complain about
> non-questionable code quite a few times. This is the reason why I
> removed them.

I suspect we have different views on what is questionable code, as I
have always found issues with the code producing warnings with -ansi
and -pedantic.

In many cases, the warnings produced by gcc with -ansi and -pedantic,
are compile time errors when compiling with the SUN Forte C compiler
on Solaris or the IBM C compiler on AIX.

I suspect in this case, you do not really care for non-gcc compilers,
and you are thus willing to take a few short cuts.  Which is fine of
course, but it helps to be aware that these are in fact short cuts. :)

> I also seem to remember that -ansi -pedantic caused your builds to
> fail once already, due to an "inline" keyword.

Yes.  I apply this patch to make the code more ANSI C:

Index: biosdecode.c
===================================================================
RCS file: /home/pere/src/cvsroot/src/dmidecode/biosdecode.c,v
retrieving revision 1.6
diff -u -3 -p -u -r1.6 biosdecode.c
--- biosdecode.c        1 Mar 2005 22:04:56 -0000       1.6
+++ biosdecode.c        1 Mar 2005 22:09:23 -0000
@@ -502,7 +502,7 @@ static struct bios_entry bios_entries[]=
 };
 
 /* Believe it or not, this is significantly faster than memcmp and strncmp */
p-static inline int anchor_match(const struct bios_entry *entry, const char *p)
+static __inline int anchor_match(const struct bios_entry *entry, const char *p)
 {
        size_t i;

> As a consequence, you are applying a patch to the Debian build to
> work around it. This has only drawbacks as far as I can see: more
> maintenance work for you, longer build time due to the additional
> patching requirement, and differences in code which could virtually
> cause Debian users to have a version of dmidecode that differs in
> behavior from mainline, making bugs harder to track. All that for
> what benefit? Almost none to date as far as I can see.

I guess writing the lonw paragraph describing the drawbacks was more
work than the extra work I have with applying this patch to the
source.  The benefit as I see it, is that the code avoid one warning
and leave only warnings on unknown and possibly problematic parts of
the code.  As I said, I have found to agree with the compiler warning
when I checked out the code in question, while I understand that you
do not experience the same.

In this example, the code will break on AIX without a macro to get rid
of the inline statement, as inline is not accepted by the AIX C
compiler.  Normally this is done by testing for 'inline' and
'__inline' support, and defining 'inline' to be '', 'inline' or
'__inline' depending on the compiler.

> Beware that -Os seems to change the way the compiler aligns the
> data.  This trades execution speed for size, which is wanted in your
> situation, but also sounds curiously related to the warnings you
> have.

Could be.  It is rather unlikely, though, as the compiler know what
alignment is required for a given architecture.

> Bottom line is that stripping saves more than -Os (of course, both
> together saves even more). So if -Os actually seems to cause trouble
> on ia64, you may want to use stripped -O1 instead.

I've never experienced that -Os caused any trouble on any
architecture, so it is not my first theory in this case.  But I have
not really investigated, so I have no idea if there are real problems
here or not.