[#8478] resolv.rb -- doc patch. — Hugh Sasse <hgs@...>
This is an attempt to get the RD format docs for resolv.rb into
[#8484] strptime fails to properly parse certain inputs — <noreply@...>
Bugs item #5263, was opened at 2006-08-01 23:14
Hi,
Hi,
nobu@ruby-lang.org wrote:
Why bother other languages? They are on their own. We should not
[#8497] Ruby Socket to support SCTP? — Philippe Langlois <philippelanglois@...>
Hi,
[#8504] TCPSocket: bind method missing — hadmut@... (Hadmut Danisch)
Hi,
[#8513] patches for the 1.8.5 deadline... — Hugh Sasse <hgs@...>
As far as I can tell the only patches which I've submitted which
On Aug 3, 2006, at 10:20 AM, Hugh Sasse wrote:
On Fri, 4 Aug 2006, Eric Hodel wrote:
[#8522] IRB change for RDoc workaround — Eric Hodel <drbrain@...7.net>
RDoc chokes on the following code:
[#8525] rdoc bug? — Steven Jenkins <steven.jenkins@...>
I think I've found a bug in rdoc's handling of C files. Specifically, it
[#8555] Process.gid= fails on OS X — <noreply@...>
Bugs item #5351, was opened at 2006-08-08 01:56
>>>>> On Tue, 8 Aug 2006 17:56:07 +0900
Hi,
Hi,
>>>>> On Wed, 9 Aug 2006 12:31:07 +0900
Hi,
[#8561] sandbox timers & block scopes — why the lucky stiff <ruby-core@...>
Two puzzles I am trying to solve:
On 8/8/06, why the lucky stiff <ruby-core@whytheluckystiff.net> wrote:
On 8/16/06, Francis Cianfrocca <garbagecat10@gmail.com> wrote:
raise ThisDecayingInquisition, "anyone? anyone at all?"
On Wed, 2006-08-16 at 00:35 +0900, why the lucky stiff wrote:
On Wed, Aug 16, 2006 at 02:46:30AM +0900, MenTaLguY wrote:
On 8/15/06, why the lucky stiff <ruby-core@whytheluckystiff.net> wrote:
On 8/15/06, Charles O Nutter <headius@headius.com> wrote:
On Wed, Aug 16, 2006 at 04:14:33AM +0900, Charles O Nutter wrote:
On 8/15/06, why the lucky stiff <ruby-core@whytheluckystiff.net> wrote:
Hi,
[#8568] Pathname.to_a — Marc Haisenko <haisenko@...>
Hi folks,
[#8585] RDoc: extensions spread across multiple C files — Tilman Sauerbeck <tilman@...>
Hi,
Tilman Sauerbeck [2006-08-11 00:39]:
[#8593] ri problem with the latest ruby_1_8 — "Kent Sibilev" <ksruby@...>
Does anyone know why for some strange reason ri doesn't know about any
On Aug 11, 2006, at 10:55 AM, Kent Sibilev wrote:
[#8608] Another ri problem (ruby_1_8 branch) — "Kent Sibilev" <ksruby@...>
I've noticed that many builtin Ruby classes don't have descriptions:
On Aug 12, 2006, at 11:45 PM, Kent Sibilev wrote:
On 8/15/06, Eric Hodel <drbrain@segment7.net> wrote:
[#8609] Again Range=== bug — Ondrej Bilka <neleai@...>
Problem of discrete membership at Range#=== is that it returns unexpected
[#8616] invalid test in "sudo make install-doc"? — <noreply@...>
Bugs item #5415, was opened at 2006-08-14 12:01
[#8662] NODE_WHEN inside a case else body — "Dominik Bathon" <dbatml@...>
Hi,
[#8690] a ruby-core primer — why the lucky stiff <ruby-core@...>
Hello, all. I've been working on the ruby-core page for the new Ruby site.
On 8/22/06, why the lucky stiff <ruby-core@whytheluckystiff.net> wrote:
On 8/24/06, Dave Howell <groups+2006@howell.seattle.wa.us> wrote:
[#8709] More ri-problems (ruby_1_8 branch again) — Johan Holmberg <holmberg@...>
Hi!
[#8735] Legal operator symbols — "Nikolai Weibull" <now@...>
Why are :>, :>=, :<=, :< fine as symbols, while := isn't?
Hi --
[#8758] sandbox r50, here we go, loading conflicting gems — why the lucky stiff <ruby-core@...>
Checky.
Building with -Wall => questions
Having built the 1.8.5-preview4 ruby on Solaris9, I wondered if
there was anything I could contribute before the final release.
I've been reading Code Quality by Spinellis
http://www.spinellis.gr/codequality/
and saw the remarks about turning warnings on to find more edge cases.
So I just tried changing CFLAGS in the Makefile to include -Wall.
The first part of the results is like this:
neelix hgs 12 %> gmake
gcc -Wall -g -O2 -DRUBY_EXPORT -Wall -I. -I. -c array.c
gcc -Wall -g -O2 -DRUBY_EXPORT -Wall -I. -I. -c bignum.c
bignum.c: In function 'rb_cstr_to_inum':
bignum.c:457: warning: suggest parentheses around assignment used as truth value
gcc -Wall -g -O2 -DRUBY_EXPORT -Wall -I. -I. -c class.c
gcc -Wall -g -O2 -DRUBY_EXPORT -Wall -I. -I. -c compar.c
gcc -Wall -g -O2 -DRUBY_EXPORT -Wall -I. -I. -c dir.c
dir.c: In function 'fnmatch':
dir.c:161: warning: suggest parentheses around assignment used as truth value
dir.c: In function 'glob_helper':
dir.c:982: warning: value computed is not used
dir.c:1009: warning: value computed is not used
dir.c:1025: warning: value computed is not used
dir.c:1053: warning: value computed is not used
dir.c:1100: warning: value computed is not used
gcc -Wall -g -O2 -DRUBY_EXPORT -Wall -I. -I. -c dln.c
dln.c: In function 'dln_find_1':
The "suggest parentheses around assignment" isn't really important, it
means
neelix hgs 51 %> gdiff -pu1 bignum.c.orig bignum.c
--- bignum.c.orig 2006-04-09 16:10:36.000000000 +0000
+++ bignum.c 2006-08-21 15:29:17.189742000 +0000
@@ -456,3 +456,3 @@ rb_cstr_to_inum(str, base, badcheck)
for (i=len;i--;) zds[i]=0;
- while (c = *str++) {
+ while ((c = *str++)) {
if (c == '_') {
neelix hgs 52 %>
In other words, use double parentheses to mark deliberate assignments.
One can debate whether that is right. A possible loss of clarity (extra
parentheses) is traded for a warning when -Wall is in effect.
The warnings for "value computed is not used" are all for
sys_warning(path);
and similar uses of sys_warning(). sys_warning is a macro
#define sys_warning(val) \
((flags & GLOB_VERBOSE) && rb_protect((VALUE (*)_((VALUE)))sys_warning_1, (VALUE)(val), 0))
Clearly the && is being used as a shortcut operator. Kernighan and Pike
http://cm.bell-labs.com/cm/cs/tpop/
talks about macros, and generally discourages their use now that
compilers can do inlining. Since the output of sys_warning is never
used, should this be changed into a void function?
And finally, should I just shut up? Well, it probably needs asking:
now may well be the wrong time to mention such things so close to
1.8.5; there may be good reasons why macros are preferred over
functions for some platforms. I can probably create some patches for
many of these cases but if now is not the time, then I'll leave it
until later.
Thank you,
Hugh