On 2 September 2014 10:30, Wiles, Roger Keith <[email protected]> wrote: > > On Sep 2, 2014, at 12:23 PM, Victor Kamensky <[email protected]> > wrote: > >> Hi, >> >> Sorry, I missed the point where we jumped to use of errno. >> I would rather leave it to POSIX and not to mess with it. IMHO >> it is quite archaic mechanism even in POSIX (recall movement >> of errno from global to TLS). > > We are not going to use the variable ‘errno’ just the ERRNO define names as a > good starting point for error codes. >> >> Also I am not sure are we talking about using errno variable >> by ODP library calls or reusing errno.h enumeration values for >> some other purposes, and/or adding new values to errno. >> >> In either case I don't think it is good idea. Few examples: >> >> o If you introduce new errno values that current system >> POSIX implementation does not understand how strerror >> function will work? I.e how it will know strings for new values > > Every one that defines a platform specific errno value will have to deal with > that problem and that is what happens today in any system, correct?
"platform specific errno value" that never got stored into errno variable? I would not call them errno values those are just some defines. Of course strerror cannot be applied to arbitrary define of type int. If you adopt "start with 'E'" naming convention for those defines you are in danger to collide with some other code that uses such simplified naming convention. In languages that lack notion on name space this issue is solved with use of prefix that designated name space (i.e ODP_ERROR_). Thanks, Victor >> >> o If ODP uses errno TLS it could be messed up with other >> POSIX calls. I.e if my app have signal handler and that signal >> handler calls will set errno value, so when ODP call comes >> back its error value will have nothing to do with ongoing ODP >> call. BTW I found this issue as one of archaic mechanism of >> POSIX errno itself. Or if ODP implementation stores errno but then >> calls app logging callback. POSIX calls from that logging >> callback may reset errno, so ODP implementation >> should always set errno after any possible logging callback. >> >> o Reusing errno.h values as return values of some other functions >> does not make much sense either, unless we are talking about very >> simple cases like EINVAL, etc >> >> Instead I think ODP should have its own error codes, and either >> return them during API calls (preferable to me) or introduce another >> TLS variables like odp_errno and use it in the same style as errno is >> used by POSIX. >> >> Thanks, >> Victor >> >> >> On 2 September 2014 09:56, Wiles, Roger Keith <[email protected]> >> wrote: >>> >>> For errno we are going to use POSIX errno values. >>> >>> Found this one from open group, which I believe to be the current IEEE std: >>> http://pubs.opengroup.org/onlinepubs/9699919799/ >>> >>> Will the above reference be OK with everyone as a reference for ERRNO >>> names? Linux man page seem to suggest it is following that standard. >>> >>> It appears the standard does not define the value only the name of the >>> errno. I had not look directly at the standard before :-( Just assuming the >>> applications must be compiled with the system it will be run. I assume we >>> are not trying to be binary compatible here. >>> >>> After tracking down the errno values/defines on my Ubuntu 14.04 system they >>> really love to hide them now a days. >>> >>> /usr/include/sys/errno.h —> >>> /usr/include/errno.h —> >>> /usr/include/bits/errno.h —> >>> /usr/include/linux/errno.h —> >>> /usr/include/asm/errno.h —> >>> /usr/include/asm-generic/errno.h —> >>> >>> /usr/include/asm-generic/errno-base.h —> >>> >>> /usr/include/asm-generic/errno.h >>> The last two define most of the defines we are interested in for ODP, but a >>> few of the ones above define a few extras :-( >>> >>> As long as we use the same define names then we should be OK. >>> >>> If ODP needs a set of defines not able to be mapped to POSIX then we need >>> to define a name space to hold these defines similar to what Bill was >>> suggesting with some type of prefix for all ODP errnos. The platform should >>> do the same, but this is were the problems begin for the application. The >>> application will need to include platform specific errno defines when >>> building with a given platform (ifdef's), so the applications can not be >>> binary compatible across different platforms. >>> >>> Does this summarize the errno discussion today and hopefully add some more >>> definition around how ODP uses errnos? >>> >>> Here is a link that someone produced by platform, which was a lot of work >>> IMO :-) and may not be up to date. >>> http://www.ioplex.com/~miallen/errcmp.html >>> >>> Thanks >>> ++Keith >>> >>> Keith Wiles, Principal Technologist with CTO office, Wind River mobile >>> 972-213-5533 >>> >>> >>> _______________________________________________ >>> lng-odp mailing list >>> [email protected] >>> http://lists.linaro.org/mailman/listinfo/lng-odp > > Keith Wiles, Principal Technologist with CTO office, Wind River mobile > 972-213-5533 > _______________________________________________ lng-odp mailing list [email protected] http://lists.linaro.org/mailman/listinfo/lng-odp
