Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > C++ > Reading Struct not Located at Four-boundary

Reply
Thread Tools

Reading Struct not Located at Four-boundary

 
 
Francesco S. Carta
Guest
Posts: n/a
 
      08-21-2010
Gennaro Prota <(E-Mail Removed)>, on 21/08/2010 23:39:39, wrote:

> On 21/08/2010 20.31, Francesco S. Carta wrote:
>> Francesco S. Carta<(E-Mail Removed)>, on 21/08/2010 19:35:51, wrote:
>>
>>> the "largest" alignment amounts to 32 bytes on my system

>>
>> Scratch that. I thought it was so, but it was just a weird result of
>> some kind of template hack I've tried to implement on my own in order to
>> guess the actual alignment.
>>
>> I still wonder if the method provided here can be trusted or not:
>>
>> http://www.monkeyspeak.com/alignment/

>
> The article is not very precise. It doesn't exclude some types,
> for instance (non-object types, etc.).


Which are the non-object types?

> And when T is not a POD, there can be padding before t in


I have skimmed the standard and I only found a mention about the fact
that a POD type cannot have initial padding, does that suffice to imply
that non-POD types can actually have initial padding or is there some
other explicit reference in the standard?

> struct Foo { T t ; char c ; } ;
>
> or even before c in
>
> struct Foo { char c ; T t ; } ;
>
> In the latter case, though, that's unlikely.
>
> FWIW, I'm using a similar technique for "computing" a suitable
> alignment down in my (experimental) version of fallible<> (the
> non-experimental version has a T member and requires
> default-construction, just like the Barton& Nackman one; the
> new version drops the default-constructible requirement and uses
> placement new---using, of course, a "suitably aligned" array of
> unsigned chars).
>
> Copy-pasting from there (beware: I have yet to review it---and
> it started as a quick experiment):
>
> template< typename T>
> struct align_of
> {
> struct trick { // gps how to name it?
> char c ;
> T t ;
> } ;
>
> enum { v = sizeof( trick ) - sizeof( T ) } ;
> enum { has_padding_at_end = v> sizeof( T ) } ; // should name
> // this better
>
> static std::size_t const value = has_padding_at_end
> ? sizeof( T )
> : v
> ;
> } ;
>
> template< typename T>
> std::size_t const
> align_of< T>::value ;
>
>
> When T is a POD the whole trick structure (which contains only a
> T and a char) is a POD as well: thus there can't be padding
> before the first member. (And I find it slightly clearer if the
> char appears first.)
>
> When T is not a POD, that padding is allowed. I see no reason
> for the compiler to exploit that possibility with the struct
> above. Anyway, if it is that "capricious" the whole thing breaks
> down (numerical "coincidences" apart ).


I suppose you could compute the initial padding by subtracting the
address of the object from the address of the first member - assuming
that is doable and useful...

> Of course, this template is not exposed: it's only used
> internally, to try one after another the POD types in a
> predefined "list", in order to find the first of them (if any)
> that has the same alignment as the type T on which fallible<> is
> instantiated (more precisely: for which align_of<>::value is the
> same as align_of< T>::value). At the end of the dance, it
> doesn't matter what the alignment really is, numerically: it
> picks the POD and puts it in the same union that contains the
> array of unsigned chars.
>
> Another thing I found perplexing in the article was
>
> template<typename T>
> struct Tchar {
> T t;
> char c;
> };
>
> #define strideof(T) \
> ((sizeof(Tchar<T>)> sizeof(T)) ? \
> sizeof(Tchar<T>)-sizeof(T) : sizeof(T))
>
>
> How can ever be the size of the struct be smaller than, or even
> equal to, sizeof( T )? [footnote]


> [footnote] I'm aware that in some cases an object may be
> "smaller than its type" (virtual base classes etc.) but in this
> case...


The author of that macro explains what (and why) has been addressed by
that ternary test: it's something about a possible and presumably
illegal padding reuse, I reported it also in the other replies to the
message you have just quoted from me.

--
FSC - http://userscripts.org/scripts/show/59948
http://fscode.altervista.org - http://sardinias.com
 
Reply With Quote
 
 
 
 
Francesco S. Carta
Guest
Posts: n/a
 
      08-21-2010
Gennaro Prota <(E-Mail Removed)>, on 22/08/2010 00:22:13, wrote:

