May 2007 - developers-list

Re: [Monetdb-developers] [Monetdb-sql-checkins] sql/src/test/Views/Tests All, 1.1, 1.2
by Romulo Goncalves 08 May '07

08 May '07

Martin Kersten wrote: > Update of /cvsroot/monetdb/sql/src/test/Views/Tests > In directory sc8-pr-cvs16:/tmp/cvs-serv2956/Tests > > Modified Files: > All > Log Message: > Added test file for bug --[ 1714814 ] View creation using a function.... > > Update of /cvsroot/monetdb/sql/src/test/BugTracker/Tests In directory sc8-pr-cvs16:/tmp/cvs-serv23652 Modified Files: All create_column.SF-1643542.sql Added Files: infinite_loop.SF-1714809.sql view_creation_using_func.SF-1714814.sql This checkin was done at 13:21 by me ;) the test for the bug was added to the BugTracker with the name of the bug_where_bug_was_reported_bug_number In views I only add normal tests created by me to test the views to detect future crash due modifications on the code. The tests that are there are do not come from bugs reports. Regards, Romulo > Index: All > =================================================================== > RCS file: /cvsroot/monetdb/sql/src/test/Views/Tests/All,v > retrieving revision 1.1 > retrieving revision 1.2 > diff -u -d -r1.1 -r1.2 > --- All 2 Nov 2006 15:04:43 -0000 1.1 > +++ All 8 May 2007 15:33:42 -0000 1.2 > @@ -1 +1,2 @@ > Views > +view_functioncall > > > ------------------------------------------------------------------------- > This SF.net email is sponsored by DB2 Express > Download DB2 Express C - the FREE version of DB2 express and take > control of your XML. No limits. Just data. Click to get it now. > http://sourceforge.net/powerbar/db2/ > _______________________________________________ > Monetdb-sql-checkins mailing list > Monetdb-sql-checkins(a)lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/monetdb-sql-checkins

1 0

Re: [Monetdb-developers] Fwd: pf/tijah startNodes: node* or string*
by Jens Teubner 08 May '07

08 May '07

