Forum: Ruby boolean annoyance

Announcement (2017-05-07): www.ruby-forum.com is now read-only since I unfortunately do not have the time to support and maintain the forum any more. Please see rubyonrails.org/community and ruby-lang.org/en/community for other Rails- und Ruby-related community platforms.
3992dbf0a47456d2e1a1a1fe1511f75b?d=identicon&s=25 Claudio Jeker (Guest)
on 2006-02-08 16:49
(Received via mailing list)
Hello,

there is one thing in ruby that annoys me most (at least for now).

if 0
	puts "true"
end

Yes, I know everything expect nil and false are true but that's probably
the most illogic part of ruby. Because of this stuff like

if flags & 0x01
	# do some stuff if flag is set
end

will execute in any case. Perhaps I'm biased because I'm a crazy C
hacker
but I can not believe that others do not fall into this trap. I realy
like
the clearness of the ruby syntax but this "everything but nil and false
is
true" logic is totaly non obvious and annoying.

Why can't there be a to_bool converter for all numerical Classes?
This converter could be used in boolean expressions, 0.to_bool would
return false and all other numbers would return true.
Probably the best way is to extend the Object class where to_bool would
return true. Subclasses may than overload to_bool with a more complex
version. This makes it possible to use .to_bool everywhere where a
boolean
expression is expected.

IMO if it looks like a boolean expression it should act like a boolean
expression.
81d609425e306219d54d793a0ad98bce?d=identicon&s=25 Matthew Moss (Guest)
on 2006-02-08 17:16
(Received via mailing list)
> there is one thing in ruby that annoys me most (at least for now).
>
> if 0
>         puts "true"
> end
>
> Yes, I know everything expect nil and false are true but that's probably
> the most illogic part of ruby.

It's actually the most illogic part of languages like C that treat 0
as false.  Believe me, having spent most of my programming life using
C/C++ and being used to that, I make mistakes regularly whilst writing
Ruby code.

0 is an integer and quite often a valid value. C's treatment of 0 as
false is convenient in some situations but horribly inconvenient in
others.  Because if I'm expecting an integer and zero is a legal
value, then you have to start playing around in your conditionals...
"Okay, today any -1 is false"...  or even at different levels than
that.  Part of the problem is that C doesn't have an actual NULL...
NULL is just defined as zero.  Overlap, explosions, crash and burn...


> Because of this stuff like
>
> if flags & 0x01
>         # do some stuff if flag is set
> end

There are alternatives....  In C/C++, this is what I would do because
it is convenient.  In Ruby, I might do:

if (flags & 0x01).nonzero?

Course, I probably wouldn't hardcode 0x01 in any language, so:

if (flags & kSomethingEnabled).nonzero?

But I'd even go a bit further (and often do this in C++ for clarity):

def something_enabled?
  (flags & kSomethingEnabled).nonzero?
end

if something_enabled?
  # do something
end

Or even (in Ruby w/ symbols):

mask = { :something => 0x01 }
def enabled? feature
  (flags & mask[feature]).nonzero?
end

if enabled?(:something)
  # do something
end


