From: | Stephen Frost <sfrost(at)snowman(dot)net> |
---|---|
To: | Michael Meskes <meskes(at)postgresql(dot)org> |
Cc: | pgsql-hackers(at)postgresql(dot)org |
Subject: | ECPG timestamp '%j' |
Date: | 2013-07-14 23:33:29 |
Message-ID: | 20130714233329.GE2511@tamriel.snowman.net |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Michael,
While looking at complaints from the Coverity scanner system, it looks
like it's detected a case in ECPG where we provide a "day-of-year"
format option (%j), but we never actually calculate what the day of
year *is*, resulting in an uninitialized value.
Other parts of the code (non-ECPG) appears to realize that timestamp2tm
doesn't fill in day-of-year in the struct and they calculate it
afterwards. Perhaps ECPG needs to adopt that approach also, perhaps
either in dttofmtasc_replace() or PGTYPEStimestamp_fmt_asc()..?
I was able to get what I believe is an incorrect result through a bit
of hacking on the ECPG test cases:
timestamp_fmt_asc: 0: 10922-abc%
after adding:
out = (char*) malloc(32);
i = PGTYPEStimestamp_fmt_asc(&ts1, out, 31, "%j-abc%%");
printf("timestamp_fmt_asc: %d: %s\n", i, out);
free(out);
into pgtypeslib/dt_test.pgc.
If you don't have time to look into this, let me know and I'll try and
get back to it soon.
Thanks!
Stephen
From | Date | Subject | |
---|---|---|---|
Next Message | Greg Smith | 2013-07-15 00:09:50 | Re: Changing recovery.conf parameters into GUCs |
Previous Message | Greg Smith | 2013-07-14 22:46:41 | Re: Improvement of checkpoint IO scheduler for stable transaction responses |