Below is the list of changes that have just been committed into a local
mysqldoc repository of paul. When paul does a push these changes will
be propagated to the main repository and, within 24 hours after the
push, to the public repository.
For information on how to access the public repository
see http://www.mysql.com/doc/I/n/Install...urce_tree.html

ChangeSet
1.2797 05/06/15 21:42:35 paul (AT) frost (DOT) snake.net +2 -0
Docs/internals.texi is dead.
Long live internals/internals.xml.

internals/internals.xml
1.2 05/06/15 21:42:33 paul (AT) frost (DOT) snake.net +35 -21
Update internals.xml with final conversion
from internals.texi.

Docs/internals-obsolete.xml
1.76 05/06/15 21:41:03 paul (AT) frost (DOT) snake.net +0 -0
Rename: Docs/internals.texi -> Docs/internals-obsolete.xml

# This is a BitKeeper patch. What follows are the unified diffs for the
# set of deltas contained in the patch. The rest of the patch, the part
# that BitKeeper cares about, is below these diffs.
# User: paul
# Host: frost.snake.net
# Root: /Volumes/frost2/MySQL/bk/mysqldoc

--- 1.1/internals/internals.xml 2005-05-06 22:15:23 -05:00
+++ 1.2/internals/internals.xml 2005-06-15 21:42:33 -05:00
@@ -2366,6 +2366,23 @@
</para></listitem>

<listitem><para>
+ If you have an 'if' statement that ends with a 'goto' or 'return'
+ you should NOT have an else statement:
+ </para>
+
+<programlisting>
+if (a == b)
+ return 5;
+else return 6;
+
+-&gt;
+
+if (a == b)
+ return 5;
+return 6;
+</programlisting></listitem>
+
+ <listitem><para>
Avoid default variable initializations. Use
<literal>LINT_INIT()</literal> if the compiler complains after
making sure that there is really no way the variable can be used
@@ -5202,25 +5219,23 @@
</para>

<para>
- This document was created when
- <ulink url="http://bugs.mysql.com/4457">Bug #4457</ulink> (Different
- results in SQL-Statements for the same record) was fixed at the end
- of August 2004. Until then there was some confusion in the
- double-to-string conversion at different places in the code.
+ This document was created when Bug #4457 (Different results in
+ SQL-Statements for the same record) was fixed at the end of August
+ 2004. Until then there was some confusion in the double-to-string
+ conversion at different places in the code.
</para>

<para>
- The bugfix for <ulink url="http://bugs.mysql.com/4937">Bug
- #4937</ulink> (<literal>INSERT + SELECT + UNION ALL + DATE to
- VARCHAR(8)</literal> conversion problem) produced a conversion
- function which was a promising approach to the conversion problems.
- Unfortunately it was only used for direct field conversions and not
- for function results etc. It did not take small numbers (absolute
- value less than 1) and negative numbers into account. It did not
- take the limited precision of <literal>float</literal> and
- <literal>double</literal> data types into account. The bugfix was
- developed in two steps: The first attempt looked like this (in
- principle):
+ The bugfix for Bug #4937 (<literal>INSERT + SELECT + UNION ALL +
+ DATE to VARCHAR(8)</literal> conversion problem) produced a
+ conversion function which was a promising approach to the conversion
+ problems. Unfortunately it was only used for direct field
+ conversions and not for function results etc. It did not take small
+ numbers (absolute value less than 1) and negative numbers into
+ account. It did not take the limited precision of
+ <literal>float</literal> and <literal>double</literal> data types
+ into account. The bugfix was developed in two steps: The first
+ attempt looked like this (in principle):
</para>

<programlisting>
@@ -5392,11 +5407,10 @@
conversions in one function, and to bring the knowledge about
<literal>float</literal> versus <literal>double</literal> to this
function wherever it is called. This solution managed to keep the
- test suite happy while solving the new problem of
- <ulink url="http://bugs.mysql.com/4457">Bug #4457</ulink>. Luckily,
- the first was not a big problem, as the test cases have been very
- carefully selected, so that they succeed as long as the machine uses
- IEEE 754 .
+ test suite happy while solving the new problem of Bug #4457.
+ Luckily, the first was not a big problem, as the test cases have
+ been very carefully selected, so that they succeed as long as the
+ machine uses IEEE 754 .
</para>

<para>

--
MySQL Internals Mailing List
For list archives: http://lists.mysql.com/internals
To unsubscribe: http://lists.mysql.com/internals?uns...ie.nctu.edu.tw