Grant Edwards @ Fri, 15 Feb 2008 15:00:49 +0000 (UTC) > > On 2008-02-15, Oleg Verych <[email protected]> wrote: > >>> If you have to deal with data layed out like that, there's >>> nothing you can do besides doing byte-by-byte access of the >>> misaligned fields. You simply can't have both u1 and u2 >>> aligned. >> >> This is problem of high-level design, or blame whatever you >> want (e.g. 8-bit past, Intel+MS hegemony, C and its >> "implementation-defined"), but not msp430 toolchain. > > Correct. The problem is not the fault of the msp430 toolchain. > > However, other toolchains (including other gcc targets) provide > a solution to the problem, while the msp430 toolchain does not. > What's worse is the compiler _pretends_ to implement a solution > by siliently emitting incorrect code.
Hope, you will agree, that packed attr. and alignment are two different things. > IMO, since the packed struct feature works correctly on other > gcc targets it's quite reasonable for an mspgcc user to expect > that packed structs work on the msp430 target. A bug is when a > product doesn't do what a user reasonably expects it to do -- > regardless of the intentions of the developers. If you're not > going to implemenent accesses to fields of packed structs, then > it should be an error when the user attempts to do so. And GCC does this two things differently. Which is quite OK, when developers have limited time and money to spend. More, AFAIK, attr. packed yields inefficient code for _any_ access to a structure (on those archs), which forces programmer, who wants to write efficient code, to make own tools and to disable GCC's features. >> C was meant to be a macro-language for PDP-11 or something >> like that. > > No it wasn't. "For the first time in 1970, the Unix operating system was officially named and ran on the PDP-11/20."[1] "C is a general-purpose, block structured, procedural, imperative computer programming language developed in 1972 by Dennis Ritchie at the Bell Telephone Laboratories for use with the Unix operating system."[0] [0] http://en.wikipedia.org/wiki/C_%28programming_language%29 [1] http://en.wikipedia.org/wiki/Unix > C was always a compiled language, What i mean by text-processing is, that change code.c, depending of what programmer wants (details and features must be known). For example to analyze codebase for possible unaligned access and to substitute it with access methods needed, if another target or more efficient code is going to be implemented. It's not statically patching code or even ugly #ifdefs. This also can allow run time unaligned access debugging -- you are inserting printf() to check data, or catch CPU exceptions by text processing, but not bloating code and leaving possible bugs, if you've forget to check some other functions manually. And if text patterns and scripts are shared among programmers, this can help to solve many problems. Just raw C code isn't that useful any more. Also, if programmers will know how to write easily readable for text-tools code, then code will be more readable for humans. * Coding styles in BSDs and Linux kernel, thus, technically (not, religiously) are not needed crutches;[2][3] * python is poor parody on all this; * perl is assassin of BREs + `sed`. Some interesting example are in [4]. [2] http://en.wikipedia.org/wiki/Kernel_Normal_Form [3] http://lxr.linux.no/linux/Documentation/CodingStyle [4] http://www.advogato.org/person/olecom/diary/3.html I also think, that validity and security of new code can be made a bit higher. When textbook security holes (dereferencing user supplied pointer, length whatever without prior checking) are put, is it OK NOW? http://www.securityfocus.com/archive/1/487982 http://lwn.net/Articles/268420/ Even worse, is it OK to have buggy official fixes for that??? http://lwn.net/Articles/268664/ This is much more ugly and stupid, than structures without a clue about, what alignment is. ________