You could even go so far to package this into a bitfield class (if
there isn't one already).
Point is, there are lots of better ways to get what you need done
without sacrificing the value 0 to the old-skool gods. (Who I get
along with just fine usually, but not with Ruby's zero.)
912c61d9da47754de7039f4271334a9f?d=identicon&s=25 unknown (Guest)
on 2006-02-08 17:45
(Received via mailing list)
Quoting Claudio Jeker <cjeker@diehard.n-r-g.com>:

> IMO if it looks like a boolean expression it should act like a
> boolean expression.

That's the point, isn't it?  0 isn't a boolean value.

You typically only see 0 -> false equivalences in languages that
don't have a distinct boolean type (C, Perl, etc...).  Ruby's not
one of those.

> Why can't there be a to_bool converter for all numerical Classes?

There is one; it's just called #nonzero? instead of #to_bool:

 if ( flags & 0x01 ).nonzero?
  ...
 end

-mental
B97225f66bb5caac601b12735d430a0d?d=identicon&s=25 Marcin MielżyÅ?ski (Guest)
on 2006-02-08 17:59
(Received via mailing list)
Claudio Jeker wrote:
> Hello,
>
> there is one thing in ruby that annoys me most (at least for now).
>
> if 0
> 	puts "true"
> end
>

0 is a proper instance of the Fixnum class, how can it be considered as
a false? And remeber, only few languages consider 0 as a false (c and
python considerably) and not even by java/smalltalk etc!


lopex
669b7046f02e5dfc4bda4421f1069731?d=identicon&s=25 Alex Fenton (Guest)
on 2006-02-08 19:18
(Received via mailing list)
Claudio Jeker wrote:
> Hello,
>
> there is one thing in ruby that annoys me most (at least for now).
>
> if 0
> 	puts "true"
> end

class Person
	def number_of_children()
		@children.length
	end

	def has_children?()
		@children.length > 0
	end
end

In this context, like most others from a high-level language
perspective, 0 is a valid meaningful value. If you *don't know* how many
children a Person's got, return nil. If you *know* a Person hasn't got
any return 0. Make a boolean-esque method if you want boolean values.

As said in other replies and in the innumerable previous threads on this
topic, 0's falsity is an implementation oddity of *some* languages.

It used to create subtle bugs in my Perl code more often than it was a
useful shortcut. Understanding why you need 'if ($value)' sometimes and
'if (defined $value)' other times is much more complicated than Ruby's
solution.

alex
912c61d9da47754de7039f4271334a9f?d=identicon&s=25 unknown (Guest)
on 2006-02-08 20:02
(Received via mailing list)
Quoting Alex Fenton <alex@deleteme.pressure.to>:

> 	def has_children?()
> 		@children.length > 0
> 	end

Of course, this could also be written more simply as:

 def has_children?
     not @children.empty?
 end

-mental
430ea1cba106cc65b7687d66e9df4f06?d=identicon&s=25 David Vallner (Guest)
on 2006-02-08 21:46
(Received via mailing list)
DÅ?a Streda 08 Február 2006 16:25 Claudio Jeker napísal:
>
> will execute in any case. Perhaps I'm biased because I'm a crazy C hacker
> but I can not believe that others do not fall into this trap. I realy like
> the clearness of the ruby syntax but this "everything but nil and false is
> true" logic is totaly non obvious and annoying.
>


This is in my opinion a matter of convention.

The predominant C convention is to return logical values in predicates,
and
then either return a NULL on failure, and a valid result on success; or
return 0 on success, a nonzero error code on failure, and pass a valid
result
via an output parameter. Frankly, I find remembering which function uses
which slightly annoying.

The predominant Ruby convention is to return true / false in predicates;
and
in other functions return the result of computation on success, nil on
"mild"
failure, and throw an exception on severe failure. Because of
exceptions,
using error codes is unnecessary.

This means that:

if (foo = some_method)
	puts "#some_method succeeded"
end

is -always- a valid idiom if this convention is followed, and a return
of
value 0 always indicates success, as opposed C, where it can mean either
depending on the call.

David Vallner
3992dbf0a47456d2e1a1a1fe1511f75b?d=identicon&s=25 Claudio Jeker (Guest)
on 2006-02-08 23:34
(Received via mailing list)
On Thu, Feb 09, 2006 at 01:16:26AM +0900, Matthew Moss wrote:
> as false.  Believe me, having spent most of my programming life using
>
If you are inspecting a integer against nothing end everything is just
legal, why are you inspecting it?

The difference between NULL and nil is not that big. Did you ever try to
do stuff like nil.split or nil.capitalize.
In ruby you have two ways of living with nil. Either you catch exections
created by nil access all over the place or check for access. This is
similar to C the only difference is that in C you get a SIGSEGV.

Sure 0 is an integer but it is a special one. If you do just

if foo.to_i
	puts "true"
end

I expect of a language as cool as ruby to actualy use some #to_bool
converter to duck type the integer into the boolean domain.
And from the math point of view I expect that 0 is treated as false in
boolean context. In boolean algebra 0 is always used to indicate false
if
numbers are used.

> if (flags & 0x01).nonzero?
>

Wow. I was told that the cool thing about ruby is to write less code.
Side node: a & b is a boolean expression a bitwise boolean expression
but
still boolean.

> Course, I probably wouldn't hardcode 0x01 in any language, so:
>

This is only a simple example. My actual code does not use magic
constants and it has nothing to do with actual problem.
8342950f34a66d9ec7cfe10b33d5494c?d=identicon&s=25 Alexis Reigel (Guest)
on 2006-02-08 23:35
(Received via mailing list)
When I started using ruby I had exactly the same problem as you, porting
some c code to ruby that was checking some flags. I didn't get to the
solution myself, as I never ever thought of 0 being true.
But once you see the advantages of it you'll really appreciate that
convention.
In c you do: (flags & 0x01)
In ruby you do: (flags & 0x01 == 0) or (flags & 0x01).nonzero?
Or even nicer: flags[0x01]


Shortly there was a discussion about the same topic on this list ("nil
!= []"). I'll cite two convincing postings:


matthew smillie.said:
<quote>
0 *the integer* is only false by convention, and it's a convention
confined to programming, originating (unless I'm mistaken) from
languages which didn't define specific 'true' and 'false' logcial
values separate from integer math.  0's used in some logical  notations
as a symbol for 'false', but it's unlikely that anyone  familiar with
formal logic will tell you those 0's are the same 0's  you get from "2 -
2".

There's no doubt that the convention's been made very useful, but
there's really no logical basis for equating any particular symbol to
true or false truth values over any other.
</quote>


amrangaye said:
<quote>
One example of this that tripped me up today is the regular expression
match operator (=~), which returns (0-based) the index of a match, or
nil otherwise. If 0 was false, you couldn't do:

if str =~ /^Hello/
</quote>




Claudio Jeker wrote:
>
> if flags & 0x01
> 	# do some stuff if flag is set
> end
>
[snip]
3992dbf0a47456d2e1a1a1fe1511f75b?d=identicon&s=25 Claudio Jeker (Guest)
on 2006-02-08 23:54
(Received via mailing list)
On Thu, Feb 09, 2006 at 01:45:22AM +0900, mental@rydia.net wrote:
> Quoting Claudio Jeker <cjeker@diehard.n-r-g.com>:
>
> > IMO if it looks like a boolean expression it should act like a
> > boolean expression.
>
> That's the point, isn't it?  0 isn't a boolean value.
>

Have you ever looked at boolean algebra. The use of 0 as false is just
standard usage in boolean expressions.

> You typically only see 0 -> false equivalences in languages that
> don't have a distinct boolean type (C, Perl, etc...).  Ruby's not
> one of those.
>

... and in bitwise boolean logic 0 meansi what? Even ruby has bitwise
logic operators. If I use 0 in a boolean domain it should not return
true.

> > Why can't there be a to_bool converter for all numerical Classes?
>
> There is one; it's just called #nonzero? instead of #to_bool:
>
>  if ( flags & 0x01 ).nonzero?
>   ...
>  end
>

But I have to explicitly use it. Ruby should use duck typing for boolean
expression like it does it in many other cases.
81d609425e306219d54d793a0ad98bce?d=identicon&s=25 Matthew Moss (Guest)
on 2006-02-09 00:29
(Received via mailing list)
> > Because if I'm expecting an integer and zero is a legal
> > value, then you have to start playing around in your conditionals...
>
> If you are inspecting a integer against nothing end everything is just
> legal, why are you inspecting it?

I didn't say everything was legal; I said zero could be legal. That
does not imply everything is legal.

I typically see this in C/C++ where someone has written a function
where 0 is a legal value, they then return a negative number for
illegal status.  But, IMO, now you start building maintainence
headaches, since some function calls look like:

  if (foo(...))

and others look like:

  if (foo(...) < 0)


Ruby just takes the stance (as do many other languages) that there
shall no automatic determination of what integers are valid and which
are invalid, and that shall be left to the coder.


> The difference between NULL and nil is not that big. Did you ever try to
> do stuff like nil.split or nil.capitalize.

Yes, I have.  Not those particular methods, but others.  Just type
'nil.methods' in irb and you can see what's defined.  And nil could be
expanded if needed (although, I suspect, generally not a good idea,
but possible).  Hell, you could do this if you really wanted to have
some excitement:

class NilClass
   def method_missing(m) nil end
end


NULL, on the other hand, is zero. Not an object.

> In ruby you have two ways of living with nil. Either you catch exections
> created by nil access all over the place or check for access. This is
> similar to C the only difference is that in C you get a SIGSEGV.

I contend that exceptions are a better solution that SIGSEGV.  As far
as checking for nil, I don't have as much experience here w/Ruby as
some others, but I've never had to put nil checking all over the
place.  Only about as often as I might branch otherwise.


> Sure 0 is an integer but it is a special one.

It is only special by convention.

> Side node: a & b is a boolean expression a bitwise boolean expression but
> still boolean.

a & b is an integer expression, implicitly typecast in C/C++ to
boolean because zero is treated as false.  Implicit typecasting can be
a dangerous thing.  The way to write a boolean expression is (a & b)
!= 0.


> Wow. I was told that the cool thing about ruby is to write less code.

There is a limit, of course. You could remove constant names, change
function identifiers to single letters, remove whitespace, etc.  All
that is writing less code, but I'd hesitate to do it.

I prefer to think that Ruby lets me write clearer code, quickly,
easily, and that often amounts to less code, in part because it is a
dynamic language (as compared to how much code I often have to write
in C++ because of it's static nature).

Still being a fairly new Ruby user, I would never write:
    if (a & b)
Yes, of course, because it doesn't work, but I also wouldn't write:
    if (a & b).nonzero?

Now I did mention that in my post, but it was to lead you to better
ways.  Something like:

class State
   def visible?
      @flags[0x01].nonzero?
   end
end

state = State.new
# ... do stuff ...
draw_scene if stat.visible?

"if stat.visible?" is much more readable that "if flags & 0x01" or the
like.
3992dbf0a47456d2e1a1a1fe1511f75b?d=identicon&s=25 Claudio Jeker (Guest)
on 2006-02-09 00:35
(Received via mailing list)
On Thu, Feb 09, 2006 at 07:35:08AM +0900, Alexis Reigel wrote:
> When I started using ruby I had exactly the same problem as you, porting
> some c code to ruby that was checking some flags. I didn't get to the
> solution myself, as I never ever thought of 0 being true.
> But once you see the advantages of it you'll really appreciate that
> convention.
> In c you do: (flags & 0x01)
> In ruby you do: (flags & 0x01 == 0) or (flags & 0x01).nonzero?
> Or even nicer: flags[0x01]

Does flags[0x01] work with any kind of mask. I thought that flags[3]
would
return the value of bit 3 and not the value of bit 0 and 1...
and from the ruby reference Bignum#[] returns the nth bit a 0 or 1 and
so
your flags[0x01] would suffer the same way as (flags & 0x01).

> languages which didn't define specific 'true' and 'false' logcial
> values separate from integer math.  0's used in some logical  notations
> as a symbol for 'false', but it's unlikely that anyone  familiar with
> formal logic will tell you those 0's are the same 0's  you get from "2 - 2".
>
> There's no doubt that the convention's been made very useful, but
> there's really no logical basis for equating any particular symbol to
> true or false truth values over any other.
> </quote>

I don't believe that 0 is originating from programming languages but
actually came from the boolean algebra itself. In a binary domain it is
natural to make 0 false. (a && !a == 0 or if converted into the
set-theory doing a intersection of a set A and the complementary set !A
results in the empty set which is normaly written as some kind of 0).
OK doing set algebra in ascii sucks but I think it is parsable.

>
OK this is a valid argument against changing behaviour because it would
cause a major regression to existing scripts. I think I have to swallow
this pill and change my coding stile for ruby. Doing binary protocols in
ruby is a bit more challenging than expected.
81d609425e306219d54d793a0ad98bce?d=identicon&s=25 Matthew Moss (Guest)
on 2006-02-09 00:36
(Received via mailing list)
> But I have to explicitly use it. Ruby should use duck typing for boolean
> expression like it does it in many other cases.

The problem is, if you do that one place (i.e. "oh, this is
bitwise-and, each bit represents a bool"), then you have to do it
everywhere, since bitwise-and is NOT limited to single-bit flag checks
(e.g. it works great for masking as well). Doing it everywhere is a
very bad thing.

Which means you either need to propose an extension to Ruby for a new
"bitwise-and-as-boolean" operator (i.e. flags ?& 0x01 or similar), or
you need to abstract out a bit more and turn (flags & 0x01) into
something valid. With a little wrapper func, it can look quite nice:

class Something
   def enabled?
     @flags[0x01].nonzero?
   end
end

And that's assuming someone hasn't already made a bitfield type class
that makes all of this even prettier.
3992dbf0a47456d2e1a1a1fe1511f75b?d=identicon&s=25 Claudio Jeker (Guest)
on 2006-02-09 00:49
(Received via mailing list)
On Thu, Feb 09, 2006 at 08:35:51AM +0900, Matthew Moss wrote:
> "bitwise-and-as-boolean" operator (i.e. flags ?& 0x01 or similar), or
> you need to abstract out a bit more and turn (flags & 0x01) into
> something valid. With a little wrapper func, it can look quite nice:
>

Until here I agree with you.

> class Something
>    def enabled?
>      @flags[0x01].nonzero?
>    end
> end
>

I think this is a bad example at it does not what you think it does.
While flags & 0x01 != 0 compares the least significant bit flags[0x01]
does not. You're of by one. It will also not work for multibit checks
like
flags & 0x1C.

> And that's assuming someone hasn't already made a bitfield type class
> that makes all of this even prettier.
>

We will see.
31ab75f7ddda241830659630746cdd3a?d=identicon&s=25 Austin Ziegler (Guest)
on 2006-02-09 01:03
(Received via mailing list)
On 08/02/06, Claudio Jeker <cjeker@diehard.n-r-g.com> wrote:
>
> if flags & 0x01
>         # do some stuff if flag is set
> end

This is your coding problem. It should be -- even in C/C++:

  if (flags & 0x01 == 0x01)
    ...
  end

> will execute in any case. Perhaps I'm biased because I'm a crazy C hacker
> but I can not believe that others do not fall into this trap. I realy like
> the clearness of the ruby syntax but this "everything but nil and false is
> true" logic is totaly non obvious and annoying.

Why? What is it about zero that makes it non-true? After all, in bash:

  foo && bar # runs bar if and only if foo returned 0!

In shell scripting, 0 is the *true* value and everything else is false.

Just as there's no meaningful sort order for "true", "false", there's
no meaningful interpretation of "0" as "false". It's merely a C-style
convention that should be abandoned with relish.

> IMO if it looks like a boolean expression it should act like a boolean
> expression.

Neither expression ("if 0" or "if flags & 0x01") looks like a valid
boolean expression to me.

-austin
81d609425e306219d54d793a0ad98bce?d=identicon&s=25 Matthew Moss (Guest)
on 2006-02-09 01:13
(Received via mailing list)
> flags & 0x1C.
Ooops...  Yup, that was wrong given the context.
31ab75f7ddda241830659630746cdd3a?d=identicon&s=25 Austin Ziegler (Guest)
on 2006-02-09 01:16
(Received via mailing list)
On 08/02/06, Claudio Jeker <cjeker@diehard.n-r-g.com> wrote:
>> that.  Part of the problem is that C doesn't have an actual NULL...
>> NULL is just defined as zero.  Overlap, explosions, crash and burn...
> If you are inspecting a integer against nothing end everything is just
> legal, why are you inspecting it?

Sorry, but that doesn't work. If you have something that returns an
integer value -- consider strtol(3). This can return *any* valid integer
value, but if you get a 0, LONG_MAX, or LONG_MIN, you have to *then*
check errno to see if the conversion was, in fact, successful. (And the
conversion could be unsuccessful for any number of reasons.)

Ruby's general approach is much better: either throw an exception or
return +nil+ if you've got a non-useful value. I shouldn't have to
second-guess what may be a valid value.

> I expect of a language as cool as ruby to actualy use some #to_bool
> converter to duck type the integer into the boolean domain. And from
> the math point of view I expect that 0 is treated as false in boolean
> context. In boolean algebra 0 is always used to indicate false if
> numbers are used.

But Ruby is *not* Boolean Algebra. And simply using "0" to represent
false is a representation -- one could use "f", just as easily. This is
what Ruby has done.

Zero isn't a special number. It's just zero.

> Side node: a & b is a boolean expression a bitwise boolean expression
> but still boolean.

It is not, in fact, a boolean expression. It is a bitwise expression.
The only thing that makes it even remotely *close* to being boolean is
its presence in an if statement. Otherwise, you wouldn't get the desired
result when you really *do* want to do bitwise OR or AND operations.

-austin
430ea1cba106cc65b7687d66e9df4f06?d=identicon&s=25 David Vallner (Guest)
on 2006-02-09 01:34
(Received via mailing list)
DÅ?a Streda 08 Február 2006 23:54 Claudio Jeker napísal:
> Have you ever looked at boolean algebra. The use of 0 as false is just
> standard usage in boolean expressions.
>

Recalling the earlier "Why Ruby isn't <insert language name>" thread,
someone
noted that what the 0 symbol represents in boolean algebra has
absolutely
nothing to do with what the 0 symbol represents in arithmetics.

Just like a capital letter O isn't a numerical 0, an arithmetical 0
isn't the
same as a boolean 0. A boolean false value is in Ruby represented by the
keyword "false", an arithmetical zero by the literal "0" - that's all
there's
to it. C's lack of distinction between these can arguably be considered
as a
fault of C while we're nitpicking, as well as Ruby's rather broad range
of
values that are true in a boolean context. Neither is, IMO, more "right"
than
the other, it depends on how often you find one practical in your code,
and
both are a lot more often practical than Java's strictness on the issue.

David Vallner
3992dbf0a47456d2e1a1a1fe1511f75b?d=identicon&s=25 Claudio Jeker (Guest)
on 2006-02-09 01:42
(Received via mailing list)
On Thu, Feb 09, 2006 at 09:15:54AM +0900, Austin Ziegler wrote:
> >> "Okay, today any -1 is false"...  or even at different levels than
> >> that.  Part of the problem is that C doesn't have an actual NULL...
> >> NULL is just defined as zero.  Overlap, explosions, crash and burn...
> > If you are inspecting a integer against nothing end everything is just
> > legal, why are you inspecting it?
>
> Sorry, but that doesn't work. If you have something that returns an
> integer value -- consider strtol(3). This can return *any* valid integer
> value, but if you get a 0, LONG_MAX, or LONG_MIN, you have to *then*
> check errno to see if the conversion was, in fact, successful. (And the
> conversion could be unsuccessful for any number of reasons.)

This is not correct. strtol(3) does not return 0 in case of an error. It
sets errno to ERANGE and returns LONG_MAX or LONG_MIN.
31af45939fec7e3c4ed8a798c0bd9b1a?d=identicon&s=25 Matthew Smillie (Guest)
on 2006-02-09 01:50
(Received via mailing list)
On Feb 8, 2006, at 23:35, Claudio Jeker wrote:

> I don't believe that 0 is originating from programming languages but
> actually came from the boolean algebra itself.

Right, I'll put it simply:

The symbols used in Boolean algebra to indicate true and false values
are the same symbols as those used to indicate the arithmetic integer
values 1 and 0.  This does not mean that those symbols represent the
same things, or are equivalent in any way apart from their shape.

Any two-element Boolean algebra (and there are many of them) is
equally valid using {a, b}, {t, f}, or even {larry, bob} as the
elements.  Various algebras also use symbols like + and * for things
other than addition and multiplication.

If you still don't think that integer 0-is-false is a peculiarity of
the C-heritage languages, check out the following Lisp fragments:

   (eql NIL 0)
   NIL

   (if 0 'true 'false)
   TRUE

matthew smillie.





----
Matthew Smillie            <M.B.Smillie@sms.ed.ac.uk>
Institute for Communicating and Collaborative Systems
University of Edinburgh
E34b5cae57e0dd170114dba444e37852?d=identicon&s=25 Logan Capaldo (Guest)
on 2006-02-09 01:53
(Received via mailing list)
On Feb 8, 2006, at 7:41 PM, Claudio Jeker wrote:

> This is not correct. strtol(3) does not return 0 in case of an
> error. It
> sets errno to ERANGE and returns LONG_MAX or LONG_MIN.

RETURN VALUES
      The strtol(), strtoll(), strtoimax() and strtoq() functions
return the
      result of the conversion, unless the value would underflow or
overflow.
      ***If no conversion could be performed, 0 is returned and the
global vari-
      able errno is set to EINVAL.***  If an overflow or underflow
occurs, errno
      is set to ERANGE and the function return value is clamped
according to
      the following table.

Emphasis (the triple *) mine.
430ea1cba106cc65b7687d66e9df4f06?d=identicon&s=25 David Vallner (Guest)
on 2006-02-09 02:50
(Received via mailing list)
DÅ?a Å tvrtok 09 Február 2006 01:52 Logan Capaldo napísal:
>       ***If no conversion could be performed, 0 is returned and the
> global vari-
>       able errno is set to EINVAL.***  If an overflow or underflow
> occurs, errno
>       is set to ERANGE and the function return value is clamped
> according to
>       the following table.
>

This made me smile and laugh and giggle. And also hover my hand on the
button
that controls the "Do not feed the troll" sign, but I'm still more
amused
than annoyed.

Rule 1 of trolling: Never, ever be blatantly wrong about anything.

David Vallner
036384a0bea8469d33c24e5f3a50dab6?d=identicon&s=25 soxinbox (Guest)
on 2006-02-09 05:33
(Received via mailing list)
I just thought I would add to the history of zero being false in C. C
was
designed to be compiler friendly. Most every processor has a branch if
zero
machine instruction that is used for loops. It is convenient therefore
to
use a zero value as a Boolean conditional for a branch. It creates
denser
code.

Strictly speaking, binary 0 is not Boolean false. It is simply a
convention
that some have chosen. In electronics it is very common to have binary 0
mean Boolean true and 1 mean false.

"Claudio Jeker" <cjeker@diehard.n-r-g.com> wrote in message
news:20060208152543.GA16920@diehard.n-r-g.com...
5befe95e6648daec3dd5728cd36602d0?d=identicon&s=25 Robert Klemme (Guest)
on 2006-02-09 10:14
(Received via mailing list)
Claudio Jeker wrote:
> Does flags[0x01] work with any kind of mask. I thought that flags[3]
> would return the value of bit 3 and not the value of bit 0 and 1...
> and from the ruby reference Bignum#[] returns the nth bit a 0 or 1
> and so your flags[0x01] would suffer the same way as (flags & 0x01).

You are correct.  It should have read

if flags[0] == 1
....

Kind regards

    robert
3992dbf0a47456d2e1a1a1fe1511f75b?d=identicon&s=25 Claudio Jeker (Guest)
on 2006-02-09 11:27
(Received via mailing list)
On Thu, Feb 09, 2006 at 09:52:33AM +0900, Logan Capaldo wrote:
>      result of the conversion, unless the value would underflow or
>
Hmmm, my man page is a bit different:

RETURN VALUES
     The strtol(), strtoll(), strtoimax(), and strtoq() functions
returns the
     result of the conversion, unless the value would underflow or
overflow.
     If overflow or underflow occurs, errno is set to ERANGE and the
function
     return value is as follows:

           Function     overflow    underflow
           strtol()     LONG_MIN    LONG_MAX
           strtoll()    LLONG_MIN   LLONG_MAX
           strtoimax()  INTMAX_MIN  INTMAX_MAX
           strtoq()     LLONG_MIN   LLONG_MAX

After googling a bit it looks like this is old BSD behaviour.
A value of 0 plus EINVAL is returned if the base is bigger than 36 which
is not checked in the original BSD code.


/me grabs the dunce hat and stands in the corner for the rest of the
day.
912c61d9da47754de7039f4271334a9f?d=identicon&s=25 unknown (Guest)
on 2006-02-09 19:27
(Received via mailing list)
Quoting Claudio Jeker <cjeker@diehard.n-r-g.com>:

> I don't believe that 0 is originating from programming languages
> but actually came from the boolean algebra itself.

Just because similar symbols are used in entirely different branches
of mathematics does not mean that they refer to the same thing.

-mental
912c61d9da47754de7039f4271334a9f?d=identicon&s=25 unknown (Guest)
on 2006-02-09 19:38
(Received via mailing list)
Quoting Claudio Jeker <cjeker@diehard.n-r-g.com>:

> OK this is a valid argument against changing behaviour because it
> would cause a major regression to existing scripts. I think I
> have to swallow this pill and change my coding stile for ruby.
> Doing binary protocols in ruby is a bit more challenging than
> expected.

For what it's worth, if you find yourself typing stuff like:

 ( x & mask ).nonzero?

over and over, you shouldn't tolerate that.  DRY -- refactor the
repeated bits it into a separate method instead.

one possibility might be:

 class Integer
   def intersect?( mask )
     ( self & mask ).nonzero?
   end
 end

Used like:

 if x.intersect? 0x1c
   ...
 end

Maybe you can think of a better name though.

-mental
31ab75f7ddda241830659630746cdd3a?d=identicon&s=25 Austin Ziegler (Guest)
on 2006-02-16 06:05
(Received via mailing list)
On 2/8/06, Claudio Jeker <cjeker@diehard.n-r-g.com> wrote:
> > >> value, then you have to start playing around in your conditionals...
> > conversion could be unsuccessful for any number of reasons.)
> This is not correct. strtol(3) does not return 0 in case of an error. It
> sets errno to ERANGE and returns LONG_MAX or LONG_MIN.

It is correct. I had looked at the man page for strtol(3) before
posting. Trying to convert a non-numeric value (say, ":") or using a
base of 40 will result in 0 with a result of EINVAL (although it is
optional to have EINVAL in case of a non-conversion result).
Therefore, you *cannot* trust a result of 0 and must always check
errno if you get 0, LONG_MAX, or LONG_MIN.

Please consider that I do know what I'm talking about.

strtol(3) would have been better if passed the target value as a
parameter and return a success or failure code *or* accepted a
success/failure code as a parameter and returned the result.

-austin
This topic is locked and can not be replied to.