[fossil-users] Proposed Fossil interface enhancement.
Wouldn't it be nice to have a tree view of the files under control, similar to this: http://www.sqlite.org/customandroid/doc/trunk/www/tree.wiki The page above was generated using tree tree.wiki on Linux then adding pre markup to tree.wiki page. That page is for an unrelated project. But it clearly demonstrates the utility of being able to view a file hierarchy at a glance. I like this so much that I'm tempted to make it my New Years Day project. Please feel free to contribute design ideas or implementation suggestions. -- D. Richard Hipp d...@sqlite.org ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
[fossil-users] C Best Practices
I have been using C for many more projects over the past year. I enjoy writing projects in C because they are fast, reasonably portable (across unices), and have a small footprint. The coding style is natural to me and I enjoy having insight into some of the lower level details. I approach the language with caution, however, due to its pointy sharp edges. It seems that wherever I turn on the Internet, others decry the notion of using C for anything other than low-level systems programming. Creating a web app in C seems universally panned, and the Internet questions the sanity of all who attempt it. Fossil has carved out its own little niche in the face of this. My sense is that this list is rife with C aficionados, or at least people who see the advantages, and I thought it might be fun to discuss a few techniques we use to create secure, stable applications using this language. I realize this might be a little off-topic for the fossil users list, and I apologize in advance for that. Call it my end-of-year indulgence. I think it's an advantage, though, because we might be able to get better viewpoints than those we so often find on the internet (particularly from Richard). For those who use/prefer C, how do you make sure your applications are secure? Is there a concise, pragmatic summary of techniques for secure code? What pitfalls do you encounter with C and how do you address these? It seems like the biggest issue is lack of standard data types. What advice would you give to someone who spent the last year getting comfortable with the C environment and wants to take advantage of all it has to offer? Thanks! ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] Proposed Fossil interface enhancement.
On Mon, Dec 30, 2013 at 8:12 PM, Richard Hipp d...@sqlite.org wrote: Please feel free to contribute design ideas or implementation suggestions. What comes to mind: - with a bit of JS it could be made interactive (collapsible/openable) - it could be a supplement or replacement for the /dir view, with the links working like they do now for /dir. - it might not be practical for repos with many thousands of files (then again, maybe it would be especially useful on such repos). On a related note: i had intended to add an ls -1 style output to /dir over the holidays (based on an ML suggestion back in November), but the hydraulic part of my computer chair is failing and the chair now sinks to the floor when i sit it for more than a few minutes, so i won't be doing any notable hacking until i get a replacement chair or can figure out how to fix this one. (God bless tablets, otherwise i'd be almost completely offline!) -- - stephan beal http://wanderinghorse.net/home/stephan/ http://gplus.to/sgbeal Freedom is sloppy. But since tyranny's the only guaranteed byproduct of those who insist on a perfect world, freedom will have to do. -- Bigby Wolf ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] C Best Practices
On Mon, Dec 30, 2013 at 8:38 PM, Sean Woods s...@seanwoods.com wrote: I realize this might be a little off-topic for the fossil users list, and I apologize in advance for that. Call it my end-of-year indulgence. I think it's an advantage, though, because we might be able to get better viewpoints than those we so often find on the internet (particularly from Richard). i'll go ahead and voice some thoughts before this thread gets banned as being too OT ;). For those who use/prefer C, how do you make sure your applications are secure? Is there a concise, pragmatic summary of techniques for secure code? In my experience, if inputs and ranges are valid/validated, there's very little which can happen in terms of buffer-related security. A lot of historical security holes (arguably the majority) were caused by laziness (or poor assumptions) on someone's part. Security against, e.g., SQL injection is much more problematic nowadays, i think, and we (==Fossil devs) try to take care to use sqlite3's facilities for avoiding those (e.g. using bound parameters instead of direct SQL string creation, and using sqlite's %q/%Q format specifiers when bound parameters are not feasible/practical). What pitfalls do you encounter with C and how do you address these? It seems like the biggest issue is lack of standard data types. The lack of standard higher-order data types is certainly a big time sink for many apps, but OTOH it forces us to write case-specific solutions which are possibly a better fit for the task at hand (and possibly more efficient). That lack is a mixed blessing, IMO. i've learned to accept it. i came back to C after growing up in the STL-using C++ world. The STL is a _huge_ time saver, and compilers are good enough to optimize out some of the levels of perceived inefficiencies. (And it's a simple fact that the STL saves development time over hand-writing/testing custom data structures which do the same thing.) What advice would you give to someone who spent the last year getting comfortable with the C environment and wants to take advantage of all it has to offer? Oh, boy. As a matter of fact... a few years ago i posed myself a very similar question a while after i had gotten (back) into C, and i ended up writing: http://wanderinghorse.net/computing/papers/DoingOOInC.pdfhttp://wanderinghorse.net/computing/papers/#oo_c that's an article on how [i prefer] to model OO in C (because i'm not happy with most approaches i see in C code). Other than that, my advice would be to find projects which successfully deploy C and study them. sqlite is certainly the example which comes foremost to mind. In C anything is possible, which leaves the doors wide open as to what and how things get programmed, with no single right/wrong answer for the vast, vast majority of the programming problems out there. But you certainly knew that there would be no simple do this and this and this answer to your question ;). -- - stephan beal http://wanderinghorse.net/home/stephan/ http://gplus.to/sgbeal Freedom is sloppy. But since tyranny's the only guaranteed byproduct of those who insist on a perfect world, freedom will have to do. -- Bigby Wolf ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] Proposed Fossil interface enhancement.
On Mon, 30 Dec, Stephan Beal wrote: - it might not be practical for repos with many thousands of files (then again, maybe it would be especially useful on such repos). If you open collapsed by default, this should not be a problem as you can drill down the path you're interested in without having thousands of files being displayed at once. -- Stefan Bellon ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] Proposed Fossil interface enhancement.
On 30 December 2013 20:12, Richard Hipp d...@sqlite.org wrote: Wouldn't it be nice to have a tree view of the files under control, similar to this: http://www.sqlite.org/customandroid/doc/trunk/www/tree.wiki ... Please feel free to contribute design ideas or implementation suggestions. As for the visual appearance: what would be very useful already for me is a clear visual difference between a dir- and file-name (in any file-manager, for that matter). I agree with Stephan's comment that it might be less useful for repos with many files (which I have here). Perhaps a 'show as tree' (or 'tree') link, showing a dir-tree with currently displayed flat directory as root would be useful. Michai ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] Proposed Fossil interface enhancement.
On 30 December 2013 20:41, Stephan Beal sgb...@googlemail.com wrote: On Mon, Dec 30, 2013 at 8:12 PM, Richard Hipp d...@sqlite.org wrote: Please feel free to contribute design ideas or implementation suggestions. What comes to mind: - with a bit of JS it could be made interactive (collapsible/openable) I'm not a greybeard console-only type, but occasionally use 'links' to browse fossil repos; perhaps JS collapse/expand should not get too much in the way there. Or if I'm the only links-/lynx-user out there, go ahead :) Michai ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] Proposed Fossil interface enhancement.
On Mon, Dec 30, 2013 at 9:20 PM, Michai Ramakers m.ramak...@gmail.comwrote: I'm not a greybeard console-only type, but occasionally use 'links' to browse fossil repos; perhaps JS collapse/expand should not get too much in the way there. Or if I'm the only links-/lynx-user out there, go ahead :) AFAIR, we have no (important/major) functionality which _requires_ JS in order to work. There are some bits which benefit from it (e.g. try clicking on two of the little boxes in the timeline, and the wysiwyg editor), but nothing major which relies on it. -- - stephan beal http://wanderinghorse.net/home/stephan/ http://gplus.to/sgbeal Freedom is sloppy. But since tyranny's the only guaranteed byproduct of those who insist on a perfect world, freedom will have to do. -- Bigby Wolf ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] Proposed Fossil interface enhancement.
On Mon, Dec 30, 2013 at 9:14 PM, Stefan Bellon sbel...@sbellon.de wrote: On Mon, 30 Dec, Stephan Beal wrote: - it might not be practical for repos with many thousands of files (then again, maybe it would be especially useful on such repos). If you open collapsed by default, this should not be a problem as you can drill down the path you're interested in without having thousands of files being displayed at once. i was thinking more about the computational cost of generating the list, not actually the rendering (which certainly wouldn't be really usable for 1 files). Generating that list must be done at one time, and delivered in the HTML response, unless the feature is AJAX-based (so far we have no AJAX-based functionality in the default build). -- - stephan beal http://wanderinghorse.net/home/stephan/ http://gplus.to/sgbeal Freedom is sloppy. But since tyranny's the only guaranteed byproduct of those who insist on a perfect world, freedom will have to do. -- Bigby Wolf ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] Proposed Fossil interface enhancement.
Thus said Stephan Beal on Mon, 30 Dec 2013 20:41:38 +0100: On a related note: i had intended to add an ls -1 style output to /dir over the holidays (based on an ML suggestion back in November), Isn't this already possible with CSS? Thanks, Andy -- TAI64 timestamp: 400052c1dcd7 ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
[fossil-users] Additional CSS skins [was Re: Proposed Fossil interface enhancement.]
Thus said Michai Ramakers on Mon, 30 Dec 2013 21:16:11 +0100:
As for the visual appearance: what would be very useful already for me
is a clear visual difference between a dir- and file-name (in any
file-manager, for that matter).
I use the following CSS for this (provided by someone on the ML):
li.dir:after {
content: '/';
}
It would be nice if some of the built-in skins had this as a default.
In fact, perhaps a couple new skins should be added to demonstrate how
to accomplish this and the single row listing so people don't have to
search the archives for how to do it?
Andy
--
TAI64 timestamp: 400052c1de2d
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] Proposed Fossil interface enhancement.
On Mon, 30 Dec 2013 21:25:36 +0100 Stephan Beal sgb...@googlemail.com wrote: On Mon, Dec 30, 2013 at 9:20 PM, Michai Ramakers m.ramak...@gmail.comwrote: I'm not a greybeard console-only type, but occasionally use 'links' to browse fossil repos; perhaps JS collapse/expand should not get too much in the way there. Or if I'm the only links-/lynx-user out there, go ahead :) AFAIR, we have no (important/major) functionality which _requires_ JS in order to work. There are some bits which benefit from it (e.g. try clicking on two of the little boxes in the timeline, and the wysiwyg editor), but nothing major which relies on it. Unless it's something else causing it here, clicking anything in the timeline without javascript enabled will take you to the honeypot... I've gotten used to browsing fossil repositories with javascript enabled as too much breaks without it. M ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] Proposed Fossil interface enhancement.
On Mon, Dec 30, 2013 at 9:51 PM, Andy Bradford amb-fos...@bradfords.orgwrote: Thus said Stephan Beal on Mon, 30 Dec 2013 20:41:38 +0100: On a related note: i had intended to add an ls -1 style output to /dir over the holidays (based on an ML suggestion back in November), Isn't this already possible with CSS? Partially - i'd actually like to do something more akin to (ls -la). A simple single-column list could (it seems) be done with CSS. -- - stephan beal http://wanderinghorse.net/home/stephan/ http://gplus.to/sgbeal Freedom is sloppy. But since tyranny's the only guaranteed byproduct of those who insist on a perfect world, freedom will have to do. -- Bigby Wolf ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] Proposed Fossil interface enhancement.
On Mon, Dec 30, 2013 at 10:21 PM, Stephan Beal sgb...@googlemail.comwrote: Partially - i'd actually like to do something more akin to (ls -la). A simple single-column list could (it seems) be done with CSS. i spoke too soon - the columns are done with TDs, and CSS isn't enough to make those single-column. -- - stephan beal http://wanderinghorse.net/home/stephan/ http://gplus.to/sgbeal Freedom is sloppy. But since tyranny's the only guaranteed byproduct of those who insist on a perfect world, freedom will have to do. -- Bigby Wolf ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] Proposed Fossil interface enhancement.
On Mon, Dec 30, 2013 at 10:04 PM, org.fossil-scm.fossil-us...@io7m.comwrote: Unless it's something else causing it here, clicking anything in the timeline without javascript enabled will take you to the honeypot... I've gotten used to browsing fossil repositories with javascript enabled as too much breaks without it. It's apparently not detecting your browser as human - fossil tries to curtail access by anything which it thinks might be a bot. One of the reasons (if not the main reason) is to keep bots from crawling the timeline history and downloading a full ZIP copy of every version of the repo. -- - stephan beal http://wanderinghorse.net/home/stephan/ http://gplus.to/sgbeal Freedom is sloppy. But since tyranny's the only guaranteed byproduct of those who insist on a perfect world, freedom will have to do. -- Bigby Wolf ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] Proposed Fossil interface enhancement.
On Mon, Dec 30, 2013 at 4:04 PM, org.fossil-scm.fossil-us...@io7m.comwrote: Unless it's something else causing it here, clicking anything in the timeline without javascript enabled will take you to the honeypot... I've gotten used to browsing fossil repositories with javascript enabled as too much breaks without it. This is a defense against spiders trying to index the entire repository, and downloading all possible diffs between any two check-ins, all possible annotations, all possible historical tarballs and ZIP archives, and so forth, and thereby soaking up far more than their fair share of CPU cycles and bandwidth. Further information here: http://www.fossil-scm.org/fossil/doc/tip/www/antibot.wiki You can disable the robot defenses by logging in using username anonymous. Note also that the timeline graph is drawn using javascript, and so if you have javascript disabled, you do not see the timeline graph at all. There is no work-around for this second problem. -- D. Richard Hipp d...@sqlite.org ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] Proposed Fossil interface enhancement.
Stephan Beal wrote: On Mon, Dec 30, 2013 at 10:21 PM, Stephan Beal sgb...@googlemail.com mailto:sgb...@googlemail.com wrote: Partially - i'd actually like to do something more akin to (ls -la). A simple single-column list could (it seems) be done with CSS. i spoke too soon - the columns are done with TDs, and CSS isn't enough to make those single-column. Is there a glitch in the Matrix? ;) http://www.mail-archive.com/fossil-users@lists.fossil-scm.org/msg13955.html ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] Proposed Fossil interface enhancement.
On Mon, Dec 30, 2013 at 10:30 PM, Joel Bruick j...@joelface.com wrote: Stephan Beal wrote: i spoke too soon - the columns are done with TDs, and CSS isn't enough to make those single-column. Is there a glitch in the Matrix? ;) http://www.mail-archive.com/fossil-users@lists.fossil-scm.org/msg13955.html Good find! Once again, it is proven that i have the memory of a goldfish! -- - stephan beal http://wanderinghorse.net/home/stephan/ http://gplus.to/sgbeal Freedom is sloppy. But since tyranny's the only guaranteed byproduct of those who insist on a perfect world, freedom will have to do. -- Bigby Wolf ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] Proposed Fossil interface enhancement.
On Mon, 30 Dec 2013 22:25:58 +0100 Stephan Beal sgb...@googlemail.com wrote: It's apparently not detecting your browser as human... On Mon, 30 Dec 2013 16:28:17 -0500 Richard Hipp d...@sqlite.org wrote: This is a defense against spiders trying to index the entire repository, Oh, I'm aware, don't worry. I was specifically commenting on the statement: AFAIR, we have no (important/major) functionality which _requires_ JS in order to work. ... Which isn't strictly true in the default setup. Browsing a fossil repository with default settings with javascript disabled is not a great experience. I see how the original statement can be taken more than one way though. I'll shut up now. M ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] Proposed Fossil interface enhancement.
Thus said Stephan Beal on Mon, 30 Dec 2013 22:34:24 +0100: Good find! Once again, it is proven that i have the memory of a goldfish! Hence my suggestion on the other thread that we have some skins that actually represent these things. I too forget them and have to continually search the archives. One day I may forget which search terms I need to enter. :-) Perhaps a skin called: Default Single Column Files And another for the / at the end of directories listings: Default ls -F Style Andy -- TAI64 timestamp: 400052c1ea98 ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] password manager support
If ssh-agent can work it's probably the way to go. It seems to be the most standardized amongst all the popular pass-phrase managers, at least on non-[apple|microsoft] platforms. But, as far as I can tell it only stores decrypted private keys and not any pass phrases and I don't have the resources to investigate. I suppose it's not really feasible to support all the various password managers that exist. Why pick one over the other? The Windows Mac APIs look stable but not so much on Linux. There is kwallet, gnome-keyring, the gnome 3 keyring, and the gnome 2 fork called mate-keyring, and others. Unfortunately for me I use fossil most on Linux FreeBSD platforms where password manager support would the most difficult to maintain. If anyone is interested in a gnome-keyring or osx keychain patch I can supply it, otherwise I'm going to keep on keeping on. Thanks for the conversation! On Fri, Dec 27, 2013 at 4:45 PM, Ron Wilson ronw.m...@gmail.com wrote: On Fri, Dec 27, 2013 at 4:30 PM, Ron Wilson ronw.m...@gmail.com wrote: There is a platform independent tool that does this for SSH: SSH-Agent. In theory, it could store other credentials. It is open source, so the client API is readily available. One of the versions for OSX, SSHkeychain, integrates with Apple Keychain. I would be surprised if there are not versions that integrate with Gnome and/or KDE key rings. Interestingly, http://en.wikipedia.org/wiki/Ssh-agent claims that Gnome Keyring and KWallet also provide SSH-Agent services. I have not (yet) confirmed this. ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] C Best Practices
I'm a die-hard C junkey and it's done me well over the years. Most of my career has been writing C for embedded systems where the newest high-level language runtime just won't fit. I've written some fairly unconventional human-machine-interface web apps where the server side is written in C and it worked great. I love use fossil because it works everywhere and when it doesn't do what I want it to it's easy to change it. I think it's extreme portability is attributed to the fact that it's well designed and written in C. C's not the end-all but in my experience it's been quite effective, and long lived. http://en.wikipedia.org/wiki/C_(programming_language) On Mon, Dec 30, 2013 at 2:02 PM, Stephan Beal sgb...@googlemail.com wrote: On Mon, Dec 30, 2013 at 8:38 PM, Sean Woods s...@seanwoods.com wrote: I realize this might be a little off-topic for the fossil users list, and I apologize in advance for that. Call it my end-of-year indulgence. I think it's an advantage, though, because we might be able to get better viewpoints than those we so often find on the internet (particularly from Richard). i'll go ahead and voice some thoughts before this thread gets banned as being too OT ;). For those who use/prefer C, how do you make sure your applications are secure? Is there a concise, pragmatic summary of techniques for secure code? In my experience, if inputs and ranges are valid/validated, there's very little which can happen in terms of buffer-related security. A lot of historical security holes (arguably the majority) were caused by laziness (or poor assumptions) on someone's part. Security against, e.g., SQL injection is much more problematic nowadays, i think, and we (==Fossil devs) try to take care to use sqlite3's facilities for avoiding those (e.g. using bound parameters instead of direct SQL string creation, and using sqlite's %q/%Q format specifiers when bound parameters are not feasible/practical). What pitfalls do you encounter with C and how do you address these? It seems like the biggest issue is lack of standard data types. The lack of standard higher-order data types is certainly a big time sink for many apps, but OTOH it forces us to write case-specific solutions which are possibly a better fit for the task at hand (and possibly more efficient). That lack is a mixed blessing, IMO. i've learned to accept it. i came back to C after growing up in the STL-using C++ world. The STL is a _huge_ time saver, and compilers are good enough to optimize out some of the levels of perceived inefficiencies. (And it's a simple fact that the STL saves development time over hand-writing/testing custom data structures which do the same thing.) What advice would you give to someone who spent the last year getting comfortable with the C environment and wants to take advantage of all it has to offer? Oh, boy. As a matter of fact... a few years ago i posed myself a very similar question a while after i had gotten (back) into C, and i ended up writing: http://wanderinghorse.net/computing/papers/DoingOOInC.pdfhttp://wanderinghorse.net/computing/papers/#oo_c that's an article on how [i prefer] to model OO in C (because i'm not happy with most approaches i see in C code). Other than that, my advice would be to find projects which successfully deploy C and study them. sqlite is certainly the example which comes foremost to mind. In C anything is possible, which leaves the doors wide open as to what and how things get programmed, with no single right/wrong answer for the vast, vast majority of the programming problems out there. But you certainly knew that there would be no simple do this and this and this answer to your question ;). -- - stephan beal http://wanderinghorse.net/home/stephan/ http://gplus.to/sgbeal Freedom is sloppy. But since tyranny's the only guaranteed byproduct of those who insist on a perfect world, freedom will have to do. -- Bigby Wolf ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] C Best Practices
El Mon, 30 Dec 2013 14:38:55 -0500 Sean Woods s...@seanwoods.com escribió: I have been using C for many more projects over the past year. I enjoy writing projects in C because they are fast, reasonably portable (across unices), and have a small footprint. The coding style is natural to me and I enjoy having insight into some of the lower level details. I approach the language with caution, however, due to its pointy sharp edges. It seems that wherever I turn on the Internet, others decry the notion of using C for anything other than low-level systems programming. Creating a web app in C seems universally panned, and the Internet questions the sanity of all who attempt it. Fossil has carved out its own little niche in the face of this. My sense is that this list is rife with C aficionados, or at least people who see the advantages, and I thought it might be fun to discuss a few techniques we use to create secure, stable applications using this language. I realize this might be a little off-topic for the fossil users list, and I apologize in advance for that. Call it my end-of-year indulgence. I think it's an advantage, though, because we might be able to get better viewpoints than those we so often find on the internet (particularly from Richard). For those who use/prefer C, how do you make sure your applications are secure? Is there a concise, pragmatic summary of techniques for secure code? What pitfalls do you encounter with C and how do you address these? It seems like the biggest issue is lack of standard data types. What advice would you give to someone who spent the last year getting comfortable with the C environment and wants to take advantage of all it has to offer? ... When I put in a balanced plate the cost in time to develop an app and in the other plate the cost in use/deploy the app, always the first one wins. What I want to say is that developing an app in C may cost in time a bit more time, but when you have to use it, you need a lot less hardware, energy, refrigeration, mantenience etc... for the rest of the app life. We changed a java multiserver web app with a C one server only and amortized the develop in 2 months. Some advices: a) Don't reinvent the wheel, use already trusted developed libs. b) Don't use pointer arithmetic if you don't understand it. Learn first and try. c) Read the RFC 1925, it's the best of all RFC. It's not a joke. d) Don't use standard io old functions, some aren't secure. You can find a list on Internet. e) Don't use malloc and companions directly, use a function or an inline function for memory management. You can find examples how to do that in postgresql, sqlite, etc... f) Be clear on what the app must do and don't. Develop time is money g) All functions must return something, at least an error code. h) Think twice, organize and plan the develop before click any key i) Test your code, you don't need to be an expert on TDD to write tests, but it helps. j) Metric your code performance AFTER having a working project. You can create the metrics code while develop the tester code. If you need to develop a time limited project, you can use these already trusted libraries with BSD/MIT/X11/Public Domain (GPL FREE) a)app skeleton libevent http://libevent.org/ b)libbsd utilities http://libbsd.freedesktop.org/wiki/ c)scgi programming http://www.xamuel.com/scgilib/ d)database ;) http://www.sqlite.org e)security/crypto Botan (C++11) http://botan.randombit.net/ We are changing from 0MQ(GPL) to nanomsg(BSD) for distributed messaging, nanomsg is still on alpha state but works! I repeat, the c) point is not a joke. Thanks! HTH P.S. Remember to read the c) point! ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
