From per@REDACTED Wed Aug 13 07:51:38 2003 From: per@REDACTED (Per Bergqvist) Date: Wed, 13 Aug 2003 08:51:38 +0300 Subject: reworked warning patches Message-ID: <200308130651.h7D6pc222647@tessla.levonline.com> Hi Kent (and other interested), Attached is a reworked set of patches to reduce the number of warnings in the standard distribution (r9c-0). I now tried to split the patches so it will be easier to see what it does and in which modules. Hope this effort will help to dispatch the patches to the correct designer(s). In total it is 29 patches. Enjoy Per ========================================================= Per Bergqvist Synapse Systems AB Phone: +46 709 686 685 Email: per@REDACTED -------------- next part -------------- A non-text attachment was scrubbed... Name: README.R9C-0-patches Type: application/octet-stream Size: 1657 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: R9C-0.patches.tar.gz Type: application/unix-tar Size: 31916 bytes Desc: not available URL: From vances@REDACTED Sun Aug 17 12:12:02 2003 From: vances@REDACTED (Vance Shipley) Date: Sun, 17 Aug 2003 06:12:02 -0400 Subject: ON_READ/ON_WRITE is actually DO_READ/DO_WRITE Message-ID: <20030817101202.GG8689@frogman.motivity.ca> .../R9C/erts-5.3/doc/html/erl_driver.html In the documentation for the driver_select() function it says: "The mode parameter can be either ON_READ or ON_WRITE" However in the erl_driver.h header file it's actually DO_READ and DO_WRITE: /* Values for mode arg to driver_select() */ #define DO_READ (1 << 0) #define DO_WRITE (1 << 1) #ifdef _OSE_ #define DO_START (1 << 2) #define DO_STOP (1 << 3) #endif /* _OSE_ */ Vance Shipley Motivity Telecom Inc. +1 519 240 3684 vances@REDACTED From vances@REDACTED Tue Aug 19 15:05:34 2003 From: vances@REDACTED (Vance Shipley) Date: Tue, 19 Aug 2003 09:05:34 -0400 Subject: erlang:port_call(Port, Operation, Data) Message-ID: <20030819130534.GF14794@frogman.motivity.ca> R9C\lib\kernel-2.9\doc\html\erlang.html The documentation for this function should read: erlang:port_call(Port, Operation, Data) and not port_call(Port, Operation, Data) At least that is how it works. Me thinks it strange that this function although modelled after port_control needs a full reference while port_control does not. -Vance From vances@REDACTED Thu Aug 21 04:57:14 2003 From: vances@REDACTED (Vance Shipley) Date: Wed, 20 Aug 2003 22:57:14 -0400 Subject: ErlDriverTerm, ErlDrvTerm & ErlDrvTermData confusion Message-ID: <20030821025714.GC21374@frogman.motivity.ca> R9C\erts-5.3\doc\html\erl_driver.html The documentation for the driver functions which create and send terms specify a type of ErlDriverTerm: ErlDriverTerm driver_mk_atom(char* string) ErlDriverTerm driver_mk_port(ErlDrvPort port) int driver_output_term(ErlDrvPort port, ErlDriverTerm* term, int n) ... However ErlDriverTerm does not appear in erl_driver.h. The individual terms are all defined as having type ErlDrvTermData: #define ERL_DRV_ATOM ((ErlDrvTermData) 2) /* driver_mk_atom(string) */ #define ERL_DRV_INT ((ErlDrvTermData) 3) /* int */ ... EXTERN ErlDrvTermData driver_mk_atom(char*); EXTERN ErlDrvTermData driver_mk_port(ErlDrvPort); ... The example for a completed complex term specifies a type of ErlDrvTerm: /* ErlDrvTerm is the type to use for casts when building * terms that should be sent to connected process, * for instance a tuple on the form {tcp, Port, [Tag|Binary]} * * ErlDrvTerm spec[] = { * ERL_DRV_ATOM, driver_mk_atom("tcp"), * ERL_DRV_PORT, driver_mk_port(drv->ix), * ERL_DRV_INT, REPLY_TAG, * ERL_DRV_BINARY, (ErlDrvTerm)bin, 50, 0, * ERL_DRV_LIST, 2, * ERL_DRV_TUPLE, 3, * } * */ I believe the intention was to define ErlDriverTerm like this: typedef ErlDrvTermData *ErlDriverTerm; I suggest adding the above to erl_driver.h and changing the documentation to correct the types used with these functions: ErlDriverTerm driver_connected(ErlDrvPort port) ErlDriverTerm driver_caller(ErlDrvPort port) int driver_output_term(ErlDrvPort port, ErlDriverTerm* term, int n) ErlDriverTerm driver_mk_atom(char* string) ErlDriverTerm driver_mk_port(ErlDrvPort port) int driver_send_term(ErlDrvPort port, ErlDriverTerm receiver, ErlDriverTerm* term, int n) The correct definitions (as they appear in erl_driver.h now) are: ErlDriverTermData driver_connected(ErlDrvPort port) ErlDriverTermData driver_caller(ErlDrvPort port) int driver_output_term(ErlDrvPort port, ErlDriverTermData* term, int n) ErlDriverTermData driver_mk_atom(char* string) ErlDriverTermData driver_mk_port(ErlDrvPort port) int driver_send_term(ErlDrvPort port, ErlDriverTermData receiver, ErlDriverTermData* term, int n) Basically all appearances of "ErlDriverTerm" in doc\html\erl_driver.html can be changed to "ErlDriverTermData". If however you follow the suggestion of adding the definition of ErlDriverTerm as a pointer to ErlDriverTermData (i.e. an array of ErlDriverTermData, a complete term) then you would define like this: int driver_output_term(ErlDrvPort port, ErlDriverTerm term, int n) int driver_send_term(ErlDrvPort port, ErlDriverTermData receiver, ErlDriverTerm term, int n) Finally the example in erl_driver.h should be corrected. -Vance From per@REDACTED Thu Aug 21 16:09:52 2003 From: per@REDACTED (Per Bergqvist) Date: Thu, 21 Aug 2003 17:09:52 +0300 Subject: erl_marshal bug Message-ID: <200308211509.h7LF9rB01470@tessla.levonline.com> Hi, just noticed that the patch i submitted for R8B-x did not make it into R9C-0 either. It fixes comparison of tuples of integers in erl_compare. (hint: try erl_compare with timestamps without it ...) /Per ========================================================= Per Bergqvist Synapse Systems AB Phone: +46 709 686 685 Email: per@REDACTED -------------- next part -------------- A non-text attachment was scrubbed... Name: R9C-0.patch-30 Type: application/octet-stream Size: 2054 bytes Desc: not available URL: From per@REDACTED Thu Aug 21 16:12:06 2003 From: per@REDACTED (Per Bergqvist) Date: Thu, 21 Aug 2003 17:12:06 +0300 Subject: fix for asn1 driver Message-ID: <200308211512.h7LFC7n01534@tessla.levonline.com> There is a debug printout that should be removed in the asn1 driver in R9C-0. Patch attached. /Per ========================================================= Per Bergqvist Synapse Systems AB Phone: +46 709 686 685 Email: per@REDACTED -------------- next part -------------- A non-text attachment was scrubbed... Name: R9C-0.patch-31 Type: application/octet-stream Size: 856 bytes Desc: not available URL: From bertil@REDACTED Thu Aug 21 17:23:09 2003 From: bertil@REDACTED (Bertil Karlsson) Date: Thu, 21 Aug 2003 17:23:09 +0200 Subject: fix for asn1 driver References: <200308211512.h7LFC7n01534@tessla.levonline.com> Message-ID: <3F44E3DD.7010702@erix.ericsson.se> Thank you, the trace printout will be removed in the next patch. Per Bergqvist wrote: > There is a debug printout that should be removed in the > asn1 driver in R9C-0. > > Patch attached. > > /Per > > ========================================================= > Per Bergqvist > Synapse Systems AB > Phone: +46 709 686 685 > Email: per@REDACTED -- / Bertil Karlsson From per@REDACTED Fri Aug 22 13:41:01 2003 From: per@REDACTED (Per Bergqvist) Date: Fri, 22 Aug 2003 14:41:01 +0300 Subject: fix for asn1 driver In-Reply-To: <3F44E3DD.7010702@erix.ericsson.se> Message-ID: <200308221241.h7MCf1o10193@tessla.levonline.com> Hi, Attached are a couple of more fixes for asn1. -32 fixes a length bug on extensions in asn1rt_ber_bin -33 fixes 'OBJECT DESCRIPTOR' bug in asn1 modules (found by Erik Reitsma but not fixed in R9C-0) -34 fixes a tag matching bug in ber decoding -35 enables erlc command line to pass +ber_bin for asn1 modules (and actually use it ;-) /Per ------------------- > Thank you, the trace printout will be removed in the next patch. > > Per Bergqvist wrote: > > There is a debug printout that should be removed in the > > asn1 driver in R9C-0. > > > > Patch attached. > > > > /Per > > > > ========================================================= > > Per Bergqvist > > Synapse Systems AB > > Phone: +46 709 686 685 > > Email: per@REDACTED > > > -- > / Bertil Karlsson > ========================================================= Per Bergqvist Synapse Systems AB Phone: +46 709 686 685 Email: per@REDACTED -------------- next part -------------- A non-text attachment was scrubbed... Name: R9C-0.patch-32 Type: application/octet-stream Size: 593 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: R9C-0.patch-33 Type: application/octet-stream Size: 1940 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: R9C-0.patch-34 Type: application/octet-stream Size: 666 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: R9C-0.patch-35 Type: application/octet-stream Size: 1303 bytes Desc: not available URL: From per@REDACTED Tue Aug 26 09:32:05 2003 From: per@REDACTED (Per Bergqvist) Date: Tue, 26 Aug 2003 10:32:05 +0300 Subject: asn1 improvement proposal In-Reply-To: <3F4B1359.1080405@erix.ericsson.se> Message-ID: <200308260832.h7Q8W5927472@tessla.levonline.com> Hi, The asn1 en/decoder proberly handles ellipsis notation as it is today. However, the decoder receives an extended PDU with ellipsis data it will simply discard that information. There is no way to tell the encoder to add extension information. I propose that each record generated by the compiler should add an additional '$ellipsis' field for the last '...' in a sequence/set. The decoder should add any extension information to the '$ellipsis' field. The encoder should allow the user to put extension information. This improvement would allow creation of proxy functions where one does not always have the latest available/vendor specific spec. /Per ========================================================= Per Bergqvist Synapse Systems AB Phone: +46 709 686 685 Email: per@REDACTED From kenneth@REDACTED Tue Aug 26 11:14:15 2003 From: kenneth@REDACTED (Kenneth Lundin) Date: Tue, 26 Aug 2003 11:14:15 +0200 Subject: asn1 improvement proposal References: <3F4B1359.1080405@erix.ericsson.se> <200308260832.h7Q8W5927472@tessla.levonline.com> Message-ID: <3F4B24E7.60404@erix.ericsson.se> Hi, We have been thinking on a solution like that earlier but didn't find time and motivation to implement it then. It would be ok to receive the unknown "elipsis" parts as an undecoded binary and to pass that to the encoder function for further distribution, but I think is would be difficult for the user to create a correct binary on his own and pass to the encoder. I think your suggestion is worth taking up and we might implement it in a coming version although we have to think about compatibility too. /Regards Kenneth Per Bergqvist wrote: > Hi, > > The asn1 en/decoder proberly handles ellipsis notation as it is > today. > > However, the decoder receives an extended PDU with > ellipsis data it will simply discard that information. > There is no way to tell the encoder to add extension information. > > I propose that each record generated by the compiler should add > an additional '$ellipsis' field for the last '...' in a sequence/set. > > The decoder should add any extension information to the '$ellipsis' > field. The encoder should allow the user to put extension information. > > This improvement would allow creation of proxy functions where one > does not always have the latest available/vendor specific spec. > > /Per > ========================================================= > Per Bergqvist > Synapse Systems AB > Phone: +46 709 686 685 > Email: per@REDACTED -- Kenneth Lundin Ericsson AB kenneth@REDACTED ?T2/UAB/UKH/K BOX 1505 +46 8 727 57 25 125 25 ?lvsj?