DJ Delorie wrote: >> I'm very suspicious of allowing users to specify this via attributes. > > Me too, but that's what extensions are all about. You never know what > the user is going to need to do.
Sorry, but I think that's far too casual. The long history of GCC extensions causing various kinds of problems is proof positive that new extensions should be added only with extreme care. We've already established the position that new extensions should come with a list of changes to the relevant language standards with the same rigor that would be used to modify the language itself. >> but I don't find it nearly so reasonable to say that some "int *" >> pointers have size four while others have size two. But, maybe I >> just need appropriate motivation. > > Well, it seems to work just fine in C. Well, I think it's in direct conflict with the C++ standard. If "X" is a 32-bit pointer type, and "x" is a value of type X, "Y" is a 16-bit pointer type, then: (X*)(Y*)x is supposed to get you back the value of "x", but I don't see how that can work, in general. So, if you want to do this in C++, you need to work through the language standard and work out how having two distinct classes of pointers is going to work. I think that's doable, but not trivial. For example, you might make the 16-bit pointers "pointers" what the standard calls pointers, and then make the 32-bit pointers "big pointers". You could say that within a single class of pointers, all the usual pointer rules apply. Then, work through things like conversions between the two (is one direction implicit? are these static_casts or reinterpret_casts?), what mangling to use for big pointers, how to encode the types in RTTI, etc. If you really just need these things in a few places (like reset vectors), then I think you'd be better off with a __builtin_long_pointer() intrinsic (returning a 32-bit integer, not pointer) to use in the initializers. You only need two classes of pointers if you expect people to use the second class in non-trivial expressions, i.e., dereference them, perform pointer arithmetic on them, etc. There's also nothing inherently wrong with assembly code; if it's necessary to express the reset vector in assembly code, well, then, so be it. I can well see why doing it in C/C++ is nicer, but I don't think we should try to extend GNU C/C++ to encompass everything that can be done with an assembler. >> Also, there is a nasty class of bugs in G++ stemming from the GCC >> attribute extensions because there are no well-defined rules about how >> to tell if two types with different attributes are the same or >> different, and if they are different what conversions (if any) can be >> used to convert back and forth. > > We have target hooks for function attributes, no reason to avoid > target hooks for data attributes. Sure -- but you still have to say what the semantics are! In my opinion, "it seems to work" arguments are far too loose for making semantic changes to the C++ front end. We've been burned too many times. -- Mark Mitchell CodeSourcery [EMAIL PROTECTED] (650) 331-3385 x713
