Let's write a c program, without knowing what it does...

[Micah Cowan]

The fact that they may have different representations is
completely uninteresting. The result is well-defined for
conversion from any one pointer type to any other, including
those requiring casts. It is only the subsequent reading of that
value that can be dangerous: however, such is not the case for a
pointer-to-unsigned-char. This is *explicitly* sanctioned by the
standard.

Yikes. I need some more coffee. =%]

BTW: Are you referring to ISO/IEC 9899:1999 6.3.2.3#7 or is there
any other section in the standard about this matter?

I'm referring to 6.3.2.3#7 for conversions between pointer types;
6.5#7 for reading as a character array.

(Of course, alignment problems are nonexistent for the character types,
so actually evaluating the pointer without dereferencing it would
be okay without 6.5#7).

-Micah

 

[Irrwahn Grausewitz]

int LowerLimit(void)
{
int how_much_darling;
int ret = 0;
int i = sizeof(int);
unsigned char *p = (unsigned char *)&how_much_darling;

Warning: unsigned char* and int* may have different representations.

The fact that they may have different representations is
completely uninteresting. The result is well-defined for
conversion from any one pointer type to any other, including
those requiring casts. It is only the subsequent reading of that
value that can be dangerous: however, such is not the case for a
pointer-to-unsigned-char. This is *explicitly* sanctioned by the
standard.

Yikes. I need some more coffee. =%]

BTW: Are you referring to ISO/IEC 9899:1999 6.3.2.3#7 or is there
any other section in the standard about this matter?

I'm referring to 6.3.2.3#7 for conversions between pointer types;
6.5#7 for reading as a character array.

^^^^^
Ah, yes, that's what I was looking for. Thank you.

(Of course, alignment problems are nonexistent for the character types,
so actually evaluating the pointer without dereferencing it would
be okay without 6.5#7).

Regards

 

[Bill Godfrey]

too many cooks....

Up to the point where this thread ran out of steam, it did remind me of the
team-based project I had to do for my degree.

On my own, I could have done a half-reasonable job over a weekend. But, we
had to work in a team and we were given the whole year to finish it.

It rather floundered, until one of us spent a weekend on it and came up
with something half-reasonable.

Bill, 'twas not I.

(Sorry, that post had very little point.)

 

[gswork]

Up to the point where this thread ran out of steam, it did remind me of the
team-based project I had to do for my degree.

On my own, I could have done a half-reasonable job over a weekend. But, we
had to work in a team and we were given the whole year to finish it.

It rather floundered, until one of us spent a weekend on it and came up
with something half-reasonable.

Bill, 'twas not I.

(Sorry, that post had very little point.)

Never really got steam, but that's ok.

rzed's "The whole problem with this thread " is a great way to ensure
no more contributions, but really it was just a little fun - and too
ambiguous from me.

If you look at sourceforge, or any set of open source open team
projects, an overwhelming number just taxi around and never take off.
In the most successful projects, as in your example, things happen
when someone or some closely knit team, plan the project and work to
deadlines.

 

[rzed]

(e-mail address removed)9.co.uk.invalid (Bill Godfrey) wrote in


Never really got steam, but that's ok.

rzed's "The whole problem with this thread " is a great way to
ensure no more contributions, but really it was just a little fun -
and too ambiguous from me.

If you look at sourceforge, or any set of open source open team
projects, an overwhelming number just taxi around and never take
off. In the most successful projects, as in your example, things
happen when someone or some closely knit team, plan the project and
work to deadlines.

Jeez, I didn't really mean to toss a wet blanket on it. I was just
getting the shakes, that's all. It was only a matter of time until
there was a steering committee and mandatory naming standards and code
reviews and another layer of management and budget overruns and ...
and ... migod, they're starting again!