From varg at thsun1.jinr.ru  Sun Sep 15 13:49:00 2002
From: varg at thsun1.jinr.ru (Sheplyakov Alexey)
Date: Sun, 15 Sep 2002 15:49:00 +0400 (MSD)
Subject: strange segfault...
Message-ID: <Pine.GSO.3.96.1020915154658.19938A-100000@thsun1>


Consider a very simple program:

// beginning of file crush_it.cxx

#include <iostream>
#include <vector>
using namespace std;

#include <ginac/ginac.h>

using namespace GiNaC;

int main(int argc,char* argv[])
{
	vector<symbol> sv(3);
	sv[0] = symbol("x");
	sv[1] = symbol("y");
	sv[2] = symbol("z");

	cout << "All is OK " << "\n";
	cout << sv[0] << " ";
	cout << sv[1] << " ";
	cout << "All is OK again" << "\n";
	
	return 0; // segfault here!
	
}
// end of file crush_it.cxx


And here is gdb session:


Breakpoint 3, main (argc=1, argv=0xbffffb24) at crush_it.cxx:21
21              return 0;
(gdb) bt
#0  main (argc=1, argv=0xbffffb24) at crush_it.cxx:21
(gdb) next

Program received signal SIGSEGV, Segmentation fault.
0x403d27fe in free () from /lib/libc.so.6
(gdb) bt
#0  0x403d27fe in free () from /lib/libc.so.6
#1  0x403d26d3 in free () from /lib/libc.so.6
#2  0x4032d6b4 in __builtin_delete () from /usr/lib/libstdc++-libc6.2-2.so.3
#3  0x401e6c8d in GiNaC::symbol::destroy () from /usr/lib/libginac-1.0.so.0
#4  0x401ea110 in GiNaC::symbol::~symbol () from /usr/lib/libginac-1.0.so.0
#5  0x0804c0d7 in void destroy<GiNaC::symbol> (__pointer=0x805259c)
    at /usr/lib/gcc-lib/i386-linux/2.95.4/../../../../include/g++-3/stl_construct.h:43
#6  0x0804bfa1 in void __destroy_aux<GiNaC::symbol *> (__first=0x8052578, __last=0x80525e4)
    at /usr/lib/gcc-lib/i386-linux/2.95.4/../../../../include/g++-3/stl_construct.h:61
#7  0x0804bbfc in void __destroy<GiNaC::symbol *, GiNaC::symbol> (__first=0x8052578, __last=0x80525e4)
    at /usr/lib/gcc-lib/i386-linux/2.95.4/../../../../include/g++-3/stl_construct.h:73
#8  0x0804b85c in void destroy<GiNaC::symbol *> (__first=0x8052578, __last=0x80525e4)
    at /usr/lib/gcc-lib/i386-linux/2.95.4/../../../../include/g++-3/stl_construct.h:78
#9  0x0804b881 in vector<GiNaC::symbol, allocator<GiNaC::symbol> >::~vector (this=0xbffffab0, __in_chrg=2)
    at /usr/lib/gcc-lib/i386-linux/2.95.4/../../../../include/g++-3/stl_vector.h:266
#10 0x0804a4dd in main (argc=1, argv=0xbffffb24) at crush_it.cxx:21



I use Debian "sid", GiNaC 1.0.10 (installed from debs), g++ 2.95.4





From cbauer at thep.physik.uni-mainz.de  Sun Sep 15 19:03:21 2002
From: cbauer at thep.physik.uni-mainz.de (Christian Bauer)
Date: Sun, 15 Sep 2002 19:03:21 +0200
Subject: strange segfault...
In-Reply-To: <Pine.GSO.3.96.1020915154658.19938A-100000@thsun1>
References: <Pine.GSO.3.96.1020915154658.19938A-100000@thsun1>
Message-ID: <20020915190321.A6568@higgs.physik.uni-mainz.de>

Hi!

On Sun, Sep 15, 2002 at 03:49:00PM +0400, Sheplyakov Alexey wrote:
> 	vector<symbol> sv(3);

It's better to use "vector<ex>" here.

Bye,
Christian

-- 
  / Coding on PowerPC and proud of it
\/ http://www.uni-mainz.de/~bauec002/


From chrisd at sci.kun.nl  Sun Sep 15 20:36:56 2002
From: chrisd at sci.kun.nl (Chris Dams)
Date: Sun, 15 Sep 2002 20:36:56 +0200 (MEST)
Subject: Hello. r u still alive?
Message-ID: <Pine.GSO.4.44.0209152032260.5021-100000@wn5.sci.kun.nl>


Hello,

I don't see any reactions on my previous post "same problem again plus a
few others". Did noone read it? It contains *three* fixes of what I think
are bugs. Don't the devellopers care that a^(-1/2) sometimes gets printed
in C-source as if it were a^(1/2)? Looking forward to hearing anything!

Greetings,
Chris Dams



From kreckel at thep.physik.uni-mainz.de  Mon Sep 16 13:34:13 2002
From: kreckel at thep.physik.uni-mainz.de (Richard B. Kreckel)
Date: Mon, 16 Sep 2002 13:34:13 +0200 (CEST)
Subject: Hello. r u still alive?
In-Reply-To: <Pine.GSO.4.44.0209152032260.5021-100000@wn5.sci.kun.nl>
Message-ID: <Pine.LNX.4.21.0209161328140.7973-100000@higgs.physik.uni-mainz.de>

On Sun, 15 Sep 2002, Chris Dams wrote:
> I don't see any reactions on my previous post "same problem again plus a
> few others". Did noone read it? It contains *three* fixes of what I think
> are bugs. Don't the devellopers care that a^(-1/2) sometimes gets printed
> in C-source as if it were a^(1/2)? Looking forward to hearing anything!

Ohhh, thanks for U.r keen interest!  ;-)

Yepp, we R. still alive.  3 weeks ago your patch went into both branches,
in rather unmodified form.  It will be in the next release.  Thanks for
having submitted it.

HTH
   -richy.
-- 
Richard B. Kreckel
<Richard.Kreckel at GiNaC.DE>
<http://www.ginac.de/~kreckel/>



From chrisd at sci.kun.nl  Mon Sep 16 15:01:20 2002
From: chrisd at sci.kun.nl (Chris Dams)
Date: Mon, 16 Sep 2002 15:01:20 +0200 (CEST)
Subject: Hello. r u still alive?
In-Reply-To: <Pine.LNX.4.21.0209161328140.7973-100000@higgs.physik.uni-mainz.de>
Message-ID: <Pine.LNX.4.44.0209161356160.29450-100000@gamow.sci.kun.nl>


Hello,

On Mon, 16 Sep 2002, Richard B. Kreckel wrote:

