> I can't think of many > cases where a downcast is used *and* the original value is expected to > ever be larger than the target type.
I can. Particularly when casting to a byte, I'm often more interested in the bit pattern than the integer value. (Admittedly, sometimes this is due to java API idiosynchrocies. For example, InputStream.read() reads a single byte, but returns it as an integer from 0 to 255, which is out of range for a java byte.) This will be a breaking change for me. I was tempted to argue that explicitly calling a coercion function shouldn't qualify as 'automatic overflow', but in Clojure these functions are sometimes used to achieve an optimization (forcing the use of java primitives) rather than for their behavior. In those use cases, I see that overflow would be unexpected and hence, harmful. Note that because of the sign, bit-masking alone can't be used to get a truncating conversion. For example, to force the lower 8 bits of an integer into a java byte you'd need something like: (defn truncating-byte [n] (byte (if (bit-test n 7) (bit-or n -256) (bit-and n 255)))) On Mar 24, 2:19 am, ataggart <alex.tagg...@gmail.com> wrote: > It was added > here:http://github.com/richhickey/clojure/commit/d0e1eef26abd215668ed27357... > > Not automatically overflowing numbers is a Good Thing. For > example:http://seclists.org/fulldisclosure/2010/Mar/447 > > Though the behavior now deviates from the java casting behavior where > the more significant bits are just truncated. I can't think of many > cases where a downcast is used *and* the original value is expected to > ever be larger than the target type. If you really need that, then > bit-masking prior to casting seems appropriate. > > On Mar 23, 7:41 am, Per Vognsen <per.vogn...@gmail.com> wrote: > > > > > Interesting. It's Clojure 1.2.0-master-SNAPSHOT as of last week: > > > Clojure 1.2.0-master-SNAPSHOT > > user=> 0xff > > 255 > > user=> (byte 0xff) > > java.lang.IllegalArgumentException: Value out of range for byte: 255 > > (NO_SOURCE_FILE:0) > > > So, this looks like a new issue. Rich? > > > -Per > > > On Tue, Mar 23, 2010 at 8:39 PM, Mark J. Reed <markjr...@gmail.com> wrote: > > > > On Tue, Mar 23, 2010 at 8:40 AM, Per Vognsen <per.vogn...@gmail.com> > > > wrote: > > >> Sorry, I didn't put that right. 0xFF would only be -1 as a signed > > >> byte. What I'm saying is that the interaction between the type system > > >> of integers and the reader's hexadecimal notation is pretty surprising > > >> to me. In particular, (byte 0xFF) throws an error. > > > > What version? It works here: > > > > Clojure 1.1.0 > > > user=> (byte 0xff) > > > -1 > > > > In fact, it seems that (byte) doesn't check the range at all: > > > > user=> (byte -129) > > > 127 > > > > -- > > > Mark J. Reed <markjr...@gmail.com> > > > > -- > > > You received this message because you are subscribed to the Google > > > Groups "Clojure" group. > > > To post to this group, send email to clojure@googlegroups.com > > > Note that posts from new members are moderated - please be patient with > > > your first post. > > > To unsubscribe from this group, send email to > > > clojure+unsubscr...@googlegroups.com > > > For more options, visit this group at > > >http://groups.google.com/group/clojure?hl=en > > > > To unsubscribe from this group, send email to > > > clojure+unsubscribegooglegroups.com or reply to this email with the words > > > "REMOVE ME" as the subject. -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en To unsubscribe from this group, send email to clojure+unsubscribegooglegroups.com or reply to this email with the words "REMOVE ME" as the subject.
