Re: ddm questions
Ingo Weinhold <bonefish-CFLBMwTPW48UNGrzBIF7/[email protected]> Sun, 26 Oct 2003 12:22:56 +0100
| Newsgroups | gmane.os.openbeos.storage |
|---|---|
| Message-ID | <[email protected]> |
On 2003-10-25 at 10:25:01 [+0200], you wrote: > > > > Yep, the non-const was chosen intentionally. I had the feeling, that > > > > e.g. > > > > truncating a name wouldn't be too unusual. > > > > > > So do you not want me to return B_NAME_TOO_LONG if the name is larger > > > than > > > B_OS_NAME_LENGTH and instead let the validate function handle things? > > > > That's what I was trying to say. :-) The string is passed to the disk > > system, > > which will truncate the name, if necessary, and the syscall just needs to > > copy it back into userland space. > > Are you okay with truncating it when copying from userland at the start of > the respective _kern_XYZ() function (but not returning an error if > truncation > occurs)? This is what I've done for the moment, as it seems more efficient > than arbitrarily allocating and copying the entire string and then forcing > the validate function to truncate it. Ah, OK, sure, I misread you. It makes sense to enforce the B_OS_NAME_LENGTH limit already in the respective validate syscall. The disk system will truncate the name further though, if it has more restrictive constraints. BTW, do you think B_OS_NAME_LENGTH (32 chars) is sufficient for partition (content) names? Since we don't use fixed size arrays in any structures, it would do any harm memory-wise to allow longer names. Oh, as I just realized fs_info reserves B_FILE_NAME_LENGTH space for the volume name. So we should probably use that limit too. CU, Ingo