> Yepp, we R. still alive.  3 weeks ago your patch went into both branches,
> in rather unmodified form.  It will be in the next release.  Thanks for
> having submitted it.

Ah, now I see the file mul.cpp indeed changed. I was looking at add.cpp
and did not see it changing. This, however, means that you did not use my
suggestion for the file add.cpp. I did not put it in the patch because it
was only one line. One of my previous posts was about a problem when
printing cln-output. The problem was that there was no plus sign before a
cl_N-constructor in the output. After this was fixed for the coefficients,
I discovered that the numeric term of an add suffers from the same
problem. Therefore I think the line

	if (overall_coeff.info(info_flags::positive))

in the file add.cpp should be

	if (overall_coeff.info(info_flags::positive) ||
					is_a<print_csrc_cl_N>(c))

I think this should still be changed.

Greetings,
Chris Dams




From kreckel at thep.physik.uni-mainz.de  Wed Sep 18 15:08:58 2002
From: kreckel at thep.physik.uni-mainz.de (Richard B. Kreckel)
Date: Wed, 18 Sep 2002 15:08:58 +0200 (CEST)
Subject: Hello. r u still alive?
In-Reply-To: <Pine.LNX.4.44.0209161356160.29450-100000@gamow.sci.kun.nl>
Message-ID: <Pine.LNX.4.21.0209181508090.13739-100000@higgs.physik.uni-mainz.de>

On Mon, 16 Sep 2002, Chris Dams wrote:
[...]
> Ah, now I see the file mul.cpp indeed changed. I was looking at add.cpp
> and did not see it changing. This, however, means that you did not use my
> suggestion for the file add.cpp. I did not put it in the patch because it
> was only one line. One of my previous posts was about a problem when
> printing cln-output. The problem was that there was no plus sign before a
> cl_N-constructor in the output. After this was fixed for the coefficients,
> I discovered that the numeric term of an add suffers from the same
> problem. Therefore I think the line
> 
> 	if (overall_coeff.info(info_flags::positive))
> 
> in the file add.cpp should be
> 
> 	if (overall_coeff.info(info_flags::positive) ||
> 					is_a<print_csrc_cl_N>(c))
> 
> I think this should still be changed.

Right.  Thanks for catching this!

Cheers
    -richy.
-- 
Richard B. Kreckel
<Richard.Kreckel at GiNaC.DE>
<http://www.ginac.de/~kreckel/>



From vollinga at thep.physik.uni-mainz.de  Wed Sep 18 18:44:39 2002
From: vollinga at thep.physik.uni-mainz.de (Jens Vollinga)
Date: Wed, 18 Sep 2002 18:44:39 +0200 (CEST)
Subject: Neue Version
Message-ID: <Pine.LNX.4.33.0209181842570.17146-100000@squark.physik.uni-mainz.de>

1.0.11 da ist.



From bagnara at cs.unipr.it  Sun Sep 22 19:49:07 2002
From: bagnara at cs.unipr.it (Roberto Bagnara)
Date: Sun, 22 Sep 2002 19:49:07 +0200
Subject: One last time: annoying warning
Message-ID: <3D8E0293.8040109@cs.unipr.it>


Dear GiNaC developer,

I was composing my fourth message about the the unused parameter
in line 84 in basic.h (GiNaC 1.0.11) and about the trivial and
100% safe patch I have proposed to fix it.  In another window
I was creating a new CVS repository for GiNaC so that we could
avoid patching your releases manually over and over again.
I was lucky enough to have the inspiration to double check
the archives of ginac-devel at ginac.de before hitting the "send"
button.  Having discovered that I was not completely ignored
during all this time, I had a chance to erase a message you
would not have liked.  (I don't think replies to messages sent
to ginac-devel should only be sent to the list, but anyway
I have now subscribed it: from what I can see this entitles
me to receive also some more spam).

I would now like to discuss the issue on purely technical
grounds.  The point is that we need to replace  the following
line (84) of basic.h

         virtual void destroy(bool call_parent) { }

with the following

         virtual void destroy(bool /* call_parent */) { }

We cannot follow the advice of Christian Bauer (*) to tell the
compiler not to warn about unused parameters for the simple
reason that we find these warnings very useful in our
development work.  In contrast, I believe the patch I am
repeatedly proposing:

1) complies with the C++ standard;
2) does not cause problems with any the versions of all the C++
    compilers we know of;
3) preserves the information about what the bool parameter is;
4) is good both for users that run with warnings on and for those
    switching them off.

I would be very grateful if someone could tell me what is so
wrong with it that we have to set up a paraller CVS repository
for GiNaC.
Thanks a lot

     Roberto


(*) "I suggest turning off that compiler warning. Yes, I'm serious."

-- 
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




From cbauer at thep.physik.uni-mainz.de  Mon Sep 23 17:26:27 2002
From: cbauer at thep.physik.uni-mainz.de (Christian Bauer)
Date: Mon, 23 Sep 2002 17:26:27 +0200
Subject: One last time: annoying warning
In-Reply-To: <3D8E0293.8040109@cs.unipr.it>
References: <3D8E0293.8040109@cs.unipr.it>
Message-ID: <20020923172627.B23402@higgs.physik.uni-mainz.de>

Hi!

On Sun, Sep 22, 2002 at 07:49:07PM +0200, Roberto Bagnara wrote:
> I was composing my fourth message about the the unused parameter
> in line 84 in basic.h (GiNaC 1.0.11)

And I'm now composing my third answer to that...

> and about the trivial and 100% safe patch I have proposed to fix it.

Short answer: There is nothing to 'fix' here.
Long answer: See below.

> Having discovered that I was not completely ignored during all this time,
> I had a chance to erase a message you would not have liked.

/me dons the asbestos suit

> I would now like to discuss the issue on purely technical grounds.

So do I.

> The point is that we need to replace  the following line (84) of basic.h
>          virtual void destroy(bool call_parent) { }
> with the following
>          virtual void destroy(bool /* call_parent */) { }
>
> We cannot follow the advice of Christian Bauer (*) to tell the
> compiler not to warn about unused parameters for the simple
> reason that we find these warnings very useful in our
> development work.

Then write a script that filters out warnings coming from ginac/basic.h...

> In contrast, I believe the patch I am repeatedly proposing:
> 
> 1) complies with the C++ standard;
> 2) does not cause problems with any the versions of all the C++
>     compilers we know of;
> 3) preserves the information about what the bool parameter is;
> 4) is good both for users that run with warnings on and for those
>     switching them off.

5) Mutilates perfectly valid code in a feeble attempt to keep some nitpicking
   compiler's trap shut.
6) Doesn't make the code any more transparent. Rather the opposite.

