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).
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 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 _______________________________________________ lng-odp mailing list [email protected] http://lists.linaro.org/mailman/listinfo/lng-odp
