Re: signed, volatile, etc

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: signed, volatile, etc
Дата
Msg-id 12343.967470322@sss.pgh.pa.us
обсуждение исходный текст
Ответ на signed, volatile, etc  (Tom Lane <tgl@sss.pgh.pa.us>)
Список pgsql-hackers
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


В списке pgsql-hackers по дате отправления:

Предыдущее
От: Hannu Krosing
Дата:
Сообщение: SQL COPY syntax extension (was: Performance on inserts)
Следующее
От: Patrick Welche
Дата:
Сообщение: Re: How Do You Pronounce "PostgreSQL"?