> On 21/08/2010 20.58, Francesco S. Carta wrote:
> [...]
>>>> In any case, I was surely overlooking (once more) the difference between
>>>> using plain "new" and calling "the operator new function". How were they
>>>> commonly referred to? "new expression" and "operator new"?
>>>
>>> Use the terminology of the standard ("new expression" and
>>> "operator new function")!

>>
>> Indeed I should, I just need more study to actually associate some
>> well-grasped content to those labels
>>
>>> <asides>
>>> - The reason for the excitement and the consequent exclamation
>>> point is that I do use it, and I feel lonely.

>>
>> Of course you're not the only one who uses the standard terms. I
>> actually try to use them as long as I feel on firm ground.

>
> Oh, but it wasn't addressed at you! And it was meant to be
> humorous ("I feel lonely" ). I just find that for these two
> things using the standard terminology isn't very common.


Sorry, I understood that yours was a pun, I just forgot to interleave a
smile between those two sentences

The second sentence was just to say that I try to speak "formally and
technically" despite being a DIY full-time hobbyist, whatever that could
mean

>
>>> - If you really want to refer to the operator (as opposed to
>>> the expression) you have to think more.

>>
>> This is not clear to me. Do you mean that I should think more if I
>> decide to add an "operator new" to some class?

>
> No no, it was one of my "off at a tangent" thoughts. I was
> thinking that the standard names work well because one of them
> avoids the term "operator" altogether, referring to the
> expression, instead. But *if* you need to talk about the
> operator (the "lexical thing"), together with the operator
> function, then things become more awkward. I meant: you'd have
> to think more about how to avoid confusion.
>
> Just to clarify:
>
> 3 + 2 additive "expression"
> ^--------- + operator
>
> Similarly:
>
> new T() new expression
> ^---------- new operator
>
> An operator and an expression are two different things; it just
> happens that in most cases we can "get away" by referring to the
> expression (in fact, it usually makes more sense than referring
> to the lexical notion, unless the topic of discussion is
> compilers, etc.).
>
> I hope I managed to explain what crossed my mind
>


You did, fully.

As I see them now and as I posted elsethread, "operator new" and "new
operator" do not look all that ambiguous anymore.

For the moment I feel that no additional thinking is needed to parse
them and to insert them into my sentences - but maybe that will change
within a couple of weeks, when the whole subject will pass to some
second plane of my attention

--
FSC - http://userscripts.org/scripts/show/59948
http://fscode.altervista.org - http://sardinias.com
 
Reply With Quote
 
 
 
 
Gennaro Prota
Guest
Posts: n/a
 
      08-22-2010
Hmm, well, with the caveat that I've just been through a
sleepless night, I'll try to correct myself. (Ehm :-s)

[...]
> And when T is not a POD, there can be padding before t in
>
> struct Foo { T t ; char c ; } ;
>
> or even before c in
>
> struct Foo { char c ; T t ; } ;


True, but the sizeof() - sizeof() would still work.

For reference, we are trying to calculate the alignment of a
type T (or a multiple thereof) as:

struct Foo
{
char c ;
T t ;
} ;

align_of( T ) = sizeof( Foo ) - sizeof( T )

Hereby I'll call this "the technique".

It may be helpful for learning purposes to use the same example
that made me realize that I was in error (actually I knew all
the pieces that go into the puzzle, and shouldn't have needed
the example. Yet... I needed it :-/)

I was trying to make the technique fail, thinking of odd but
legal ways to add padding within the structure Foo.

Let's consider the case that the alignment of our T, as well as
its size in bytes, are 4. (In the following I'll use the
expression "at n" as a shorthand to "at n-byte boundaries").

One obvious think to do for the compiler is to align any
instance of Foo at 4 as well, putting 4 bytes before t (one for
the char plus 3 padding bytes).

But given that the char may be moved happily around and be
placed "everywhere", the compiler might "decide" (I think) that
instances of Foo will always be allocated at addresses that are
multiples of 2 but not of 4. That is, addresses of the form
2(2k-1) = 4k-2 (with k = 1, 2, 3, 4, ...) or, which is the same,
4(k-1)+2.

Just to fix our attention, let's put k=1. In this case, it would
put the char and one padding byte at the addresses 0x2 and 0x3,
then the subobject t at 0x04.

