Re: [dev] [st][patch] externalpipe()
Greetings. On Sat, 21 Dec 2013 11:06:02 +0100 koneu wrote: > Rob wrote: > > Yeah, based it off url-select, love that feature. urxvt takes 8 seconds > > or so to open on my laptop, so necessity is the mother of invention and > > all that. > > Configure with --disable-everything and use urxvtd. Faster (and more > stable) than st for me. You didn’t send a bug report. Your crticism against st is invalid. Sincerely, Christoph Lohmann
Re: [dev] strlcpy and strlcat
There is also Annex K in C11 specifying strcpy_s and friends. Yet it is optional part of standard, so hard to say if it will be widely adopted. -- Paul Onyschuk
Re: [dev][announce] Optimizing C compiler & c++ compiler/runtime
Strake wrote: On 20/12/2013, Rob wrote: https://github.com/bobrippling/ucc-c-compiler Why are you rewriting libc? I think calling it a libc rewrite does it too much justice. When I started out I needed something I could statically link against that would be simple to debug, and had compatible function prologue/epilogue sequences to the cdecl-calling convention ucc originally used. So I knocked together a few libc functions. Now the parser is at a stage that it can handle system headers, and the code-gen can generate x86_64 compatible function call sequences I don't need it, it'll be canned at some point. Rob
Re: [dev] strlcpy and strlcat
On Sat, Dec 21, 2013 at 01:32:44PM +1100, Daniel Bryan wrote: > I just read this message by an OpenBSD developer on the prevalence of > strlcpy in the OpenBSD ports tree: > > http://marc.info/?l=openbsd-tech&m=138733933417096&w=2 > > I'd like to know what the opinion here is of these functions. I've so > far avoided them, but it seems like there's an argument to be made for > their simplicity, though they're not POSIX standard. I've included these functions as part of ubase[1]. There is a possibility that they will be included in sbase, if and when we need them. [1] http://git.suckless.org/ubase/tree/util
Re: [dev] strlcpy and strlcat
Daniel Bryan dixit: >I'd like to know what the opinion here is of these functions. I've so Not using them in this time and age is gross negligence. Using strcpy, strcat and sprintf is even more; using strncpy is minor negligence, but _strncat_ is positively dangerous. So, yes, by all means, use strlcpy, strlcat, snprintf. (On strcpy_s: these were implemented in, IIRC, MSVCRT before, but nobody bothered with them. Instead, I noticed Win32 developers adding strlcpy too. Funnily enough, strcpy_s mostly behaves like strlcpy except its return value is less generic.) bye, //mirabilos -- > Hi, does anyone sell openbsd stickers by themselves and not packaged > with other products? No, the only way I've seen them sold is for $40 with a free OpenBSD CD. -- Haroon Khalid and Steve Shockley in gmane.os.openbsd.misc
