- Dillo-dev - lists.mailman3.com

[Dillo-dev]short absence...

by Jorge Arellano Cid

Hi there, I'm leaving town for a few days. I'll be back on Thursday. Cheers Jorge.-

July 26, 2004

[Dillo-dev]Re: any documents about html parser?

by Calvin Yu

yes, I'm going to make dillo able to render chinese. Furthermore, I wish I can add support for JavaScript for dillo. So I must analyse the code of html parser. Am I right? By the way, what do you think of porting GUI to gtk+-directfb? Then we don't need X Windows any longer. I'm a newbie in browser. Please tell me whether what I think is right or not. Thank you very much!

July 26, 2004

Re: [Dillo-dev]HTTPS Cleanup

by Garrett Kajmowicz

On July 23, 2004 07:33 pm, Jorge Arellano Cid wrote: > On Fri, Jul 23, 2004 at 01:10:42PM -0400, Garrett Kajmowicz wrote: > > [...] > > I would also like your opinion on how to "clean up" the function > > save_certificate_home() > > It has three exit points, and dropping it to fewer would be somewhat of a > > challenge to do cleanly. > > Done. > > I also added some comments, and put the snprintf's in one line. > > BTW, why 01777 instead of 01700? The flags setting are automatically bitwize-anded with the umask. My thinking at the time was that it would be better to have the user settings determine how the certificates would be saved. And since the only thing that certificate access might give people is an extremely small list of sites the user had been to, I didn't deem it a security risk. If you prefer I change it, I will do so.... - Garrett Kajmowicz

July 24, 2004

Re: [Dillo-dev]HTTPS Cleanup

by Jorge Arellano Cid

On Fri, Jul 23, 2004 at 01:10:42PM -0400, Garrett Kajmowicz wrote: > [...] > I would also like your opinion on how to "clean up" the function > save_certificate_home() > It has three exit points, and dropping it to fewer would be somewhat of a > challenge to do cleanly. Done. I also added some comments, and put the snprintf's in one line. BTW, why 01777 instead of 01700? Cheers Jorge.-

July 23, 2004

[Dillo-dev]Your attention please: we have a webmaster!

by Jorge Arellano Cid

Hi there, Yes it's true, now we have a dedicated webmaster. Jörgen Viksell (or Jorgen if the umlaut doesn't display) has accepted these duties, so now you'll see our old site starts to renew. For instance now we have a FAQ link (a work in progress). Please contact him for site-related suggestions/fixes/etc. He's in charge now. Cheers Jorge.- PS: Jörgen: please don't forget the webmaster link. (you can use an image or the same mangling as in the bugtrack for the email address). PS2: Garret: I added your suggestion to the NC_Design.

July 23, 2004

Re: [Dillo-dev]HTTPS Cleanup

by Jorge Arellano Cid

On Fri, Jul 23, 2004 at 01:10:42PM -0400, Garrett Kajmowicz wrote: > I have gone through and modified the https.c file to use (what I believe are) > your preferred coding standards, with one exception. Done. (i.e. commited). > I *cannot* stand unbraced if statements (or any other statements), and thus I > braced them in two locations. I also don't care for use of the tertiary > operator, but you wrote the function it is used in, so I don't plan on > touching it. No problem. Always-braced if statements probably is a better practice! > > I would also like your opinion on how to "clean up" the function > save_certificate_home() > It has three exit points, and dropping it to fewer would be somewhat of a > challenge to do cleanly. OK, I'll look at it. > There are a few loctions where I believe you broke a statement which would ift > on one line, specifically snprintf statements. I might have dont this > (though I can't think of why). If this is the case, could you let me know > your reasoning behind this? I'd like to learn from this if possible... Those statements were originally in your patch! :-) <q> [...] + /*Attempt to create .dillo/certs blindly - check later*/ + snprintf(buf,4096,"%s/.dillo/", + g_get_home_dir() + ); + mkdir(buf, 01777); + snprintf(buf,4096,"%s/.dillo/certs/", + g_get_home_dir() + ); + mkdir(buf, 01777); + + do{ + snprintf(buf,4096,"%s/.dillo/certs/%x.%u\0", + g_get_home_dir(), + X509_subject_name_hash(cert), i + ); [...] </q> You can make them one line. --- BTW, g_free() tests for NULL so this statements: if (http_query != NULL){ g_free(http_query); http_query = NULL; } can simply become: g_free(http_query); because the variable is local, there's no need to NULL it. Except for 'root_url' which can also be made local. Finally, please send the patches to me directly (not to the list), but comments belong to the list. This saves some band width to hundreds of subscribers. Thanks for taking my advice. It'so much easier to review the patches now. Cheers Jorge.-

July 23, 2004

[Dillo-dev]HTTPS Cleanup

