Message-ID: <1f8a7f29-b526-db35-5584-a078ca20c8e2@postgrespro.ru>
Date: Mon, 10 Jul 2023 12:39:52 +0300
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:102.0)
 Gecko/20100101 Thunderbird/102.12.0
Subject: Re: gcc -Wclobbered in PostgresMain
Content-Language: en-US
To: Tom Lane <tgl@sss.pgh.pa.us>
Cc: PostgreSQL Hackers <pgsql-hackers@postgresql.org>
References: <2eda015b-7dff-47fd-d5e2-f1a9899b90a6@postgrespro.ru>
 <1632266.1688829082@sss.pgh.pa.us>
From: Sergey Shinderuk <s.shinderuk@postgrespro.ru>
In-Reply-To: <1632266.1688829082@sss.pgh.pa.us>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Archived-At: 
 <https://www.postgresql.org/message-id/1f8a7f29-b526-db35-5584-a078ca20c8e2%40postgrespro.ru>
Precedence: bulk

Hello, Tom,


On 08.07.2023 18:11, Tom Lane wrote:
> What we ought to be doing is resetting these two flags
> after the disable_all_timeouts call.


Oops, I missed that.


> Having done that, it wouldn't really be necessary to mark these
> as volatile.  I kept that marking anyway for consistency with
> send_ready_for_query, but perhaps we shouldn't?


I don't know. Maybe marking them volatile is more future proof. Not sure.


>> I also moved firstchar's declaration inside the loop where it's used, to
>> make it clear that this variable needn't be volatile and is not
>> preserved after longjmp().
> 
> Good idea, but then why not the same for input_message?  It's fully
> reinitialized each time through the loop, too.


Yeah, that's better.


> In short, something like the attached, except I'm not totally sold
> on changing the volatility of the timeout flags.

Looks good to me.


Thank you.

-- 
Sergey Shinderuk		https://postgrespro.com/