Unused parameters are to be expected when overloading functions. A compiler
that issues a warning about this needs to be gagged. What is it 'warning' us
about, anyway? That the parameter is dispensable and can be removed? That
would make some sense if this was pure C code. But here, the parameter is
needed. The compiler is just too stupid/ignorant to see that.

There's absolutely *nothing* whatsoever wrong with that line of code. Your
'fix' only serves to outsmart your compiler's warning heuristics. The function
still has one unused parameter. Why doesn't the compiler warn about that?

Accepting your fix may open the flood gates to invite all kinds of nonsense.
I mean, what's next? Somebody asking us to change variable names because he's
using a brain-damaged compiler that spits out Mathematica-esque warnings like
"Possible spelling error: identifier 'numy' is similar to existing identifier
'numx'."? There has to be a line drawn somewhere, and I draw it at the point
where the only purpose of a patch is to avoid a (pointless) compiler warning.

Don't get me wrong. I'll gladly replace "while (c = *s++)" with
"while ((c = *s++) != 0)" anytime, because that also makes the code more
comprehensible. But I despise stuff like commenting out variable names,
'UNUSED' macros etc. in code that is 100% OK, just to avoid compiler messages.

Bye,
Christian

-- 
  / Coding on PowerPC and proud of it
\/ http://www.uni-mainz.de/~bauec002/


From bagnara at cs.unipr.it  Mon Sep 23 20:26:46 2002
From: bagnara at cs.unipr.it (Roberto Bagnara)
Date: Mon, 23 Sep 2002 20:26:46 +0200
Subject: One last time: annoying warning
References: <3D8E0293.8040109@cs.unipr.it> <20020923172627.B23402@higgs.physik.uni-mainz.de>
Message-ID: <3D8F5CE6.8090102@cs.unipr.it>

Christian Bauer wrote:
>>In contrast, I believe the patch I am repeatedly proposing:
>>
>>1) complies with the C++ standard;
>>2) does not cause problems with any the versions of all the C++
>>    compilers we know of;
>>3) preserves the information about what the bool parameter is;
>>4) is good both for users that run with warnings on and for those
>>    switching them off.
> 
> 
> 5) Mutilates perfectly valid code in a feeble attempt to keep some nitpicking
>    compiler's trap shut.

"Mutilates"?!
Putting the argument name within comments "mutilates"?
Come on!

> 6) Doesn't make the code any more transparent. Rather the opposite.

It makes clear that the argument is _intentionally_ unused.
Pretty obvious in the specific case, but, more generally, not using function
arguments may happen (and does happen) also by mistake.

> Unused parameters are to be expected when overloading functions.

So what?

> What is it 'warning' us
> about, anyway? That the parameter is dispensable and can be removed?

No: that the parameter is not being used in the function body.
This catches a significant number of mistakes.  Many people use
g++ and compile with -Wall and they agree that it is a nice thing
to be warned about that cases.

> There's absolutely *nothing* whatsoever wrong with that line of code.

Strictly speaking, the line is not wrong but only significantly less useful
than it could be.  It only serves well the portion of your user base not using
g++ or its extra-warnings options.  It does not serve well others.

> Your
> 'fix' only serves to outsmart your compiler's warning heuristics.

It is not a heuristics in the usual sense: unused arguments are always flagged
when these warnings are enabled.  And this is so by design.  The same
functionality is available in other C++ compilers.  Guess why.

> The function
> still has one unused parameter. Why doesn't the compiler warn about that?

Because omitting the argument name is the ISO standard compliant way of
specifying that the argument is _intentionally_ unused.  While omitting
the argument altogether causes an information loss, omitting it by commenting
it out is perfectly OK.

> [...] keep some nitpicking compiler's trap shut [...]
 > A compiler that issues a warning about this needs to be gagged. [...]
 > The compiler is just too stupid/ignorant to see that. [...]
 > Your 'fix' only serves to outsmart your compiler's warning heuristics. [...]
> Accepting your fix may open the flood gates to invite all kinds of nonsense.
> [...] I despise stuff like commenting out variable names [...]

You have a very simple way to satisfy the entire user base and, in particular,
those of us compiling with extra warnings enabled.  Instead you are choosing
to disrespect users and contributors of GiNaC (and the GCC authors as an extra
bonus) by imposing your religious arguments upon them.
This is a serious mistake for anyone and for a library provider is even worse.
Anyway, starting from now, the PURRS project will reduce its dependence on
GiNaC as much as possible.  At the same time we will create a parallel CVS
repository for GiNaC + our improvements (you know, those idiotic things we like
and you despise).
Good luck

    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



From cbauer at thep.physik.uni-mainz.de  Tue Sep 24 04:04:46 2002
From: cbauer at thep.physik.uni-mainz.de (Christian Bauer)
Date: Tue, 24 Sep 2002 04:04:46 +0200
Subject: One last time: annoying warning
In-Reply-To: <3D8F5CE6.8090102@cs.unipr.it>
References: <3D8E0293.8040109@cs.unipr.it> <20020923172627.B23402@higgs.physik.uni-mainz.de> <3D8F5CE6.8090102@cs.unipr.it>
Message-ID: <20020924040446.A27542@higgs.physik.uni-mainz.de>

Hi!

(Ah, this is great. I haven't had a good flame war for years! :-)

On Mon, Sep 23, 2002 at 08:26:46PM +0200, Roberto Bagnara wrote:
> Christian Bauer wrote:
> > 5) Mutilates perfectly valid code in a feeble attempt to keep some nitpicking
> >    compiler's trap shut.
> 
> "Mutilates"?!
> Putting the argument name within comments "mutilates"?

Changing code for the *sole* purpose of getting rid of a compiler warning
(a warning, remind you; not an error, not a compiler bug, but a *warning*.
Warnings mean nothing. They are produced by a program that doesn't even try
to 'understand' the code. Yes, warnings are useful in 99% of all cases. This
is one example of where they aren't.) isn't my idea of elegant software
development.

> > 6) Doesn't make the code any more transparent. Rather the opposite.
> 
> It makes clear that the argument is _intentionally_ unused.

To whom? To your compiler, perhaps (because someone programmed it to behave
that way). Not to me.

> Pretty obvious in the specific case, but, more generally, not using function
> arguments may happen (and does happen) also by mistake.

Yes, but...

> > Unused parameters are to be expected when overloading functions.
> 
> So what?

So a C++ compiler should know not to complain about that.

> > What is it 'warning' us
> > about, anyway? That the parameter is dispensable and can be removed?
> 
> No: that the parameter is not being used in the function body.

D'oh...

> This catches a significant number of mistakes.

*Potential* mistakes. There is definitely no mistake here.

