On 30 January 2015 at 13:06, Savolainen, Petri (NSN - FI/Espoo) <petri.savolai...@nsn.com> wrote: > > >> -----Original Message----- >> From: ext Taras Kondratiuk [mailto:taras.kondrat...@linaro.org] >> Sent: Friday, January 30, 2015 1:50 PM >> To: Savolainen, Petri (NSN - FI/Espoo); ext Ola Liljedahl >> Cc: lng-odp@lists.linaro.org >> Subject: Re: [lng-odp] Handling xxx_INVALID handles >> >> On 01/30/2015 01:15 PM, Savolainen, Petri (NSN - FI/Espoo) wrote: >> > As explained below, XXX_NULL != XXX_INVALID enables to distinguish this >> error ... >> > >> > x = odp_xxx_create(...); // error! => Returns XXX_INVALID >> > y = odp_yyy_create(x, ....); // x == XXX_INVALID => error! When in ODP will this be the recommended or desired practice? Either the user will have to check the return values for success or the different calls will have to check their inputs for validity.
If we are trying to support a number of (non-obvious) design patterns for the applications to use, these need to be documented (e.g. in architecture document or user's guide). >> >> Deferring error detection to a second function doesn't look like a good >> practice. It will be harder to determine a cause of the error then. > > The "error!" mains any, undefined error (e.g. crash). It's an example of an > error, another would be this. > > x = XXX_INVALID; //init Why initialize x at all? The compiler will warn you if you are reading x before it has been assigned a value. IMO default initializations are dangerous. > > // forgot to set x with valid value > > y = odp_yyy_create(x, ....); // x == XXX_INVALID => error! > > >> >> Also 'x == XXX_INVALID => error!' is not a correct statement. >> We agreed that 'x == XXX_INVALID => *undefined behavior*', so this is a >> definitely a bad example. > > Error! == undefined error, crash! > > -Petri > >> >> > >> > >> > ... from this valid use case (user choose to leave x NULL) >> > >> > y = odp_yyy_create(XXX_NULL, ....); >> >> >> >> > >> > >> > >> > -Petri >> > >> > >> >> -----Original Message----- >> >> From: ext Ola Liljedahl [mailto:ola.liljed...@linaro.org] >> >> Sent: Friday, January 30, 2015 10:58 AM >> >> To: Savolainen, Petri (NSN - FI/Espoo) >> >> Cc: ext Bill Fischofer; lng-odp@lists.linaro.org >> >> Subject: Re: [lng-odp] Handling xxx_INVALID handles >> >> >> >> On 30 January 2015 at 09:08, Savolainen, Petri (NSN - FI/Espoo) >> >> <petri.savolai...@nsn.com> wrote: >> >>> >> >>> >> >>> In API definition, XXX_NULL is not alias for XXX_INVALID. When user >> >> passes >> >>> XXX_NULL, it tells that application did not pass a handle. If user >> >> passes >> >>> XXX_INVALID, it’s an error (e.g. another ODP call returned XXX_INVALID >> >>> before this one, and user tries to pass that INVALID forward). >> >> How is this not like passing a NULL handle? >> >>> >> >>> >> >>> >> >>> Current linux-generic odp_pool_create() implementation uses SHM_NULL >> and >> >>> SHM_INVALID as synonyms, but that’s not robust and actually against >> API >> >>> definition, since SHM_INVALID should cause an error. >> >> I understand the definition and usage of ODP_SHM_NULL, it's like any >> >> other NULL definitions, including the NULL pointer in C/C++. >> >> >> >> But if the INVALID and NULL handles are not supposed to be equivalent, >> >> then I don't understand why ODP needs the INVALID handles. You never >> >> need to specify an INVALID handle (if you have the NULL handle) and >> >> calls that cannot return a handle that refers to a valid object can >> >> return the NULL handle. So what's the INVALID handle for? >> >> >> >> Currently it seems like the INVALID handle is a synonym for the NULL >> >> handle but only for outputs (return values) according to your >> >> statement above. >> >> >> >> The semantics of the different ODP operations here do not seem >> >> different from e.g. malloc, strdup and free. How come C can support >> >> these operations with only a NULL handle? >> >> >> >>> >> >>> >> >>> >> >>> -Petri >> >>> >> >>> >> >>> >> >>> >> >>> >> >>> From: lng-odp-boun...@lists.linaro.org >> >>> [mailto:lng-odp-boun...@lists.linaro.org] On Behalf Of ext Bill >> >> Fischofer >> >>> Sent: Thursday, January 29, 2015 11:14 PM >> >>> To: Ola Liljedahl >> >>> Cc: lng-odp@lists.linaro.org >> >>> Subject: Re: [lng-odp] Handling xxx_INVALID handles >> >>> >> >>> >> >>> >> >>> Given that pool creation/deletion is a relatively involved procedure >> and >> >> not >> >>> expected to be called frequently, it makes sense to include full >> >> parameter >> >>> validation as part of the operation. The same should be true for >> other >> >> APIs >> >>> with similar expected call frequencies. >> >>> >> >>> >> >>> >> >>> We do allow explicit INVALID input parameters, however for semantic >> >> reasons >> >>> they sometimes have aliases. For example, odp_pool_create() can take >> >>> ODP_SHM_NULL as input to specify that the caller is not supplying a >> shm >> >>> handle. However this is just an alias for ODP_SHM_INVALID since that >> is >> >> the >> >>> distinguished "not a handle" value for that data type. >> >>> >> >>> >> > _______________________________________________ >> > lng-odp mailing list >> > lng-odp@lists.linaro.org >> > http://lists.linaro.org/mailman/listinfo/lng-odp >> > > _______________________________________________ lng-odp mailing list lng-odp@lists.linaro.org http://lists.linaro.org/mailman/listinfo/lng-odp