I thought that this would make the technique fail because I'd
got sizeof( Foo ) = 6 => align_of( T ) = 6 - 4 = 2.

But I was wrong. If the compiler does so, it has to add more
padding at the end. Consider, in fact, another Foo instance
which immediately follows the first one (think of an array). If
sizeof( Foo ) were 6 then the second instance would have the
char and the padding byte at 0x08 and 0x09, and then t at 0x0a:
misaligned! To make things line up properly the compiler would
have to add another 2 bytes (or 6, 10, 14...) at the end of the
struct. Thus the technique would work anyway.

I think that I got confused by thinking in terms of offset from
start only. In C, you may find a similar technique:

#define align_of( T ) offsetof( struct { char c; T t ; }, t )

This one *would* fail with my example. The sizeof() - sizeof()
is more powerful than offsetof, even in C.


It's also useful IMHO to spell out some guarantees on which all
the reasonings that are behind the technique may rest:

- T must not be an array type (actually I haven't thought much
about this; it may work, but I think it's just easier to treat
the case separately, saying that the alignment of an array
object is that of its first element (recursively))

- T must not be a reference type (we'd have problems due to how
sizeof works on a reference type)

- T must be instantiatable, and arrays of T must be
instantiatable too. Thus, for instance, no abstract classes,
no types whose constructors are all =delete.