I still fail to see how this warning is supposed to be useful _in this
specific case_. We are not dealing with a 200+ line function here where
one of the parameters might accidentally have been confused with a similarly
named local variable. This function's body is empty. Any intelligent being
looking at the code can immediately tell that "call_parent" is unused, because
the function, well, doesn't do anything at all. There is absolutely no need
to provide any more information about the unusedness of that parameter.

> Many people use g++ and compile with -Wall and they agree that it is a
> nice thing to be warned about that cases.

I also compile my stuff with -Wall every now and then, but then I sort the
messages produced into three categories:
 1) "Oops. That really is a bug. Thank <insert your deity here> for
    these warnings!"
 2) "Not a bug, but gcc has a point here. Changing the code might make it
    more readable/transparent/portable."
 3) "Bogus warning. Stupid compiler. No cookie. That's why I don't have -Wall
    in the makefile."

Your matter falls into category 3, I'm afraid...

> > There's absolutely *nothing* whatsoever wrong with that line of code.
> 
> Strictly speaking, the line is not wrong but only significantly less useful
> than it could be. It only serves well the portion of your user base not using
> g++ or its extra-warnings options.  It does not serve well others.

Are we on the same page here? I define the usefulness of code by the results
it produces, or by the potential for useful results it may have in the future.
Not by how much output the build process spews out in the case that someone,
somewhere activates _optional_ gizmos on his or her tools.

> > Your 'fix' only serves to outsmart your compiler's warning heuristics.
> 
> It is not a heuristics in the usual sense: unused arguments are always flagged
> when these warnings are enabled.  And this is so by design.  The same
> functionality is available in other C++ compilers.  Guess why.

Because a compiler is a mindless automaton that translates an algorithm into
a different representation? Because a compiler can't (and shouldn't) know
why that algorithm was written down in the exact way it was in the source
file? Because compiler writers are well aware of that fact and have added
an option to suppress these warnings?

> > The function
> > still has one unused parameter. Why doesn't the compiler warn about that?
> 
> Because omitting the argument name is the ISO standard compliant way of
> specifying that the argument is _intentionally_ unused.

Yeah, right. It says so in the standard: "If you want your compiler to shut
the frell up about this stuff, we recommend you put your variable names in
comments.". I don't think so.

(Whoa, wait! Hold your fire! That last comment was meant ironically. I know
what you wanted to say. :-)

> While omitting the argument altogether causes an information loss, omitting
> it by commenting it out is perfectly OK.

...except that it obfuscates the source.

> Instead you are choosing to disrespect users and contributors of GiNaC (and
> the GCC authors as an extra bonus) by imposing your religious arguments upon
> them.

And you are imposing your compiler's imbecility upon us...

Do I tell you how you have to indent _your_ code just because it happens to
be misformatted in the editor _I_ am using? No, I don't. You'd probably say
"Your editor sucks, dude. Use another one, or at least configure it
properly.". And you'd be right.

(And how exactly did I disrespect the GCC authors?)

> This is a serious mistake for anyone and for a library provider is even
> worse.

I'm thankful for any help offered, but I choose to reject patches that seem
pointless to me. I acknowledge that your intentions in proposing this patch
are good, I read it, I gave it some thought, but I've come to the conclusion
that it's a kludge that I'd rather not have in our code. My suggestion still
is to suppress the compiler warnings if they annoy you, or to find a more
appropriate way to deal with them.

> Anyway, starting from now, the PURRS project will reduce its dependence on
> GiNaC as much as possible.

Yeah, go play in your own sandbox! And, I tell you what: We will reduce our
use of PURRS here to zero! Now, how does that feel? (Wait, come to think of
it, we never used PURRS in the first place... What is this 'PURRS', anyway?).

;-)

> At the same time we will create a parallel CVS repository for GiNaC + our
> improvements (you know, those idiotic things we like and you despise).

Isn't that precisely one of the things CVS was designed for?

To summarize:
 - The code in question is 100% valid
 - I also don't think there's any risk of it being misinterpreted
 - Compiler warnings are nothing more than hints, not divine revelations;
   they are therefore to be
    a) subjected to a critical examination
    b) taken with a grain of salt
 - In this case, the warning is pointless
 - Problems should preferrably be fixed at their place of origin
 - In this case, the problem lies with the compiler, not with the code
 - 'Fixing' the compiler is trivial: it has an option to not complain about
   this (which is actually the default setting, but that's only marginally
   relevant here)
 - Therefore, the solution is to change the compiler options. Case closed.

That's all, folks.

Bye,
Christian

-- 
  / Coding on PowerPC and proud of it
\/ http://www.uni-mainz.de/~bauec002/


From kreckel at thep.physik.uni-mainz.de  Thu Sep 26 14:59:36 2002
From: kreckel at thep.physik.uni-mainz.de (Richard B. Kreckel)
Date: Thu, 26 Sep 2002 14:59:36 +0200 (CEST)
Subject: One last time: annoying warning
In-Reply-To: <3D8F5CE6.8090102@cs.unipr.it>
Message-ID: <Pine.LNX.4.33.0209261358001.5472-100000@higgs.physik.uni-mainz.de>

Ciao everybody,

Folks, is such a heated discussion really appropiate in this case?

For my own part, I really don't care very much whether we comment out this
silly parameter name or not.  But I do think that Christian Bauer raised
some strong points against this patch.

Adding `-Wunused-parameter' will show the one warning Roberto Bagnara is
complaining about when compiling your own programs with GiNaC headers.
Note that when compiling GiNaC itself it shows a lot of similar warnings
for code like this one (from normal.cpp):

ex basic::smod(const numeric &xi) const
{
    return *this;
}

Hence, for reasons of coding style uniformity we wouldn't just change the
one line in basic.h, but also all the other ones.  Since in the case of
virtual functions a compiler would have to have knowledge of all derived
classes in order to suppress such a warning we are very unlikely to see
this ever fixed at the compiler side.

Anyways, isn't this particular warning easily grepped away?

On Mon, 23 Sep 2002, Roberto Bagnara wrote:
> No: that the parameter is not being used in the function body.
> This catches a significant number of mistakes.  Many people use
> g++ and compile with -Wall and they agree that it is a nice thing
> to be warned about that cases.

As a little known historical aside: why is `-Wunused-parameter' not
switched on with `-Wall'?  Because `-Wall' is the set of all warnings that
can be switched on without being triggerd when compiling GNU/Emacs!
Sounds silly?  Maybe it is.  But this is how such choices are made some
times: by religious arguments.  I seriously doubt that this practice helps
anybody at all.

[...]
> Strictly speaking, the line is not wrong but only significantly less useful
> than it could be.  It only serves well the portion of your user base not using
> g++ or its extra-warnings options.  It does not serve well others.

Remember that this code merely estabilishes a vtbl entry so inlining
cannot take place anyways.  Why not suggest another patch?  Wouldn't it be
totally equivalent to remove the empty default code and put it in
basic.cpp?  I'm sure you can come up with an acceptable solution for your
problem!

