OSDev.org

Jeko wrote:In fact, if the function returns a string allocated in the kernel memory, the user process can't access to the string.

Solar wrote:

Jeko wrote:In fact, if the function returns a string allocated in the kernel memory, the user process can't access to the string.

Map the result into user address space as read-only?

Solar wrote:Make the user provide the memory, return zero if successfull, and the amount of memory required if what the user provided isn't long enough?

Jeko wrote:

Solar wrote:

Solar wrote:Make the user provide the memory, return zero if successfull, and the amount of memory required if what the user provided isn't long enough?

With this method the user must allocate memory, call the function, allocate more memory, call another time the function.

#include <stdio.h>

...
char * buffer = malloc( FILENAME_MAX );
...

Solar wrote:

Jeko wrote:With this method the user must allocate memory, call the function, allocate more memory, call another time the function.

If he did this the first time around, he'd be able to catch 99% of all filename cases:

Code: Select all

#include <stdio.h>

...
char * buffer = malloc( FILENAME_MAX );
...

Oh, while we're at it - are your filenames in ASCII (if yes, which codepage?), or Unicode (if yes, which encoding?)?

MessiahAndrw wrote:Look how Microsoft do it.

e.g.
ReturnSomeKernelString(char *buffer, uint sizeOfBuffer);

Jeko wrote:(What are codepages, and what are encodings?)

Solar wrote:

Jeko wrote:(What are codepages, and what are encodings?)

Codepages is DOS vocabulary; more generally spoken it's about character encodings. ISO 646, ISO 8859, EBCDIC, Windows-125*, KOI-8, ISO 2022...

With "encoding" I meant UTF-8, UTF-16, UTF-32...

I know you usually don't want to bother with these things in the beginning, you just "want it to work". But they are a royal PITA when you attempt to retrofit this kind of international support, because it affects virtually everything down to the simplest of functions.

Solar wrote:UTF-8 is space-efficient, at least as long as most of your characters are ASCII, or at least BMP (Basic Multilingual Plane). However, it's a multibyte encoding - i.e. you can't know how many bytes you have to skip if you want to skip n characters, as one character can be 1..? bytes.

UTF-32 is not space-efficient, as every character takes 32 bits of space (wide encoding). However, skipping characters, concatenating and many other string operations are more efficient because of this.

ISO/IEC 9899:1999 (C language standard) more or less assumes that files are stored as multibytes, while in-memory-operations are usually done in wide encoding.

Jeko wrote:

MessiahAndrw wrote:Look how Microsoft do it.

e.g.
ReturnSomeKernelString(char *buffer, uint sizeOfBuffer);

So a filename is returned partially. If sizeOfBuffer < filename, only a part of the filename will be put in the buffer

// somewhere that can be shared between all common functions like this (not thread safe though):
#define CHUNKS_TO_DO_AT_ONCE 1024
char buffer[CHUNKS_TO_DO_AT_ONCE];

// the system call:
void sysReturnSomeKernelString(char *bufferToStoreChars, uint offsetInName, uint charsThatFitInBuffer, bool &stillMoreCharactersRemaining);

// the func:
std::string ReturnSomeKernelString()
{
    std::string str;
    bool stillMore = true;
    uint offset = 0;

    while(stillMore)
    {
        sysReturnSomeKernelString(buffer, offset, CHUNKS_TO_DO_AT_ONCE, stillMore);
        offset += CHUNKS_TO_DO_AT_ONCE;
        if(stillMore)
             str += std::string(buffer, CHUNKS_TO_DO_AT_ONCE); // no null-terminator so we specify size
        else
             str += std::string(buffer); // will stop at null-terminator
    }

    return str;
}