On Thu, 2004-09-16 at 09:18, Neil Conway wrote:
> I'll update the patch and apply it later today.
Applied to HEAD. The version of the patch that I applied is attached.
-Neil
Index: src/backend/utils/adt/arrayfuncs.c
===
RCS file: /h
On Thu, 2004-09-16 at 12:19, Tom Lane wrote:
> I prefer
>
> ptr = (foo *) malloc(sizeof(foo));
> or
> ptr = (foo *) malloc(n * sizeof(foo));
> since here you will get a warning if ptr is typed as something other
> than foo *.
I was leaving out the cast above because IMHO that's some
Neil Conway <[EMAIL PROTECTED]> writes:
> Personally I like the style I used, because it makes one class of
> mistake more difficult -- getting the sizeof() wrong. Suppose the type
> of the variable you're allocating changes -- if you use
> ptr = malloc(sizeof(*ptr));
> then the code is still rig
On Thu, 2004-09-16 at 00:18, Tom Lane wrote:
> I dislike what you did at lines 983-1012 (replace a local variable by
> possibly-many stores into an array).
Ok, I'll revert it.
> Also, as long as we're fixing unreadable code, how about (line 1019)
> [...]
Sounds good to me.
I'll update the patch
On Thu, 2004-09-16 at 03:32, Joe Conway wrote:
> Personally I prefer the original style here.
Personally I like the style I used, because it makes one class of
mistake more difficult -- getting the sizeof() wrong. Suppose the type
of the variable you're allocating changes -- if you use
ptr = mall
Neil Conway wrote:
Barring any objections, I'll apply the patch within 24 hours.
***
*** 965,978
* (including any overhead such as escaping backslashes), and detect
* whether each item needs double quotes.
*/
! values = (char **) palloc(nitems * si
Neil Conway <[EMAIL PROTECTED]> writes:
> I fixed it by initializing dims_str[0] to '\0' circa line 1018 in
> current sources. While doing so I couldn't resist the temptation to fix
> a few of arrayfunc.c's crimes against good programming practise, so the
> attached patch includes some additional c
This patch fixes a read of uninitialized memory in array_out(). The code
was previously doing a strlen() on a stack-allocated char array that,
under some code paths, had never been assigned to. The problem doesn't
appear in REL7_4_STABLE, so there's no need for a backport.
I fixed it by initializi
