OSDev.org

It's been a long week, shuffling around lines of code, getting ready for the first public release of my two projects, ccaprice and ecaprice, and well it's there! I'd like to present to you the caprice library suite. Yes that sounds quite good. Now the first thing that you're all thinking .. "there are other vendor implementations that do the same thing". Correct. But it's the simplicity of mine, and the license that seperates us from the animals. I've never been a fan of such enforcing licenses, expecially the GPL, or LGPL, which let face it, everything is. So I set aside some time to develop my own libraries to share with the world.

Anyways enough chatter lets get down to the specifics. First and fore most my libraries are highly incomplete. but don't let that scare you away, because they're still quite applicable for OS developers and embedded system programmers.

Anyways the homepage is here: https://staff.chatspike.net/~graphitemaster/ (I'd like to thank LaptopBrain for providing the hosting) The domain name http://www.libcaprice.com will be active in 24-72 hours so hold steady.

It should be noted that I'll be appreciated if anyone would also like to contribute and work on these two projects with me; as I'm the only developer currently. Just as much as helping improve various functionality or implemented new functionality would help move along this project. Anyways I'll be happy to hear from members, and I hope these will be of value to you. Thanks

It's not just a libc, it's a libc++ too, it's well documented, and has a less preposterous license. It's simple small and scalable, and easy to work with unlike other libraries. Primarly the biggest difference is this is a much more open project than others, anyone can contribute.

PDCLib, newlib, uClibc are open source project too.
I'm interested in how much more open project is yours.

I had a quick look at your library, mainly because I'm writing my own. I noticed a problemette. It seems your include files include non-system headers. For example locale.h does this ...Won't this be a problem after the headers are installed in /usr/include ?

Oh and I don't believe what Linus says in https://lkml.org/lkml/2011/9/1/229.

gerryg400 wrote:Won't this be a problem after the headers are installed in /usr/include ?

Unless the header names collide with something that's already there it shouldn't be a problem.

The license is a standard MIT license. Nothing special there.

As for implementation... I think that code has a long way yet to go.

I did only a quick scan of likely candidates for buggy implementation, and was disappointed to see how many of them are broken. The functions strncpy and strncat don't do what the standard says, assert() doesn't print a diagnostic, printf() breaks with %x and %u... not nice.

The effort is certainly appreciated, and I wish you well in your project, but right now I would discourage people from actually using it.

I'm unsure as to why you think the strncpy is not legal according to the standard. Also printf does work for %x and %u, wait when I added 'f' it falls through into it instead of 'd' nice catch, thanks for that tibit.

graphitemaster wrote:I'm unsure as to why you think the strncpy is not legal according to the standard.

Because I've implemented PDCLib with the standard document on my knees, know what to look for, and found your implementation lacking.

strncpy() is specified (in section 7.21.2.4 of the C99 specs, haven't checked ISO/IEC 9899:2011 yet) to copy from the source up to the first null byte, but no more than n bytes; then - if n has not been reached - filling the destination with zero bytes until n is reached.

You call memcpy( dest, src, n ) - which is not what the standard specified.

Solar wrote:

gerryg400 wrote:Won't this be a problem after the headers are installed in /usr/include ?

Unless the header names collide with something that's already there it shouldn't be a problem.

If I #include <locale.h> and that in turns tries to include "inc/ctype.h" it won't be found because ctype.h will surely be installed in /usr/include. (not in /usr/include/inc)

Ah, OK, I can see what you're aiming at. Correct, that looks like a bug.

Whoops, found another one...

Aside from the problem mentioned above, standard headers are not allowed to include each other in the first place (with the noteable exception of inttypes.h including stdint.h as per spec).

(The rationale is quite simple: Let's say I don't know anything about locale.h, and have a struct lconv in my source. Including ccaprice's ctype.h will suddenly break my (perfectly legal) code due to redefiniton of the struct, because ccaprice's ctyle.h includes locale.h behind my back...)

thanks for telling me all this. It's a great help to solving any bugs. However instead of describing them here, could you please direct them to the issue tracker on github https://github.com/graphitemaster/ccaprice/issues thanks.

New monthly installment of caprice libraries, reworked site (domain now works too) http://www.libcaprice.com
Version 0.1.1 of ccaprice and ecaprice

ccaprice second public release -- version 0.1.1
Fixed multiple header inclusion issues. C standard doesn't allow
standard library headers to include other standard library headers.
Rewrote brk() for FreeBSD (still desn't work for 32bit). Ported code
to work on clang and EkoPath/PathScale C compilers. Rewrote makefile
to request arguments before compilation, and also select proper shell
enviroment based on OS; e.g bash on BSD is /usr/local/bin/bash.
Implemented compile time constants for build date, build OS, build
host info (uname -a), as well as build host compiler (the compiler used
to build ccaprice). Rewrote test suite, fixed all broken functions
that failed to pass previous tests. Implemented more posix functionality;
specifically <strings.h>: of the following functions: bcmp, bcopy,
bzero, ffs, index, rindex, strcasecmp, strncasecmp.
Removed all standard library includes, ccaprice now implements it's
own, which is guarded by system headers that could ignore the rules.
Implemented various other functionality such as offsetof(), using
compiler builtins (if detected) otherwise emulated using macros
(unsafe), remove, strrchr and strtok. Locked off all ccaprice extensions
from inclusion into the global scope via a preprocessor macro
CCAPRICE_EXTENSIONS. Various bug fixes and refactoring of existing
code as well. Perliminary support for Windows and OSx as well, Windows
code compiles, but doesn't run.

ecaprice second public release -- version 0.1.1
Fixed partial bug in weak_ptr and shared_ptr, reference was spelt
incorrectly for typedefs. Updated all license headers to reflect
the MIT license in ccaprice. This project is now MIT too. Tons of
refactoring of implementation structure layout (now reflect ccaprice)
Wrote a features.txt (reflects ccaprice feature.txt) show cases all
implemented functionality in ecaprice. Fixed primitive unit tests
which need to be rewrote to compile again. Rewrote makefile to stop
doing silly things. Not many changes otherwise to the library, no
new features actually implemented. Most work was focused on getting
ccaprice stable and useable as a library. Next months release will
be more focused on ecaprice.

Feature list C library: https://raw.github.com/graphitemaster/c ... atures.txt
Feature list C++ library: https://raw.github.com/graphitemaster/e ... atures.txt

Lots to do yet but it's looking good, anyone wanting to join is welcome. Next months installment is focused on ecaprice, and getting working math library (softfp) in ccaprice (partly done, but missing lots of important functions)

gerryg400 wrote:Oh and I don't believe what Linus says in https://lkml.org/lkml/2011/9/1/229.

While generally untrue, this is starting to be the case for newer Intel microarchitectures. I've documented the appropriate techniques to dealing with large memory blocks here.

EDIT: Oops, that was the wrong link.

I don't mind being wrong here. Thanks for the correction.

I'd like to announce version 0.1.2 (yes third release) of caprice libraries. A lot of stuff has changed and has been fixed to be more respectful to the standards. Not eveything is fully conformant, but ccaprice is almost ANSI complete! Not much has changed in the C++ standard library other than some trivial things. I noticed some issues around "rep movsb" not actually being the fastest on Intel Atoms .. so I wrote a MMX (sort of SSE) based memcpy to accomdate that (in respect to some things mentioned on this forum) so thanks to you guys. These libraries are provided free of cost, but I like to eat, so donations would be awesome, even if it's $5 (that can buy me a bag of chips or two). Anyways updated site is here: www.libcaprice.com, enjoy guys.