If you look in the manpage, that isn't ambiguous: numbers starting with 0 are considered to have an implied decimal point before the first 0, so the more leading zeros, the smaller.
Since it diverges at 00 vs 04, anything after the decimal point is ignored.

But there is another bug in the version I just posted:
compare 2004 204, and my code assumes it's dealing with a leading 0
I have an idea for fixing it, but haven't done so yet.

notes: need to use an unsigned int or 0 is 111111111111.....
maybe use:
((*v>>24)&&(*v&0xFF00FFFF))&&((*v&0xFFFF00FF)&&(*v<<24))
because the compiler can combine some of these operations and/or thread them_________________Check out my github repositories. I may eventually get around to updating my blogspot.

Note: zero-arg functions like fork() may need to be modified on older compilers and all of the types (structs, etc...) will need to be defined and there is absolutely no type checking. If you would like some semblance of type checking, you can later modify the defines to be static inline functions like:

There are quite a few other functions in the kernel that would be useful if you wanted to wrap them in a syscall for userspace (all of the crypto stuff and filesystem detection for instance)_________________Check out my github repositories. I may eventually get around to updating my blogspot.

I now have the beginnings of my nano-libc that can be used as a single header file and have added many mime types to the "file --mime-type alternative"

The libc should work with any gcc toolchain and handles all linux syscalls (stat is the only one with the structs predefined though) as well as a couple of string functions and a basic {f}printf - I recommend using musl libc to add any extra functions you may need.

A statically compiled program that uses printf is just over 1kb (other libc implementations are at least 7kb) and just a basic write(1,"hello world\n",12); is ~600b (without using sstrip, - that brings it to under half a kb)

ftype.c has also been tested with it and runs 60-120 times faster than `file --mime-type`

Cool!
Is it possible to use the libc.h directly as #include "libc.h" or is it better to copy the different functions into the main code?
I tried to substitute the codeblock in ftype.c within #ifdef STANDALONE with #include "libc.h" but got some errors compiling:

I leave off nostdinc so that it picks up the NR* syscall defines from the linux headers ... See unistd.h (the only include in libc.h) they could be included directly, but I am leaving platform specific stuff out as much as possible for future arm stuff. My latest version of ftype only uses libc.h instead of builtin standalone code. I think Its currently a good starting point though to bootstrap whatever additional functions you may need for a single purpose app. At least printf doesnt keep your app from running on the stack like most implementations do... at least for now since only the most common bits are implemented (va_* was the hard part, but it can be used for other fxns that need variable# of args)

When you build with the parameters in the libc.h header it should work the same for any toolchain ... Otherwise it is sucking in includes from other than just the linux headers, but I havent found a good way to get 1 without the other._________________Check out my github repositories. I may eventually get around to updating my blogspot.

Its a bit disorganized but I added a ton of stuff to test
Edit: ok, really disorganized, I will do a bunch of cleanup and testing before the next version and try to complete the string functions and will be in a new thread.

The primary purpose is to allow for smaller overheads in static binaries so that multicall binaries are not needed so much. To finish this out, I need to make a tool chain that symlinks all of the stdinc files to libc.h and wraps cc with nostdlib nostdinc and fnobuiltin and some optimizations.

If anyone uses it and runs into missing structs or defined constants, please post them, (figuring out the basic types used in structs can take a lot of time) which also reminds me, I should define these to the basic types as I find them (rather than typedeffing them) ... Of course that means you should do development against a "real" c library first for sanity checks (any noted differences will help). Currently only targeting x86, but will consider basic arm support (64 bit versions wouldnt make sense, but feel free to fork )

note, linux 3.10 is lts so it will be the basis, thus sycalls may not be available in older kernels... most static binaries will work unless you try to use a newer syscall like finit_module on an older kernel

//note the << and >> operations could depend on endianness
// >>3 == /8 and <<3 == *8, but is faster it with optimization off

to initialize a large array of booleans all you need to do is:
char cbits[]={0,0xF,0,0xFF};
// 00000000000011110000000011111111
or for all zeroes
char cbits[4]={0};
// 00000000000000000000000000000000
int ibits[]={0xF0F0F0F0,~0};
//1111000011110000111100001111000011111111111111111111111111111111

then just use the macros to access the bitfields
If you will only be accessing 1 type of array like this it may be better to make the macros into proper functions like:

Code:

char getbit(char *x, unsigned n){
return x[n>>3] & 1 << (n&7);
}

Why do this? Normally boolean types take at least 8 bits because they have to be addressable in memory on x86(_64) they are 32 (or 64) bits.

If you have a large amount of flags in the range of thousands, it could be the difference in whether the program stays in cache (or run out of memory on constrained systems)_________________Check out my github repositories. I may eventually get around to updating my blogspot.

This is useful for iterating on data with different functions, conditionally calling arbitrary functions, implementing an object based system, or even to save small amount of space in a shared library (enums can be 1 byte vs <long_function_name>)_________________Check out my github repositories. I may eventually get around to updating my blogspot.

You cannot post new topics in this forumYou cannot reply to topics in this forumYou cannot edit your posts in this forumYou cannot delete your posts in this forumYou cannot vote in polls in this forumYou cannot attach files in this forumYou can download files in this forum