On Monday, 18 September 2017 at 02:04:49 UTC, bitwise wrote:
The following code will run fine on Windows, but crash on iOS
due to the misaligned access:
Interesting, does iOS crash such a process intentionally, or is
it a side effect?
char data[8];
int i = 0x;
int* p = (int*)&dat
On Monday, 18 September 2017 at 02:04:49 UTC, bitwise wrote:
On Monday, 18 September 2017 at 00:12:49 UTC, Mike Parker wrote:
On Sunday, 17 September 2017 at 19:16:06 UTC, bitwise wrote:
[...]
I've been maintaining bindings to multiple C libraries
(including Freetype 2 bindings) for 13 years
On Monday, 18 September 2017 at 00:12:49 UTC, Mike Parker wrote:
On Sunday, 17 September 2017 at 19:16:06 UTC, bitwise wrote:
[...]
I've been maintaining bindings to multiple C libraries
(including Freetype 2 bindings) for 13 years now. I have never
encountered an issue with an enum size mis
On Sunday, 17 September 2017 at 19:16:06 UTC, bitwise wrote:
On Sunday, 17 September 2017 at 18:44:47 UTC, nkm1 wrote:
On Sunday, 17 September 2017 at 17:06:10 UTC, bitwise wrote:
[...]
Just put the burden on the users then. It's implementation
defined, so they are in position to figure it o
On Sunday, 17 September 2017 at 18:44:47 UTC, nkm1 wrote:
On Sunday, 17 September 2017 at 17:06:10 UTC, bitwise wrote:
[...]
Just put the burden on the users then. It's implementation
defined, so they are in position to figure it out...
This isn't something that can really be done with bind
On Sunday, 17 September 2017 at 17:06:10 UTC, bitwise wrote:
I don't really see a way to deal with this aside from branching
the entire library and inserting something like
'FT_SIZE_REQUEST_TYPE__FORCE_INT = 0x' into every enum
incase the devs used it in a struct.
Just put the burden
On Saturday, 16 September 2017 at 12:34:58 UTC, nkm1 wrote:
On Saturday, 16 September 2017 at 03:06:24 UTC, Timothy Foster
wrote:
[...]
[...]
So it appears I'm screwed then.
Example:
typedef enum FT_Size_Request_Type_
{
FT_SIZE_REQUEST_TYPE_NOMINAL,
FT_SIZE_REQUEST_TYPE_REAL_DIM,
On Saturday, 16 September 2017 at 03:06:24 UTC, Timothy Foster
wrote:
You are correct, however 6.7.2.2 "Enumeration specifiers"
states: "Each enumerated type shall be compatible with char, a
signed integer type, or an unsigned integer type. The choice of
type is implementation-defined, but shal
On Friday, 15 September 2017 at 19:35:50 UTC, nkm1 wrote:
On Friday, 15 September 2017 at 19:21:02 UTC, Timothy Foster
wrote:
I believe C enum size is implementation defined. A C compiler
can pick the underlying type (1, 2, or 4 bytes, signed or
unsigned) that fits the values in the enum.
No,
On Friday, September 15, 2017 19:04:56 jmh530 via Digitalmars-d-learn wrote:
> On Friday, 15 September 2017 at 18:20:06 UTC, Jonathan M Davis
>
> wrote:
> > It is my understanding that for both C and C++, an enum is
> > always an int (unless you're talking about enum classes in
> > C++). The size o
On Friday, 15 September 2017 at 19:35:50 UTC, nkm1 wrote:
On Friday, 15 September 2017 at 19:21:02 UTC, Timothy Foster
wrote:
I believe C enum size is implementation defined. A C compiler
can pick the underlying type (1, 2, or 4 bytes, signed or
unsigned) that fits the values in the enum.
No,
On Friday, 15 September 2017 at 19:21:02 UTC, Timothy Foster
wrote:
I believe C enum size is implementation defined. A C compiler
can pick the underlying type (1, 2, or 4 bytes, signed or
unsigned) that fits the values in the enum.
No, at least, not C99. See 6.4.4.3: "An identifier declared as
struct members.
If I declare an extern(C) enum in D, is it guaranteed to have
the same underlying type and size as it would for a C
compiler on the same platform?
extern(C) should have no effect on enums. It's for function
linkage, and enums don't even have an address, so they don&#
On Friday, 15 September 2017 at 18:20:06 UTC, Jonathan M Davis
wrote:
It is my understanding that for both C and C++, an enum is
always an int (unless you're talking about enum classes in
C++). The size of an int can change based on your architecture,
but AFAIK, all of the architectures suppo
the headers for FreeType2 to D, and in many
> >> cases, enums are used as struct members.
> >>
> >> If I declare an extern(C) enum in D, is it guaranteed to have
> >> the same underlying type and size as it would for a C compiler
> >> on the s
On Friday, 15 September 2017 at 07:24:34 UTC, Jonathan M Davis
wrote:
On Friday, September 15, 2017 04:15:57 bitwise via
Digitalmars-d-learn wrote:
I translated the headers for FreeType2 to D, and in many
cases, enums are used as struct members.
If I declare an extern(C) enum in D, is it
On Friday, 15 September 2017 at 06:57:31 UTC, rikki cattermole
wrote:
On 15/09/2017 5:15 AM, bitwise wrote:
I translated the headers for FreeType2 to D, and in many
cases, enums are used as struct members.
If I declare an extern(C) enum in D, is it guaranteed to have
the same underlying type
On Friday, September 15, 2017 04:15:57 bitwise via Digitalmars-d-learn
wrote:
> I translated the headers for FreeType2 to D, and in many cases,
> enums are used as struct members.
>
> If I declare an extern(C) enum in D, is it guaranteed to have the
> same underlying type and size
On 15/09/2017 5:15 AM, bitwise wrote:
I translated the headers for FreeType2 to D, and in many cases, enums
are used as struct members.
If I declare an extern(C) enum in D, is it guaranteed to have the same
underlying type and size as it would for a C compiler on the same platform?
No need
I translated the headers for FreeType2 to D, and in many cases,
enums are used as struct members.
If I declare an extern(C) enum in D, is it guaranteed to have the
same underlying type and size as it would for a C compiler on the
same platform?
20 matches
Mail list logo
