~ubuntu-branches/ubuntu/quantal/elinks/quantal

« back to all changes in this revision

Viewing changes to doc/html/hacking.html

  • Committer: Bazaar Package Importer
  • Author(s): Siegfried-Angel Gevatter Pujals (RainCT)
  • Date: 2008-02-01 16:29:06 UTC
  • mfrom: (1.1.3 upstream)
  • Revision ID: james.westby@ubuntu.com-20080201162906-xdourui5tyjva0al
Tags: 0.11.3-5ubuntu1
 
* Merge from Debian unstable (LP: #187936); remaining changes:
  - Add X-Ubuntu-Gettext-Domain to .desktop files.
  - debian/control: Maintainer field update.
* Improve the text in the .desktop file and add some translations.
 

Show diffs side-by-side

added added

removed removed

Lines of Context:
1
1
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.1//EN"
2
2
    "http://www.w3.org/TR/xhtml11/DTD/xhtml11.dtd">
3
 
<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en" >
 
3
<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en">
4
4
<head>
5
 
<meta http-equiv="Content-Type" content="text/html; charset=ISO-8859-1"/>
6
 
<meta name="generator" content="AsciiDoc 7.0.0"/>
 
5
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8" />
 
6
<meta name="generator" content="AsciiDoc 7.1.2" />
7
7
<style type="text/css">
8
8
/* Debug borders */
9
9
p, li, dt, dd, div, pre, h1, h2, h3, h4, h5, h6 {
16
16
  margin: 1em 5% 1em 5%;
17
17
}
18
18
 
19
 
a { color: blue; }
20
 
a:visited { color: fuchsia; }
 
19
a {
 
20
  color: blue;
 
21
  text-decoration: underline;
 
22
}
 
23
a:visited {
 
24
  color: fuchsia;
 
25
}
21
26
 
22
 
span.emphasis {
 
27
em {
23
28
  font-style: italic;
24
29
}
25
30
 
26
 
span.strong {
 
31
strong {
27
32
  font-weight: bold;
28
33
}
29
34
 
30
 
span.monospaced {
31
 
  font-family: monospace;
 
35
tt {
32
36
  color: navy;
33
37
}
34
38
 
113
117
}
114
118
 
115
119
/* Block element titles. */
116
 
div.title {
 
120
div.title, caption.title {
117
121
  font-family: sans-serif;
118
122
  font-weight: bold;
 
123
  text-align: left;
119
124
  margin-top: 1.0em;
120
125
  margin-bottom: 0.5em;
121
126
}
148
153
div.quoteblock > div.content {
149
154
  padding-left: 2.0em;
150
155
}
151
 
div.quoteblock .attribution {
 
156
 
 
157
div.attribution {
152
158
  text-align: right;
153
159
}
 
160
div.verseblock + div.attribution {
 
161
  text-align: left;
 
162
}
154
163
 
155
164
div.admonitionblock .icon {
156
165
  vertical-align: top;
199
208
}
200
209
 
201
210
div.tableblock > table {
202
 
  border-color: #527bbd;
203
 
  border-width: 3px;
 
211
  border: 3px solid #527bbd;
204
212
}
205
213
thead {
206
214
  font-family: sans-serif;
255
263
  padding-left: 0.5em;
256
264
}
257
265
</style>
 
266
<title>Hacking ELinks</title>
258
267
</head>
259
268
<body>
260
269
<div id="header">
 
270
<h1>Hacking ELinks</h1>
261
271
</div>
262
 
<h2>Hacking ELinks</h2>
 
272
<div id="preamble">
263
273
<div class="sectionbody">
264
274
<p>Welcome, mere mortal, to the realm of evil unindented code, heaps of one or
265
275
two-letter variables, seas of gotos accompanied with 30-letters labels in Czech
267
277
<p>Don't take this file as a law. We may or may not be right in these issues.</p>
268
278
<p>Motto: I didn't expect someone to look at the source, so it's unreadable.
269
279
       &#8212;Mikulas</p>
270
 
<h3>Language files</h3>
 
280
</div>
 
281
</div>
 
282
<h2>Language files</h2>
 
283
<div class="sectionbody">
271
284
<p>Each UI output should use language files in order to be able to translate the
272
285
messages to a desired language.  Those language files reside in the po/ subdir. If
273
286
you want to update a .po file, please read the gettext manual available at
274
287
&lt;http://www.gnu.org/manual/gettext&gt;. In order to actually use your updates on
275
288
your own system, you have to have the gettext tools installed.</p>
276
 
<h3>ELinks philosophy</h3>
 
289
</div>
 
290
<h2>ELinks philosophy</h2>
 
291
<div class="sectionbody">
277
292
<p>ELinks is based on the philosophy of asynchronism.  That means, you pass a
278
293
callback to each function, and when the requested task finishes sometime in the
279
294
unclear future, the callback will be called in order to notify you that you can
280
295
go on.</p>
281
296
<p>When you use multiple elinks instances at once, normally only one of them is a
282
 
<span class="emphasis">master</span>, and the rest of them are just kinda dumb terminals.  So if you want
283
 
to test some new feature, you have to start elinks with the <span class="emphasis">-no-connect</span>
 
297
<em>master</em>, and the rest of them are just kinda dumb terminals.  So if you want
 
298
to test some new feature, you have to start elinks with the <em>-no-connect</em>
284
299
parameter, otherwise it will just connect to an already running elinks and you
285
300
won't see your great new feature that you just added with such much pain.</p>
286
301
<p>There are two basic structures in ELinks.  Connection and session - their names
296
311
us a patch.</p>
297
312
<p>Various parts are described either below or in README* file(s) of appropriate
298
313
directory.</p>
299
 
<h3>HTML parser</h3>
 
314
</div>
 
315
<h2>HTML parser</h2>
 
316
<div class="sectionbody">
300
317
<p>The following was found in the mailing list archive - Mikulas wrote it:</p>
301
318
<p>The entry of the parser is parse_html.  This function gets an html source to
302
319
parse (pointers html and eof) and the functions it should call when it wants to
320
337
(in case of tables).  struct part has a pointer to struct f_data - a structure
321
338
that holds the actual formatted data.  If the pointer is NULL, rendering
322
339
functions only calculate size.</p>
323
 
<h3>Documents management</h3>
 
340
</div>
 
341
<h2>Documents management</h2>
 
342
<div class="sectionbody">
324
343
<p>Just a few words regarding the document structures. To understand the code, it
325
344
is important to note the difference between rendered documents and document
326
345
views.</p>
341
360
a certain view of the document, and the mapping to document is many to one.
342
361
Unlike document_view, though, its lifespan is much longer. When you chain
343
362
those view_states up, you get a session history.</p>
344
 
<h3>Lua support</h3>
 
363
</div>
 
364
<h2>Lua support</h2>
 
365
<div class="sectionbody">
345
366
<p>Peter Wang wrote this on the mailing list:</p>
346
367
<p>The parts of the Links-Lua and ELinks code that related to Lua are mostly
347
368
wrapped inside #ifdef HAVE_LUA &#8230;  #endif conditions, so they're easy to find.
353
374
<div class="listingblock">
354
375
<div class="title">Example: The code implementing the Go To URL dialog box hook :</div>
355
376
<div class="content">
356
 
<pre><span class="monospaced">void goto_url_with_hook(struct session *ses, unsigned char *url)
 
377
<pre><tt>void goto_url_with_hook(struct session *ses, unsigned char *url)
357
378
{
358
379
#ifndef HAVE_LUA
359
380
        goto_url(ses, url);
382
403
                alert_lua_error("goto_url_hook must return a string or nil");
383
404
        lua_pop(L, 1);
384
405
#endif
385
 
}</span></pre>
 
406
}</tt></pre>
386
407
</div></div>
387
408
<p>Quick description of what it does:</p>
388
409
<ol>
432
453
<p>The code to allow binding Lua code to a keypress is slightly different then the
433
454
hooks, but not much.  Instead of branching off to some C code when a key is
434
455
pressed, we branch off to some Lua code.</p>
435
 
<h3>Coding style</h3>
436
 
<p>Mikulas once said that <span class="emphasis">it was hard to code, so it should be hard to read</span> -
 
456
</div>
 
457
<h2>Coding style</h2>
 
458
<div class="sectionbody">
 
459
<p>Mikulas once said that <em>it was hard to code, so it should be hard to read</em> -
437
460
and he drove by this when he was writing links.  However, we do NOT drive by
438
461
this rule anymore ;-).  We strongly welcome cleanup patches and you have 99%
439
462
chance that they will be applied, if they are correct.</p>
440
 
<p>Variable names should be descriptive.  Well, in worst case we'll accept <span class="emphasis">i</span> for
 
463
<p>Variable names should be descriptive.  Well, in worst case we'll accept <em>i</em> for
441
464
index, but if possible don't do even this :).  You should try to declare them
442
465
on the lowest level possible, so their declaration and initialization will be
443
466
near their usage and you will also prevent reuse of one variable for two
445
468
reasonable, initialize variables during their declaration and don't group too
446
469
many variables in one line.  ALWAYS make a blank line after the declaration
447
470
part.</p>
448
 
<p>Be sure to prefix all local functions with <span class="emphasis">static</span>.</p>
 
471
<p>Be sure to prefix all local functions with <em>static</em>.</p>
449
472
<p>Indent shift width is 8 characters&#8212;that means one tab character.</p>
450
 
<p><span class="emphasis">{</span> should be on the same line as conditions near for, if, while, switch etc.,
 
473
<p><em>{</em> should be on the same line as conditions near for, if, while, switch etc.,
451
474
but on separate lines near function headers in function definitions.</p>
452
475
<p>Please _USE_ one tab instead of 8 spaces!  It makes things easier.</p>
453
 
<p>Always place spaces around <span class="emphasis">=</span>, after <span class="emphasis">,</span> and - if reasonable - around other
 
476
<p>Always place spaces around <em>=</em>, after <em>,</em> and - if reasonable - around other
454
477
operators as well.  You shouldn't make assignments in conditionals:</p>
455
478
<div class="listingblock">
456
479
<div class="title">Example: Use:</div>
457
480
<div class="content">
458
 
<pre><span class="monospaced">foo = mem_alloc(1234);
459
 
if (!foo) panic("out of memory");</span></pre>
 
481
<pre><tt>foo = mem_alloc(1234);
 
482
if (!foo) panic("out of memory");</tt></pre>
460
483
</div></div>
461
484
<div class="listingblock">
462
485
<div class="title">Example: Instead of:</div>
463
486
<div class="content">
464
 
<pre><span class="monospaced">if (!(foo = mem_alloc(1234))) panic("out of memory");</span></pre>
 
487
<pre><tt>if (!(foo = mem_alloc(1234))) panic("out of memory");</tt></pre>
465
488
</div></div>
466
489
<p>Note that thou shalt ALWAYS test for success on everything - we are supposed
467
490
to die with honor if we are to die!</p>
471
494
weird and ancient systems and we are already used to C89 anyway. The most
472
495
remarkable implication of no C99 are no C++ (//) comments and declarations
473
496
at the start of block only.</p>
474
 
<h3>Comments</h3>
475
 
<p>Use blank lines frequently to separate chunks of code.  And use magic <span class="monospaced">/*</span> and
476
 
<span class="monospaced">*/</span> to give others an idea about what it does and about possible pitfalls.
 
497
</div>
 
498
<h2>Comments</h2>
 
499
<div class="sectionbody">
 
500
<p>Use blank lines frequently to separate chunks of code.  And use magic <tt>/*</tt> and
 
501
<tt>*/</tt> to give others an idea about what it does and about possible pitfalls.
477
502
(Do not use //, as that is not a feature of ANSI C a.k.a. C89.)</p>
478
503
<p>Keep in mind that if there's an object and verb in the comment (and it is, in
479
504
most cases), it is a sentence, so it has to start with a capital letter and end
481
506
should sign yourself; e.g.,</p>
482
507
<div class="literalblock">
483
508
<div class="content">
484
 
<pre><span class="monospaced">/* TODO: Move this far away! --pasky */</span></pre>
 
509
<pre><tt>/* TODO: Move this far away! --pasky */</tt></pre>
485
510
</div></div>
486
511
<p>Comments should be written in _ENGLISH_ only.</p>
487
512
<p>All three following styles of comments are acceptable:</p>
488
513
<div class="listingblock">
489
514
<div class="content">
490
 
<pre><span class="monospaced">/*
 
515
<pre><tt>/*
491
516
 * Bla bla bla.
492
517
 * blabla?
493
518
 */
497
522
 */
498
523
 
499
524
/* Bla bla bla.
500
 
 * blabla? */</span></pre>
 
525
 * blabla? */</tt></pre>
501
526
</div></div>
502
527
<p>The best one usually depends on the actual context.</p>
503
528
<p>If you describe a structure, make either:</p>
504
529
<div class="listingblock">
505
530
<div class="content">
506
 
<pre><span class="monospaced">char *name; /* name of the tag */
 
531
<pre><tt>char *name; /* name of the tag */
507
532
void (*func)(unsigned char *); /* function hopefully handling the
508
533
                                * content of the tag */
509
 
int linebreak; /* needed for break of a line? */</span></pre>
 
534
int linebreak; /* needed for break of a line? */</tt></pre>
510
535
</div></div>
511
536
<p>or</p>
512
537
<div class="listingblock">
513
538
<div class="content">
514
 
<pre><span class="monospaced">/* Name of the tag */
 
539
<pre><tt>/* Name of the tag */
515
540
char *name;
516
541
/* Function hopefully handling the content of the tag */
517
542
void (*func)(unsigned char *);
518
543
 
519
544
/* Do we need to break a line? */
520
 
int linebreak;</span></pre>
 
545
int linebreak;</tt></pre>
521
546
</div></div>
522
547
<p>Same if you comment the code.  If the comment is</p>
523
548
<div class="literalblock">
524
549
<div class="content">
525
 
<pre><span class="monospaced">/* then do it now! */</span></pre>
 
550
<pre><tt>/* then do it now! */</tt></pre>
526
551
</div></div>
527
552
<p>place it on the same line as the command, if it's</p>
528
553
<div class="literalblock">
529
554
<div class="content">
530
 
<pre><span class="monospaced">/* We have to parse this crap now, as it is going to be freed in free_crap() */</span></pre>
 
555
<pre><tt>/* We have to parse this crap now, as it is going to be freed in free_crap() */</tt></pre>
531
556
</div></div>
532
557
<p>place it on the preceding line.</p>
533
 
<h3>More about style</h3>
 
558
</div>
 
559
<h2>More about style</h2>
 
560
<div class="sectionbody">
534
561
<p>Note: We use short variables names and stupid examples here, do not take that
535
562
      as a guideline for _REAL_ coding.  Always use descriptive variables
536
563
      names and do not write stupid code ;).</p>
537
 
<h4>General style is:</h4>
 
564
<h3>General style is:</h3>
538
565
<div class="listingblock">
539
566
<div class="content">
540
 
<pre><span class="monospaced">[blank line]
 
567
<pre><tt>[blank line]
541
568
/* This is a comment about that function */
542
569
int
543
570
func(int a, int b)
556
583
        }
557
584
 
558
585
        return (c * d);
559
 
}</span></pre>
 
586
}</tt></pre>
560
587
</div></div>
561
 
<h4>You should observe the following rules:</h4>
 
588
<h3>You should observe the following rules:</h3>
562
589
<p>Always have a blank line before a function declaration or comment.</p>
563
590
<p>Please add a comment about what the function does.</p>
564
591
<p>A function's type must be on first line while the function's name is on the
569
596
<div class="listingblock">
570
597
<div class="title">Example: Use:</div>
571
598
<div class="content">
572
 
<pre><span class="monospaced">int
 
599
<pre><tt>int
573
600
func(int p1, int p2, int p3,
574
601
     struct very_long_name_for_a_structure *s,
575
602
     unsigned long last_parameter)
577
604
        int v;
578
605
 
579
606
        ...
580
 
}</span></pre>
 
607
}</tt></pre>
581
608
</div></div>
582
609
<p>The start of a function's body should be alone on the first column.</p>
583
610
<p>Always have a blank line after declarations.</p>
585
612
<div class="listingblock">
586
613
<div class="title">Example: Use:</div>
587
614
<div class="content">
588
 
