pgsql (aclocal.m4 configure configure.in)

Peter Eisentraut - PostgreSQL <petere@hub.org> writes:

Remove configure tests for `signed', `volatile', and signal handler args;
the harm potential outweighs the possible benefits.

Ahem. Should this change not have been discussed *before* making it?
I am sure you have just broken some ports to older systems. You need
to justify doing that. Where is the "harm potential"?

regards, tom lane

Peter Eisentraut <peter_e@gmx.net> writes:

Tom Lane writes:

Peter Eisentraut - PostgreSQL <petere@hub.org> writes:

Remove configure tests for `signed', `volatile', and signal handler args;
the harm potential outweighs the possible benefits.

Ahem. Should this change not have been discussed *before* making it?

Well, I can't really do more than ask and wait for objections, can I?

If you did, I didn't see it.

The problem with omitting "signed" is that it is simply not correct to
just omit it. Consider "signed char" where char is unsigned by default.

OK, so we *may* have problems on machines where (a) the compiler doesn't
grok "signed" AND (b) char is unsigned by default. Your change does not
improve matters at all for these machines; the only way to fix it (if
anything needs fixed) is to change the code. On the other hand, you
just broke Postgres for machines where the compiler doesn't do "signed"
and char is signed --- which I believe is a larger population. For
everyone else, it's a no-op.

Regardless of the number of machines involved, breaking things for one
group without improving matters elsewhere is not a net forward step in
portability in my mind.

The problem with volatile is similar: omitting volatile breaks the program
semantics.

Again, same comments. You haven't fixed any platforms, and you may have
broken some.

For signal handlers, three things: firstly this thing has been hard-coded,
no way to for users to change it except for hand-editing, and there is no
known case where anyone had to do that. If it is a problem then we need to
automate that check.

Agreed, there is not currently any known system where the macro would
need to be changed. But what's the point of removing the macro? You
haven't improved portability, nor improved readability (if anything,
you have hurt it --- formerly it was easy to tell that a routine was
intended as a signal handler, or to search for all signal handlers).
You've merely ensured that if anyone ever does have a problem in this
area, they will need to undo what you did on their way to fixing it.

I think all three of these changes were ill-considered.

regards, tom lane

Peter Eisentraut <peter_e@gmx.net> writes:

Points taken. I'm reverting it.

Good, thanks for listening...

regards, tom lane