by Garrett Kajmowicz

I have gone through and modified the https.c file to use (what I believe are) your preferred coding standards, with one exception. I *cannot* stand unbraced if statements (or any other statements), and thus I braced them in two locations. I also don't care for use of the tertiary operator, but you wrote the function it is used in, so I don't plan on touching it. I would also like your opinion on how to "clean up" the function save_certificate_home() It has three exit points, and dropping it to fewer would be somewhat of a challenge to do cleanly. There are a few loctions where I believe you broke a statement which would ift on one line, specifically snprintf statements. I might have dont this (though I can't think of why). If this is the case, could you let me know your reasoning behind this? I'd like to learn from this if possible... - Garrett Kajmowicz

July 23, 2004

Re: [Dillo-dev]HTTPS certificate support

by Garrett Kajmowicz

> Producing code quick is not the goal. The point is to produce > well designed code that works OK, and that's easy to > read/review/follow and thus to maintain. I'm spending a lot of time on this because I've been working on a project for several months to revamp some PCs with 32MB of RAM to be sent to the homes of deaf people. I'm running a uClibc based distribution, but I need a good web browser which works. Thus I want to get this done as soon as possible. > The problem I found (and probably your classmates) is that > reviewing rushed-code takes more time than necessary, and once > understood, it changes. In my case is a bit worst because I took > the extra time to polish it, only to find it back with my work > wasted. I crank out a lot of code because I think quickly and clearly, and have no life. If I could comit often enough, I could gurantee you about 4 hours/day solid development for the next month and a half. More if I dropped another pet programming project and some metal work I am doing. I am usually the person doing the code reviews. I'm also the person who tends to put the most documentation into my code to make the most redably readable. > Let me suggest you a second stage after your code is working. > Stop, and take the same amount of time polishing it. Think of the > design, long functions, multiple exit points, global variables, > data structures, future additions, variable names, memory > management, comments, etc. > > Once you finish this second stage, testing for robustness will > be much easier (third stage). Once you've done it, your > classmates will love your code. Most of my classmates can't program *snort*. Then again, neither can the comp sci professors..... > Just an example, multiple exit points make code more complex to > grasp because you have to understand the flow of execution of > each one of the exits, before having confidence of not breaking > it with some changes. I would disagree with that point. With single exit point functions, you have to carry a variable (extra stack allocation) through the application and all code. Thus you can either have large numbers of nested statements (which is very effective and reasonably clean, but excedes line length) or you have your finalized variable being carried through the rest of the application with nothing else to do. With the multi-exit point strategy, you can exit the application as soon as you are done done whatever it is that you need to do. This way you aren't hanging around in the code any more. I have found that tends to make for better code than single-exit writing. > > Another big problem comes with finalization code (freeing > memory, leaving variables in a stable state, return codes, side > effects...). > > Take for instance yes_ssl_support(). Look at the many exit > points and its finalization code, and compare with a single exit > code version. > > It took a lot of time. > > Please follow my advice. Since this is the preffered coding standard (I suggest adding it to the coding standards on the web) I will follow it as you wish. I will follow any coding standards to the letter, and will take suggestions as I see fit. I will modify everything that I have writen to conform to your preferences, and resubmit. I'm tempted to blow away all of my work and start over sust so I can have a sync'd tree to make sane diffs against. *sigh* - Garrett

July 23, 2004

Re: [Dillo-dev]HTTPS certificate support

by Garrett Kajmowicz

I accepted nearly all of the changes you requested. In recards to switch statements, in the updated function there is a need to deal with 3 possabilities, thus I kept the switch statement. The rest of the locations I converted to braced if statements which use else statements to return an abort code as the alternative option. Though computer science dictates that there should be only one entry and one exit point from a function, using break calls not only hurts my eyes, it produces code which is less readable. Thus all locations where a function might exit for one purpose I have the code to exit for all purposes, with a catch-all return -1 at the function. Personal preference. Once again, please evaluate. - Garrett Kajmowicz

July 22, 2004

Re: [Dillo-dev]HTTPS certificate support

by Garrett Kajmowicz

> > ## Why do we need these functions back again commented out? I originally wrote them to parse the response number from the displayed dialog. When I submitted my post, you wrote a new function in https, thus the old one was no longer needed and I commented it out, as that is what I presumed you wanted to do. If you prefer it, please continue to use it. > > ## This can be avoided with g_get_home_dir(). I spent quite a few minutes looking for such a function, but I guess I just missed it in the API reference. With the function name, I know what I am looking for and will rewrite immediately. I'm going to redo this whole thing and resubmit. Part of my problem is trying to maintain multiple versions, working after I submit one patch but before it is applied. My school mates hate me for it - I crank out code like a mad man! - Garrett Kajmowicz

July 22, 2004