<pre><span class="monospaced">c = a * b - (a + b);</span></pre>
 
615
<pre><tt>c = a * b - (a + b);</tt></pre>
589
616
</div></div>
590
617
<div class="listingblock">
591
618
<div class="title">Example: Instead of:</div>
592
619
<div class="content">
593
 
<pre><span class="monospaced">c=a*b-(a+b);</span></pre>
 
620
<pre><tt>c=a*b-(a+b);</tt></pre>
594
621
</div></div>
595
622
<ul>
596
623
<li>
602
629
<div class="listingblock">
603
630
<div class="title">Example: Use:</div>
604
631
<div class="content">
605
 
<pre><span class="monospaced">c = a;
606
 
if (c == b) {...</span></pre>
 
632
<pre><tt>c = a;
 
633
if (c == b) {...</tt></pre>
607
634
</div></div>
608
635
<div class="listingblock">
609
636
<div class="title">Example: Instead of:</div>
610
637
<div class="content">
611
 
<pre><span class="monospaced">if ((c = a) == b) {...</span></pre>
 
638
<pre><tt>if ((c = a) == b) {...</tt></pre>
612
639
</div></div>
613
640
<p>Never use spaces within ().</p>
614
641
<div class="listingblock">
615
642
<div class="title">Example: Use:</div>
616
643
<div class="content">
617
 
<pre><span class="monospaced">if (a) ...</span></pre>
 
644
<pre><tt>if (a) ...</tt></pre>
618
645
</div></div>
619
646
<div class="listingblock">
620
647
<div class="title">Example: Instead of:</div>
621
648
<div class="content">
622
 
<pre><span class="monospaced">if ( a ) ...</span></pre>
 
649
<pre><tt>if ( a ) ...</tt></pre>
623
650
</div></div>
624
651
<p>Indent.</p>
625
652
<div class="listingblock">
626
653
<div class="title">Example: Use:</div>
627
654
<div class="content">
628
 
<pre><span class="monospaced">foreach (a, b)
 
655
<pre><tt>foreach (a, b)
629
656
        if (a == c)
630
657
                ...
631
658
        else
632
 
                ...</span></pre>
 
659
                ...</tt></pre>
633
660
</div></div>
634
661
<div class="listingblock">
635
662
<div class="title">Example: Instead of:</div>
636
663
<div class="content">
637
 
<pre><span class="monospaced">foreach(a, b) if (a == c) ...  else ...</span></pre>
 
664
<pre><tt>foreach(a, b) if (a == c) ...  else ...</tt></pre>
638
665
</div></div>
639
666
<p>If you have a chain of if () { .. } else if () { .. } else { .. } with longer
640
667
statements, you can insert a blank line before each else line.</p>
641
 
<p>Label names should start on the first column and with have a blank line before
642
 
it.</p>
 
668
<p>Label names should start on the first column and a blank line should be
 
669
inserted before it.</p>
643
670
<div class="listingblock">
644
671
<div class="title">Example: Use:</div>
645
672
<div class="content">
646
 
<pre><span class="monospaced">        some_code(aaa);
 
673
<pre><tt>        some_code(aaa);
647
674
 
648
675
label:
649
 
        some_other_code(bbb);</span></pre>
 
676
        some_other_code(bbb);</tt></pre>
650
677
</div></div>
651
678
<div class="listingblock">
652
679
<div class="title">Example: Instead of:</div>
653
680
<div class="content">
654
 
<pre><span class="monospaced">        some_code(aaa);
 
681
<pre><tt>        some_code(aaa);
655
682
        label:
656
 
        some_other_code(bbb);</span></pre>
 
683
        some_other_code(bbb);</tt></pre>
657
684
</div></div>
658
685
<p>Wrap conditions on spaces before operators like &amp;&amp; or ||.</p>
659
686
<div class="listingblock">
660
687
<div class="title">Example: Use:</div>
661
688
<div class="content">
662
 
<pre><span class="monospaced">if (some_very_long_thing1 == some_very_long_thing2
 
689
<pre><tt>if (some_very_long_thing1 == some_very_long_thing2
663
690
    &amp;&amp; (test1 == test2
664
691
        || some_very_long_thing3 == some_very_long_thing4)) {
665
692
        ....
666
 
}</span></pre>
 
693
}</tt></pre>
667
694
</div></div>
668
695
<p>Please remove useless spaces or tabs at the end of lines.  Vim has a syntax
669
696
file called "Whitespace (add)" &#8230;</p>
674
701
<div class="listingblock">
675
702
<div class="title">Example: Use:</div>
676
703
<div class="content">
677
 
<pre><span class="monospaced">int
 
704
<pre><tt>int
678
705
func(void)
679
706
{
680
707
        some_code();
681
 
}</span></pre>
 
708
}</tt></pre>
682
709
</div></div>
683
710
<div class="listingblock">
684
711
<div class="title">Example: Instead of:</div>
685
712
<div class="content">
686
 
<pre><span class="monospaced">int
 
713
<pre><tt>int
687
714
func()
688
715
{
689
716
        some_code();
690
 
}</span></pre>
 
717
}</tt></pre>
691
718
</div></div>
692
719
<p>Please write if (), while (), switch (), for (), &#8230;. instead of if(),
693
720
while(), switch(), for()&#8230;  Same thing apply for all iterators and tests
694
721
(e.g. foreach, foreachback).</p>
695
722
<p>Please write sizeof(something) instead of sizeof something.</p>
696
723
<p>Use assert() and assertm() where applicable. It will prevent hidden bugs.</p>
 
724
<p>Names of enum constants should be in upper case.</p>
 
725
<p>Please call the charset "utf8" or "UTF8" in identifiers, "UTF-8"
 
726
elsewhere, and "utf_8" only for compatibility.</p>
697
727
<p>If you see code in ELinks that doesn't follow these rules, fix it or tell us
698
728
about it.</p>
699
729
<p>All the .c files MUST start by a short one-line description:</p>
700
730
<div class="literalblock">
701
731
<div class="content">
702
 
<pre><span class="monospaced">/* &lt;short one-line description&gt; */</span></pre>
 
732
<pre><tt>/* &lt;short one-line description&gt; */</tt></pre>
703
733
</div></div>
704
 
<p>All the .h files MUST start by a CVS Id tag and then anti-reinclusion ifdef.
 
734
<p>All the .h files MUST start by an anti-reinclusion ifdef.
705
735
The macro is</p>
706
736
<div class="literalblock">
707
737
<div class="content">
708
 
<pre><span class="monospaced">EL_&lt;path_relative_to_src:s/[\/.]/_/&gt;.</span></pre>
 
738
<pre><tt>EL_&lt;path_relative_to_src:s/[\/.]/_/&gt;.</tt></pre>
709
739
</div></div>
710
740
<p>There are obviously exceptions to these rules, but don't make a rule from your
711
741
exception and be prepared to defend your exception at anytime ;).</p>
712
 
<h3>Coding practices</h3>
713
 
<h4>Use bitfields to store boolean values</h4>
 
742
</div>
 
743
<h2>Coding practices</h2>
 
744
<div class="sectionbody">
 
745
<h3>Use bitfields to store boolean values</h3>
714
746
<p>If speed is not critical and especially if you are messing with some struct
715
747
where size might matter, feel encouraged to use bitfields to store boolean (or
716
748
tristate or tetrastate ;) values (e.g. unsigned int foo:1 for one-bit field).
717
749
HOWEVER please ALWAYS specify signedness of all such fields. It is very easy
718
750
to reach the top bit in these cases, and with int foo:1, foo would be either 0
719
751
or -1, which is probably not what you want.</p>
720
 
<h4>Wrap hard initializations of structures with macros</h4>
 
752
<h3>Wrap hard initializations of structures with macros</h3>
721
753
<p>This should be done if the structure's initializers are going to be spread
722
754
widely (so that we can grep for them easily), there are massive typecasts
723
755
needed in most of the initializers, you feel that order of the fields in
726
758
<div class="listingblock">
727
759
<div class="title">Example: You can do it like:</div>
728
760
<div class="content">
729
 
<pre><span class="monospaced">struct example {
 
761
<pre><tt>struct example {
730
762
        int a;
731
763
        int b;
732
764
        char *c;
740
772
        NULL_EXAMPLE
741
773
};
742
774
 
743
 
struct example t = NULL_EXAMPLE;</span></pre>
 
775
struct example t = NULL_EXAMPLE;</tt></pre>
744
776
</div></div>
745
 
<h4>Please try to keep order of fields</h4>
 
777
<h3>Please try to keep order of fields</h3>
746
778
<p>Please try to keep order of fields from max. to min. of size of each type of
747
779
fields, especially in structures:</p>
748
780
<div class="listingblock">
749
781
<div class="title">Example: Use:</div>
750
782
<div class="content">
751
 
<pre><span class="monospaced">long a;
 
783
<pre><tt>long a;
752
784
int b;
753
 
char c;</span></pre>
 
785
char c;</tt></pre>
754
786
</div></div>
755
787
<div class="listingblock">
756
788
<div class="title">Example: Instead of:</div>
757
789
<div class="content">
758
 
<pre><span class="monospaced">char c;
 
790
<pre><tt>char c;
759
791
int b;
760
 
long b;</span></pre>
 
792
long b;</tt></pre>
761
793
</div></div>
762
794
<p>It will help to reduce memory padding on some architectures. Note that this
763
795
applies only if this will not affect logical division of the structure. The
764
796
logical composition always takes precedence over this optimization, modulo
765
797
some very rare critical structures.</p>
766
 
<h4>Please do not use sizeof(struct item_struct_name)</h4>
 
798
<h3>Please do not use sizeof(struct item_struct_name)</h3>
767
799
<p>Instead use sizeof(*item) when possible.</p>
768
800
<div class="listingblock">
769
801
<div class="content">
770
 
<pre><span class="monospaced">struct example {
 
802
<pre><tt>struct example {
771
803
        int *integers;
772
804
        void **pointers;
773
805
}
774
806
 
775
 
struct example *item;</span></pre>
 
807
struct example *item;</tt></pre>
776
808
</div></div>
777
809
<div class="listingblock">
778
810
<div class="title">Example: Use:</div>
779
811
<div class="content">
780
 
<pre><span class="monospaced">item = mem_alloc(sizeof(*item));
 
812
<pre><tt>item = mem_alloc(sizeof(*item));
781
813
memset(item, 0, sizeof(*item));
782
814
item-&gt;integers = mem_calloc(10, sizeof(*item-&gt;integers));
783
 
item-&gt;pointers = mem_calloc(10, sizeof(*item-&gt;pointers));</span></pre>
 
815
item-&gt;pointers = mem_calloc(10, sizeof(*item-&gt;pointers));</tt></pre>
784
816
</div></div>
785
817
<div class="listingblock">
786
818
<div class="title">Example: Instead of:</div>
787
819
<div class="content">
788
 
<pre><span class="monospaced">item = mem_alloc(sizeof(struct example));
 
820
<pre><tt>item = mem_alloc(sizeof(struct example));
789
821
memset(item, 0, sizeof(struct example));
790
822
item-&gt;integers = mem_calloc(10, sizeof(int));
791
 
item-&gt;pointers = mem_calloc(10, sizeof(void *));</span></pre>
 
823
item-&gt;pointers = mem_calloc(10, sizeof(void *));</tt></pre>
792
824
</div></div>
793
825
<p>The preferred form eases future changes in types, and maintain size vs type
794
826
coherence.</p>
795
 
<h4>Please postfix defined types with _T</h4>
 
827
<h3>Please postfix defined types with _T</h3>
796
828
<div class="listingblock">
797
829
<div class="content">
798
 
<pre><span class="monospaced">typedef int (some_func_T)(void *);
799
 
typedef long long our_long_T;</span></pre>
 
830
<pre><tt>typedef int (some_func_T)(void *);
 
831
typedef long long our_long_T;</tt></pre>
800
832
</div></div>
801
 
<h4>Please use mode_t and S_I???? macros instead of numeric modes</h4>
 
833
<h3>Please use mode_t and S_I???? macros instead of numeric modes</h3>
802
834
<div class="listingblock">
803
835
<div class="title">Example: Use:</div>
804
836
<div class="content">
805
 
<pre><span class="monospaced">mode_t mode = S_IRWXU | S_IRGRP | S_IROTH;</span></pre>
 
837
<pre><tt>mode_t mode = S_IRWXU | S_IRGRP | S_IROTH;</tt></pre>
806
838
</div></div>
807
839
<div class="listingblock">
808
840
<div class="title">Example: Instead of:</div>
809
841
<div class="content">
810
 
<pre><span class="monospaced">int mode = 0744;</span></pre>
 
842
<pre><tt>int mode = 0744;</tt></pre>
811
843
</div></div>
812
844
<p>Note that S_IREAD, S_IWRITE and S_IEXEC are obsolete, you should use S_IRUSR,
813
845
S_IWUSR, S_IXUSR instead.</p>
814
 
<h3>Patches</h3>
 
846
</div>
 
847
<h2>Patches</h2>
 
848
<div class="sectionbody">
815
849
<p>Please send unified patches only.</p>
816
850
<div class="listingblock">
817
851
<div class="title">Example: The recommended way is:</div>
818
852
<div class="content">
819
 
<pre><span class="monospaced">cp -a elinks/ elinks+mysuperfeature/
 
853
<pre><tt>cp -a elinks/ elinks+mysuperfeature/
820
854
cd elinks+mysuperfeature/
821
855
*clap clap*
822
856
*clickety clickey*
824
858
./elinks -no-connect
825
859
*goto clap*
826
860
cd ..
827
 
diff -ru elinks/ elinks+mysuperfeature/ &gt;elinks-mysuperfeature.patch</span></pre>
 
861
diff -ru elinks/ elinks+mysuperfeature/ &gt;elinks-mysuperfeature.patch</tt></pre>
828
862
</div></div>
829
863
<p>Please manually remove any bloat like changes in ./configure, whitespace
830
864
changes etc. ;-).</p>
831
 
<p>We also accept output from <span class="monospaced">cvs diff -u</span> :).  The statement about bloat
 
865
<p>We also accept output from <tt>cvs diff -u</tt> :).  The statement about bloat
832
866
removing above still applies.</p>
833
867
<p>Big patches are hard to review so if your feature involves a lot of changes
834
868
please consider splitting it in appropriate bits. Appropriate could mean:</p>
848
882
important thing is to separate big changes to smaller ones and smaller ones,
849
883
breaking it to the "thinnest" possible level where the change is still
850
884
sufficiently self-contained.</p>
851
 
