Path: utzoo!utgpu!news-server.csri.toronto.edu!clyde.concordia.ca!uunet!wuarchive!zaphod.mps.ohio-state.edu!sdd.hp.com!elroy.jpl.nasa.gov!jpl-devvax!lwall From: lwall@jpl-devvax.JPL.NASA.GOV (Larry Wall) Newsgroups: comp.lang.perl Subject: Re: vec(expr,offset,bits) Message-ID: <9107@jpl-devvax.JPL.NASA.GOV> Date: 10 Aug 90 23:19:27 GMT References: Reply-To: lwall@jpl-devvax.JPL.NASA.GOV (Larry Wall) Organization: Jet Propulsion Laboratory, Pasadena, CA Lines: 44 In article stergios@jessica.stanford.edu writes: : : can someone explain the behavior of vec to me? I've been playing with : the example below, followed by its output. I understand the first : line of output when the offset is 0; the value printed is from the : i-th bit to the first.. When I give a nonzero offset, however, I dont : quite understand whats happening. What is the offset applied to, the : string or the bitfield? : : thanks : : sm : : ********************************************************************** : : $string = sprintf ("%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c", : 255,255,255,255, 255,255,255,255, : 255,255,255,255, 255,255,255,255 ); A little easier to write "\377" x 16, by the way, and it computes it at compile time... : foreach $j (0,1,2,3) { : for($i=1 ; $i <= 8 ; $i++) { : printf "%5d ", vec($string,$j,$i) ; : } : print "\n" ; : } : : ********************************************************************** : 1 3 7 15 31 63 127 255 : 1 3 7 15 7 3 1 255 : 1 3 3 15 31 15 3 255 : 1 3 7 15 1 63 7 255 : ********************************************************************** What's going on here is only the values 1, 2, 4 and 8 are documented to be valid as the 3rd argument of vec. The other values happen to work when the offset is 0 because the bitfield doesn't cross a byte boundary. The code doesn't attempt to decode bitfields across byte boundaries because the situation never arises if the number of bits is a power of 2. Larry