C standard library redesign

[bluemoon]

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?

[Kevin]

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.

Yes. Which is why it's a good solution for many cases, but in some cases it won't be enough and you need to add some kind of error code anyway. Just because your programs don't make use of error information internally (or even give useful error messages) it's not said that noone else does better.

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).

What's wrong with an additional pointer argument?

[Owen]

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?

Because a FILE is useless without a file associated with it.

Also, you want FILE to be opaque. Lots of stuff in there, and also allocating one on the stack will mean somebody very quickly breaks things

[rdos]

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.

At least on x86, there is a method to make them reentrant. You use the FS or GS register an let it point to per-thread data (TLS = Thread Local Storage). Unfortunately, newlib was built at a time when this wasn't invented yet, and so have some really gruesome way to solve this issue.

[Combuster]

Code: Select all

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

I think that needs to be:

Code: Select all

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

So that the size and contents of struct FILE isn't needed for the caller.

[linguofreak]

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?

A solution I've wondered about is having a special kernel worker thread that runs in pre-reserved memory whose one purpose is to be woken in the event of an OOM condition and present the user with a list of running processes and a prompt to select one of them to be killed. It wouldn't be able to make any calls to the rest of the kernel that might allocate memory, of course, and that might just kill the idea (while writing such an interactive OOM handler itself without allocating memory might not be overly difficult, it might involve having non-allocating duplicates of a fair number of kernel functions that need to allocate memory in normal use).

[palk]

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.

No pointer necessary; you are allowed to return structs:

Code: Select all

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]

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?

[sortie]

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?

Nobody - the <stddef.h> header is from C89 while <stdint.h> is from C99. They put the stuff in different headers to mitigate namespace pollution and to avoid trouble with existing systems and programs that already declared similarly named macros (which is, for instance, why we get to dead with <stdbool.h> instead of just adding the bool data type).

I do agree, a new incompatible standard library ought to redesign the types API - although it's not that bad if you wish to be compatible and will be implementing large parts of ISO C as well.

[Oranos]

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?

.. 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?"

[FallenAvatar]

...

.. 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?

- Monk

[Oranos]

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

I'm not aware of BASIC type definitions.

Second, did you read the title of the thread?

No.

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

[AndrewAPrice]

Alternatives:

There are a few exception libraries out there for C. Handle what you want to handle, for example if you just want to know if it failed, just listen for EXCEPTION. If you want to handle code branches for different circumstances, listen for DEVICEEXCEPTION, PERMISSIONEXCEPTION, FILENOTFOUNDEXCEPTION, etc.

Alternatively, make the entire library event based and non-blocking. Each IO operation is asynchronous and you pass it a callback function. Handle errno as a callback parameter.