On 11/09/15 17:49, Robert Millan wrote:
Hi Antti,
El 16/08/15 a les 13:23, Robert Millan ha escrit:
On 16/08/15 13:20, Antti Kantee wrote:
On 16/08/15 00:55, Robert Millan wrote:
Uhm yes, I think it could be useful to me. However based on your
replies I suspect I may be doing
something strange, or at least unusual.
Ok send a patch for that.
Here.
Did you have a chance to look at this one?
Yes, but I couldn't quite figure out what the right thing to do is, and
then I admittedly forgot about it for a few weeks.
+ If the translation header includes <errno.h>, it won't work on systems
without errno.h. That said, I don't know of any systems with EFOO but
no errno.h. Notably, <rump/foo.h> generally does not include any
"outside" headers to make <rump/> maximally adaptable to any
environment. If the translation header does not include errno.h, using
it is very error-prone (forget to include errno.h and you get wrong
results).
+ The current <rump/rumperr.h> does not depend on the host having the
concept of errnos, therefore the new routine should probably go into a
separate header. Also, that header was very stupidly named, but I can't
go back and change it anymore.
So, hmm, to me the best option seems to put the translations in a
separate header (e.g. <rump/errnotrans.h>). I'm still a bit undecided
about whether or not it should include <errno.h>. Theoretically C
modules using <rump/foo.h> should be portable over all environments, but
then again you a) need to include something else to get the appropriate
type definitions required by e.g. <rump/rump_syscalls.h> b) not sure
you'd ever want to write programs with modules which don't interact with
the host at all.
Thoughts?
