Re: ddm questions
"Axel Dörfler" <[email protected]> Sat, 25 Oct 2003 02:40:52 +0200 CEST
| Newsgroups | gmane.os.openbeos.storage |
|---|---|
| Message-ID | <852056798-BeMail@nichtsnutz> |
Tyler Dauwalder <tyler-cyCl/[email protected]> wrote: > > You have to copy all pointer references from userland applications > > using the provided user_*() copy calls. The reason is simple: there > > is > > no guarantee that this memory stays valid during the execution. So > > if > > any kernel function has to access the memory the pointer points to, > > you > > need to copy it first into kernel space to make sure it stays > > valid. > Yes, but I was asking about copying back out (i.e. what the intended > semantics of the functions are). I know, that paragraph did only prepare the points I listed later on - the way I did it was probably confusing, so I am sorry about that :-) > > But there are some problems in your code: > > - there is apparently no user_strcpy() function in the kernel - you > > could either implement it (by calling user_memcpy()), or just call > > user_memcpy() directly - which is the preferred way, if you already > > know the length > Isn't there one declared in headers/private/kernel/vm.h right next to > user_strlcpy() and friends, and defined similarly in > src/kernel/core/arch/x86/arch_cpu.h, etc? Yeah, it's just not implemented anywhere :-) I don't think we should have it either, because I almost can't think of a good reason to use it. > That would be fine with me (adding a buffer length parameter). Ingo? It would be needed for the syscall only anyway. > > - you only check the return value of user_strlcpy() for >= max. > > name > > length - that's not correct; you also have to check it against > > values < > > B_OK - that's what it returns to report an error > Damn. Another good point. Thanks. Since I somehow never got the CVS diffs, I wouldn't have seen it if you hadn't used user_strcpy() :-) > > > + Do we have a limit on the length of those parameter strings? > > > I'm > > > currently assuming no. > > I don't think there is a limit. However, to be more robust, we > > should > > introduce one, 32K or 64K. > Take your pick. :-) Oh no, so everyone will point their fingers to me if it turns out that it is not enough ;) Bye, Axel.