| From: | Pavan Deolasee <pavan(dot)deolasee(at)gmail(dot)com> |
|---|---|
| To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
| Cc: | pgsql-hackers <pgsql-hackers(at)postgresql(dot)org> |
| Subject: | Re: Is this code safe? |
| Date: | 2014-08-28 12:29:07 |
| Message-ID: | CABOikdO4ZaE-T_x-DDuFCTb1fN1LVX_C3=d_Hxtm0dT9XBNhOg@mail.gmail.com |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On Thu, Aug 28, 2014 at 11:20 AM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> Pavan Deolasee <pavan(dot)deolasee(at)gmail(dot)com> writes:
> > Can some kind of compiler optimisation reorder things such that the "else
> > if" expression is evaluated using the old, uninitialised value of optval?
>
> Any such behavior is patently illegal per the C standard.
Thanks a lot for explaining that.
> Not that that's
> always stopped compiler writers; but I think you might be looking at a
> compiler bug.
I'd requested the reporter to try moving the getsockopt() call outside "if"
expression. That hasn't helped. So I think its a case of getsockopt()
neither returning an error nor setting optval to any sane value. Will try
to get more details about the platform etc.
Thanks,
Pavan
--
Pavan Deolasee
http://www.linkedin.com/in/pavandeolasee
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Magnus Hagander | 2014-08-28 12:29:29 | Re: re-reading SSL certificates during server reload |
| Previous Message | Fujii Masao | 2014-08-28 12:28:05 | Re: pgsql: Allow units to be specified in relation option setting value. |