[...]
> Because omitting the argument name is the ISO standard compliant way of
> specifying that the argument is _intentionally_ unused.

Hmm, can you provide evidence in support of what you are implying?

[...]
> Anyway, starting from now, the PURRS project will reduce its dependence on
> GiNaC as much as possible.

You are really blessed if you can afford to base your choice of software
on such arguments.

>                             At the same time we will create a parallel CVS
> repository for GiNaC + our improvements (you know, those idiotic things we like
> and you despise).

You're welcome.  But please keep in mind that we are generally quite open
for suggestions/patches/additions.

Best wishes
         -richy.
-- 
Richard B. Kreckel
<Richard.Kreckel at GiNaC.DE>
<http://www.ginac.de/~kreckel/>



From bagnara at cs.unipr.it  Thu Sep 26 17:24:49 2002
From: bagnara at cs.unipr.it (Roberto Bagnara)
Date: Thu, 26 Sep 2002 17:24:49 +0200
Subject: One last time: annoying warning
References: <Pine.LNX.4.33.0209261358001.5472-100000@higgs.physik.uni-mainz.de>
Message-ID: <3D9326C1.90200@cs.unipr.it>

Richard B. Kreckel wrote:
 > Folks, is such a heated discussion really appropiate in this case?

No, it is not.  But I am fed up about the attitude of your colleague.

 > For my own part, I really don't care very much whether we comment out this
 > silly parameter name or not.  But I do think that Christian Bauer raised
 > some strong points against this patch.
 >
 > Adding `-Wunused-parameter' will show the one warning Roberto Bagnara is
 > complaining about when compiling your own programs with GiNaC headers.
 > Note that when compiling GiNaC itself it shows a lot of similar warnings
 > for code like this one (from normal.cpp):
 >
 > ex basic::smod(const numeric &xi) const
 > {
 >     return *this;
 > }

It is overwhelmingly clear that GiNaC itself can adopt any programming
style that fits the needs of their developer.

 > Hence, for reasons of coding style uniformity we wouldn't just change the
 > one line in basic.h, but also all the other ones.

Here is where you are missing the point.  Your .cpp files. are one
thing.  A completely different thing are the .h header files you give
to your users.  These, to be really useful, must suite the needs of as
many compilers as possible with as many combinations of compilation
options as possible.  The ideal is that they must be good for
everyone.  The headers should not impose any requirement apart from
the use of a standard conforming compiler; for the rest they should be
100% bullet proof.  I am sure you understand that.  (And if you don't
it means only we have too different views on how a truly professional
library should be written.)  BTW: do you know that all your header
files are not standard conforming?

 > Since in the case of
 > virtual functions a compiler would have to have knowledge of all derived
 > classes in order to suppress such a warning we are very unlikely to see
 > this ever fixed at the compiler side.

At least you realize that.  Your friend, instead, prefers insulting
the GCC developers because of their "stupid compiler".  I look forward
to see his own compiler ;-)

 > Anyways, isn't this particular warning easily grepped away?

Yes, it is.  But that is not the point.

 >>Strictly speaking, the line is not wrong but only significantly less useful
 >>than it could be.  It only serves well the portion of your user base not using
 >>g++ or its extra-warnings options.  It does not serve well others.
 >
 >
 > Remember that this code merely estabilishes a vtbl entry so inlining
 > cannot take place anyways.  Why not suggest another patch?  Wouldn't it be
 > totally equivalent to remove the empty default code and put it in
 > basic.cpp?  I'm sure you can come up with an acceptable solution for your
 > problem!

Hem, Richard, it is not up to us to suggest the very right patches to
GiNaC.  We have raised a number of issues concerning GiNaC: that is
our duty as collaborative users.  It is up to GiNaC's developers to
understand the issues and find the right solutions.  We are also
writing our share of free software so let us make a deal: you provide
the world with the best computer algebra library ever, we provide the
best polyhedra library ever (http://www.cs.unipr.it/ppl/) and will
soon provide the best recurrence relation solver ever (that is what
the PURRS project aims at).

 >>Because omitting the argument name is the ISO standard compliant way of
 >>specifying that the argument is _intentionally_ unused.
 >
 >
 > Hmm, can you provide evidence in support of what you are implying?

I am not sure to understand you.  However, here is the proof: the ISO
C++ standard says that unused parameters need not be named (see
[8.4p5]).  Moreover, there is no way you can directly refer (i.e., not
resorting to an alias) to an unnamed parameter in the body of the
function.  Thus, if the programmer has omitted the name of a
parameter, he/she has expressed quite clearly his/her intention not to
use it in the body of the function.

 >>Anyway, starting from now, the PURRS project will reduce its dependence on
 >>GiNaC as much as possible.
 >
 >
 > You are really blessed if you can afford to base your choice of software
 > on such arguments.
 >
 >
 >>                            At the same time we will create a parallel CVS
 >>repository for GiNaC + our improvements (you know, those idiotic things we like
 >>and you despise).
 >
 >
 > You're welcome.  But please keep in mind that we are generally quite open
 > for suggestions/patches/additions.

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.  Today the great programmer
refuses to _mutilate_ his code and we do not know what will happen
tomorrow.  If you understand that, then please start treating us like
the evolute users and fine developers we are and not like people that
has time to waste and has chosen to waste it by annoying you.  Our
projects are significantly younger than yours, but we treat our users
very differently, especially those that show the good will and
dedication necessary to come up with patches and proposals (whether or
not they turn out to be the best possible ones).
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



From kreckel at thep.physik.uni-mainz.de  Thu Sep 26 20:23:14 2002
From: kreckel at thep.physik.uni-mainz.de (Richard B. Kreckel)
Date: Thu, 26 Sep 2002 20:23:14 +0200 (CEST)
Subject: One last time: annoying warning
In-Reply-To: <3D9326C1.90200@cs.unipr.it>
Message-ID: <Pine.LNX.4.33.0209261929340.22903-100000@higgs.physik.uni-mainz.de>

Ciao again,

On Thu, 26 Sep 2002, Roberto Bagnara wrote:
[...]
>            The headers should not impose any requirement apart from
> the use of a standard conforming compiler; for the rest they should be
> 100% bullet proof.  I am sure you understand that.  (And if you don't
> it means only we have too different views on how a truly professional
> library should be written.)

I understand that and we do agree.

>                              BTW: do you know that all your header
> files are not standard conforming?

Hmm, which are the non-conforming parts in our header files?

>  > Since in the case of
>  > virtual functions a compiler would have to have knowledge of all derived
>  > classes in order to suppress such a warning we are very unlikely to see
>  > this ever fixed at the compiler side.
>
> 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.

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.

>  >>Strictly speaking, the line is not wrong but only significantly less useful
>  >>than it could be.  It only serves well the portion of your user base not using
>  >>g++ or its extra-warnings options.  It does not serve well others.
>  >
>  >
>  > Remember that this code merely estabilishes a vtbl entry so inlining
>  > cannot take place anyways.  Why not suggest another patch?  Wouldn't it be
>  > totally equivalent to remove the empty default code and put it in
>  > basic.cpp?  I'm sure you can come up with an acceptable solution for your
>  > problem!
>
> Hem, Richard, it is not up to us to suggest the very right patches to
> GiNaC.  We have raised a number of issues concerning GiNaC: that is
> our duty as collaborative users.  It is up to GiNaC's developers to
> understand the issues and find the right solutions.

Sorry, I just realized [*] that recent versions of GCC do a pretty good
job at optimizing even this inlined code when possible.  So my previous
suggestion about moving the body is not a good one.  At the moment I don't
have another one.  If one occurs to me I will reconsider the issue---until
then my time is too costly.

>                                                      We are also
> writing our share of free software so let us make a deal: you provide
> the world with the best computer algebra library ever,

Sorry, we cannot fulfill such a deal.   ;-)

[...]
>  >>Because omitting the argument name is the ISO standard compliant way of
>  >>specifying that the argument is _intentionally_ unused.
>  >
>  >
>  > Hmm, can you provide evidence in support of what you are implying?
>
> I am not sure to understand you.  However, here is the proof: the ISO
> C++ standard says that unused parameters need not be named (see
> [8.4p5]).  Moreover, there is no way you can directly refer (i.e., not
> resorting to an alias) to an unnamed parameter in the body of the
> function.  Thus, if the programmer has omitted the name of a
> parameter, he/she has expressed quite clearly his/her intention not to
> use it in the body of the function.

I was actually hoping for an authoritative suggestion rather than a vague
option...

> 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.

>                                         Today the great programmer
> refuses to _mutilate_ his code and we do not know what will happen
> tomorrow.

Rest assured, you won't see any real mutilation of the code.  We are not
Micro$oft, after all!

>            If you understand that, then please start treating us like
> the evolute users and fine developers we are and not like people that
> has time to waste and has chosen to waste it by annoying you.  Our
> projects are significantly younger than yours, but we treat our users
> very differently, especially those that show the good will and
> dedication necessary to come up with patches and proposals (whether or
> not they turn out to be the best possible ones).

Come on, please.  Almost any suggestion/patch/addition you've made has
been added to the sources.  And those were more important issues.  And we
will certainly continue to consider all suggestions/patches/additions in
the future.

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

Regards
     -richy.

[*] Through timing and looking at code sizes and comparing the generated
    assembler -- though not fully understanding it.  That would require
    much more time which I don't have.
-- 
Richard B. Kreckel
<Richard.Kreckel at GiNaC.DE>
<http://www.ginac.de/~kreckel/>



From gdr at integrable-solutions.net  Thu Sep 26 20:39:55 2002
From: gdr at integrable-solutions.net (Gabriel Dos Reis)
Date: 26 Sep 2002 20:39:55 +0200
Subject: One last time: annoying warning
In-Reply-To: "Richard B. Kreckel"'s message of "Thu, 26 Sep 2002 20:23:14 +0200 (CEST)"
References: <Pine.LNX.4.33.0209261929340.22903-100000@higgs.physik.uni-mainz.de>
Message-ID: <m3wup8ppc4.fsf@soliton.integrable-solutions.net>

"Richard B. Kreckel" <kreckel at zino.physik.uni-mainz.de> writes:

[...]

| I would bet that the GCC developers would agree with him on this
| particular unused parameter issue -- but this is speculative. 

It depends on the GCC developer :-)  
*I* certainly agree with him; but I can only speak for myself.

-- Gaby


From bagnara at cs.unipr.it  Thu Sep 26 23:10:09 2002
From: bagnara at cs.unipr.it (Roberto Bagnara)
Date: Thu, 26 Sep 2002 23:10:09 +0200
Subject: One last time: annoying warning
References: <Pine.LNX.4.33.0209261929340.22903-100000@higgs.physik.uni-mainz.de>
Message-ID: <3D9377B1.2070707@cs.unipr.it>

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



From kreckel at thep.physik.uni-mainz.de  Fri Sep 27 18:17:54 2002
From: kreckel at thep.physik.uni-mainz.de (Richard B. Kreckel)
Date: Fri, 27 Sep 2002 18:17:54 +0200 (CEST)
Subject: One last time: annoying warning
In-Reply-To: <3D9377B1.2070707@cs.unipr.it>
Message-ID: <Pine.LNX.4.33.0209271754190.4905-100000@higgs.physik.uni-mainz.de>

Hi again,

On Thu, 26 Sep 2002, Roberto Bagnara wrote:
[...]
> You are violating [17.4.3.1.2], for instance.

LOL!  I was actually anticipating this to come up.  Anything else, Sir?

[...]
> a) writing header files so as to suit the needs of as many users
>     as possible, and

Exactly.  If those leading underscores pose a problem in any realistic
compilation environment I will happily patch it.  Until then there is
nothing to worry about.

> b) ask for and provide clearly specified interfaces

Good.  So let me next specify `lsolve()' and it's relation to the matrix
class.

