Alignment

[CBFalconer]

.... snip ...

compute the Gödel number of a mathematical theorem and multiply
it by three, you usually won't get the Gödel number of another
mathematical theorem).

What in the devil is a 'GAFdel' number. That is very roughly the
appearence here of that expresssion.

 

[Keith Thompson]

What in the devil is a 'GAFdel' number. That is very roughly the
appearence here of that expresssion.

In my newsreader, it looked like "Godel", with an umlaut (two dots)
over the 'o', as it was intended to. The article used a UTF-8
encoding, which of course not all newsreaders are going to recognize.
Since Peter is posting from Austria (.at), I'm sure it's easy to
forget that not everyone can cope with umlauts.

 

[Peter J. Holzer]

In my newsreader, it looked like "Godel", with an umlaut (two dots)
over the 'o', as it was intended to. The article used a UTF-8
encoding, which of course not all newsreaders are going to recognize.
Since Peter is posting from Austria (.at), I'm sure it's easy to
forget that not everyone can cope with umlauts.

I don't forget that, but I prefer correct spelling over indulging
users of outdated software. MIME is now 15 years old, UTF-8 not much
younger, so I do think that if somebody still uses software which
doesn't support them, it's their problem and not the the problem of
everybody else. (Incidentally, the newsreader I use doesn't implement
MIME completely, either. But if I come across a posting which uses a
missing feature (e.g. multipart), then I'll ignore the posting or fix it
manually[0] - I won't complain to the poster).

hp

[0] And if there are too many such postings, I'll fix the newsreader.

 

[CBFalconer]

.... snip ...

In my newsreader, it looked like "Godel", with an umlaut (two dots)
over the 'o', as it was intended to. The article used a UTF-8
encoding, which of course not all newsreaders are going to recognize.
Since Peter is posting from Austria (.at), I'm sure it's easy to
forget that not everyone can cope with umlauts.

I don't forget that, but I prefer correct spelling over indulging
users of outdated software. MIME is now 15 years old, UTF-8 not much
younger, so I do think that if somebody still uses software which
doesn't support them, it's their problem and not the the problem of
everybody else. (Incidentally, the newsreader I use doesn't implement
MIME completely, either. But if I come across a posting which uses a
missing feature (e.g. multipart), then I'll ignore the posting or fix it
manually[0] - I won't complain to the poster).

I asked for information. I don't recall complaining.

 

[Peter J. Holzer]

[...]
I asked for information. I don't recall complaining.

Ah sorry. I was taking for granted that everbody who's into programming
had heard of Kurt Goedel and would recognize the name even if it was
slightly garbled (but then I'm used to that kind of garbling - character
encoding problems have been me ever since I first turned on an Apple UA
(sorry, Apple ][) 23 years ago). So I didn't consider that you were
really asking for information.

hp

PS: http://en.wikipedia.org/wiki/Kurt_gödel
http://en.wikipedia.org/wiki/Gödel's_incompleteness_theorems

 

[Richard Bos]

Portably, there is no sign bit.
Float representations can be anything.

That's debatable. There must at least be a sign bit in the conceptual
floating point model; I would be very surprised at an implementation of
that model which didn't have an actual sign bit in its representation,
and I'm not at all sure that such an implementation would be conforming.

This expression: (0 > float_variable) gives a compiler all the
information it needs to do the best optimizations conceivable to
determine if float_variable is negative.

That much is, in any case, true and good advise.

Richard

 

[Keith Thompson]

That's debatable. There must at least be a sign bit in the conceptual
floating point model; I would be very surprised at an implementation of
that model which didn't have an actual sign bit in its representation,
and I'm not at all sure that such an implementation would be conforming.

In IEEE format, the exponent is represented in something like
excess-128 notation (depending on the size of the exponent), where
all-bits-zero represents the most negative value, not 0. I can
imagine a floating-point format where the mantissa uses a similar
representation. (I think there might still be a bit that's a reversed
sign bit, with 0 for negative values and 1 for positive values).

I can easily believe that no such representation exists in the real
world, but I don't thinkt the C standard says enough about FP
representations to make it non-conforming. See the DS9K.

[...]

 

[Richard Bos]

I don't forget that, but I prefer correct spelling over indulging
users of outdated software. MIME is now 15 years old, UTF-8 not much
younger, so I do think that if somebody still uses software which
doesn't support them, it's their problem and not the the problem of
everybody else.

MIME is Multi-part Internet _Mail_ Extensions, though. This is not mail,
it's Usenet. More to the point, it's a Big-7 Usenet group, where 7-bits,
plain ASCII is still the norm. I'm not complaining about your post, just
as I'm not complaining about Outhouse's Quoted-Illegible making code
unreadable[1]; but any communication problems _are_ the fault of the
party using a protocol which does not belong here, not that of the party
which is Usenet-compliant.

Richard

[1] I just ignore any posts which are too much trouble to decode

 

[pete]

That's debatable. There must at least be a sign bit in the conceptual
floating point model;

There must be a sign, in the conceptual floating point model,
but the standard does not say
that there must be a special bit for that.

 

[Chris Thomasson]

[...]
I cannot imagine why one needs a strictest-aligned variable of
static duration, but the following would work
typedef union { [...]
} strict_align_t;
strict_align_t myvar;

Unsigned and complex stuff can be inferred to fit this alignment.

It's very likely to work, but it's certainly not guaranteed to work.
There are arbitrarily many types, and any of them could theoretically
have stricter alignment requirements than any of the types you've
listed.

[...]

Do you think the following code you work at least 80% of the time:


---------------
#include <stdio.h>
#include <stddef.h>


typedef struct aligned_s aligned_t;
typedef union aligned_offset_u aligned_offset_t;
typedef union aligned_ptrs_u aligned_ptrs_t;
typedef union aligned_uptrs_u aligned_uptrs_t;
typedef union aligned_ints_u aligned_ints_t;
typedef union aligned_uints_u aligned_uints_t;
typedef enum aligned_enum_u aligned_enum_t;


#if ! defined(ALIGN_TYPEUNION_APPEND)
typedef union aligned_append_u aligned_append_t;

union aligned_append_u {
char whatever[1024];
};

#define ALIGN_TYPEUNION_APPEND() aligned_append_t
#endif


enum aligned_enum_u {
aligned_enum_u_v1,
aligned_enum_u_v2,
aligned_enum_u_v3
};


union aligned_ptrs_u {
char* t_char;
short* t_short;
int* t_int;
long* t_long;
float* t_float;
double* t_double;
long double* t_long_double;
long long* t_long_long;
ptrdiff_t* t_ptrdiff;
void* t_void;
float* (*t_fptr_0) (long double);
long long* (*t_fptr_1) (void*);
void* (*t_fptr_2) (void*, ptrdiff_t*);
aligned_ints_t* t_ints;
aligned_ptrs_t* t_aptrs;
aligned_offset_t* t_offset;
aligned_enum_t *t_enum;
};

union aligned_uptrs_u {
unsigned char* t_uchar;
unsigned short* t_ushort;
unsigned int* t_uint;
unsigned long* t_ulong;
size_t* t_size;
float* t_ufloat;
double* t_udouble;
unsigned long long*t_ulong_long;
unsigned int* t_uint_ptr;
unsigned long* (*t_ufptr_1) (unsigned int);
unsigned char* (*t_ufptr_2) (double, long double);
aligned_uints_t* t_uints;
aligned_uptrs_t* t_uaptrs;
};


union aligned_ints_u {
char t_char;
short t_short;
int t_int;
long t_long;
float t_float;
double t_double;
long double t_long_double;
long long t_long_long;
ptrdiff_t t_ptrdiff;
aligned_enum_t t_enum;
};

union aligned_uints_u {
unsigned char t_uchar;
unsigned short t_ushort;
unsigned int t_uint;
unsigned long t_ulong;
unsigned long long t_ulong_long;
size_t t_size;
};


union aligned_offset_u {
aligned_ints_t t_ints;
aligned_uints_t t_uints;
aligned_ptrs_t t_ptrs;
aligned_uptrs_t t_uptrs;
ALIGN_TYPEUNION_APPEND() t_append;
};


struct aligned_s {
char base;
aligned_offset_t offset;
};


#define ALIGN_MAX_ESTIMATE() ( \
sizeof(aligned_t) > sizeof(aligned_offset_t) \
? sizeof(aligned_t) - sizeof(aligned_offset_t) \
: sizeof(aligned_offset_t) \
)




int main(void) {
{
printf("estimated strict aligment: %u\n",
ALIGN_MAX_ESTIMATE());
}

puts("\n\n\n\
_______________________\npress <enter> to exit...\n");
return getchar();
}

 

[Chris Thomasson]

[...]

Do you think the following code you work at least 80% of the time:

[...]

That was suppose to read as:

'Do you think the following code might work at _least_ 80% of the time'

 

[pete]

union aligned_ptrs_u {
char* t_char;

void* t_void;

t_char and t_void
have the same representation and alignment requirements.

 

[Chris Thomasson]

[...]

Do you think the following code you work at least 80% of the time:

[...]

A user can mutate the posted alignment code with the
'ALIGN_TYPEUNION_APPEND' macro function as follows:

-----------
typedef union aligned_your_special_u aligned_your_special_t;

union aligned_your_special_u {
int whatever_types_you_need;
};

#define ALIGN_TYPEUNION_APPEND() aligned_your_special_t
-----------


So, this might be 81% reliable...

;^)

 

[Keith Thompson]

[...]

Do you think the following code you work at least 80% of the time:

[...]

That was suppose to read as:

'Do you think the following code might work at _least_ 80% of the time'

Maybe.

If I find a platform where if fails, and run it 99 times on that
platform and once on a platform where it works, then it will fail 99%
of the time.

Correctness isn't a matter of percentages. (Though sometimes having a
suffiently high probability of working can be an adequate substitute
for correctness.)

 

[Chris Thomasson]

[...]

Do you think the following code you work at least 80% of the time:

[...]

That was suppose to read as:

'Do you think the following code might work at _least_ 80% of the time'

Maybe.

If I find a platform where if fails, and run it 99 times on that
platform and once on a platform where it works, then it will fail 99%
of the time.

Well, we should measure per-platform, not per-run? So that would be 1
failure and 1 success...

;^)

[...]

 

[Chris Thomasson]

[...]

Do you think the following code you work at least 80% of the time:

[...]

That was suppose to read as:

'Do you think the following code might work at _least_ 80% of the time'

Maybe.

If I find a platform where if fails, and run it 99 times on that
platform and once on a platform where it works, then it will fail 99%
of the time.

[...]

Can you think of an existing platform where the code would most likely
break?