<h3>Advantages of <span class="monospaced">&#8212;enable-debug</span> configure option</h3>
 
885
</div>
 
886
<h2>Advantages of <tt>&#8212;enable-debug</tt> configure option</h2>
 
887
<div class="sectionbody">
852
888
<p>Since ELinks 0.4pre11, a memory debugger can be enabled using the
853
 
<span class="monospaced">&#8212;enable-debug</span> configure script option.  It may help to find memleaks and more
 
889
<tt>&#8212;enable-debug</tt> configure script option.  It may help to find memleaks and more
854
890
which is why everybody concerned with ELinks develepment should use it:</p>
855
 
<p>In 0.5 versions <span class="monospaced">&#8212;enable-debug</span> add some fancy things:
856
 
- many data integrity checking (see <span class="monospaced">lists.h</span>)
 
891
<p>In 0.5 versions <tt>&#8212;enable-debug</tt> add some fancy things:
 
892
- many data integrity checking (see <tt>lists.h</tt>)
857
893
- hotkey debugging: especially cool for translators, it highlights redundant
858
 
  hotkeys in a menu.
 
894
  hotkeys in a menu.  (See also po/perl/README.)
859
895
- more errors messages
860
896
- low bug tolerance: it will core dump on some errors instead of just writing
861
897
  an error description.
862
898
- internal backtrace feature (always enabled if possible)
863
899
- and more&#8230;</p>
864
900
<p>Before sending a patch, always try to compile and test it with
865
 
<span class="monospaced">&#8212;enable-debug</span>, then in normal mode, then in <span class="monospaced">&#8212;fast-mem</span> mode. If it fails
 
901
<tt>&#8212;enable-debug</tt>, then in normal mode, then in <tt>&#8212;fast-mem</tt> mode. If it fails
866
902
to compile or execute in one of these modes, then rework it.</p>
867
903
<p>Happy hacking!</p>
868
904
</div>
869
905
<div id="footer">
870
906
<div id="footer-text">
871
 
Last updated 25-Jan-2006 04:49:54 CEST
 
907
Last updated 14-Apr-2007 12:33:17 EEST
872
908
</div>
873
909
</div>
874
910
</body>