Just some thoughts: that whole notion of "clearly specified interfaces"
is not always entirely clear.  As soon as one allows general expressions
lie `x+sin(x)+cos(2*x)' one opens a pandora's box of controversial
evaluations, both anonymous and named ones.  It is not always easy to
clearly specify the intent since that appears clearly as people work with
the system and not earlier.  Remember that `sqrfree()' discussion and the
change in behaviour between GiNaC-1.0.0 and GiNaC-1.0.1?  As a developer,
I find a set of regression tests more useful than a set of formal
specifications since a problem is much easier trapped there.  I hope you
do the same.

However: what is unclear about the notion of polynomials?

Regards
     -richy.
-- 
Richard B. Kreckel
<Richard.Kreckel at GiNaC.DE>
<http://www.ginac.de/~kreckel/>



From gdr at integrable-solutions.net  Fri Sep 27 20:21:32 2002
From: gdr at integrable-solutions.net (Gabriel Dos Reis)
Date: 27 Sep 2002 20:21:32 +0200
Subject: One last time: annoying warning
In-Reply-To: Roberto Bagnara's message of "Thu, 26 Sep 2002 23:10:09 +0200"
References: <Pine.LNX.4.33.0209261929340.22903-100000@higgs.physik.uni-mainz.de> <3D9377B1.2070707@cs.unipr.it>
Message-ID: <m3znu3b8er.fsf@soliton.integrable-solutions.net>