- alignment must be a function *of the type*. In fact, we don't
even instantiate Foo but make reasonings (it's a multiple of
this, it's a multiple of that...) about the address at which
its instances will be allocated. In particular, we don't
consider the case that, say, instances within arrays are
aligned at 8 and "standalone instances" are aligned at 2. We
consider *one* alignment value.

--
Gennaro Prota | I'm available for your projects.
Breeze (preview): <https://sourceforge.net/projects/breeze/>
 
Reply With Quote
 
Juha Nieminen
Guest
Posts: n/a
 
      08-22-2010
Paavo Helde <(E-Mail Removed)> wrote:
> Accessing unaligned data is UB, depending on the platform this may crash
> or produce wrong results. On some platforms it may works (notably x86),
> but with a performance penalty.


UltraSparc is an example of a platform where trying to access unaligned
data will crash the program (with a "bus error" signal, to be precise).

Accessing unaligned data in portable code is indeed a no-no.
 
Reply With Quote
 
Larry Evans
Guest
Posts: n/a
 
      08-22-2010
On 08/21/10 13:31, Francesco S. Carta wrote:
[snip]
> I still wonder if the method provided here can be trusted or not:
>
> http://www.monkeyspeak.com/alignment/
>
> Take a look at the following piece of code and its results on my setup
> [MinGW 4.4.0, Windows7, AMD Athlon(tm) II Dual-Core M300 2.00 Ghz]
>
> I wonder why "long double" gives a stride of 4 while "double" gives a
> stride of 8 - where "stride" should stand for something like
> "alignment", in the above linked page:
>
> (maybe "long double" is stored as three floats or three longs in my
> implementation?)

[snip]
See if:


http://www.boost.org/doc/libs/1_44_0...gnment_of.html

doesn't give a better number. It's implementation:

http://svn.boost.org/svn/boost/trunk...ignment_of.hpp

does seem to use a similar method as the monkeyspeak one in some
cases; however, the comments in that code do suggest it doesn't always
get the right answer. Also, it uses a different order of T and char:

template <typename T>
struct alignment_of_hack
{
char c;
T t;
alignment_of_hack();
};

 
Reply With Quote
 
Larry Evans
Guest
Posts: n/a
 
      08-22-2010
On 08/22/10 04:15, Gennaro Prota wrote:
[snip]
> struct Foo
> {
> char c ;
> T t ;
> } ;
>

[snip]
> One obvious think to do for the compiler is to align any
> instance of Foo at 4 as well, putting 4 bytes before t (one for
> the char plus 3 padding bytes).
>
> But given that the char may be moved happily around and be
> placed "everywhere", the compiler might "decide" (I think) that
> instances of Foo will always be allocated at addresses that are
> multiples of 2 but not of 4. That is, addresses of the form
> 2(2k-1) = 4k-2 (with k = 1, 2, 3, 4, ...) or, which is the same,
> 4(k-1)+2.
>
> Just to fix our attention, let's put k=1. In this case, it would
> put the char and one padding byte at the addresses 0x2 and 0x3,
> then the subobject t at 0x04.
>
> I thought that this would make the technique fail because I'd
> got sizeof( Foo ) = 6 => align_of( T ) = 6 - 4 = 2.


To be more explicit, lets call the Foo at the address designated by k=1
as foo, then the 6 comes from:
offset(Foo,t)+sizeof(T) - &foo
= 0x04+sizeof(T) - 0x2
= 0x04+0x04 - 0x2
= 0x08 - 0x2
= 0x06

Although it may seem obvious to you (as it does now to me)
it wasn't obvious to me before where the 6 came from

>
> But I was wrong. If the compiler does so, it has to add more
> padding at the end. Consider, in fact, another Foo instance
> which immediately follows the first one (think of an array). If
> sizeof( Foo ) were 6 then the second instance would have the
> char and the padding byte at 0x08 and 0x09, and then t at 0x0a:
> misaligned! To make things line up properly the compiler would
> have to add another 2 bytes (or 6, 10, 14...) at the end of the
> struct. Thus the technique would work anyway.


So, what's the sizeof(Foo) then? I'm not understanding why
you say the technique would work anyway. Are you saying it would
work if sizeof(Foo) is a certain value? Then what is that value
that would make it work? I'm guessing that only sizeof(Foo) = 8
would work as suggested by the above quoted sentence, repeated here:

> One obvious think to do for the compiler is to align any
> instance of Foo at 4 as well, putting 4 bytes before t (one for
> the char plus 3 padding bytes).


[snip]
 
Reply With Quote
 
Gennaro Prota
Guest
Posts: n/a
 
      08-22-2010
On 22/08/2010 16.10, Larry Evans wrote:
> On 08/22/10 04:15, Gennaro Prota wrote:
> [snip]
>> struct Foo
>> {
>> char c ;
>> T t ;
>> } ;
>>

> [snip]
>> One obvious think to do for the compiler is to align any
>> instance of Foo at 4 as well, putting 4 bytes before t (one for
>> the char plus 3 padding bytes).
>>
>> But given that the char may be moved happily around and be
>> placed "everywhere", the compiler might "decide" (I think) that
>> instances of Foo will always be allocated at addresses that are
>> multiples of 2 but not of 4. That is, addresses of the form
>> 2(2k-1) = 4k-2 (with k = 1, 2, 3, 4, ...) or, which is the same,
>> 4(k-1)+2.
>>
>> Just to fix our attention, let's put k=1. In this case, it would
>> put the char and one padding byte at the addresses 0x2 and 0x3,
>> then the subobject t at 0x04.
>>
>> I thought that this would make the technique fail because I'd
>> got sizeof( Foo ) = 6 => align_of( T ) = 6 - 4 = 2.

>
> To be more explicit, lets call the Foo at the address designated by k=1
> as foo, then the 6 comes from:
> offset(Foo,t)+sizeof(T) - &foo
> = 0x04+sizeof(T) - 0x2
> = 0x04+0x04 - 0x2
> = 0x08 - 0x2
> = 0x06


No. It came from 2 (the offset before t in the layout I
imagined) plus sizeof( T ): I thought, stupidly, that the
compiler could "terminate" the structure Foo just after t.

> Although it may seem obvious to you (as it does now to me)
> it wasn't obvious to me before where the 6 came from
>
>>
>> But I was wrong. If the compiler does so, it has to add more
>> padding at the end. Consider, in fact, another Foo instance
>> which immediately follows the first one (think of an array). If
>> sizeof( Foo ) were 6 then the second instance would have the
>> char and the padding byte at 0x08 and 0x09, and then t at 0x0a:
>> misaligned! To make things line up properly the compiler would
>> have to add another 2 bytes (or 6, 10, 14...) at the end of the
>> struct. Thus the technique would work anyway.

>
> So, what's the sizeof(Foo) then?


It can be 8, 12, 16, ... but not 6. See also what is called
Appendix 2 in the article Francesco linked to.

> I'm not understanding why
> you say the technique would work anyway.


Because both sizeof( Foo ) and sizeof( T ) are multiples of the
alignment of T. Thus their difference is, too.

--
Gennaro Prota | I'm available for your projects.
Breeze (preview): <https://sourceforge.net/projects/breeze/>
 
Reply With Quote
 
Gennaro Prota
Guest
Posts: n/a
 
      08-22-2010
On 22/08/2010 1.33, Francesco S. Carta wrote:
> Gennaro Prota <(E-Mail Removed)>, on 21/08/2010 23:39:39, wrote:
>
>> On 21/08/2010 20.31, Francesco S. Carta wrote:
>>> Francesco S. Carta<(E-Mail Removed)>, on 21/08/2010 19:35:51, wrote:
>>>
>>>> the "largest" alignment amounts to 32 bytes on my system
>>>
>>> Scratch that. I thought it was so, but it was just a weird result of
>>> some kind of template hack I've tried to implement on my own in order to
>>> guess the actual alignment.
>>>
>>> I still wonder if the method provided here can be trusted or not:
>>>
>>> http://www.monkeyspeak.com/alignment/

>>
>> The article is not very precise. It doesn't exclude some types,
>> for instance (non-object types, etc.).

>
> Which are the non-object types?


See and [basic.types]/5 and [basic.types]/9. (For the non-"non-"
version )

>> And when T is not a POD, there can be padding before t in

>
> I have skimmed the standard and I only found a mention about the fact
> that a POD type cannot have initial padding, does that suffice to imply
> that non-POD types can actually have initial padding or is there some
> other explicit reference in the standard?


I see no explicit reference, but the rules seem to be carefully
crafted to allow it. I'm sure someone will come up with an
example where it is necessary. I'm just too tired right now to
think of anything sensible.

[...]
>> Another thing I found perplexing in the article was
>>
>> template<typename T>
>> struct Tchar {
>> T t;
>> char c;
>> };
>>
>> #define strideof(T) \
>> ((sizeof(Tchar<T>)> sizeof(T)) ? \
>> sizeof(Tchar<T>)-sizeof(T) : sizeof(T))
>>
>>
>> How can ever be the size of the struct be smaller than, or even
>> equal to, sizeof( T )? [footnote]

>
>> [footnote] I'm aware that in some cases an object may be
>> "smaller than its type" (virtual base classes etc.) but in this
>> case...

>
> The author of that macro explains what (and why) has been addressed by
> that ternary test: it's something about a possible and presumably
> illegal padding reuse, I reported it also in the other replies to the
> message you have just quoted from me.


OK. It had never occurred to me but, apparently, it has been
asked, even to the C committee. See bullet g of

<http://www.open-std.org/jtc1/sc22/wg14/www/docs/dr_074.html>

I don't have the C90 standard so I can't tell what the content
of subclause 6.3 is. I suspect that it's something related to
accessing the object at runtime, though (such as memset()'ing t
and getting something in c). Could anyone provide a quotation?

So, if my guess is right, one might claim that if the struct is
never instantiated... Or he can invent cases that are slightly
different from question g in that DR... I'd say that the intent
is just to disallow it, and quickly skimming through a couple of
comp.std.c threads seems to confirm my gut feeling.

As Francis Glassborow put it in one of the posts that I read:

I do not think you need specific text [that prohibits that
reusage] because as you have already noted, such an
arrangement would result in storage for a variable being
changed without program instruction. Such behaviour must be
wrong else we might as well all give up and go home.

In fact, when the "questioning" reaches such a fundamental level
I begin to hate C++. Especially since the standard doesn't
provide ground to prove these theorems, even if you are willing
to (but even if you are... how can you program if you have to
prove theorems in the language at every corner).

BTW, that DR also has some bad news in the answer to bullet a.
For the little that I've been able to gather from the new C++0x
requirements, this seems an incompatibility between C and C++
(because C++ seems to intend that the alignment is a function of
the type: an object of the same type has the same alignment. But
as you might have seen, I've asked for a confirmation about
this, without success. In fact, I'm looking for an effective way
to deal with it before C++0x is finalized. Some national body
should probably help, as a DR would just be dealt with after the
publication of the standard).

--
Gennaro Prota | I'm available for your projects.
Breeze (preview): <https://sourceforge.net/projects/breeze/>
 
Reply With Quote
 
Larry Evans
Guest
Posts: n/a
 
      08-22-2010
On 08/21/10 12:35, Francesco S. Carta wrote:
> Larry Evans <(E-Mail Removed)>, on 21/08/2010 11:06:36, wrote:
>
>> On 08/21/10 06:30, Francesco S. Carta wrote:
>> [snip]
>>> I've created a struct that occupies 64 bytes of storage, then I
>>> dynamically allocated it and I checked its address to see if, as I was
>>> expecting, it was a multiple of 64. As it turned out, it wasn't, showing
>>> me that my assumption was stupid at best.
>>>
>>> I have no idea about where I have taken that misconception from, I could
>>> very well have made it up all by myself.

>> [snip]
>>
>> Hi Francesco.
>>
>> I struggled a few yrs (months?) ago about that and think I've
>> figured it out.
>>
>> The alignment of your 64 byte long structure is dependent on the
>> types contained in the structure.

>
> Hi Larry, thank you for your post.
>
> Indeed, I suspected something like that, by now I see that regardless of
> what I am allocating, the "largest" alignment amounts to 32 bytes on my
> system, so it all should come down to the most stringent alignment
> required for fundamental types.
>
>> Using variadic template:

>
> I'm snipping all of your post for brevity as...
>
> <snip>
>
>> Sorry if this seems complicated. It is, at least to me

>
> ...believe me, all of that is not complicated for me, it is just plain
> unintelligible: I never really put my hands on such advanced features of
> the upcoming new C++ standard, I've only read about some of them in some
> article here and there, I'm afraid I'll have to stay on the current
> standard for some good time still, as there are too many basic concepts
> that still trick me even if I already have acquired some good bits on
> all the existing features.

The statement from my previous post:

alignof(C) == fold(lcm,1,alignof(T)...)

is suggested by:

> Can A(struct foo) be greater than the least common multiple of
> A(type_1), A(type_2), ..., A(type_n),
> where type_1 to type_n are the types of the elements of struct foo?


from the defect report (DR) reference Gennaro gave (thanks Gennaro)
in another post:

http://groups.google.com/group/comp....d02e03e148dea3

More explicitly:

alignof(T)... in my post
corresponds to:
A(type_1), A(type_2), ..., A(type_n) from the DR.

alignof(C) in my post
corresponds to:
A(struct foo) from the DR.

Does that make things clearer? I did write some justifcation
for this and uploaded it to the boost vault. IIRC, the
justification is just in a .txt file and I think (judging
from the description shown on the web) that it located somewhere
in the zip file here:

http://www.boostpro.com/vault/index....=downloadfile&
filename=aligned_types.2.zip&directory=variadic_te mplates&

I'm pretty sure the .txt file doesn't use in variadic template
notation; so, hopefully that won't be part of any roadblock to
your understanding.

HTH.

-Larry


 
Reply With Quote
 
Francesco S. Carta
Guest
Posts: n/a
 
      08-22-2010
Gennaro Prota <(E-Mail Removed)>, on 22/08/2010 20:56:33, wrote:

> On 22/08/2010 1.33, Francesco S. Carta wrote:
>> Gennaro Prota<(E-Mail Removed)>, on 21/08/2010 23:39:39, wrote:
>>
>>> On 21/08/2010 20.31, Francesco S. Carta wrote:
>>>> Francesco S. Carta<(E-Mail Removed)>, on 21/08/2010 19:35:51, wrote:
>>>>
>>>>> the "largest" alignment amounts to 32 bytes on my system
>>>>
>>>> Scratch that. I thought it was so, but it was just a weird result of
>>>> some kind of template hack I've tried to implement on my own in order to
>>>> guess the actual alignment.
>>>>
>>>> I still wonder if the method provided here can be trusted or not:
>>>>
>>>> http://www.monkeyspeak.com/alignment/
>>>
>>> The article is not very precise. It doesn't exclude some types,
>>> for instance (non-object types, etc.).

>>
>> Which are the non-object types?

>
> See and [basic.types]/5 and [basic.types]/9. (For the non-"non-"
> version )


Ah, yes, of course, silly me...

>>> And when T is not a POD, there can be padding before t in

>>
>> I have skimmed the standard and I only found a mention about the fact
>> that a POD type cannot have initial padding, does that suffice to imply
>> that non-POD types can actually have initial padding or is there some
>> other explicit reference in the standard?

>
> I see no explicit reference, but the rules seem to be carefully
> crafted to allow it. I'm sure someone will come up with an
> example where it is necessary. I'm just too tired right now to
> think of anything sensible.


I'm really curious to see an example where such initial padding could
come useful... anybody else still keeping an eye here?

> [...]
>>> Another thing I found perplexing in the article was
>>>
>>> template<typename T>
>>> struct Tchar {
>>> T t;
>>> char c;
>>> };
>>>
>>> #define strideof(T) \
>>> ((sizeof(Tchar<T>)> sizeof(T)) ? \
>>> sizeof(Tchar<T>)-sizeof(T) : sizeof(T))
>>>
>>>
>>> How can ever be the size of the struct be smaller than, or even
>>> equal to, sizeof( T )? [footnote]

>>
>>> [footnote] I'm aware that in some cases an object may be
>>> "smaller than its type" (virtual base classes etc.) but in this
>>> case...

>>
>> The author of that macro explains what (and why) has been addressed by
>> that ternary test: it's something about a possible and presumably
>> illegal padding reuse, I reported it also in the other replies to the
>> message you have just quoted from me.

>
> OK. It had never occurred to me but, apparently, it has been
> asked, even to the C committee. See bullet g of
>
> <http://www.open-std.org/jtc1/sc22/wg14/www/docs/dr_074.html>
>
> I don't have the C90 standard so I can't tell what the content
> of subclause 6.3 is. I suspect that it's something related to
> accessing the object at runtime, though (such as memset()'ing t
> and getting something in c). Could anyone provide a quotation?
>
> So, if my guess is right, one might claim that if the struct is
> never instantiated... Or he can invent cases that are slightly
> different from question g in that DR... I'd say that the intent
> is just to disallow it, and quickly skimming through a couple of
> comp.std.c threads seems to confirm my gut feeling.
>
> As Francis Glassborow put it in one of the posts that I read:
>
> I do not think you need specific text [that prohibits that
> reusage] because as you have already noted, such an
> arrangement would result in storage for a variable being
> changed without program instruction. Such behaviour must be
> wrong else we might as well all give up and go home.
>
> In fact, when the "questioning" reaches such a fundamental level
> I begin to hate C++. Especially since the standard doesn't
> provide ground to prove these theorems, even if you are willing
> to (but even if you are... how can you program if you have to
> prove theorems in the language at every corner).
>
> BTW, that DR also has some bad news in the answer to bullet a.
> For the little that I've been able to gather from the new C++0x
> requirements, this seems an incompatibility between C and C++
> (because C++ seems to intend that the alignment is a function of
> the type: an object of the same type has the same alignment. But
> as you might have seen, I've asked for a confirmation about
> this, without success. In fact, I'm looking for an effective way
> to deal with it before C++0x is finalized. Some national body
> should probably help, as a DR would just be dealt with after the
> publication of the standard).
>


Thanks for the references.

As I mentioned elsethread, I'm almost completely unaware of the details
of the new standard, I only had a read to some articles here and there,
but sooner or later I'll have to dip my fingers there.

Unfortunately I cannot give any help about your reports... isn't there
in the committee some Italian entity or person that you could contact to
focus a bit of attention on those issues?

Well maybe you just need to exercise some more patience, your reports
can still get a feedback before the new publication, I think.

Or eventually, I wonder whether the DR is not the proper shape to
present those issues, as you say those should be addressed after the
publication... but I'm far from my firm ground, so I'll be better
shutting up before writing some (further) silliness

--
FSC - http://userscripts.org/scripts/show/59948
http://fscode.altervista.org - http://sardinias.com
 
Reply With Quote
 
 
 
Reply

Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
Can *common* struct-members of 2 different struct-types, that are thesame for the first common members, be accessed via pointer cast to either struct-type? John Reye C Programming 28 05-08-2012 12:24 AM
static struct initialization in a Class:: -- not my struct christian.bongiorno@gmail.com C++ 2 09-20-2006 06:53 PM
Printer not located in new laptop from wireless network =?Utf-8?B?dG1jZ2luNzEwMzk1?= Wireless Networking 3 04-19-2006 02:15 AM
struct my_struct *p = (struct my_struct *)malloc(sizeof(struct my_struct)); Chris Fogelklou C Programming 36 04-20-2004 08:27 AM
To coerce or not...? struct sockaddr vs struct sockaddr_in James Harris C Programming 4 10-09-2003 10:06 PM



Advertisments