You're appointed as Portability Advisor

[Malcolm McLean]

Old Wolf:



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?

I think that, yes.
size_t is a function if you adopt the mathematical definition of the word,
not if you adopt the programming definition. However I feel it is more
useful to give it the same syntax as other functions.

 

[Mark Bluemel]

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".

And the value of that would be precisely what?

 

[jacob navia]

Richard Heathfield:



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?

Many programmers do not read this group anymore, completely fed up
with the "regulars"

For instance Paul Hsie participates here only occasionally, and he is
way better than Heathfield and co.

 

[Army1987]

"Tomás Ó hÉilidhe" <[email protected]> wrote in message

I think that, yes.
size_t is a function if you adopt the mathematical definition of the word,
not if you adopt the programming definition. However I feel it is more
useful to give it the same syntax as other functions.

(You meant sizeof)

But it doesn't have the same syntax.
func(arg) is a postfix-expression, sizeof(arg) isn't.
So func(arg)[ptr] means ptr[func(arg)],
but sizeof(arg)[ptr] means sizeof ptr[arg], not ptr[sizeof arg].
This is only relevant to IOCCC entries, but they don't
have the same syntax.

(And sizeof isn't a mathematical function either, as 1 == 1ULL, but
sizeof(1) can be != sizeof(1ULL).)

 

[Tomás Ó hÉilidhe]

Mark Bluemel:

And the value of that would be precisely what?

If it were held in high regard, then compiler vendors would pay
attention to it, and programmers would have more freedom to implement more
techniques in their code. Just as an example, it might influence compiler
writers to disable bad-memory-location checks when dereferencing a pointer
to an array. Of course, that's just one example.

 

[Richard Heathfield]

Tomás Ó hÉilidhe said:

Richard Heathfield:

<snip tripe>

In fact I was offering supporting evidence to demonstrate that you are not
the only person who writes char unsigned.

Forgetting ad hominem attacks for the moment,

Er, what are you talking about?

(or whatever it is you
(plural) are actually trying to do to cast a derisory eye on my
proposal),

I'm not trying to cast any eyes, derisory or otherwise. You've made a
proposal, and I've offered my opinion about it. I'm not deriding your
proposal; I'm merely expressing my own point of view.

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?

I don't think the world's best C programmers /do/ agree on how C should be
changed, if indeed it should be changed, so such a Web page is a
non-starter.

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.

You /are/ a part of the comp.lang.c newsgroup, because you subscribe to it
and contribute to it. If by "this group" you mean "some of the world's
best C programmers", perhaps you'd better identify who you mean by that,
to save the rest of us the trouble of expressing an opinion.

Your hostile reaction to ordinary to-ing and fro-ing is most peculiar. I
had you down as a fairly sensible chap, but I'm beginning to wonder
whether that was a mistake on my part.

 

[Richard Heathfield]

Tomás Ó hÉilidhe said:

Richard Heathfield:


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?

Bits of it are, yes. For example, Chris Torek is a de facto authority on C.
The problem is that there is no consensus on who /else/ is an authority.

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.
Right.

(Even if the changes were to come to fruition, nobody would pay
attention).

Right again.

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".

In effect, this sounds like an attempt to create a "clc C standard". I
would suggest that, if ISO can't hack it, clc certainly can't. There is no
consensus here. Ask a C question of half a dozen clcers and you'll get at
least seven different opinions, no deadline for ending the debate, and no
formal voting mechanism. This is not the stuff that Standards are made on.

 

[Mark Bluemel]

Mark Bluemel:



If it were held in high regard,

In your dreams...

 

[Mark Bluemel]

Tomás Ó hÉilidhe said:


Bits of it are, yes. For example, Chris Torek is a de facto authority on C.
The problem is that there is no consensus on who /else/ is an authority.

Are you sure you phrased that right? I sometimes get the feeling that
the consensus is that noone else is an authority...

 

[Tomás Ó hÉilidhe]

Richard Heathfield:

In fact I was offering supporting evidence to demonstrate that you are
not the only person who writes char unsigned.

Oh, sorry about that, I latched onto Old Wolf's tone and blindly assumed
your post was an extension of it. My bad.

 

[Tomás Ó hÉilidhe]

Richard Heathfield:

In effect, this sounds like an attempt to create a "clc C standard". I
would suggest that, if ISO can't hack it, clc certainly can't. There
is no consensus here. Ask a C question of half a dozen clcers and
you'll get at least seven different opinions, no deadline for ending
the debate, and no formal voting mechanism. This is not the stuff that
Standards are made on.

Actually yeah come to think of it you're right. Seems like a no-goer.

 

[Mark Bluemel]

Richard Heathfield wrote:
[In response to Tomas]

You /are/ a part of the comp.lang.c newsgroup, because you subscribe to it
and contribute to it. If by "this group" you mean "some of the world's
best C programmers", perhaps you'd better identify who you mean by that,
to save the rest of us the trouble of expressing an opinion.

Your hostile reaction to ordinary to-ing and fro-ing is most peculiar. I
had you down as a fairly sensible chap, but I'm beginning to wonder
whether that was a mistake on my part.

He's beginning to feel like one of those people who, as my partner puts
it, can start an argument in an empty room.

 

[Malcolm McLean]

(You meant sizeof)

Yes. Who will free us of these gibberish types that are even too similar to
keywords?

 

[Chris Dollin]

Yes. Who will free us of these gibberish types that are even too similar to
keywords?