Roberto Bagnara <bagnara at cs.unipr.it> writes:

[...]

| 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; }

I'm one of those GCC people taking care of the library and I can
assure you I don't particularly appreciate that style (like some other
things in the V3 STYLE).  So, I would say that you should be very
careful in drawing conclusions from things you might read in the V3
source code -- not every one has the same idea of the styles to be used.

[...]

| (stl_alloc.h, lines 120 ff.), ..., you will find hundreds of examples
| like that.  Naturally, I am really thankful they do that.

Naturally you'll also see the opposite:
>From stl_algobase.h:

     template<typename _InputIter, typename _OutputIter>
	inline _OutputIter
	__copy(_InputIter __first, _InputIter __last,
	       _OutputIter __result,
	       input_iterator_tag)
     template<typename _InputIter, typename _OutputIter>
	inline _OutputIter
	__copy(_InputIter __first, _InputIter __last,
	       _OutputIter __result,
	       input_iterator_tag)

and so one.

-- Gaby


From bagnara at cs.unipr.it  Fri Sep 27 22:15:21 2002
From: bagnara at cs.unipr.it (Roberto Bagnara)
Date: Fri, 27 Sep 2002 22:15:21 +0200
Subject: One last time: annoying warning
References: <Pine.LNX.4.33.0209261929340.22903-100000@higgs.physik.uni-mainz.de> <3D9377B1.2070707@cs.unipr.it> <m3znu3b8er.fsf@soliton.integrable-solutions.net>
Message-ID: <3D94BC59.5040403@cs.unipr.it>

Gabriel Dos Reis wrote:
> Roberto Bagnara <bagnara at cs.unipr.it> writes:
> 
> [...]
> 
> | 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; }
> 
> I'm one of those GCC people taking care of the library and I can
> assure you I don't particularly appreciate that style (like some other
> things in the V3 STYLE).  So, I would say that you should be very
> careful in drawing conclusions from things you might read in the V3
> source code -- not every one has the same idea of the styles to be used.

It is not a matter of style: it is a matter of respect for the users.

> [...]
> 
> | (stl_alloc.h, lines 120 ff.), ..., you will find hundreds of examples
> | like that.  Naturally, I am really thankful they do that.
> 
> Naturally you'll also see the opposite:
>>From stl_algobase.h:
> 
>      template<typename _InputIter, typename _OutputIter>
> 	inline _OutputIter
> 	__copy(_InputIter __first, _InputIter __last,
> 	       _OutputIter __result,
> 	       input_iterator_tag)
>      template<typename _InputIter, typename _OutputIter>
> 	inline _OutputIter
> 	__copy(_InputIter __first, _InputIter __last,
> 	       _OutputIter __result,
> 	       input_iterator_tag)
> 
> and so one.

Huh?  Looks like a copy-and-paste error...


-- 
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



From gdr at integrable-solutions.net  Sat Sep 28 14:54:45 2002
From: gdr at integrable-solutions.net (Gabriel Dos Reis)
Date: 28 Sep 2002 14:54:45 +0200
Subject: One last time: annoying warning
In-Reply-To: Roberto Bagnara's message of "Fri, 27 Sep 2002 22:15:21 +0200"
References: <Pine.LNX.4.33.0209261929340.22903-100000@higgs.physik.uni-mainz.de> <3D9377B1.2070707@cs.unipr.it> <m3znu3b8er.fsf@soliton.integrable-solutions.net> <3D94BC59.5040403@cs.unipr.it>
Message-ID: <m3ofaijmui.fsf@soliton.integrable-solutions.net>

Roberto Bagnara <bagnara at cs.unipr.it> writes:

| Gabriel Dos Reis wrote:
| > Roberto Bagnara <bagnara at cs.unipr.it> writes:
| > 
| > [...]
| > 
| > | 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; }
| > 
| > I'm one of those GCC people taking care of the library and I can
| > assure you I don't particularly appreciate that style (like some other
| > things in the V3 STYLE).  So, I would say that you should be very
| > careful in drawing conclusions from things you might read in the V3
| > source code -- not every one has the same idea of the styles to be used.
| 
| It is not a matter of style: it is a matter of respect for the users.

I guess it depends on what you define to be irrespectful for users.
Given the tone you're taking and the lack of recognizing actual facst, I
guess there is no much interest in continuing this thread.

[...]

| Huh?  Looks like a copy-and-paste error...

No. Just go and check out.

-- Gaby


From bagnara at cs.unipr.it  Sat Sep 28 19:16:29 2002
From: bagnara at cs.unipr.it (Roberto Bagnara)
Date: Sat, 28 Sep 2002 19:16:29 +0200
Subject: [PURRS-devel] Re: One last time: annoying warning
References: <Pine.LNX.4.33.0209261929340.22903-100000@higgs.physik.uni-mainz.de> <3D9377B1.2070707@cs.unipr.it> <m3znu3b8er.fsf@soliton.integrable-solutions.net> <3D94BC59.5040403@cs.unipr.it> <m3ofaijmui.fsf@soliton.integrable-solutions.net>
Message-ID: <3D95E3ED.7000803@cs.unipr.it>

Gabriel Dos Reis wrote:
> Roberto Bagnara <bagnara at cs.unipr.it> writes:
> 
> | Gabriel Dos Reis wrote:
> | > I'm one of those GCC people taking care of the library and I can
> | > assure you I don't particularly appreciate that style (like some other
> | > things in the V3 STYLE).  So, I would say that you should be very
> | > careful in drawing conclusions from things you might read in the V3
> | > source code -- not every one has the same idea of the styles to be used.
> | 
> | It is not a matter of style: it is a matter of respect for the users.
> 
> I guess it depends on what you define to be irrespectful for users.

Here is a partial definition that applies to the present case.
Refusing to write

(1)      virtual void destroy(bool /* call_parent */) { }

instead of

(2)      virtual void destroy(bool call_parent) { }

*in a header file* is irrespectful to the users.  The reason is that
(1) is semantically equivalent to (2), conveys the same information
to maintainers than (2), and has the advantage of allowing a productive
compilation with -W -Wall of g++, with --remarks of Comeau C++,
with -w2 of Intel's icc, and so forth.

> Given the tone you're taking

Tone?  Which tone?  I am simply defending a point of view that I
believe is quite reasonable.  I have reread my messages but I don't
see what you are talking about.  Please, resist the temptation of
nitpicking on my tone and see if you can suggest a viable solution
to the issue I am raising.

 > and the lack of recognizing actual facst,

Facts?  Which facts?  I was offered no facts: you and others have
simply stated that your very personal taste is against things like

     void foo(int /* i */) { }

