OSDev.org

thepowersgang wrote:For example, fopen returns a file pointer, short of adding either a FILE** argument to it (so it can return an error code)

int fopen(FILESTRUCT* file, const char* filename, int mode);

rdos wrote:The whole idea of using an error string instead of an error code is so code should never parse them or use them for anything else than logging or displaying them to the user.

thepowersgang wrote:For example, fopen returns a file pointer, short of adding either a FILE** argument to it (so it can return an error code), or adding an int* argument (to recieve the error code), there has to be a second channel for error information (with a return value of NULL indicating the error).

bluemoon wrote:

thepowersgang wrote:For example, fopen returns a file pointer, short of adding either a FILE** argument to it (so it can return an error code)

Code: Select all

int fopen(FILESTRUCT* file, const char* filename, int mode);

IMO is quite elegant. If FILESTRUCT is opaque you add function to allocate/initialize the space required (aka new/constructor)
PS. why should fopen allocate new space while it means to open a file?

thepowersgang wrote:Just chipping my 2c in.

I agree that non-reentrant functions should be avoided in modern code, and errno does (as was originally designed) make almost everything non-reentrant, there are times when it is nearly unavoidable.

bwat wrote:How does the programmer/sysadmin communicate to Linux that a certain application is vital? For example, let us say I have a system where application A is vital, but application B is not. For the sake of argument assume B is dynamically allocating memory without freeing in an infinite loop. How can I make sure that in the case where resources become so scarce that progress cannot be made for B, that B and not A is killed?

thepowersgang wrote:For example, fopen returns a file pointer, short of adding either a FILE** argument to it (so it can return an error code), or adding an int* argument (to recieve the error code), there has to be a second channel for error information (with a return value of NULL indicating the error). This also allows the reason for an error to be seamlessly propagated up the call chain, without forcing a calling convention on parent functions.

struct fopen_result {
    FILE * handle;
    int result_code;
};

struct fopen_result fopen(const char * foo);

struct fopen_result result = fopen("blah");
if (result.result_code) {
    switch (result.result_code) {
        case ENOMEM:
            ...
        case ENOENT:
            ...
    }
    exit(EXIT_FAILURE);
}
FILE * file = result.handle;
...

palk wrote:It's very annoying having to include stddef.h to get the type definition of size_t, stdint.h to get SIZE_MAX and the bit-count aware types, and then inttypes.h to get the format macros. Who thought it would be good to separate them?

palk wrote:Throwing my two cents in:

I think C's standard library would benefit from generic data structures such as linked lists, red-black trees, hash tables, arbitrarily large bit vectors. It seems like most of the time in C, code is managing or moving data, so I'd want to fast-track that.

I would replace most of the "signal handling" stuff and try to actually support an event-driven architecture that works internally to a thread (single process, single thread mode), between threads (single process, multithread mode), and between processes (multiprocess, multithread mode). I haven't looked into this, but most GUI toolkits (written in C) seem to support this, so I would think it's not infeasible, and worst case you'd have to add support into the OS to help out (which is kinda what you're here for in the first place, right?).

Finally, and this is more of a peeve, I'd rework the types and defines provided by stddef.h, stdint.h, inttypes.h, stdbool.h, etc. to make uintX_t have the definition of uint_fastX_t and provide every uintX_t type for every value of X up to 64 (unsigned long long is required to be at least 64 bits, so this is fine to do). Then, e.g., uint11_t would mean "the fastest type that is at least 11 bits." The macros PRIX32 and co. would be in the same header as the type definition, but I'd make the names shorter: FX32, Fu32, Fo32, etc. It's very annoying having to include stddef.h to get the type definition of size_t, stdint.h to get SIZE_MAX and the bit-count aware types, and then inttypes.h to get the format macros. Who thought it would be good to separate them?

uint = word size
uint8 = 8 bits; 'Byte' is an alias
uint16 = 16 bits
uint32 = 32 bits
uint64 = 64 bits

Oranos wrote:

palk wrote:...

.. I don't like any of those suggestions. I find this scheme sufficient for types:

Code: Select all

uint = word size
uint8 = 8 bits; 'Byte' is an alias
uint16 = 16 bits
uint32 = 32 bits
uint64 = 64 bits

But, why is everyone talking about modifying the existing C standard library? I thought the original post was about starting a library from scratch, not making trivial changes to a few functions. I find everything about it naive and it leaves me to question like: "who the hell standardized this skiv?"

First off, what did palk's post have to do with BASIC type definitions?

Second, did you read the title of the thread?

So, what I'm wondering is what improvements do you think could be made if one were to start from scratch?