«

Richard Heathfield wrote:
>
> Tomás Ó hÉilidhe said:
>
> <snip>
>
> > You get down to it. You open up the network drive and navigate to James
> > Weir's source file. Its context is "run on anything". You're looking
> > thru it and you come to the following section of code:
> >
> > typedef union ConfigFlags {
> > unsigned entire; /* Write to all bytes
> > char unsigned bytes[sizeof(unsigned)]; at once or access
> > } ConfigFlags; them individually
> > */
> >
> > int IsRemoteAdminEnabled(ConfigFlags const cf)
> > {
> > return cf.bytes[3] & 0x3u;
> > }
>
> This won't even run on MS-DOS, let alone "anything".

And we're assuming that the issue about the comment is just a typo
by the OP, and not in "James Weir's source file".

> > You look at this code and you think, "Hmm, this chap plans to write to
> > 'entire' and then subsequently read individual bytes by using the
> > 'bytes' member of the structure".
>
> No, I look at this code and I think, "someone has assumed that unsigned
> ints are at least four bytes wide", which isn't true on typical MS-DOS
> systems (yes, they're still used, believe it or not), isn't true on
> various DSPs, and came within a gnat's whisker of being true on at least
> one Cray.

And perhaps unsigned ints are 8 bytes on some new 64-bit systems? (At
least the above then doesn't invoke UB, however.)

> > You have a second suspicion that
> > perhaps James might have made assumptions about the size of "unsigned",
> > but inspecting the code you find that he hasn't.
>
> Yes, he has.

He's also made an assumption about endianness.

> > Now, the question is, in the real world, at 10:13am on a sunny Thursday
> > morning, sitting at your desk with a hot cup of tea, munching away on a
> > fig-roll bar getting small crumbs between the keys on the keyboard, are
> > you really going to reject this code?
>
> Absolutely, yes.

Ditto. Even though every system I happen to work on at the moment
uses 4-byte unsigned ints, some are big-endian and others are little.

[...]
> > What I'm trying to get across is, that, while we may discuss in black
> > and white what the Standard permits and what it forbids... are we really
> > going to be so obtuse as to reject this code in the real world?
>
> No, we're really going to be so acute as to reject this code in the real
> world.


--
+-------------------------+--------------------+-----------------------+
| Kenneth J. Brody | www.hvcomputer.com | #include |
| kenbrody/at\spamcop.net | www.fptech.com | <std_disclaimer.h> |
+-------------------------+--------------------+-----------------------+
Don't e-mail me at: <private.php?do=newpm&u=>

Tomás Ó hÉilidhe wrote:
>
.... snip ...
>
> The first thought I think comes to everyone's mind when we're talking
> about these unnecessarily rigid rules, is that the Standard just needs
> to be neatly amended. But, of course, it's C we're talking about, where
> the current standard is from 1989 and where still not too many people
> are paying attention to the 1999 standard that came out nine years ago.
>
> So, I wonder, what can we do? If there was a consenus between many of
> the world's most skilled and experienced C programmers that a certain
> rule in the Standard were unnecessarily rigid, would it not be worth the
> compiler vendors' while to listen? Here at comp.lang.c, there are,
> without exageration, some of the world's best C programmers. Instead of
> contacting each and every compiler vendor to let them know that we'd
> prefer to optimise-away assignments to union members, would it be
> convenient, both for the programmers and the compiler vendors, to have a
> single place to go to to read what the world's best programmers think?
> Should we have a webpage that lists the common coding techniques that
> skilled programmers use, but which are officially forbidden or "a grey
> area" in the Standard?

You're off-topic on c.l.c. This sort of thing belongs on
comp.std.c.

--
[mail]: Chuck F (cbfalconer at maineline dot net)
[page]: <http://cbfalconer.home.att.net>
Try the download section.



--
Posted via a free Usenet account from http://www.teranews.com

On Feb 15, 1:05 pm, "Tomás Ó hÉilidhe" <t...@lavabit.com> wrote:
> Your job is to screen the code that other programmers in the company
> write.
> a) This code must run on everything from a hedge-trimmer to an iPod, to
>
> typedef union ConfigFlags {
> unsigned entire; /* Write to all bytes
> char unsigned bytes[sizeof(unsigned)]; at once or access
> } ConfigFlags; them individually
>
> int IsRemoteAdminEnabled(ConfigFlags const cf)
> {
> return cf.bytes[3] & 0x3u;
> }
>
> You look at this code and you think, "Hmm, this chap plans to write to
> 'entire' and then subsequently read individual bytes by using the
> 'bytes' member of the structure".

I would think "Hmm, this guy got Tomas/JKop from c.l.c to
write his code". (I've never seen anybody else write 'char
unsigned').

> Now, the question is, in the real world, at 10:13am on a sunny Thursday
> morning, sitting at your desk with a hot cup of tea, munching away on a
> fig-roll bar getting small crumbs between the keys on the keyboard,

What does that have to do with it?

> are you really going to reject this code?

Of course you are. On some systems the flag is cf.entire & 3;
on others it's cf.entire & (3 << 24); and on others it's
something else entirely. You'd have to dig through lots more
code to check that this code snippet is correct.

> You're sitting there 100% aware that the Standard explicitly
> forbids you to write to member A of a union and then read
> from member B

Perhaps you are looking for comp.lang.c++

> but how much do you care?

If your job is to make the code portable, then you care
about undefined behaviour.

> Later on in the code, you come to:
>
> double tangents[5];
> ...
> double *p = tangents;
> double const *const pend = *(&tangents + 1);
>
> Again, you look at this code and you think to yourself this really is
> quite a neat way of achieving what he wants.

Come on, you wrote this whole post just to keep trying
to rationalize your ridiculous "clever" idea?

Any sane person would think: What the hell is that?,
fire the guy, and fix the code to be readable and correct.

Old Wolf said:

<snip>

> I would think "Hmm, this guy got Tomas/JKop from c.l.c to
> write his code". (I've never seen anybody else write 'char
> unsigned').

What about that chap of Irish descent from a year or two back? Graham
somebody, wasn't it? The one who kept using "domestic" instead of
"canonical"? Hmmm, "domestic", grummage grummage grummage, oh yes, it was
indeed Graham somebody, for certain values of Graham: Frederick Gotham, in
fact. He was a great one for saving up adjectives, and "char unsigned" was
indeed amongst his specialites[1] du 2006.

[1] Insert accents to taste.

--
Richard Heathfield <http://www.cpax.org.uk>
Email: -http://www. +rjh@
Google users: <http://www.cpax.org.uk/prg/writings/googly.php>
"Usenet is a strange place" - dmr 29 July 1999

Richard Heathfield:

> This won't even run on MS-DOS, let alone "anything".


Wups, that's what I get for rushing an example.

The moral of the original post tho:

Do you think that comp.lang.c should have a page where it lists its
"ammendments" to the Standard?

--
Tomás Ó hÉilidhe

Tomás Ó hÉilidhe said:

> Richard Heathfield:
>
>> This won't even run on MS-DOS, let alone "anything".
>
>
> Wups, that's what I get for rushing an example.
>
> The moral of the original post tho:
>
> Do you think that comp.lang.c should have a page where it lists its
> "ammendments" to the Standard?

Personally, no, I don't think that's necessary.

The comp.lang.c newsgroup discusses the C language as it is (de jure, de
facto, and de historio(?)), not as clc would like the C language to be.
That's comp.std.c's job, I guess.

--
Richard Heathfield <http://www.cpax.org.uk>
Email: -http://www. +rjh@
Google users: <http://www.cpax.org.uk/prg/writings/googly.php>
"Usenet is a strange place" - dmr 29 July 1999

Old Wolf:

> (I've never seen anybody else write 'char
> unsigned').


Are you some how arguing that your ignorance of certain programming
styles and techniques somehow renders them deprecated? 99% of C
programmers have never seen anyone use sizeof without it immediately
being followed by parentheses, so are you saying that we should always
put parentheses after sizeof lest we get bullied by the Style Police?


> Of course you are. On some systems the flag is cf.entire & 3;
> on others it's cf.entire & (3 << 24); and on others it's
> something else entirely. You'd have to dig through lots more
> code to check that this code snippet is correct.


As has already been pointed out, my snippet was erroneous. The point of
my post tho wasn't to do soley with that snippet.


> If your job is to make the code portable, then you care
> about undefined behaviour.


It's the first thing you'd care about, I'd imagine.


> Come on, you wrote this whole post just to keep trying
> to rationalize your ridiculous "clever" idea?


That's one reason, yes. I liked the idea I had for getting the end
pointer of a array, and I could see no reason not to use it other than
politics. More specifically, I couldn't use it just because the
Standard, maybe, might, perhaps, said that I couldn't.

--
Tomás Ó hÉilidhe

Richard Heathfield:

<snip tripe>

Forgetting ad hominem attacks for the moment, (or whatever it is you
(plural) are actually trying to do to cast a derisory eye on my proposal),
what do you think of the prospect of comp.lang.c having a page where it
lists its ammendments to the Standard, ammendments that are agreed upon by
some of the world's best C programmers? And before someone goes on to post
more tripe suggesting arrogance or pretentiousnness on my part by implying
that I expressed, either explicitly or implicitly, that I'm a part of this
group, well I have made and make no such expression.

--
Tomás Ó hÉilidhe

Richard Heathfield:

> The comp.lang.c newsgroup discusses the C language as it is (de jure, de
> facto, and de historio(?)), not as clc would like the C language to be.
> That's comp.std.c's job, I guess.


Because some of the world's most skilled and most experienced C programmers
hang around comp.lang.c, do you think it would be reasonable to say that it
might be a bit of an authority on these matters?

I agree with you entirely that it is comp.std.c's job, but I think we both
know that lobbying for changes to the C standard is a lost cause. (Even if
the changes were to come to fruition, nobody would pay attention).

The page I'm proposing would be something like "Stupid stuff in the
Standard that shouldn't be there, and stuff that they left out that should
be there".

--
Tomás Ó hÉilidhe

"Richard Heathfield" <> wrote in message
> (The Cray implementation in question very nearly defined CHAR_BIT as 64, >
> but they changed their mind, apparently quite late in the game. Had they
> not changed their mind, sizeof(unsigned) would have been 1 on that
> implementation.)
>
Come to my arms.

--
Free games and programming goodies.
http://www.personal.leeds.ac.uk/~bgy1mm