which I don't believe is a fact.  OK, you offered the fact that
the GNU standard library does not always use the form (1) above:
this is a fact.  You also stated, but this is not a fact, that you
would rather use form (2): something that, I believe, would turn
compiling with -W -Wall to a complete nightmare.  (I wonder if,
to be consistent, you should also advocate the removal of the unused
argument warnings from g++.)

I also do not consider a fact the suggestion that we should write
a script to filter out warnings for each compiler we use, perhaps
with variants for different compilation flags, perhaps changing
the scripts to accommodate changes in GiNaC header.
Besides being compiler-dependent, should the script to filter out
warnings be also dependent on the location where GiNaC is installed?
On the line number where (2) occurs?  Should all warnings coming
from a file called basic.h be silenced?  But of course, if GiNaC's
developers prefer (2) to (1), we should be prepared to teach the
script to ignore also the warnings coming from the 40 (fourty)
include files of GiNaC, and we should update the script if they
restructure their include files.
No: I don't think this is a serious suggestion.

Perhaps the implicit suggestion we have been given is to stop
compiling with extra warnings, but we don't want to do it.
We did not invent the extra warnings options.  We found them
there and we discovered that they were very effective in catching
errors we and our students make.
So we use them with all the compilers we use.  We were happy
until the day when, around GiNaC 1.0.5, the line of code (2)
was inserted...

 > I guess there is no much interest in continuing this thread.

This is a beautiful oxymoron ;-)

> | Huh?  Looks like a copy-and-paste error...
> 
> No. Just go and check out.

I had checked already: the fragment you included is

      template<typename _InputIter, typename _OutputIter>
	inline _OutputIter
	__copy(_InputIter __first, _InputIter __last,
	       _OutputIter __result,
	       input_iterator_tag)
      template<typename _InputIter, typename _OutputIter>
	inline _OutputIter
	__copy(_InputIter __first, _InputIter __last,
	       _OutputIter __result,
	       input_iterator_tag)

This is not C++, does not occur anywhere in the file
stl_algobase.h released with GCC 3.2 and, not containing
a function body, does not show any unused parameter.
I guess what you wanted to show is on the CVS sources:
fine.  Point understood anyway.  I keep my fingers crossed
in the hope that the GCC developers will resist the temptation
of screwing their header files in the name of abstract style
considerations that do not take the user's needs into account.
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



From gdr at integrable-solutions.net  Sun Sep 29 10:19:24 2002
From: gdr at integrable-solutions.net (Gabriel Dos Reis)
Date: 29 Sep 2002 10:19:24 +0200
Subject: [PURRS-devel] Re: One last time: annoying warning
In-Reply-To: Roberto Bagnara's message of "Sat, 28 Sep 2002 19:16:29 +0200"
References: <Pine.LNX.4.33.0209261929340.22903-100000@higgs.physik.uni-mainz.de> <3D9377B1.2070707@cs.unipr.it> <m3znu3b8er.fsf@soliton.integrable-solutions.net> <3D94BC59.5040403@cs.unipr.it> <m3ofaijmui.fsf@soliton.integrable-solutions.net> <3D95E3ED.7000803@cs.unipr.it>
Message-ID: <m3d6qxfbsj.fsf@soliton.integrable-solutions.net>

Roberto Bagnara <bagnara at cs.unipr.it> writes:

[...]

| > Given the tone you're taking
| 
| Tone?  Which tone?  I am simply defending a point of view that I
| believe is quite reasonable.

Telling people they are irrespectful to users, when it is a matter of
style isn't something I consider "reasonable" for any reasonable
definition of "reasonable.

[...]

|  > and the lack of recognizing actual facst,
| 
| Facts?  Which facts?  I was offered no facts: you and others have
| simply stated that your very personal taste is against things like
| 
|      void foo(int /* i */) { }
| 
| which I don't believe is a fact.  OK, you offered the fact that
| the GNU standard library does not always use the form (1) above:
| this is a fact.

Well, you need to agree with yourself when a fact was given or not.
Saying no, then yes isn't helpful.

[...]

| (I wonder if,
| to be consistent, you should also advocate the removal of the unused
| argument warnings from g++.)

As a g++ user, probably yes.  *I* never saw its usefulness.  But I
understand that other peolpe do use it, and since I don't use it in my
own code its mere presence in the compiler doesn't bother me.

| I also do not consider a fact the suggestion that we should write
| a script to filter out warnings for each compiler we use, perhaps
| with variants for different compilation flags, perhaps changing
| the scripts to accommodate changes in GiNaC header.

First I never qualify that as a *fact* -- so I don't understand why
you're bringing it in the first place in this part of your reply.

Now, given the wide variety of kinds of noise^Wdiagnostics
different compilers output, I do consider that suggestion a good one.

[...]

| Perhaps the implicit suggestion we have been given is to stop
| compiling with extra warnings, but we don't want to do it.
| We did not invent the extra warnings options. 

Not just because you didn't invent them means you ought to use them.

[...]

| I keep my fingers crossed
| in the hope that the GCC developers will resist the temptation
| of screwing their header files in the name of abstract style
| considerations that do not take the user's needs into account.

Well, the header files were screwed (IMO) many times in the name of
"abstract style" considerations -- I can't say those modifications
were actually taking any input from users.  You can look in the
archives to see the logs.

We also use 

  #pragma GCC system_header

to make sure no warning will be output (with some set of options) just
because someone thought a given abstract style ought to be diagnosed.

Just learn to use the tool.

-- Gaby


From bagnara at cs.unipr.it  Sun Sep 29 11:05:00 2002
From: bagnara at cs.unipr.it (Roberto Bagnara)
Date: Sun, 29 Sep 2002 11:05:00 +0200
Subject: [PURRS-devel] Re: One last time: annoying warning
References: <Pine.LNX.4.33.0209261929340.22903-100000@higgs.physik.uni-mainz.de> <3D9377B1.2070707@cs.unipr.it> <m3znu3b8er.fsf@soliton.integrable-solutions.net> <3D94BC59.5040403@cs.unipr.it> <m3ofaijmui.fsf@soliton.integrable-solutions.net> <3D95E3ED.7000803@cs.unipr.it> <m3d6qxfbsj.fsf@soliton.integrable-solutions.net>
Message-ID: <3D96C23C.8040407@cs.unipr.it>

Gabriel Dos Reis wrote:
> We also use 
> 
>   #pragma GCC system_header
> 
> to make sure no warning will be output (with some set of options) just
> because someone thought a given abstract style ought to be diagnosed.
> 
> Just learn to use the tool.
 >
 > -- Gaby

I know how to use the tool, thanks.  Perhaps GiNaC developers could use
a pragma that way. Or perhaps they don't really care.  I certainly do not
care any longer and, quite frankly, I have more interesting things to do.
Hope the same for you.

    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