Quite right. My comment was mainly aimed at something like casting 0xABC to a byte, and didn't consider the signed value problem. I think this is a good case for a separate function, such as the one you provided.
On Mar 24, 8:21 am, Josh Arnold <[email protected]> wrote: > > 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 <[email protected]> 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 <[email protected]> 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 <[email protected]> wrote: > > > > > On Tue, Mar 23, 2010 at 8:40 AM, Per Vognsen <[email protected]> > > > > 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 <[email protected]> > > > > > -- > > > > You received this message because you are subscribed to the Google > > > > Groups "Clojure" group. > > > > To post to this group, send email to [email protected] > > > > Note that posts from new members are moderated - please be patient with > > > > your first post. > > > > To unsubscribe from this group, send email to > > > > [email protected] > > > > 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 [email protected] Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to [email protected] 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.
