Thread: Looking for thoughts on my new alternative to printf/scanf

the point of c runtime library being installed in almost every operating system on every hardware that exists today is to use runtime function in a portable way. having your own version of printf, scanf or any generic function of the c library is good for personal gratification when you finish it just about right or better but it defeats the purpose of the c runtime library functions being installed, again, in almost every os on every hardware. say i write something in win32 that uses printf - when i wish to port the code to say raspberry pi that is under the arm architecture, i can still use the same printf coz the runtime is installed there. and almost everyone uses c/c++ so rest assured that the libraries are installed everywhere.

Originally Posted by interglobber

This is true, but I don't think designing what you might think to be a better solution needs to invalidate the standard library. Nor do I think that you should necessarily roll a solution strictly using the standard library just because you could hackily put something together. If portable code is your goal, you absolutely should just cut your losses and use the standard library, but this person is interested in a totally unique standard library that does not have a lot of what they see as historical baggage.

Thanks for that, only just saw both messages this morning, but yeah, the standard libraries do carry a lot of historical baggage from experimenting, I'm trying to make a library that can be used along side the standard library or simply on it's own, the reason I want it to be usable along side the standard library is so that any experimental features that are implemented in the standard library can then be used without issue, paw would then only implement those features after the lessons have been learned and use hose lessons to provide a consistent api, in other words paw would be the final standard rather than the experimental standard, this is the other reason I do a lot of posting about it on these forums since a lot of the peops here have more experience than me and can point out potential problems they know of, it's also the reason that I'm not marking a 1st release until I'm confident there'll be no changes to the api I've made for it just to introduce new features, if new features are to be implemented that clash with the existing api then I'll just mark it version 2 and affix the number 2 to the paw prefix resulting in the new api looking like this paw2slen() and the new lib name looking like this: libpaw2_x.so vs the 1st lib name that would look like this: libpaw1_x.so, because it's meant purely for use with the launcher I'm designing for a cross-platform solution to software development where the development paradigm would be cross-platform 1st then native, ie use paw's features to query what system running on, then load in system specific libs, in both cases the libs and apps will be installed via the system package manager, there will be no official paw repo for paw designed apps, they just build themselves, then launch something like "paw --install <name> <build_dir>" to actually install their libraries and apps to the directories that are not always in the PATH variable, since they are only supposed to be mapped in by the paw launcher when the users launches their app with something like "paw --sys-start <name> <exe>". This method gives both the option of shared libraries and app specific libraries, all without ever needing root permissions for the install, instead paw will try the following in this order: $TOP_DIR/.paw $OTG_DIR/.paw $SHARED_HOME/.paw $HOME/.paw, those are the only places it will install apps to and it will be in sub directories for each abi, so if your $OTG_DIR is taken to systems of differing abis AND apis you'll still get the same software available in the paw directories (as long as the binaries needed were built before it was installed), the $TOP_DIR one is for testing builds follow what paw expects without corrupting your normal install directories

As for stuff like sand-boxing, since that can be left to a command line app like chroot (even if it's not the best, it should still be a choice the user can make) paw will not implement it, at all