Any halfway decent IDE or PTE will make the difference manifest.

 

[CBFalconer]

.... snip ...

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".

Any such page will be 47% full of "Things in the standard I am too
ignorant to understand the reason for". Another 47% will be spent
on "Things I am to ignorant to understand why they are not
implementable in the generalized machines used for C". Total: 94%
useless.

 

[CBFalconer]

Mark Bluemel:

If it were held in high regard, then compiler vendors would pay
attention to it, and programmers would have more freedom to
implement more techniques in their code. Just as an example, it
might influence compiler writers to disable bad-memory-location
checks when dereferencing a pointer to an array. Of course,
that's just one example.

Admirable. Then:

int aray[28];
....
b = aray[100];

should never fail. Please advise what the value stored in b should
be? and why.

 

[CBFalconer]

.... snip ...

For instance Paul Hsie participates here only occasionally, and
he is way better than Heathfield and co.

Good lord. I gather you don't read anything any of them publish.

 

[vippstar]

I think that, yes.
size_t is a function if you adopt the mathematical definition of the word,
not if you adopt the programming definition. However I feel it is more
useful to give it the same syntax as other functions.

(You meant sizeof)

But it doesn't have the same syntax.
func(arg) is a postfix-expression, sizeof(arg) isn't.
So func(arg)[ptr] means ptr[func(arg)],
but sizeof(arg)[ptr] means sizeof ptr[arg], not ptr[sizeof arg].
This is only relevant to IOCCC entries, but they don't
have the same syntax.

(And sizeof isn't a mathematical function either, as 1 == 1ULL, but
sizeof(1) can be != sizeof(1ULL).)

But 1 and 1ULL are not values.
They are expressions, they have a type, a size and a value. (and don't
forget that sizeof works with expressions/types not values)
It can still be a mathematical function.

 

[Martin Golding]

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.

More precisely, several (but not all) of the posters stated that
_they_ wouldn't use it, and explained why not. YOU get to do anything
you want to any code over which you have control. As you decide what
to write, presuming it's for hire, remember that in that environment,
communicating with your coworkers is as important as communicating
with the compiler.

I like it, but it's a sufficiently odd idiom that I'd define a macro
for it, and as long as I was defining a macro, I'd likely use the more
common (in my experience) sizeof.


#include <stdio.h>

#define ENDOF(array) (array+sizeof array/sizeof *array)

int
main(void)
{
char i[20];
char *orig = *(&i+1);
char *modified = &(&i+1)[0][0];
char *sizof = &i[sizeof i/sizeof i[0]];

printf("%d, %d, %d, %d\n", orig-i, modified-i, sizof-i, ENDOF(i)-i);
return 0;

}

Martin

 

[Keith Thompson]

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.

As you acknowledged in a later followup, there were no ad hominem
attacks in Richard's article. As you haven't acknowledged, there were
also no ad hominem attacks in Old Wolf's article. He did not attack
your usage of "char unsigned", he merely noted it (it is rather
unusual, after all). He did strongly criticize one of the technical
ideas that you offered (that ``*(&array + 1)'' is a good way to obtain
a pointer just past the end of an array); that is not an ad hominem
attack. If he had said or implied that your ideas are stupid because
they came from you, *that* would have been ad hominem, but he didn't
do that. I'll grant you that Old Wolf's words were fairly harsh,
perhaps more so than necessary. Feel free to criticize him for that
if you like, but my friendly advice is to grow a thicker skin.

Getting to the substantive question you're asking, I'd like to be
clearer on just what you're proposing. When you talk about amendments
(note spelling) to the C standard, do you mean changes that we agree
should be adopted in the next version, or do you mean changes that we
could all safely adopt right now, even if they contradict what the
standard actually says? For the former, comp.std.c is the best place
to discuss such things. If you mean the latter (areas where the
standard's requirements can be safely ignored), then I have no
objection to creating such a list -- as long as it's empty.

Sometimes the line between behavior that the standard defines and
behavior that it doesn't define isn't based on what *can* possibly be
defined; rather, it's based on the need to have a clear and
understandable dividing line between defined and undefined behavior.
In the standard as it's currently written, dereferencing a pointer
value that doesn't point to an object (assuming a pointer-to-object
type, of course) is undefined. There may be some corner cases where
you could get away with it if only the standard were more reasonable.
But covering all those corner cases would, IMHO, be a waste of time;
the benefit would be small, and the result would be a much larger
standard -- with more opportunities for errors. And try getting
agreement on which cases are reasonable and which ones aren't.

As for the specific case of ``*(&array + 1)'', I'll grant you that
it's clever. But in programming, being "clever" is not always a good
thing. You have to factor in the time others will have to spend
<optimism>appreciating your cleverness</optimism>, rather than getting
on with the job of understanding what the code does.

Combine that with the fact that the standard does not define its
behavior, that most implementations apparently will let you get away
with it (which means it's a potential bug that you can't find by
testing), and that there are clearer and more flexible ways to do
exactly the same thing,

Not all code has to be 100% portable. For example, if I'm writing
code that depends intimately on POSIX, I can safely assume that
CHAR_BIT==8 (since that's what POSIX requires). There is a known and
coherent set of implementations on which that assumption is valid.
Your assumption that ``*(&array + 1)'' does what you expect it to do,
on the other hand, depends not on the known nature of the platform,
but on the whim of the compiler writer. Your code could be broken
tomorrow by a new version of an optimizer on a platform that you don't
even use.