Andreas Schwab wrote:
> This thread is about objects of type struct object_id, and their
> address is always the same as the address of its first member.
> Nothing else is relevant.
Indeed. I suggest you ingore that guy, he will only derail the
discussion.
--
Felipe Contreras
--
To unsubscribe f
Andreas Schwab writes:
> David Kastrup writes:
>
>> Your premise is _not_ assumed in my statement. My premise was "a
>> pointer to something of the same type of [the struct's] first member".
>> That does quite explicitly _not_ state that an object of struct type is
>> in existence.
>
> So you a
David Kastrup writes:
> Your premise is _not_ assumed in my statement. My premise was "a
> pointer to something of the same type of [the struct's] first member".
> That does quite explicitly _not_ state that an object of struct type is
> in existence.
So you are not taking about struct object_i
On 05/05/2014 11:50 AM, David Kastrup wrote:
> The case we are talking about is basically passing a pointer to some
> actual bonafide toplevel unsigned char [20] object to a routine that
> expects a pointer to a struct _only_ containing one such
> unsigned char [20] element.
>
> This is the situat
Andreas Schwab writes:
> David Kastrup writes:
>
>> It does not as far as I can see guarantee that a pointer to something
>> of the same type of its first member can be converted to a pointer to
>> a struct even if the struct only contains a member of such type.
>
> This sentence doesn't make an
On 5 May 2014 19:23:06 GMT+10:00, Andreas Schwab wrote:
>David Kastrup writes:
>
>> It does not as far as I can see guarantee that a pointer to something
>> of the same type of its first member can be converted to a pointer to
>> a struct even if the struct only contains a member of such type.
>
David Kastrup writes:
> It does not as far as I can see guarantee that a pointer to something
> of the same type of its first member can be converted to a pointer to
> a struct even if the struct only contains a member of such type.
This sentence doesn't make any sense. If you have an object of
Andreas Schwab writes:
> Johannes Sixt writes:
>
>> Isn't internal padding only allowed between members to achieve correct
>> alignment of later members, and at the end only sufficient padding so
>> that members are aligned correctly when the struct is part of an array?
>
> The standard allows a
Johannes Sixt writes:
> Isn't internal padding only allowed between members to achieve correct
> alignment of later members, and at the end only sufficient padding so
> that members are aligned correctly when the struct is part of an array?
The standard allows arbitrary internal padding, it does
Am 04.05.2014 12:55, schrieb Andreas Schwab:
> Johannes Sixt writes:
>
>> I think that a compiler that has different size and alignment requirements
>> for the proposed struct object_id and an unsigned char[20] would, strictly
>> speaking, not be a "C" compiler.
>
> Unlike arrays, a struct can h
David Kastrup writes:
> Andreas Schwab writes:
>
>> David Kastrup writes:
>>
>>> Andreas Schwab writes:
>>>
"brian m. carlson" writes:
> I don't even plan to write the code assuming that offsetof(struct
> object_id, oid) is 0.
This is guaranteed by the C standard,
Andreas Schwab writes:
> David Kastrup writes:
>
>> Andreas Schwab writes:
>>
>>> "brian m. carlson" writes:
>>>
I don't even plan to write the code assuming that offsetof(struct
object_id, oid) is 0.
>>>
>>> This is guaranteed by the C standard, though.
>>
>> Any reference?
>
> §6.7
David Kastrup writes:
> Andreas Schwab writes:
>
>> "brian m. carlson" writes:
>>
>>> I don't even plan to write the code assuming that offsetof(struct
>>> object_id, oid) is 0.
>>
>> This is guaranteed by the C standard, though.
>
> Any reference?
§6.7.2.1#15
Andreas.
--
Andreas Schwab, sc
Andreas Schwab writes:
> "brian m. carlson" writes:
>
>> I don't even plan to write the code assuming that offsetof(struct
>> object_id, oid) is 0.
>
> This is guaranteed by the C standard, though.
Any reference?
--
David Kastrup
--
To unsubscribe from this list: send the line "unsubscribe gi
"brian m. carlson" writes:
> I don't even plan to write the code assuming that offsetof(struct
> object_id, oid) is 0.
This is guaranteed by the C standard, though.
Andreas.
--
Andreas Schwab, sch...@linux-m68k.org
GPG Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5
"And
On Sun, May 04, 2014 at 08:07:26AM +0200, Michael Haggerty wrote:
> Please clarify whether you plan to rely on all platforms having "the
> same size and alignment constraints" for correctness, or whether that
> observation of the status quo is only meant to reassure us that this
> change won't caus
On Sun, May 4, 2014 at 1:07 PM, Michael Haggerty wrote:
> On 05/03/2014 10:12 PM, brian m. carlson wrote:
>> Many places throughout the code use "unsigned char [20]" to store object IDs
>> (SHA-1 values). This leads to lots of hardcoded numbers throughout the
>> codebase. It also leads to confus
Johannes Sixt writes:
> I think that a compiler that has different size and alignment requirements
> for the proposed struct object_id and an unsigned char[20] would, strictly
> speaking, not be a "C" compiler.
Unlike arrays, a struct can have arbitrary internal padding. It is
perfectly complia
Johannes Sixt writes:
> Am 04.05.2014 08:07, schrieb Michael Haggerty:
>> On 05/03/2014 10:12 PM, brian m. carlson wrote:
>>> Introduce a structure for object IDs. This allows us to obtain the benefits
>>> of compile-time checking for misuse. The structure is expected to remain
>>> the same siz
Am 04.05.2014 08:07, schrieb Michael Haggerty:
On 05/03/2014 10:12 PM, brian m. carlson wrote:
Introduce a structure for object IDs. This allows us to obtain the benefits
of compile-time checking for misuse. The structure is expected to remain
the same size and have the same alignment requirem
On 05/03/2014 10:12 PM, brian m. carlson wrote:
> Many places throughout the code use "unsigned char [20]" to store object IDs
> (SHA-1 values). This leads to lots of hardcoded numbers throughout the
> codebase. It also leads to confusion about the purposes of a buffer.
>
> Introduce a structure
Many places throughout the code use "unsigned char [20]" to store object IDs
(SHA-1 values). This leads to lots of hardcoded numbers throughout the
codebase. It also leads to confusion about the purposes of a buffer.
Introduce a structure for object IDs. This allows us to obtain the benefits
of
22 matches
Mail list logo
