Andreas Schwab sch...@linux-m68k.org writes:
Johannes Sixt j...@kdbg.org 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
David Kastrup d...@gnu.org 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
On 5 May 2014 19:23:06 GMT+10:00, Andreas Schwab sch...@linux-m68k.org wrote:
David Kastrup d...@gnu.org 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
Andreas Schwab sch...@linux-m68k.org writes:
David Kastrup d...@gnu.org 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
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 situation
David Kastrup d...@gnu.org 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
Andreas Schwab sch...@linux-m68k.org writes:
David Kastrup d...@gnu.org 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
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
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 for
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
Johannes Sixt j...@kdbg.org 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
Johannes Sixt j...@kdbg.org 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
On Sun, May 4, 2014 at 1:07 PM, Michael Haggerty mhag...@alum.mit.edu 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
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 cause
brian m. carlson sand...@crustytoothpaste.net 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
Andreas Schwab sch...@linux-m68k.org writes:
brian m. carlson sand...@crustytoothpaste.net 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
David Kastrup d...@gnu.org writes:
Andreas Schwab sch...@linux-m68k.org writes:
brian m. carlson sand...@crustytoothpaste.net 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?
Andreas Schwab sch...@linux-m68k.org writes:
David Kastrup d...@gnu.org writes:
Andreas Schwab sch...@linux-m68k.org writes:
brian m. carlson sand...@crustytoothpaste.net writes:
I don't even plan to write the code assuming that offsetof(struct
object_id, oid) is 0.
This is guaranteed
David Kastrup d...@gnu.org writes:
Andreas Schwab sch...@linux-m68k.org writes:
David Kastrup d...@gnu.org writes:
Andreas Schwab sch...@linux-m68k.org writes:
brian m. carlson sand...@crustytoothpaste.net writes:
I don't even plan to write the code assuming that offsetof(struct
Am 04.05.2014 12:55, schrieb Andreas Schwab:
Johannes Sixt j...@kdbg.org 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
Johannes Sixt j...@kdbg.org 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
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
