From hio@REDACTED Mon Oct 1 12:43:26 2007 From: hio@REDACTED (YAMASHINA Hio) Date: Mon, 1 Oct 2007 19:43:26 +0900 Subject: [erlang-bugs] Data passed by port_call is corrupted under smp. Message-ID: <20071001194326.3cff9f65.hio@hio.jp> Hi all. Bif port_call uses pre-allocated buffer, and reuse it on succeeding call. But there is no any protection. Then, when using -smp option and port-locking, port_call data is overwritten by another thread. code for reproduction is here: http://fleur.hio.jp/~hio/prive/port_buffer_corruption.tar.gz 9ed0a6e9d5ac5a1b85d80ab3ba8f3ac8 port_buffer_corruption.tar.gz Running make test raises an exception. In call function of this driver, 1. dump data contained in buffer. >> port[86] (A) 83 a 2 cmd[2] buf=0x2aaaaab248c8 thr=1084270944 (port id, "(A)", data, command, pointer and pthread_t) 2. sleep 1 sec (for ease of reproduction). 3. dump same data again. >> port[86] (B) 83 a 3 cmd[2] buf=0x2aaaaab248c8 thr=1084270944 4. return incoming data as return value. At this point, erts_port_call_buff (erts/emulator/beam/erl_bif_port.c) is shared in a OS-specific process. I guess it is required something exclusive control or to make it store as thread-specific. Attached patch is quick hack workaround for this problem. This patch is just a quick hack and using pthread library directly. Tested on otp_src_R11B-5 and otp_src_R12B-0. before patched: $ erl -smp +S 3 -noshell -eval 'my_driver:test_parallel(), halt()' port[86] (A) 83 a 2 cmd[2] buf=0x2aaaaab248c8 thr=1080068448 port[87] (A) 83 a 3 cmd[3] buf=0x2aaaaab248c8 thr=1082169696 port[85] (A) 83 a 1 cmd[1] buf=0x2aaaaab248c8 thr=1084270944 port[85] (B) 83 a 1 cmd[1] buf=0x2aaaaab248c8 thr=1084270944 port[88] (A) 83 a 4 cmd[4] buf=0x2aaaaab248c8 thr=1084270944 port[86] (B) 83 a 4 cmd[2] buf=0x2aaaaab248c8 thr=1080068448 port[89] (A) 83 a 5 cmd[5] buf=0x2aaaaab248c8 thr=1080068448 port[87] (B) 83 a 5 cmd[3] buf=0x2aaaaab248c8 thr=1082169696 port[88] (B) 83 a 5 cmd[4] buf=0x2aaaaab248c8 thr=1084270944 port[89] (B) 83 a 5 cmd[5] buf=0x2aaaaab248c8 thr=1080068448 child:1 collected =ERROR REPORT==== 1-Oct-2007::19:29:10 === Error in process <0.30.0> with exit value: {{badmatch,{2,4}},[{my_driver,child,4}]} =ERROR REPORT==== 1-Oct-2007::19:29:11 === Error in process <0.31.0> with exit value: {{badmatch,{3,5}},[{my_driver,child,4}]} =ERROR REPORT==== 1-Oct-2007::19:29:11 === Error in process <0.32.0> with exit value: {{badmatch,{4,5}},[{my_driver,child,4}]} Communication buffer is shared with every threads. after patched: $ erl -smp +S 3 -noshell -eval 'my_driver:test_parallel(), halt()' port[86] (A) 83 a 2 cmd[2] buf=0x2aaaaab24ab0 thr=1082169696 port[87] (A) 83 a 3 cmd[3] buf=0x2aaaaab24be0 thr=1084270944 port[85] (A) 83 a 1 cmd[1] buf=0x2aaaaab24900 thr=1080068448 port[86] (B) 83 a 2 cmd[2] buf=0x2aaaaab24ab0 thr=1082169696 port[88] (A) 83 a 4 cmd[4] buf=0x2aaaaab24ab0 thr=1082169696 port[87] (B) 83 a 3 cmd[3] buf=0x2aaaaab24be0 thr=1084270944 port[89] (A) 83 a 5 cmd[5] buf=0x2aaaaab24be0 thr=1084270944 port[85] (B) 83 a 1 cmd[1] buf=0x2aaaaab24900 thr=1080068448 port[88] (B) 83 a 4 cmd[4] buf=0x2aaaaab24ab0 thr=1082169696 port[89] (B) 83 a 5 cmd[5] buf=0x2aaaaab24be0 thr=1084270944 child:1 collected child:2 collected child:3 collected child:4 collected child:5 collected $ Each thread has own buffer. Regards. -- YAMASHINA Hio -------------- next part -------------- A non-text attachment was scrubbed... Name: otp_src_R11B-5.portfix.patch Type: application/octet-stream Size: 2364 bytes Desc: not available URL: From rickard.s.green@REDACTED Mon Oct 1 15:30:01 2007 From: rickard.s.green@REDACTED (Rickard Green) Date: Mon, 01 Oct 2007 15:30:01 +0200 Subject: [erlang-bugs] Data passed by port_call is corrupted under smp. In-Reply-To: <20071001194326.3cff9f65.hio@hio.jp> References: <20071001194326.3cff9f65.hio@hio.jp> Message-ID: <4700F659.206@ericsson.com> Thanks for your bug report. This bug will be fixed in the next release. BR, Rickard Green, Erlang/OTP, Ericsson AB. YAMASHINA Hio wrote: > Hi all. > > Bif port_call uses pre-allocated buffer, > and reuse it on succeeding call. > But there is no any protection. > Then, when using -smp option and port-locking, > port_call data is overwritten by another thread. > > code for reproduction is here: > http://fleur.hio.jp/~hio/prive/port_buffer_corruption.tar.gz > > 9ed0a6e9d5ac5a1b85d80ab3ba8f3ac8 port_buffer_corruption.tar.gz > > > Running make test raises an exception. > > In call function of this driver, > 1. dump data contained in buffer. > >> port[86] (A) 83 a 2 cmd[2] buf=0x2aaaaab248c8 thr=1084270944 > (port id, "(A)", data, command, pointer and pthread_t) > 2. sleep 1 sec (for ease of reproduction). > 3. dump same data again. > >> port[86] (B) 83 a 3 cmd[2] buf=0x2aaaaab248c8 thr=1084270944 > 4. return incoming data as return value. > > At this point, erts_port_call_buff (erts/emulator/beam/erl_bif_port.c) > is shared in a OS-specific process. > I guess it is required something exclusive control or > to make it store as thread-specific. > > > Attached patch is quick hack workaround for this problem. > This patch is just a quick hack and using pthread > library directly. > > Tested on otp_src_R11B-5 and otp_src_R12B-0. > > > before patched: > > $ erl -smp +S 3 -noshell -eval 'my_driver:test_parallel(), halt()' > port[86] (A) 83 a 2 cmd[2] buf=0x2aaaaab248c8 thr=1080068448 > port[87] (A) 83 a 3 cmd[3] buf=0x2aaaaab248c8 thr=1082169696 > port[85] (A) 83 a 1 cmd[1] buf=0x2aaaaab248c8 thr=1084270944 > port[85] (B) 83 a 1 cmd[1] buf=0x2aaaaab248c8 thr=1084270944 > port[88] (A) 83 a 4 cmd[4] buf=0x2aaaaab248c8 thr=1084270944 > port[86] (B) 83 a 4 cmd[2] buf=0x2aaaaab248c8 thr=1080068448 > port[89] (A) 83 a 5 cmd[5] buf=0x2aaaaab248c8 thr=1080068448 > port[87] (B) 83 a 5 cmd[3] buf=0x2aaaaab248c8 thr=1082169696 > port[88] (B) 83 a 5 cmd[4] buf=0x2aaaaab248c8 thr=1084270944 > port[89] (B) 83 a 5 cmd[5] buf=0x2aaaaab248c8 thr=1080068448 > child:1 collected > =ERROR REPORT==== 1-Oct-2007::19:29:10 === > Error in process <0.30.0> with exit value: {{badmatch,{2,4}},[{my_driver,child,4}]} > =ERROR REPORT==== 1-Oct-2007::19:29:11 === > Error in process <0.31.0> with exit value: {{badmatch,{3,5}},[{my_driver,child,4}]} > =ERROR REPORT==== 1-Oct-2007::19:29:11 === > Error in process <0.32.0> with exit value: {{badmatch,{4,5}},[{my_driver,child,4}]} > > Communication buffer is shared with every threads. > > after patched: > > $ erl -smp +S 3 -noshell -eval 'my_driver:test_parallel(), halt()' > port[86] (A) 83 a 2 cmd[2] buf=0x2aaaaab24ab0 thr=1082169696 > port[87] (A) 83 a 3 cmd[3] buf=0x2aaaaab24be0 thr=1084270944 > port[85] (A) 83 a 1 cmd[1] buf=0x2aaaaab24900 thr=1080068448 > port[86] (B) 83 a 2 cmd[2] buf=0x2aaaaab24ab0 thr=1082169696 > port[88] (A) 83 a 4 cmd[4] buf=0x2aaaaab24ab0 thr=1082169696 > port[87] (B) 83 a 3 cmd[3] buf=0x2aaaaab24be0 thr=1084270944 > port[89] (A) 83 a 5 cmd[5] buf=0x2aaaaab24be0 thr=1084270944 > port[85] (B) 83 a 1 cmd[1] buf=0x2aaaaab24900 thr=1080068448 > port[88] (B) 83 a 4 cmd[4] buf=0x2aaaaab24ab0 thr=1082169696 > port[89] (B) 83 a 5 cmd[5] buf=0x2aaaaab24be0 thr=1084270944 > child:1 collected > child:2 collected > child:3 collected > child:4 collected > child:5 collected > $ > > Each thread has own buffer. > > > Regards. > > > > ------------------------------------------------------------------------ > > _______________________________________________ > erlang-bugs mailing list > erlang-bugs@REDACTED > http://www.erlang.org/mailman/listinfo/erlang-bugs From dougedmunds@REDACTED Wed Oct 3 02:57:28 2007 From: dougedmunds@REDACTED (Doug Edmunds) Date: Tue, 2 Oct 2007 17:57:28 -0700 Subject: [erlang-bugs] gs documentation bug Message-ID: In the GS user guide, it states: - gs:create(Objtype, Name, Parent, Options). - gs:create(Objtype, Name, Parent, Option). In the GS reference manual, it states: * create(ObjType, Parent, Name, Options) -> ObjId* Obviously one of these has the order of the Parent/Name parameters wrong. -- Doug Edmunds -------------- next part -------------- An HTML attachment was scrubbed... URL: From dougedmunds@REDACTED Wed Oct 3 22:53:50 2007 From: dougedmunds@REDACTED (DougEdmunds) Date: Wed, 03 Oct 2007 13:53:50 -0700 Subject: [erlang-bugs] error in gs documentation in source code Message-ID: <4704015E.8010003@gmail.com> in lib/gs-1.5.7/src/gstk_editor.erl the Options information (beginning at line 24) given is for a Canvas object, not an Editor object Also, if you have the correct Options information for Editor, please email to me. Thanks. == Doug Edmunds From pradermecker@REDACTED Thu Oct 4 03:00:54 2007 From: pradermecker@REDACTED (Pierre Radermecker) Date: Wed, 03 Oct 2007 21:00:54 -0400 Subject: [erlang-bugs] tempo-complete-tag not working at L1 C1 Message-ID: <47043B46.1040600@yahoo.ca> The function tempo-complete-tag (C-c M-Tab) is not working when the cursor is at line 1 col 1. The tempo-match-finder pattern is "[^-a-zA-Z0-9_]\\([-a-zA-Z0-9_]+\\)\\=". If I set it to be "\\b\\([^\\b]+\\)\\=" the bug disappears. Unfortunately it does not match hyphen so "gen-event" is not found. I have tried some combination without much success. So I hope a regex master out there will be able to figure out a correct pattern. Thanks for your help. From matthew@REDACTED Thu Oct 4 19:57:31 2007 From: matthew@REDACTED (Matthew Dempsky) Date: Thu, 4 Oct 2007 10:57:31 -0700 Subject: [erlang-bugs] Patch for illegal memory access in open_port BIF. Message-ID: The open_port BIF assumes that if a tuple is passed as the first argument, it will have at least one element. This causes an illegal memory access if open_port({}, []) is called. --- erl_bif_port.c.orig 2007-10-04 10:50:05.000000000 -0700 +++ erl_bif_port.c 2007-10-04 10:49:03.000000000 -0700 @@ -613,6 +613,10 @@ tp = tuple_val(name); arity = *tp++; + if (arity == make_arityval(0)) { + OPEN_PORT_ERROR(-3); + } + if (*tp == am_spawn) { /* A process port */ if (arity != make_arityval(2)) { OPEN_PORT_ERROR(-3); From dougedmunds@REDACTED Sun Oct 7 06:07:25 2007 From: dougedmunds@REDACTED (Doug Edmunds) Date: Sat, 6 Oct 2007 21:07:25 -0700 Subject: [erlang-bugs] gs module, editor object: unable to change highlightfg option Message-ID: Hello, There is a bug in the gs code relating to editor objects: highlightfg is a rectangle around the object when it has focus. The default is a dark rectangle (black). Attempting the set the highlightfg of an editor object in gs has no effect. gs:create(editor,editor1,window1, [{highlightfg,yellow}]). and gs:config(editor1,[{highlightfg, yellow}]). It works correctly for entry objects. Other objects not tested. -- Doug Edmunds -------------- next part -------------- An HTML attachment was scrubbed... URL: From ulf@REDACTED Mon Oct 8 14:59:56 2007 From: ulf@REDACTED (Ulf Wiger) Date: Mon, 8 Oct 2007 14:59:56 +0200 Subject: [erlang-bugs] documentation bug(s) - mnesia:lock/2 Message-ID: <8209f740710080559g5c39545do32f2658fdd0e3cdb@mail.gmail.com> In the documentation for mnesia:lock/2, http://www.erlang.org/doc/man/mnesia.html#lock/2 one can read the following: Currently, two kinds of LockItem's are supported by this function: "{table, Tab} This acquires a lock of type LockKind on the entire table Tab. {global, GlobalKey, Nodes} This acquires a lock of type LockKind on the global resource GlobalKey. The lock is acquired on all active nodes in the Nodes list. " but the function also supports a third kind of LockItem (perhaps the most interesting): {record, Tab, Key} Furthermore, it states that stick_write is not supported by the function, but looking at the source, not only is sticky_write (note the spelling) supported, but also 'none'. Finally, looking at the function prototype: lock(LockItem, LockKind) -> GoodNodes | transaction abort This doesn't seem to be correct either. The function returns the result of mnesia:read({Tab,Key}), or something to that effect. BR, Ulf W BR, Ulf W From mikpe@REDACTED Tue Oct 9 09:03:05 2007 From: mikpe@REDACTED (Mikael Pettersson) Date: Tue, 9 Oct 2007 09:03:05 +0200 (MEST) Subject: [erlang-bugs] Patch for illegal memory access in open_port BIF. Message-ID: <200710090703.l99735cP026812@harpo.it.uu.se> On Thu, 4 Oct 2007 10:57:31 -0700, Matthew Dempsky wrote: >The open_port BIF assumes that if a tuple is passed as the first >argument, it will have at least one element. This causes an illegal >memory access if open_port({}, []) is called. > >--- erl_bif_port.c.orig 2007-10-04 10:50:05.000000000 -0700 >+++ erl_bif_port.c 2007-10-04 10:49:03.000000000 -0700 >@@ -613,6 +613,10 @@ > tp = tuple_val(name); > arity = *tp++; > >+ if (arity == make_arityval(0)) { >+ OPEN_PORT_ERROR(-3); >+ } >+ > if (*tp == am_spawn) { /* A process port */ > if (arity != make_arityval(2)) { > OPEN_PORT_ERROR(-3); Indeed. Good catch. I haven't seen a reply to this yet from the OTP folks so I'm including this fix in HiPE CVS for now to make sure it doesn't get lost. /Mikael From anders.nygren@REDACTED Wed Oct 10 00:44:53 2007 From: anders.nygren@REDACTED (Anders Nygren) Date: Tue, 9 Oct 2007 17:44:53 -0500 Subject: [erlang-bugs] failed to build R12 snapshot Message-ID: Hi In case anyone is interested to know this. I tried to build the R12 snapshot (otp_src_R12B-0_2007-10-04_20) It is an Intel Centrino Duo uname -a Linux XXXXX 2.6.22.5-31-default #1 SMP 2007/09/21 22:29:00 UTC i686 i686 i386 GNU/Linux It failed like this Dialyzer will now build auxiliary information needed for subsequent analyses... A PLT for following libs will be built: [kernel,mnesia,stdlib] To select a different set please edit the file /usr/local/src/otp/otp_src_R12B-0/lib/dialyzer/src/Makefile /usr/local/src/otp/otp_src_R12B-0/bin/dialyzer --check_init_plt Checking whether the initial PLT exists and is up-to-date... no Creating initial PLT (will take several minutes; please be patient) EXITED with reason {'trans_fun/2',{trim,2}} @hipe_beam_to_icode:1071 {"init terminating in do_boot",{{badmatch,{'EXIT',{{hipe_beam_to_icode,1071,{'trans_fun/2',{trim,2}}},[{hipe_beam_to_icode,trans_fun,2},{hipe_beam_to_icode,trans_fun,2},{hipe_beam_to_icode,trans_fun,2},{hipe_beam_to_icode,trans_fun,2},{hipe_beam_to_icode,trans_fun,2},{hipe_beam_to_icode,trans_fun,2},{hipe_beam_to_icode,trans_fun,2},{hipe_beam_to_icode,trans_fun,2}]}}},[{hipe,get_beam_icode,4},{hipe,'-run_compiler_1/3-fun-0-',4}]}} Crash dump was written to: erl_crash.dump init terminating in do_boot () make[2]: *** [/usr/local/src/otp/otp_src_R12B-0/lib/dialyzer/plt/dialyzer_init_plt] Error 1 From mikpe@REDACTED Wed Oct 10 09:18:56 2007 From: mikpe@REDACTED (Mikael Pettersson) Date: Wed, 10 Oct 2007 09:18:56 +0200 (MEST) Subject: [erlang-bugs] failed to build R12 snapshot Message-ID: <200710100718.l9A7Iu2N008203@harpo.it.uu.se> On Tue, 9 Oct 2007 17:44:53 -0500, Anders Nygren wrote: > In case anyone is interested to know this. > > I tried to build the R12 snapshot (otp_src_R12B-0_2007-10-04_20) > > It is an Intel Centrino Duo > > uname -a > Linux XXXXX 2.6.22.5-31-default #1 SMP 2007/09/21 22:29:00 UTC i686 > i686 i386 GNU/Linux > > It failed like this > > Dialyzer will now build auxiliary information needed for subsequent analyses... > A PLT for following libs will be built: > [kernel,mnesia,stdlib] > To select a different set please edit the file > /usr/local/src/otp/otp_src_R12B-0/lib/dialyzer/src/Makefile > /usr/local/src/otp/otp_src_R12B-0/bin/dialyzer --check_init_plt > Checking whether the initial PLT exists and is up-to-date... no > Creating initial PLT (will take several minutes; please be patient) > EXITED with reason {'trans_fun/2',{trim,2}} > @hipe_beam_to_icode:1071 > {"init terminating in > do_boot",{{badmatch,{'EXIT',{{hipe_beam_to_icode,1071,{'trans_fun/2',{trim,2}}},[{hipe_beam_to_icode,trans_fun,2},{hipe_beam_to_icode,trans_fun,2},{hipe_beam_to_icode,trans_fun,2},{hipe_beam_to_icode,trans_fun,2},{hipe_beam_to_icode,trans_fun,2},{hipe_beam_to_icode,trans_fun,2},{hipe_beam_to_icode,trans_fun,2},{hipe_beam_to_icode,trans_fun,2}]}}},[{hipe,get_beam_icode,4},{hipe,'-run_compiler_1/3-fun-0-',4}]}} > > Crash dump was written to: erl_crash.dump > init terminating in do_boot () > make[2]: *** [/usr/local/src/otp/otp_src_R12B-0/lib/dialyzer/plt/dialyzer_init_plt] > Error 1 Thanks. I'm forwarding this report to the relevant people. /Mikael From stupalo@REDACTED Wed Oct 10 10:16:38 2007 From: stupalo@REDACTED (=?ISO-8859-1?Q?G=F6ran_Stupalo?=) Date: Wed, 10 Oct 2007 10:16:38 +0200 Subject: [erlang-bugs] documentation bug(s) - mnesia:lock/2 In-Reply-To: <8209f740710080559g5c39545do32f2658fdd0e3cdb@mail.gmail.com> References: <8209f740710080559g5c39545do32f2658fdd0e3cdb@mail.gmail.com> Message-ID: <470C8A66.20009@erix.ericsson.se> We will try to fix it in R12B. /Goran Ulf Wiger wrote: > In the documentation for mnesia:lock/2, > > http://www.erlang.org/doc/man/mnesia.html#lock/2 > > one can read the following: > > Currently, two kinds of LockItem's are supported by this function: > > "{table, Tab} > This acquires a lock of type LockKind on the entire table Tab. > {global, GlobalKey, Nodes} > This acquires a lock of type LockKind on the global resource > GlobalKey. The lock is acquired on all active nodes in the Nodes list. > " > > but the function also supports a third kind of LockItem (perhaps the most > interesting): > > {record, Tab, Key} > > > Furthermore, it states that stick_write is not supported by the > function, but looking at the source, not only is sticky_write > (note the spelling) supported, but also 'none'. > > Finally, looking at the function prototype: > > lock(LockItem, LockKind) -> GoodNodes | transaction abort > > This doesn't seem to be correct either. The function returns > the result of mnesia:read({Tab,Key}), or something to that > effect. > > BR, > Ulf W > > BR, > Ulf W > _______________________________________________ > erlang-bugs mailing list > erlang-bugs@REDACTED > http://www.erlang.org/mailman/listinfo/erlang-bugs > -- G?ran Stupalo, Erlang/OTP, Ericsson AB From bjorn@REDACTED Thu Oct 11 15:00:03 2007 From: bjorn@REDACTED (Bjorn Gustavsson) Date: 11 Oct 2007 15:00:03 +0200 Subject: [erlang-bugs] Patch for illegal memory access in open_port BIF. In-Reply-To: <200710090703.l99735cP026812@harpo.it.uu.se> References: <200710090703.l99735cP026812@harpo.it.uu.se> Message-ID: Mikael Pettersson writes: > On Thu, 4 Oct 2007 10:57:31 -0700, Matthew Dempsky wrote: > >The open_port BIF assumes that if a tuple is passed as the first > >argument, it will have at least one element. This causes an illegal > >memory access if open_port({}, []) is called. > > > >--- erl_bif_port.c.orig 2007-10-04 10:50:05.000000000 -0700 > >+++ erl_bif_port.c 2007-10-04 10:49:03.000000000 -0700 > >@@ -613,6 +613,10 @@ > > tp = tuple_val(name); > > arity = *tp++; > > > >+ if (arity == make_arityval(0)) { > >+ OPEN_PORT_ERROR(-3); > >+ } > >+ > > if (*tp == am_spawn) { /* A process port */ > > if (arity != make_arityval(2)) { > > OPEN_PORT_ERROR(-3); > > Indeed. Good catch. > I haven't seen a reply to this yet from the OTP folks so I'm including > this fix in HiPE CVS for now to make sure it doesn't get lost. Thanks! I have merged the change to our R12B development branch and written a release note. /Bjorn -- Bj?rn Gustavsson, Erlang/OTP, Ericsson AB From pradermecker@REDACTED Mon Oct 15 05:43:28 2007 From: pradermecker@REDACTED (Pierre Radermecker) Date: Sun, 14 Oct 2007 23:43:28 -0400 Subject: [erlang-bugs] tempo-complete-tag not working at L1 C1 In-Reply-To: <47043B46.1040600@yahoo.ca> References: <47043B46.1040600@yahoo.ca> Message-ID: <4712E1E0.70103@yahoo.ca> Sorry I forgot to mention I was talking about the erlang emacs-mode. I am using the latest version 2.5.4 From trevor@REDACTED Sat Oct 20 02:08:36 2007 From: trevor@REDACTED (Trevor Wennblom) Date: Fri, 19 Oct 2007 19:08:36 -0500 Subject: [erlang-bugs] Erlang / SCTP problems compiling on Solaris 10 Message-ID: <79EBAF06-EE0D-4FB5-B677-3691E8254118@umn.edu> I'm having some problems compiling Erlang on Solaris 10. It seems to want some features of SCTP that are not present on the machine. The file /usr/include/netinet/sctp.h is preset, with this identifier: #pragma ident^I"@(#)sctp.h^I1.4^I04/10/18 SMI"$ The file doesn't have the declarations that Erlang is looking for. Is there a way to skip SCTP support? Also, would it be possible for 'configure' to detect that the necessary declarations are unavailable? % gcc - v 1 Using built-in specs. Target: sparc-sun-solaris2.10 Configured with: ../configure --enable-threads=posix --disable-nls -- with-ld=/usr/ccs/bin/ld --with-as=/usr/ccs/bin/as --enable-shared -- enable-languages=c,c++,objc,fortran --disable-libgcj Thread model: posix gcc version 4.1.2 % make [..snip..] gcc -g -O2 -I/tmp/otp_src_R12B-0/erts/sparc-sun-solaris2.10 - D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 -DERTS_SMP -DHAVE_CONFIG_H -Wall -Wstrict-prototypes -Wmissing-prototypes -DUSE_THREADS - D_THREAD_SAFE -D_REENTRANT -D_POSIX_PTHREAD_SEMANTICS -Wa,- xarch=v8plusa -Ibeam -Isys/unix -Isys/common -Isparc-sun-solaris2.10/ opt/smp -Isparc-sun-solaris2.10 -Izlib -Ihipe -I../include/internal - I../include/internal/sparc-sun-solaris2.10 -Idrivers/common -Idrivers/ unix -c drivers/common/inet_drv.c -o obj/sparc-sun-solaris2.10/opt/ smp/inet_drv.o drivers/common/inet_drv.c: In function 'sctp_fill_opts': drivers/common/inet_drv.c:6642: error: 'SCTP_CLOSED' undeclared (first use in this function) drivers/common/inet_drv.c:6642: error: (Each undeclared identifier is reported only once drivers/common/inet_drv.c:6642: error: for each function it appears in.) drivers/common/inet_drv.c:6653: error: 'SCTP_COOKIE_WAIT' undeclared (first use in this function) drivers/common/inet_drv.c:6656: error: 'SCTP_COOKIE_ECHOED' undeclared (first use in this function) drivers/common/inet_drv.c:6659: error: 'SCTP_ESTABLISHED' undeclared (first use in this function) drivers/common/inet_drv.c:6662: error: 'SCTP_SHUTDOWN_PENDING' undeclared (first use in this function) drivers/common/inet_drv.c:6665: error: 'SCTP_SHUTDOWN_SENT' undeclared (first use in this function) drivers/common/inet_drv.c:6668: error: 'SCTP_SHUTDOWN_RECEIVED' undeclared (first use in this function) drivers/common/inet_drv.c:6671: error: 'SCTP_SHUTDOWN_ACK_SENT' undeclared (first use in this function) make[3]: *** [obj/sparc-sun-solaris2.10/opt/smp/inet_drv.o] Error 1 make[3]: Leaving directory `/tmp/otp_src_R12B-0/erts/emulator' make[2]: *** [opt] Error 2 make[2]: Leaving directory `/tmp/otp_src_R12B-0/erts/emulator' make[1]: *** [smp] Error 2 make[1]: Leaving directory `/tmp/otp_src_R12B-0/erts' make: *** [emulator] Error 2 From s.egner@REDACTED Tue Oct 23 14:37:44 2007 From: s.egner@REDACTED (Sebastian Egner) Date: Tue, 23 Oct 2007 14:37:44 +0200 Subject: [erlang-bugs] Does 'ic' (the CORBA IDL compiler) support recursive types? In-Reply-To: <46E7DD7B.8010909@specs.de> References: <46E7DD7B.8010909@specs.de> Message-ID: <471DEB18.2060800@specs.de> Hello, This is not strictly a bug report, but a question for clarification: Is it correct that the 'ic' IDL compiler does not support recursive types? Forward declarations or self-references result in a "syntax error"/"undeclared identifier": enum NodeType { Empty, Tuple }; // union Tree; // doesn't help either union Tree switch (NodeType) { case NT_Tuple: sequence< Tree > p; }; Can't find the restriction mentioned in the manual. Sebastian From nick@REDACTED Tue Oct 23 15:17:57 2007 From: nick@REDACTED (Niclas Eklund) Date: Tue, 23 Oct 2007 15:17:57 +0200 (MEST) Subject: [erlang-bugs] Does 'ic' (the CORBA IDL compiler) support recursive types? In-Reply-To: <471DEB18.2060800@specs.de> Message-ID: Hello! It's correct, IC doesn't support recursive types. The only way is to avoid using rescursive structures (i.e. change the IDL specification). Note, Anonymous Types was deprecated in CORBA-2.4: sequence next; // Deprecated. Unless you must represent a tree, you can use: struct A { long i; }; typedef sequence ASeq; After a quick search in my mail boxes I found that the last time someone asked about rescursive types was back in Nov 2003. As you understand, since it's seldom used and one can solve this in other ways, it hasn't been a high prio IC extension. /Niclas On Tue, 23 Oct 2007, Sebastian Egner wrote: > Hello, > > This is not strictly a bug report, but a question for clarification: Is > it correct that the 'ic' IDL compiler does > not support recursive types? Forward declarations or self-references > result in a "syntax error"/"undeclared identifier": > > enum NodeType { Empty, Tuple }; > > // union Tree; // doesn't help either > > union Tree switch (NodeType) { > case NT_Tuple: sequence< Tree > p; > }; > > Can't find the restriction mentioned in the manual. > > Sebastian > _______________________________________________ > erlang-bugs mailing list > erlang-bugs@REDACTED > http://www.erlang.org/mailman/listinfo/erlang-bugs > From anders.nygren@REDACTED Tue Oct 23 16:41:26 2007 From: anders.nygren@REDACTED (Anders Nygren) Date: Tue, 23 Oct 2007 09:41:26 -0500 Subject: [erlang-bugs] hipe zombies Message-ID: Hi When I do a native compilation in the shell, it leaves a process that is not terminated. pman says that it is hanging in hipe_icode_coordinator:coordinate/4 /Anders From s.egner@REDACTED Tue Oct 23 17:18:10 2007 From: s.egner@REDACTED (Sebastian Egner) Date: Tue, 23 Oct 2007 17:18:10 +0200 Subject: [erlang-bugs] Does 'ic' (the CORBA IDL compiler) support recursive types? In-Reply-To: References: Message-ID: <471E10B2.9060301@specs.de> Hello Niclas, Thanks for the quick reply! My intention was to send a restricted form of Erlang terms (atom|string|integer|float|binary|list|tuple) through CORBA for complex parameter structures which I do not want to encode in IDL. But there are certainly alternatives. Cheers, Sebastian. Niclas Eklund wrote: > Hello! > > It's correct, IC doesn't support recursive types. The only way is to avoid > using rescursive structures (i.e. change the IDL specification). From per.gustafsson@REDACTED Wed Oct 24 10:47:51 2007 From: per.gustafsson@REDACTED (Per Gustafsson) Date: Wed, 24 Oct 2007 01:47:51 -0700 (PDT) Subject: [erlang-bugs] hipe zombies In-Reply-To: References: Message-ID: <13381647.post@talk.nabble.com> Anders Nygren wrote: > > Hi > When I do a native compilation in the shell, it leaves a process > that is not terminated. pman says that it is hanging in > hipe_icode_coordinator:coordinate/4 > > /Anders > I've found the bug and it will be fixed in R12, but if you want to avoid th problem you can give hipe the o3 option as in: hipe:c(module,[o3]). Per -- View this message in context: http://www.nabble.com/hipe-zombies-tf4678014.html#a13381647 Sent from the Erlang Bugs mailing list archive at Nabble.com. From anders.nygren@REDACTED Wed Oct 24 20:38:32 2007 From: anders.nygren@REDACTED (Anders Nygren) Date: Wed, 24 Oct 2007 13:38:32 -0500 Subject: [erlang-bugs] file:pread documentation error Message-ID: The documentation says that file:pread/3 returns {ok,eof} at end of file. In reality on R11B-5, it returns eof /Anders From exta7@REDACTED Thu Oct 25 00:56:54 2007 From: exta7@REDACTED (Zvi) Date: Wed, 24 Oct 2007 15:56:54 -0700 (PDT) Subject: [erlang-bugs] Does 'ic' (the CORBA IDL compiler) support recursive types? In-Reply-To: <471DEB18.2060800@specs.de> References: <46E7DD7B.8010909@specs.de> <471DEB18.2060800@specs.de> Message-ID: <13376384.post@talk.nabble.com> Hi Sebastian, Which ORB do you use on the non-Erlang side? I'm currious if Erlang ORB will work with TAO ORB C++ ? Thanks in advance, Zvi Sebastian Egner-2 wrote: > > Hello, > > This is not strictly a bug report, but a question for clarification: Is > it correct that the 'ic' IDL compiler does > not support recursive types? Forward declarations or self-references > result in a "syntax error"/"undeclared identifier": > > enum NodeType { Empty, Tuple }; > > // union Tree; // doesn't help either > > union Tree switch (NodeType) { > case NT_Tuple: sequence< Tree > p; > }; > > Can't find the restriction mentioned in the manual. > > Sebastian > _______________________________________________ > erlang-bugs mailing list > erlang-bugs@REDACTED > http://www.erlang.org/mailman/listinfo/erlang-bugs > > -- View this message in context: http://www.nabble.com/possible-bug-in-%27ic%27-%28the-CORBA-IDL-compiler%29-tf4429004.html#a13376384 Sent from the Erlang Bugs mailing list archive at Nabble.com. From nick@REDACTED Thu Oct 25 10:01:06 2007 From: nick@REDACTED (Niclas Eklund) Date: Thu, 25 Oct 2007 10:01:06 +0200 (MEST) Subject: [erlang-bugs] Does 'ic' (the CORBA IDL compiler) support recursive types? In-Reply-To: <13376384.post@talk.nabble.com> Message-ID: Hello! The external ORB I know have been used together with Orber is: * JacORB * TAO * Visibroker * Orbix * JavaIDL There are most likely even more since that piece of information is usually left out when people post a question via erlang.org. See also http://www.puder.org/corba/matrix/ and http://www.omg.org/technology/corba/corbadownloads.htm /Niclas On Wed, 24 Oct 2007, Zvi wrote: > > Hi Sebastian, > > Which ORB do you use on the non-Erlang side? > I'm currious if Erlang ORB will work with TAO ORB C++ ? > > Thanks in advance, > Zvi > > > Sebastian Egner-2 wrote: > > > > Hello, > > > > This is not strictly a bug report, but a question for clarification: Is > > it correct that the 'ic' IDL compiler does > > not support recursive types? Forward declarations or self-references > > result in a "syntax error"/"undeclared identifier": > > > > enum NodeType { Empty, Tuple }; > > > > // union Tree; // doesn't help either > > > > union Tree switch (NodeType) { > > case NT_Tuple: sequence< Tree > p; > > }; > > > > Can't find the restriction mentioned in the manual. > > > > Sebastian > > _______________________________________________ > > erlang-bugs mailing list > > erlang-bugs@REDACTED > > http://www.erlang.org/mailman/listinfo/erlang-bugs > > > > > > -- > View this message in context: http://www.nabble.com/possible-bug-in-%27ic%27-%28the-CORBA-IDL-compiler%29-tf4429004.html#a13376384 > Sent from the Erlang Bugs mailing list archive at Nabble.com. > > _______________________________________________ > erlang-bugs mailing list > erlang-bugs@REDACTED > http://www.erlang.org/mailman/listinfo/erlang-bugs > From s.egner@REDACTED Thu Oct 25 12:20:56 2007 From: s.egner@REDACTED (Sebastian Egner) Date: Thu, 25 Oct 2007 12:20:56 +0200 Subject: [erlang-bugs] Does 'ic' (the CORBA IDL compiler) support, recursive types? Message-ID: <47206E08.6080506@specs.de> > Hi Sebastian, > > Which ORB do you use on the non-Erlang side? > I'm currious if Erlang ORB will work with TAO ORB C++ ? > > Thanks in advance, > Zvi OmniORB for C++ and Python, and 'idlj' for Java6. Sebastian. From fritchie@REDACTED Mon Oct 29 23:36:16 2007 From: fritchie@REDACTED (Scott Lystig Fritchie) Date: Mon, 29 Oct 2007 17:36:16 -0500 Subject: [erlang-bugs] ODBC enhancement: support for out & inout parameters for stored procedures Message-ID: <200710292236.l9TMaGBI071136@snookles.snookles.com> Howdy. We've been using the patch below for months without any ill effect and are wondering if it'd be useful for the community at large. IIRC, it supports out & inout parameters for stored procedures ... er, or something else that the ODBC driver can't quite do. :-) -Scott --- snip --- snip --- snip --- snip --- snip --- snip --- --- ./otp_src_R11B-5/lib/odbc/c_src/odbcserver.c.org 2007-01-29 05:17:56.000000000 -0800 +++ ./otp_src_R11B-5/lib/odbc/c_src/odbcserver.c 2007-07-24 19:03:43.000000000 -0700 @@ -81,7 +81,8 @@ N - integer Binary - binary encodede tuple of {SQLQuery, NoRows, Parameters} NoRows - integer - Parameters - [{Datatype, Value}] + Parameters - [{Datatype, InOrOut, Value}] + InOrOut = [IN | OUT | INOUT] Datatype - USER_INT | USER_SMALL_INT | {USER_DECIMAL, Precision, Scale} | {USER_NMERIC, Precision, Scale} | {USER_CHAR, Max} | {USER_VARCHAR, Max} | {USER_FLOAT, Precision} | USER_REAL | USER_DOUBLE @@ -144,6 +145,10 @@ static db_result_msg encode_result(db_state *state); static db_result_msg encode_result_set(SQLSMALLINT num_of_columns, db_state *state); +static db_result_msg encode_out_params(db_state *state, + int cols, + param_array *params, + int num_param_values); static db_result_msg encode_column_name_list(SQLSMALLINT num_of_columns, db_state *state); static db_result_msg encode_value_list(SQLSMALLINT num_of_columns, @@ -203,7 +208,7 @@ static void init_driver(int erl_auto_commit_mode, int erl_trace_driver, db_state *state); static void init_param_column(param_array *params, byte *buffer, int *index, - int num_param_values); + int num_param_values, db_state* state); static void init_param_statement(int cols, int num_param_values, @@ -225,6 +230,7 @@ db_state *state); static db_result_msg retrive_scrollable_cursor_support_info(db_state *state); +static int num_out_params(int num_of_params, param_array* params); /* ------------- Error handling functions --------------------------------*/ static diagnos get_diagnos(SQLSMALLINT handleType, SQLHANDLE handle); @@ -240,7 +246,7 @@ # define DO_EXIT(code) do { ExitProcess((code)); exit((code));} while (0) /* exit() called only to avoid a warning */ #else -# define DO_EXIT(code) exit((code)) +# define DO_EXIT(code) _exit((code)) #endif /* ----------------- Main functions --------------------------------------*/ @@ -327,7 +333,7 @@ byte *request_buffer = NULL; db_state state = {NULL, NULL, NULL, NULL, 0, {NULL, 0, 0}, - FALSE, FALSE, FALSE, FALSE, FALSE}; + FALSE, FALSE, FALSE, FALSE, FALSE, FALSE}; byte request_id; #ifdef WIN32 SOCKET socket; @@ -771,7 +777,11 @@ } if(msg.length == 0) { ei_x_new_with_version(&dynamic_buffer(state)); - msg = encode_result(state); + if(out_params(state)){ + msg = encode_out_params(state, cols, params, num_param_values); + }else{ + msg = encode_result(state); + } if(msg.length == 0) { msg.buffer = dynamic_buffer(state).buff; msg.length = dynamic_buffer(state).index; @@ -951,9 +961,9 @@ } if (num_of_columns == 0) { - elements = 2; - atom = "updated"; - update = TRUE; + elements = 2; + atom = "updated"; + update = TRUE; } else { elements = 3; atom = "selected"; @@ -1011,6 +1021,85 @@ return msg; } +static db_result_msg encode_out_params(db_state *state, + int num_of_params, + param_array* params, + int num_param_values) +{ + int num_of_columns = 0; + int i = 0; + int j = 0; + param_array column; + db_result_msg msg; + msg = encode_empty_message(); + + ei_x_encode_tuple_header(&dynamic_buffer(state), 3); + ei_x_encode_atom(&dynamic_buffer(state), "executed"); + + num_of_columns = num_out_params(num_of_params, params); + ei_x_encode_long(&dynamic_buffer(state), num_of_columns); + + ei_x_encode_list_header(&dynamic_buffer(state), num_param_values); + for(j =0; j < num_param_values; j ++){ + + if(tuple_row(state)) { + ei_x_encode_tuple_header(&dynamic_buffer(state), num_of_columns); + + } else { + ei_x_encode_list_header(&dynamic_buffer(state), num_of_columns); + } + + for (i = 0; i< num_of_params; i++) { + if(params[i].input_output_type==SQL_PARAM_INPUT){ + continue; + } + column = params[i]; + if (column.type.len == 0 || + column.type.strlen_or_indptr == SQL_NULL_DATA) { + ei_x_encode_atom(&dynamic_buffer(state), "null"); + } else { + void* values = retrive_param_values(&column); + switch(column.type.c) { + case SQL_C_CHAR: + ei_x_encode_string(&dynamic_buffer(state), ((char*)values)+j*column.type.len); + break; + case SQL_C_SLONG: + ei_x_encode_long(&dynamic_buffer(state), ((long*)values)[j]); + break; + case SQL_C_DOUBLE: + ei_x_encode_double(&dynamic_buffer(state), + ((double*)values)[j]); + break; + case SQL_C_BIT: + ei_x_encode_atom(&dynamic_buffer(state), + ((Boolean*)values)[j]==TRUE?"true":"false"); + break; + default: + ei_x_encode_atom(&dynamic_buffer(state), "error"); + break; + } + } + } + if(!tuple_row(state)) { + ei_x_encode_empty_list(&dynamic_buffer(state)); + } + } + ei_x_encode_empty_list(&dynamic_buffer(state)); + return msg; +} + +static int num_out_params(int num_of_params, param_array* params) +{ + int ret = 0; + int i = 0; + for(i=0; i < num_of_params; i++){ + if(params[i].input_output_type==SQL_PARAM_INPUT_OUTPUT || + params[i].input_output_type==SQL_PARAM_OUTPUT) + ret++; + } + return ret; +} + /* Description: Encodes the result set into the "ei_x" - dynamic_buffer held by the state variable */ static db_result_msg encode_result_set(SQLSMALLINT num_of_columns, @@ -1514,7 +1603,9 @@ } /* ------------- Socket communication functions --------------------------*/ -#ifdef WIN32 +#define USE_IPV4 +#define SOCKET int +#if defined WIN32 || defined USE_IPV4 /* Currently only an old windows compiler is supported so we do not have ipv6 capabilities */ static SOCKET connect_to_erlang(const char *port) @@ -1856,10 +1947,11 @@ } static void init_param_column(param_array *params, byte *buffer, int *index, - int num_param_values) + int num_param_values, db_state* state) { int size, erl_type; long user_type, precision, scale, length, dummy; + long in_or_out; ei_decode_long(buffer, index, &user_type); @@ -1972,6 +2064,20 @@ break; } params->offset = 0; + + ei_decode_long(buffer, index, &in_or_out); + switch((in_or_out_type)in_or_out){ + case(OUT): + out_params(state) = TRUE; + params->input_output_type = SQL_PARAM_OUTPUT; break; + case(INOUT): + out_params(state) = TRUE; + params->input_output_type = SQL_PARAM_INPUT_OUTPUT; break; + case(IN): + default: + params->input_output_type = SQL_PARAM_INPUT; break; + } + } static void init_param_statement(int cols, int num_param_values, @@ -1987,7 +2093,8 @@ DO_EXIT(EXIT_ALLOC); } - + if(num_param_values <= 1) return; + if(!sql_success(SQLSetStmtAttr(statement_handle(state), SQL_ATTR_PARAM_BIND_TYPE, SQL_PARAM_BIND_BY_COLUMN, 0))) { @@ -2129,7 +2236,7 @@ ei_decode_tuple_header(buffer, index, &size); - init_param_column(¶ms[i], buffer, index, num_param_values); + init_param_column(¶ms[i], buffer, index, num_param_values, state); ei_decode_list_header(buffer, index, &size); @@ -2153,7 +2260,7 @@ if(!sql_success( SQLBindParameter(statement_handle(state), i + 1, - SQL_PARAM_INPUT, + params[i].input_output_type, params[i].type.c, params[i].type.sql, params[i].type.col_size, --- ./otp_src_R11B-5/lib/odbc/c_src/odbcserver.h.org 2007-01-29 05:18:02.000000000 -0800 +++ ./otp_src_R11B-5/lib/odbc/c_src/odbcserver.h 2007-07-24 19:01:23.000000000 -0700 @@ -142,6 +142,7 @@ typedef struct { col_type type; int offset; + SQLUSMALLINT input_output_type; union { byte *string; long *integer; @@ -167,8 +168,15 @@ Boolean tuple_row; Boolean exists_more_result_sets; Boolean param_query; + Boolean out_params; } db_state; +typedef enum { + IN = 0, + OUT=1, + INOUT=2 +} in_or_out_type; + #define connection_handle(db_state) (db_state -> connection_handle) #define environment_handle(db_state) (db_state -> environment_handle) #define statement_handle(db_state) (db_state -> statement_handle) @@ -180,3 +188,4 @@ #define tuple_row(db_state) (db_state -> tuple_row) #define exists_more_result_sets(db_state) (db_state -> exists_more_result_sets) #define param_query(db_state) (db_state -> param_query) +#define out_params(db_state) (db_state -> out_params) --- ./otp_src_R11B-5/lib/odbc/src/odbc.erl.org 2007-01-29 05:17:55.000000000 -0800 +++ ./otp_src_R11B-5/lib/odbc/src/odbc.erl 2007-07-24 19:01:23.000000000 -0700 @@ -864,23 +864,31 @@ end. %%------------------------------------------------------------------------- -fix_params({sql_integer, Values}) -> - {?USER_INT, [256 | Values]}; -fix_params({sql_smallint, Values}) -> - {?USER_SMALL_INT, [256 | Values]}; -fix_params({sql_tinyint, Values}) -> - {?USER_TINY_INT, [256 | Values]}; -fix_params({{sql_decimal, Precision, 0}, +%% integer values(0, 1, 2) are defined in odbcserver.h - in_or_out_type +fix_inout(in) -> + 0; +fix_inout(out) -> + 1; +fix_inout(inout) -> + 2. + +fix_params({sql_integer, InOut, Values}) -> + {?USER_INT, fix_inout(InOut), [256 | Values]}; +fix_params({sql_smallint, InOut, Values}) -> + {?USER_SMALL_INT, fix_inout(InOut), [256 | Values]}; +fix_params({sql_tinyint, InOut, Values}) -> + {?USER_TINY_INT, fix_inout(InOut), [256 | Values]}; +fix_params({{sql_decimal, InOut, Precision, 0}, Values}) when Precision >= 0, Precision =< 9 -> - {?USER_DECIMAL, Precision, 0, [256 | Values]}; -fix_params({{sql_decimal, Precision, Scale}, Values}) -> - {?USER_DECIMAL, Precision, Scale, Values}; -fix_params({{sql_numeric, Precision, 0}, + {?USER_DECIMAL, Precision, 0, fix_inout(InOut), [256 | Values]}; +fix_params({{sql_decimal, InOut, Precision, Scale}, Values}) -> + {?USER_DECIMAL, Precision, Scale, fix_inout(InOut), Values}; +fix_params({{sql_numeric, InOut, Precision, 0}, Values}) when Precision >= 0, Precision =< 9 -> - {?USER_NUMERIC, Precision, 0, [256 | Values]}; -fix_params({{sql_numeric, Precision, Scale}, Values}) -> - {?USER_NUMERIC, Precision, Scale, Values}; -fix_params({{sql_char, Max}, Values}) -> + {?USER_NUMERIC, Precision, 0, fix_inout(InOut), [256 | Values]}; +fix_params({{sql_numeric, InOut, Precision, Scale}, Values}) -> + {?USER_NUMERIC, Precision, Scale, fix_inout(InOut), Values}; +fix_params({{sql_char, InOut, Max}, Values}) -> NewValues = case (catch lists:map(fun(Str) -> Str ++ [?STR_TERMINATOR] end, Values)) of @@ -889,8 +897,8 @@ Result -> Result end, - {?USER_CHAR, Max, NewValues}; -fix_params({{sql_varchar, Max}, Values}) -> + {?USER_CHAR, Max, fix_inout(InOut), NewValues}; +fix_params({{sql_varchar, InOut, Max}, Values}) -> NewValues = case (catch lists:map(fun(Str) -> Str ++ [?STR_TERMINATOR] end, Values)) of @@ -899,12 +907,36 @@ Result -> Result end, - {?USER_VARCHAR, Max, NewValues}; + {?USER_VARCHAR, Max, fix_inout(InOut), NewValues}; +fix_params({{sql_float, InOut, Precision}, Values}) -> + {?USER_FLOAT, Precision, fix_inout(InOut), Values}; +fix_params({sql_real, InOut, Values}) -> + {?USER_REAL, fix_inout(InOut), Values}; +fix_params({sql_double, InOut, Values}) -> + {?USER_DOUBLE, fix_inout(InOut), Values}; +fix_params({sql_bit, InOut, Values}) -> + {?USER_BOOLEAN, fix_inout(InOut), Values}; +%% default is IN %%% +fix_params({sql_integer, Values}) -> + fix_params({sql_integer, in, Values}); +fix_params({sql_smallint, Values}) -> + fix_params({sql_smallint, in, Values}); +fix_params({sql_tinyint, Values}) -> + fix_params({sql_tinyint, in, Values}); +fix_params({{sql_decimal, Precision, Scale}, Values}) -> + fix_params({{sql_decimal, in, Precision, Scale}, Values}); +fix_params({{sql_numeric, Precision, Scale}, Values}) -> + fix_params({{sql_numeric, in, Precision, Scale}, Values}); +fix_params({{sql_char, Max}, Values}) -> + fix_params({{sql_char, in, Max}, Values}); +fix_params({{sql_varchar, Max}, Values}) -> + fix_params({{sql_varchar, in, Max}, Values}); fix_params({{sql_float, Precision}, Values}) -> - {?USER_FLOAT, Precision, Values}; + fix_params({{sql_float, in, Precision}, Values}); fix_params({sql_real, Values}) -> - {?USER_REAL, Values}; + fix_params({sql_real, in, Values}); fix_params({sql_double, Values}) -> - {?USER_DOUBLE, Values}; + fix_params({sql_double, in, Values}); fix_params({sql_bit, Values}) -> - {?USER_BOOLEAN, Values}. + fix_params({sql_bit, in, Values}). +