On Fri, Dec 12, 2008 at 1:31 AM, Dave Thompson <[email protected]> wrote: >> One note: type casting doesn't modify the pointer value (check your >> ANSI/ISO C89/C99 standard references). What you need is data at an >> 'aligned pointer'. > > Yes and no. Standard C allows different data pointer types to have [...] > But (I believe) your point was that casting an unaligned pointer > doesn't (reliably) make it aligned. That's true, and important.
Yup, that was my point. The whole 'get me a properly aligned pointer' is system-specific activity anyhow and should be restricted to system-specific code (device drivers, that sort of thing). I wonder if that (i.e. 'alignment') is his _real_ trouble right now, but sometimes a little short-term scare helps a brain long term. ;-) Besides, on all alignment faulting/trapping/whatchamacallit platforms I've been, both malloc() and array declarations of the proper word type (and in case of 'dunno', it's 'long' or 'double' you can use) align on safe memory boundaries (malloc() takes care of that under the hood; the array decls are taken care of alignment-wise by the compiler), so the only 'real' alignment trouble you can run into these days is using char[] arrays and accessing it as int[] or other bigger types on hardware which doesn't like that, e.g. MC68K. i86 is very forgiving, but slows down a tad when you do that kind of thing. ... "Not a very educational platform, i86 is," Yoda says. [backedit: sorry, reiterated of what you already said] (This is, of course, neglecting all the goodness regarding DMA ( / GPU bitblit) transfers, which are often 'sector'-aligned and other hardware-assisted activities.) >> // for C89: >> typedef unsigned char byte; >> > Did you mean this single line 'for C89' or the whole code? > There is no difference between C89 and C99 as to a type named 'byte', > so the typedef is equally needed in C99. (And // comments aren't C89!) > (C99 library has new 'exact' types like uint8_least_t, only if you > #include <stdint.h> or <inttypes.h>, but not any named byte.) Ha! That's what I get when banging my bongo keyboard late at night and people-in-the-know are watching! :-)) What I meant was 'uint8_t' instead of 'byte', all the way through. <bows /> > Use unsigned. int is not necessarily big enough for (all) addresses [...] > (unsigned)rawptr & (wordsize-1) > gives the same result and is almost always more efficient. And yes again. See lame 'late night' excuse above. > Declaration after (executable) statement in a block is C99 or C++ only. > Easily fixed; for that matter, we don't really need shift as a separate > variable, I assume you just used it for greater explanatoryness. Yup. And combine that with total laziness. The major idea here was a curveball: see if I could trigger the brain into thinking 'hey, this alignment stuff is unusual, and now that I use it, the problem persists, so maybe it's not what I need, let's recheck my code and see if I fubar'ed a different sort of thing...' Your corrections clearly prove I shouldn't try 'fancy' while having other stuff on the brain as well (such as 'bed'). One benefit: if the intended message (the curveball) isn't coming through 20-20 (loud & clear) by now, I don't now what will. > Note that this method will give (byte*)rawptr+wordsize in the case > rawptr is already aligned, which for _malloc it *usually* will be. BUG in my code - and a grievious mistake at that. :-( Wasn't my best day, yesterday. [added backedit line above] > int shift = wordsize; > shift -= ((int)rawptr) % wordsize; --> unsigned int shift = wordsize - 1; shift -= ((unsigned int)rawptr) % wordsize; > Or, we can easily use (byte*)rawptr+0 in that 'special' case: > al_ptr = ((unsigned)rawptr + wordsize-1) & -wordsize; May I? nitpick: casting back to pointer is missing. I like the -wordsize (I always used ~wordsize, which is what you really want and identical for 2's complement signed int machines - do we still have the other kind around, BTW?) And I did the modulo-plus-pointer-shift thing above instead of this bit-masking-shoving-into-int-and-back-into-pointer (which is faster on all machines I know) to allow for those platforms where a pointer does not fit an int (or a long) (e.g. MSVC2005 64-bit i86: int/long = 32 bit, long long = 64 bit, but then 'long long' doesn't exist on older C89 environments, so harder to port (ahem). >> /* perform word-aligned operation: */ >> do_aligned_thing(); >> > on al_ptr for srclen*wordsize, or maybe part(s) thereof, > which you need to pass to it (either directly or indirectly). Indeed. That was left as an exercise for the reader. > IF the aligned processing modified the data, need to copy it back. > Don't forget _cleanse if appropriate and _free. >> >> >> >> So far, 'C class 102'. ;-) >> Now with free lecture notes as well. :-) Thanks for the exchange. Now I can cope with Friday morning again. -- Met vriendelijke groeten / Best regards, Ger Hobbelt -------------------------------------------------- web: http://www.hobbelt.com/ http://www.hebbut.net/ mail: [email protected] mobile: +31-6-11 120 978 -------------------------------------------------- ______________________________________________________________________ OpenSSL Project http://www.openssl.org Development Mailing List [email protected] Automated List Manager [email protected]
