One last time: annoying warning

[Roberto Bagnara]

Richard B. Kreckel wrote:
 >>                             BTW: do you know that all your header
 >>files are not standard conforming?
 >
 >
 > Hmm, which are the non-conforming parts in our header files?

You are violating [17.4.3.1.2], for instance.

 >>At least you realize that.  Your friend, instead, prefers insulting
 >>the GCC developers because of their "stupid compiler".
 >
 >
 > Oh, we appreciate GCC and the work of the developers very much over here
 > -- a point that has frequently been made clear on this list.

You should take a closer look to the two messages by Christian Bauer.

 > I would bet that the GCC developers would agree with him on this
 > particular unused parameter issue -- but this is speculative.  If you
 > insist, I may contact some of the developers who I happen to know
 > quite well personally.

No, there is no need you contact your friends or that I contact mine
(for we would then need ways to check who of them has it bigger).
What is important is that the GCC people taking care of the standard
library do the right thing.  Since they know that someone may very
legitimately wish to compile with, e.g., -W -Wall, they write code
like

       virtual iter_type
       do_get_time(iter_type __s, iter_type /*__end*/, ios_base&,
                   ios_base::iostate& /*__err*/, tm* /*__t*/) const
       { return __s; }

(standard library released with GCC 3.2, locale_facets.h, lines 1101 ff.)

   static void deallocate(void* __p, size_t /* __n */)
   {
     free(__p);
   }

   static void* reallocate(void* __p, size_t /* old_sz */, size_t __new_sz)
   {
     void* __result = realloc(__p, __new_sz);
     if (0 == __result) __result = _S_oom_realloc(__p, __new_sz);
     return __result;
   }

(stl_alloc.h, lines 120 ff.), ..., you will find hundreds of examples
like that.  Naturally, I am really thankful they do that.  We also do
that.  Many others do that.  You could also do that... now, immediately,
without hurting no one in your current user base (and without wasting our
and your time that way).

 >>For our project we need clear interfaces, unambiguous documentation,
 >>very formal specifications of just anything, and an easy way of
 >>continuing with the development style we have chosen (which, in
 >>particular, includes running with lots of warnings switched on).  All
 >>of us have been unsatisfied concerning one or more of these things, so
 >>we have decided not to tie our project with GiNaC too much.  Yesterday
 >>we did not receive satisfactory answers about the _exact_
 >>specification of some GiNaC functions.
 >
 >
 > Please do read that thread ("Documentation of prem()" on the list
 > ginac-list at ginac.de) again.  The answer seemed perfectly clear to me: `q'
 > is not the quotient, but the polynomial pseudo-quotient of `a' and `b'
 > which can be thought of as a generalization of the former for GCD
 > purposes.  That thread ended with a question wich was not answered from
 > your side, by the way.

I was not referring to the prem() issue in particular and in fact
our answer to that unsatisfactory exchange is in preparation.  There are
many other things that have not been answered properly, starting
from a precise and unambiguous definition of "polynomial" and going
on that way.  And also, replying by email is only part of the solution.
If we have to really depend on GiNaC we need the specifications
to become part of GiNaC's documentation.  In other words, we are rather
uninterested about what GiNaC does _today_: we need too know precisely
what is the intended behavior of everything.  If this kind of "contract
with the user" does not go into GiNaC's documentation there is a risk
tomorrow someone comes, changes the behavior and pretends not having
inserted a bug for reasons like "Hey, I never specified what 'q' is!",
"Hey, I have never said expand() would do that and that!" and so forth.

 > Can we stop this childish academic flame war now, please?  Please!

We can stop it.  I am not sure I understand what do you mean by
"childish" and "academic".  If by "childish" you mean that I am
showing too much how the great programmer pissed me off and how
annoyed I am to have to maintain our version of GiNaC and live with
the sense of insecurity given by the lack of full documentation,
then I agree with you.  It would be perhaps look more professional to
simply unsubscribe the mailing lists and go back doing more productive
work.  However, I disagree the issues we have been raising are
"academic" in the negative sense it is usually attributed to that
word.  Yes, I teach computer science in the academia, but

a) writing header files so as to suit the needs of as many users
    as possible, and
b) ask for and provide clearly specified interfaces

are not "academic" things in that sense.  They are, to tell the
entire truth, very basic stuff in and outside the academia.
In my humble but not so humble opinion, of course.

Back to useful work now.  Let us communicate with the sources from
now on (that will also look less childish).  We will study your
commits to GiNaC's repository and will take care of our repository.
A thin layer of software between us and GiNaC (we are writing it these
days) will help us clearly identifying which services we require from
a computer algebra package.  Then we will try to understand whether we
can collect enough information so as to ensure that we can implement
these services _reliably_ using GiNaC (I hope so, of course).
All the best

      Roberto

-- 
Prof. Roberto Bagnara
Computer Science Group
Department of Mathematics, University of Parma, Italy
http://www.cs.unipr.it/~bagnara/
mailto:bagnara at cs.unipr.it