On Tue, May 08, 2007 at 03:39:03PM +0200, Jan Flokstra wrote: > Hi Jens, > > Hope you are still in Munich:-) We have a little problem here which we > do not known how to debug. It is described extensively in the the > e-mail at the end of this mail. But the basic problem is we do not > know how to debug a typing problem. We have the following query: > > tijah:query(fn:collection("c"),"//LINE[about(.,foul)]") > > And the signatures of the function involved are: > > (0) fn:collection (string) as node* > (1) tijah:query(string) as node* > (2) tijah:query(item*, string) as node* > (3) tijah:query(string, item) as node* > (4) tijah:query(item*, string, item) as node* Yes, I am still here. First of all, the function signatures that you listed here are the ones that appear in the *comments* in xquery_fo.c. Unfortunately, the code says something different! Very dangerous! I have corrected this some minutes ago. So here's what happens during Core generation and type checking and why your example makes trouble. (It boils down to a conflict between the signatures (2) and (3).) Out of the possible implementations for a function (tijah:query()), Pathfinder's function scope checker assigns those to the function application that have the matching *number of parameters*. This is in the spirit of the W3C specs: user-defined functions may be overloaded, but must differ in the number of arguments (and not just be distinguishable by their types). Only built-in functions may be overloaded in the sense that two functions may have the same number of arguments, but different argument types. Then, Core generation in fs.brg looks at the required type for each of the arguments. If the function expects an atomic value, the function argument is *atomized* (i.e., nodes are converted into something atomic, typically xs:untypedAtomic). Pathfinder's type checker finally selects the most specific implementation if there is more than one for the given number of argument (only really relevant for built-ins). The problem that you are experiencing is a combination of the two foregoing paragraphs. The function scope checker assigns those function implementations with two arguments to the `apply' node (signatures (2) and (3)). Core generation then (randomly) picks on of these two to determine whether atomization is required. Type checking finally throws the error. This behavior is perfectly okay for all functions we had so far and for all functions in the W3C specs. The combination of (a) two function signatures with the same number of arguments and (b) arguments having a node type in one signature and an atomic type in the other is what bites you. You probably should rethink your two function signatures (2) and (3). Note that they also introduce some ambiguity. If I call the function as `tijah:query (node, node)', should the first or the second argument be casted to an atomic value? Note that this implicit atomization happens everywhere in XQuery (if necessary) and it is perfectly consistent to do this here as well. A clean solution would work without such two conflicting signatures. A hack could be to treat tijah:query() explicitly in the involved parts in the Pathfinder code and do something magic to make things work. I would not recommend to do so, though, as it primarily would introduce inconsistency. Don't hesitate to ask again if my answers weren't clear. Jens -- Jens Teubner Technische Universitaet Muenchen, Department of Informatics D-85748 Garching, Germany Tel: +49 89 289-17259 Fax: +49 89 289-17263 Please avoid sending me MS Word, MS Excel or MS PowerPoint files. Why? See http://www.fsf.org/philosophy/no-word-attachments.html

1 0

Re: [Monetdb-developers] [Monetdb-checkins] MonetDB5/src/optimizer opt_partitions.mx, 1.6, 1.7
by Stefan Manegold 07 May '07

07 May '07

On Mon, May 07, 2007 at 07:48:22AM +0000, Martin Kersten wrote: > Update of /cvsroot/monetdb/MonetDB5/src/optimizer > In directory sc8-pr-cvs16:/tmp/cvs-serv3297 > > Modified Files: > opt_partitions.mx > Log Message: > The first version of the partition code generator. > The code produced looks reasonable. > The necessary list module is not yet implemented. Nevertheless, checked-in code should always compile --- at least on one platform (and with the most conservative settings); however: ======== gcc -DHAVE_CONFIG_H -I. -I/ufs/manegold/_/scratch0/Monet/Testing/Current/source/MonetDB5/src/optimizer -I../.. -I/ufs/manegold/_/scratch0/Monet/Testing/Current/source/MonetDB5/src/optimizer -I../mal -I/ufs/manegold/_/scratch0/Monet/Testing/Current/source/MonetDB5/src/optimizer/../mal -I../modules/mal -I/ufs/manegold/_/scratch0/Monet/Testing/Current/source/MonetDB5/src/optimizer/../modules/mal -I/ufs/manegold/_/scratch0/Monet/Testing/Current/prefix.--enable-strict_--disable-optimize_--enable-debug/include/MonetDB -I/ufs/manegold/_/scratch0/Monet/Testing/Current/prefix.--enable-strict_--disable-optimize_--enable-debug/include/MonetDB/common -I/ufs/manegold/_/scratch0/Monet/Testing/Current/prefix.--enable-strict_--disable-optimize_--enable-debug/include/MonetDB/gdk -DLIBOPTIMIZER -Wall -Wextra -std=c99 -g -Werror-implicit-function-declaration -Werror -Wpointer-arith -Wdeclaration-after-statement -D_REENTRANT -c opt_partitions.c -fPIC -DPIC -o .libs/lib_optimizer_la-opt_partitions.o /ufs/manegold/_/scratch0/Monet/Testing/Current/source/MonetDB5/src/optimizer/opt_partitions.mx: In function 'OPTpartitionStrategy': /ufs/manegold/_/scratch0/Monet/Testing/Current/source/MonetDB5/src/optimizer/opt_partitions.mx:269: error: 'TYPE_list' undeclared (first use in this function) /ufs/manegold/_/scratch0/Monet/Testing/Current/source/MonetDB5/src/optimizer/opt_partitions.mx:269: error: (Each undeclared identifier is reported only once /ufs/manegold/_/scratch0/Monet/Testing/Current/source/MonetDB5/src/optimizer/opt_partitions.mx:269: error: for each function it appears in.) make[5]: *** [lib_optimizer_la-opt_partitions.lo] Error 1 ======== Stefan -- | Dr. Stefan Manegold | mailto:Stefan.Manegold@cwi.nl | | CWI, P.O.Box 94079 | http://www.cwi.nl/~manegold/ | | 1090 GB Amsterdam | Tel.: +31 (20) 592-4212 | | The Netherlands | Fax : +31 (20) 592-4312 |

1 0

[Monetdb-developers] An XQuery question
by Ying Zhang 07 May '07

07 May '07

Dear developers, If I run the follwoing XQuery query with Galax: ========== test.xq ========== declare namespace t = "test"; declare function t:echoVoid() { () }; t:echoVoid() ========== Galax gives a warning: $ galax-run ~/test.xq [WARNING] Expression '???' at File "/ufs/zhang/test.xq", line 3, characters 8-37 has empty type, but is not the empty expression () Does any one have an idea how I can correct/modify my query to get rid of this warning? Thanks in advance! Jennie

2 2

Re: [Monetdb-developers] [Monetdb-pf-checkins] pathfinder/modules/pftijah nexi.c, 1.57, 1.58 nexi_generate_mil.c, 1.27, 1.28 pftijah.mx, 1.116, 1.117
by Stefan Manegold 07 May '07

07 May '07

On Mon, May 07, 2007 at 07:01:43AM +0000, Jan Flokstra wrote: > Update of /cvsroot/monetdb/pathfinder/modules/pftijah > In directory sc8-pr-cvs16:/tmp/cvs-serv20990/modules/pftijah > > Modified Files: > nexi.c nexi_generate_mil.c pftijah.mx > Log Message: > * Implement private term- and tag dictionaries. Default is still the global > version so nothing changed yet in the format. I'm having terrible trouble > with the Mtest's again. This version could not be tested by our Mtest tests > because the first query executes OK but all queries after that seem to > 'forget' the instance variables of module pftijah. I will look if the same > happens on other machine and post a bugreport for it. does the same happen if you run the test(s) by hand i.e., without Mtest? How do the queries and the test script(s) look like? How do you (successfully?) run them by hand? How do you (unsuccesfully) run them via Mtest? Stefan -- | Dr. Stefan Manegold | mailto:Stefan.Manegold@cwi.nl | | CWI, P.O.Box 94079 | http://www.cwi.nl/~manegold/ | | 1090 GB Amsterdam | Tel.: +31 (20) 592-4212 | | The Netherlands | Fax : +31 (20) 592-4312 |

2 2

[Monetdb-developers] Mtest_4_sql
by Romulo Goncalves 04 May '07

04 May '07

I am running Mtest_4_SQL and I am getting strange error messages from MAPIPORT: ! Socket-Check failed for MAPIserver on <localhost:37631> with #98; 'Address already in use' ! ! MAPIPORT was not properly released by Mserver ! * (zones.test.err.FILTERED) significantly ... * (rank.test.out.FILTERED) significantly . ! Socket-Check failed for MAPIserver on <localhost:30932> with #98; 'Address already in use' ! ! MAPIPORT was not properly released by Mserver ! * (function_syntax.test.out.FILTERED) significantly * (function_syntax.test.err.FILTERED) significantly . ! Socket-Check failed for MAPIserver on <localhost:37107> with #98; 'Address already in use' ! ! MAPIPORT was not properly released by Mserver ! Any idea? Regards, Romulo

3 2

Re: [Monetdb-developers] [Monetdb-pf-checkins] pathfinder/compiler/mil milprint_summer.c, 1.371, 1.372
by Stefan Manegold 02 May '07

02 May '07

Sjoerd, didn't like my fix? ;-) Well, actually, I'm afraid you just re-introduced the problem: in short ======== size_t maxbufsize = 0; char *nme = NULL; while (...) { ... if (maxbufsize < strlen(tpe) + 4) { maxbufsize = strlen(tpe) + 4; nme = nme ? realloc(nme, maxbufsize) : malloc(maxbufsize); } ... if (...) { *nme++ = 'x'; ... } } if (nme) free(nme); ... ======== IMHO does not work, since the nme++ changes nme, causing later realloc(nme, maxbufsize) and/or free(nme) to "behave strangly" --- or simply segfault ... Stefan On Wed, May 02, 2007 at 09:39:32PM +0000, Sjoerd Mullender wrote: > Update of /cvsroot/monetdb/pathfinder/compiler/mil > In directory sc8-pr-cvs16:/tmp/cvs-serv18640 > > Modified Files: > milprint_summer.c > Log Message: > Fix bug introduced by replacing call to alloca. > > Index: milprint_summer.c > =================================================================== > RCS file: /cvsroot/monetdb/pathfinder/compiler/mil/milprint_summer.c,v > retrieving revision 1.371 > retrieving revision 1.372 > diff -u -d -r1.371 -r1.372 > --- milprint_summer.c 2 May 2007 21:15:18 -0000 1.371 > +++ milprint_summer.c 2 May 2007 21:39:30 -0000 1.372 > @@ -11142,17 +11142,17 @@ > /* initialize function variables */ > /* ============================= */ > size_t maxbufsize = 0; > - char *buf = NULL; > + char *nme = NULL; > while (args->kind != c_nil) > { > /* get the type name, and assure there *is* a namespace */ > char *tpe = PFty_str(TY(LR(args))); > - char *nme; > + char *buf; > if (maxbufsize < strlen(tpe) + 4) { > maxbufsize = strlen(tpe) + 4; > - buf = buf ? realloc(buf, maxbufsize) : malloc(maxbufsize); > + nme = nme ? realloc(nme, maxbufsize) : malloc(maxbufsize); > } > - nme = buf; > + buf = nme; > if (strchr(tpe, ':') == NULL) { > *nme++ = 'x'; > *nme++ = 's'; > @@ -11178,8 +11178,8 @@ > > args = R(args); > } > - if (buf) > - free(buf); > + if (nme) > + free(nme); > /* create the full signature that also is a valid MIL identifier */ > c->sem.fun->sig = PFmalloc(12+3*(strlen(sig)+strlen(p))); > > > > ------------------------------------------------------------------------- > This SF.net email is sponsored by DB2 Express > Download DB2 Express C - the FREE version of DB2 express and take > control of your XML. No limits. Just data. Click to get it now. > http://sourceforge.net/powerbar/db2/ > _______________________________________________ > Monetdb-pf-checkins mailing list > Monetdb-pf-checkins(a)lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/monetdb-pf-checkins > -- | Dr. Stefan Manegold | mailto:Stefan.Manegold@cwi.nl | | CWI, P.O.Box 94079 | http://www.cwi.nl/~manegold/ | | 1090 GB Amsterdam | Tel.: +31 (20) 592-4212 | | The Netherlands | Fax : +31 (20) 592-4312 |

1 1

Re: [Monetdb-developers] [Monetdb-sql-checkins] sql/src/tools embeddedclient.mx, 1.23, 1.24 monetdb.py.i, 1.5, 1.6 prog.c, 1.17, 1.18
by Jan Rittinger 02 May '07

02 May '07

perhaps its triggered by Niels newest ``any type'' changes in bat_store.mx -- just guessing. On 04/27/2007 03:47 PM, Jan Rittinger wrote with possible deletions: > I just managed to install gdb as well and it seems like it is memory > related (BTW pathfinder works). > > gdb M4: > MonetDB>module(sql_server); > [New Thread 1082132832 (LWP 896)] > > Program received signal SIGSEGV, Segmentation fault. > [Switching to Thread 182925371136 (LWP 887)] > 0x0000002a97183c1f in memcpy () from /lib64/tls/libc.so.6 > (gdb) bt > #0 0x0000002a97183c1f in memcpy () from /lib64/tls/libc.so.6 > #1 0x0000002a9f960718 in ?? () > #2 0x0000002a965eff6c in HEAPcopy () from > /home/ntap/rittinge/work/MonetDB/Linux/lib64/libbat.so.0 > #3 0x0000002a966b340e in BATcopy () from > /home/ntap/rittinge/work/MonetDB/Linux/lib64/libbat.so.0 > #4 0x0000002a965f0a34 in BATkdiff () from > /home/ntap/rittinge/work/MonetDB/Linux/lib64/libbat.so.0 > #5 0x0000002a9e8713f9 in load_trans () from > /home/ntap/rittinge/work/MonetDB4/Linux/lib64/MonetDB4/lib/lib_sql_server.so > > #6 0x0000002a9e873b65 in store_init () from > /home/ntap/rittinge/work/MonetDB4/Linux/lib64/MonetDB4/lib/lib_sql_server.so > > #7 0x0000002a9e846b1a in mvc_init () from > /home/ntap/rittinge/work/MonetDB4/Linux/lib64/MonetDB4/lib/lib_sql_server.so > > #8 0x0000002a9e80276a in sql_frontend_wrap () from > /home/ntap/rittinge/work/MonetDB4/Linux/lib64/MonetDB4/lib/lib_sql_server.so > > #9 0x0000002a95f8bd48 in interpret () from > /home/ntap/rittinge/work/MonetDB4/Linux/lib64/libmonet.so.0 > #10 0x0000002a95f9c0aa in interpret_assignment () from > /home/ntap/rittinge/work/MonetDB4/Linux/lib64/libmonet.so.0 > #11 0x0000002a95f8bfb6 in interpret () from > /home/ntap/rittinge/work/MonetDB4/Linux/lib64/libmonet.so.0 > #12 0x0000002a95f9bb29 in interpret_seqblock () from > /home/ntap/rittinge/work/MonetDB4/Linux/lib64/libmonet.so.0 > #13 0x0000002a95f8bf98 in interpret () from > /home/ntap/rittinge/work/MonetDB4/Linux/lib64/libmonet.so.0 > #14 0x0000002a95a32d44 in CMDcatch () from > /home/ntap/rittinge/work/MonetDB4/Linux/lib64/MonetDB4/lib/lib_builtin.so.0 > #15 0x0000002a95f8bd48 in interpret () from > /home/ntap/rittinge/work/MonetDB4/Linux/lib64/libmonet.so.0 > #16 0x0000002a95f9bebb in interpret_assignment () from > /home/ntap/rittinge/work/MonetDB4/Linux/lib64/libmonet.so.0 > #17 0x0000002a95f9c2af in interpret_var () from > /home/ntap/rittinge/work/MonetDB4/Linux/lib64/libmonet.so.0 > #18 0x0000002a95f8c118 in interpret () from > /home/ntap/rittinge/work/MonetDB4/Linux/lib64/libmonet.so.0 > #19 0x0000002a95f9bb29 in interpret_seqblock () from > /home/ntap/rittinge/work/MonetDB4/Linux/lib64/libmonet.so.0 > #20 0x0000002a95f8bf98 in interpret () from > /home/ntap/rittinge/work/MonetDB4/Linux/lib64/libmonet.so.0 > #21 0x0000002a95f8c4ec in interpret () from > /home/ntap/rittinge/work/MonetDB4/Linux/lib64/libmonet.so.0 > #22 0x0000002a95f9bb29 in interpret_seqblock () from > /home/ntap/rittinge/work/MonetDB4/Linux/lib64/libmonet.so.0 > #23 0x0000002a95f8bf98 in interpret () from > /home/ntap/rittinge/work/MonetDB4/Linux/lib64/libmonet.so.0 > #24 0x0000002a95f9e289 in handleRequest () from > /home/ntap/rittinge/work/MonetDB4/Linux/lib64/libmonet.so.0 > #25 0x0000002a95f9efc9 in doRequest () from > /home/ntap/rittinge/work/MonetDB4/Linux/lib64/libmonet.so.0 > #26 0x0000002a95fe280e in monetInterpreter () from > /home/ntap/rittinge/work/MonetDB4/Linux/lib64/libmonet.so.0 > #27 0x00000000004020f1 in main () > > gdb M5: > > (gdb) run --dbinit="include sql;" > Starting program: /home/ntap/rittinge/work/MonetDB4/Linux/bin/mserver5 > --dbinit="include sql;" > [Thread debugging using libthread_db enabled] > [New Thread 182918905952 (LWP 938)] > # MonetDB Server v5.0.0_beta2_1 > # Copyright (c) 1993-2007 CWI, all rights reserved > # Compiled for x86_64-suse-linux/64bit with 32bit OIDs dynamically linked > # dbname:demo > # Visit http://monetdb.cwi.nl/ for further information > [New Thread 1082132832 (LWP 939)] > #warning: please don't forget to set your vault key! > #(see /home/ntap/rittinge/work/MonetDB4/Linux//etc/monetdb5.conf) > > > Program received signal SIGSEGV, Segmentation fault. > [Switching to Thread 1082132832 (LWP 939)] > 0x0000002a969f8c1f in memcpy () from /lib64/tls/libc.so.6 > (gdb) bt > #0 0x0000002a969f8c1f in memcpy () from /lib64/tls/libc.so.6 > #1 0x0000000000b373d8 in ?? () > #2 0x0000002a95d2bf6c in HEAPcopy () from > /home/ntap/rittinge/work/MonetDB/Linux/lib64/libbat.so.0 > #3 0x0000002a95def40e in BATcopy () from > /home/ntap/rittinge/work/MonetDB/Linux/lib64/libbat.so.0 > #4 0x0000002a95d2ca34 in BATkdiff () from > /home/ntap/rittinge/work/MonetDB/Linux/lib64/libbat.so.0 > #5 0x0000002aa0403c59 in load_trans () from > /home/ntap/rittinge/work/MonetDB4/Linux//lib64/MonetDB5/lib/lib_sql.so > #6 0x0000002aa04063c5 in store_init () from > /home/ntap/rittinge/work/MonetDB4/Linux//lib64/MonetDB5/lib/lib_sql.so > #7 0x0000002aa03d937a in mvc_init () from > /home/ntap/rittinge/work/MonetDB4/Linux//lib64/MonetDB5/lib/lib_sql.so > #8 0x0000002aa039507b in SQLinit () from > /home/ntap/rittinge/work/MonetDB4/Linux//lib64/MonetDB5/lib/lib_sql.so > #9 0x0000002a956ad57b in initScenario () from > /home/ntap/rittinge/work/MonetDB4/Linux//lib64/libmal.so.0 > #10 0x0000002a956ad81f in setScenario () from > /home/ntap/rittinge/work/MonetDB4/Linux//lib64/libmal.so.0 > #11 0x0000002a9568528b in MSscheduleClient () from > /home/ntap/rittinge/work/MonetDB4/Linux//lib64/libmal.so.0 > #12 0x0000002a9f80e371 in doChallenge () from > /home/ntap/rittinge/work/MonetDB4/Linux//lib64/MonetDB5/lib/lib_mserver.so > #13 0x0000002a9f80ece9 in SERVERlistenThread () from > /home/ntap/rittinge/work/MonetDB4/Linux//lib64/MonetDB5/lib/lib_mserver.so > #14 0x0000002a9663db8f in start_thread () from /lib64/tls/libpthread.so.0 > #15 0x0000002a96a414b3 in clone () from /lib64/tls/libc.so.6 > -- Jan Rittinger Database Systems Technische Universität München (Germany) http://www-db.in.tum.de/~rittinge/

2 3

Re: [Monetdb-developers] [Monetdb-pf-checkins] pathfinder/compiler/mil milprint_summer.c, 1.367, 1.368
by Jan Flokstra 02 May '07

02 May '07

I have great compilation troubles with the last lesson from the master:-) The compiler doesn not know the realloc() and the malloc() function() in the current setting. When I change them into PFrealloc() and PFmalloc() it compiles. But then I still have problems with the "free(buf);" line. There is no PFfree(); and I think GDKfree() will not always work, JanF. On Tuesday 01 May 2007 17:58, Sjoerd Mullender wrote: > Update of /cvsroot/monetdb/pathfinder/compiler/mil > In directory sc8-pr-cvs16:/tmp/cvs-serv17830 > > Modified Files: > milprint_summer.c > Log Message: > When you want to use a library function, make sure the appropriate > include file is included. For alloca there is an extra twist: for the > way to include alloca.h see e.g. monet_utils.mx. Do not hide the lack > of a declaration with a cast. The compiler then thinks the function > returns an int which may well be smaller in space than the actual > value, and hence some bytes of the value may get lost. > > Having said this, alloca should *not* be used in a loop. It allocates > memory in each iteration which is only freed at the end of the > function. If the loop loops many times, that can be a lot of memory > which is allocated on the stack (which is a very finite resource!). > > Here ends today's lesson. > > > Index: milprint_summer.c > =================================================================== > RCS file: /cvsroot/monetdb/pathfinder/compiler/mil/milprint_summer.c,v > retrieving revision 1.367 > retrieving revision 1.368 > diff -u -d -r1.367 -r1.368 > --- milprint_summer.c 27 Apr 2007 18:22:40 -0000 1.367 > +++ milprint_summer.c 1 May 2007 15:57:59 -0000 1.368 > @@ -11140,12 +11140,18 @@ > /* ============================= */ > /* initialize function variables */ > /* ============================= */ > + size_t maxbufsize = 0; > + char *buf = NULL; > while (args->kind != c_nil) > { > /* get the type name, and assure there *is* a namespace */ > char *tpe = PFty_str(TY(LR(args))); > - char *buf = (char*) alloca(4+strlen(tpe)); > - char *nme = buf; > + char *nme; > + if (maxbufsize < strlen(tpe) + 4) { > + maxbufsize = strlen(tpe) + 4; > + buf = buf ? realloc(buf, maxbufsize) : malloc(maxbufsize); > + } > + nme = buf; > if (strchr(tpe, ':') == NULL) { > *buf++ = 'x'; > *buf++ = 's'; > @@ -11171,6 +11177,8 @@ > > args = R(args); > } > + if (buf) > + free(buf); > /* create the full signature that also is a valid MIL identifier > */ c->sem.fun->sig = PFmalloc(12+3*(strlen(sig)+strlen(p))); > > > > ------------------------------------------------------------------------- > This SF.net email is sponsored by DB2 Express > Download DB2 Express C - the FREE version of DB2 express and take > control of your XML. No limits. Just data. Click to get it now. > http://sourceforge.net/powerbar/db2/ > _______________________________________________ > Monetdb-pf-checkins mailing list > Monetdb-pf-checkins(a)lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/monetdb-pf-checkins

3 3