Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > C Programming > You're appointed as Portability Advisor

Reply
Thread Tools

You're appointed as Portability Advisor

 
 
Paul Hsieh
Guest
Posts: n/a
 
      02-15-2008
On Feb 15, 4:13 am, Richard Heathfield <(E-Mail Removed)> wrote:
> Tomás Ó hÉilidhe said:
> > 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(?)),


That's just what the regulars want/wish. You can take any random
sample here and even removing the spam and hw questions you can see
that that just isn't the case. Random posts that come in here
invariably are talking about gcc, UNIX, MSVC++, or even C++.

> [...] not as clc would like the C language to be. That's comp.std.c's job,
> I guess.


The (demand and lobbying for the) removal of gets() happened here
(clc). Not there (csc). Google groups is good for one thing: you can
look through the historical record.

--
Paul Hsieh
http://www.pobox.com/~qed/
http://bstring.sf.net/
 
Reply With Quote
 
 
 
 
Paul Hsieh
Guest
Posts: n/a
 
      02-15-2008
On Feb 15, 5:24 am, Mark Bluemel <(E-Mail Removed)> wrote:
> Tomás Ó hÉilidhe wrote:
> > 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?


To ostracize and put the lie to the C standard committee perhaps?
That's how gets() was removed from the standard.

--
Paul Hsieh
http://www.pobox.com/~qed/
http://bstring.sf.net/
 
Reply With Quote
 
 
 
 
Army1987
Guest
Posts: n/a
 
      02-15-2008
Malcolm McLean wrote:

> "Army1987" <(E-Mail Removed)> wrote in message news:
>> Malcolm McLean wrote:
>>> size_t is [...]

>> (You meant sizeof)
>>

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

Who will free us of those posters to whom a trailing `_t` isn't
immediately glaring?
<g,d&r>

--
Army1987 (Replace "NOSPAM" with "email")
 
Reply With Quote
 
Army1987
Guest
Posts: n/a
 
      02-15-2008
vippstar wrote:

> On Feb 15, 3:37 pm, Army1987 <(E-Mail Removed)> wrote:
>> (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.

Yes, if you define it as a function over the set of all C expressions (with
complete type, and let's let VLAs alone).


--
Army1987 (Replace "NOSPAM" with "email")
 
Reply With Quote
 
Antoninus Twink
Guest
Posts: n/a
 
      02-16-2008
On 15 Feb 2008 at 13:29, jacob navia wrote:
> Tomás Ó hÉilidhe wrote:
>> 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?
>>

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


"Indeed".

 
Reply With Quote
 
Old Wolf
Guest
Posts: n/a
 
      02-17-2008
On Feb 16, 1:03 am, Richard Heathfield <(E-Mail Removed)> wrote:
> 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.


Ah yes. Let us not forget Martin Wells either.
 
Reply With Quote
 
Peter 'Shaggy' Haywood
Guest
Posts: n/a
 
      02-18-2008
Groovy hepcat Tomás Ó hÉilidhe was jivin' in comp.lang.c on Fri, 15 Feb
2008 11:05 am. It's a cool scene! Dig it.

> However, let's consider this: Let's say you're appointed as the
> Portability Advisor for a multi-national company that makes billions
> of dollar each year.


[Snip.]

> Your job is to screen the code that other programmers in the company
> write. Every couple of days there's a fresh upload of code to the
> network drive, and your job is to scan thru the code and point out and
> alter anything that's not portable. Of course tho, you're given a
> context in which to judge the code, for instance:
> a) This code must run on everything from a hedge-trimmer to an iPod,
> to a Playstation 3,
> b) This code must run on all the well-known Desktop PC's


[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;
> }
>
> 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


I may suspect this, but I would check that that's what he actually is
planning on doing before I jump to conclusions. If it's not in his
code, as it appears so far, then I would ask him to clarify his
intentions.

> 'bytes' member of the structure". 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 assumed that sizeof(unsigned) is at least 4, since
he's accessing cf.bytes[3].

> 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?


Of course. He's making an assumption about the size of unsigned.
That's a portability deal breaker.

> 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, but
> how much do you care?


The standard doesn't forbid it, but mandates an unspecified value,
which may be a trap representation, and does so for a very good reason.
The causes of problems resulting from doing this may or may not exist
on a given implementation, even on the vast majority; but even if it
fails on one implementation, that's a deal breaker when the deal is
absolute portability.

> 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. Again, you know that the
> Standard in all its marvelous rigidity doesn't want you to dereference
> that pointer, but are you bothered? Are you, as the Portability
> Advisor, going to reject this code?


This is dereferencing a pointer to Lala Land. That's not portable, and
is likely to cause problems. You want to leave something like this in,
knowing full well that it's not kosher?

> 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?


Yes, and it's not obtuse. If I'm in charge of making code portable,
I'm going to make code portable to the best of my ability. I may miss
some things, but what I don't miss won't get through. That's my job.
I'm a Portability Advisor.

> Are we really going to reject some code for a reason that we see as
> stupidly restrictive in the language's definition?


You mean a reason that *you* see as stupidly restrictive. But that's
your hangup, man.

> Perhaps it might be useful to point out what exactly can go wrong when
> we're treading on a particular rule.


That's a good point. But sometimes it is unclear what can co wrong.
But that doesn't mean that nothing can go wrong. That's why we often
give the stock answer that "undefined behaviour" means anything can
happen. Anything *can* happen, including the program working correctly
(whatever that may mean in the context of undefined behaviour).

> In both these cases I've
> mentioned, I don't think anything can go wrong, not naturally anyway.


Sure they can. Take the expression *(&tangents + 1), for example.
tangents may be allocated at the end of memory. Dereferencing a pointer
pointing beyond it may yield a bogus value, even a trap that causes an
immediate memory access error. Or it could just wrap to memory location
0, which just happens to be a null pointer on a particular
implementation (very many of them, in fact). Any way you look at it,
dereferencing a pointer that points beyond an object is an error, even
if it's not allocated at the end of memory.

> What _can_ cause problems tho is aspects of the compiler:
> 1) Over-zealous with its optimisation
> 2) Deliberately putting in checks (such as terminating the program
> when it thinks you're going to access memory out-of-bounds).


If you are accessing memory out of bounds, then it makes sense for an
implementation to kill the program or take some other appropriate
action. That's usually the domain of the host system, though, rather
than the compiler/library. If you're not accessing memory out of bounds
(or doing other things that may cause problems), then you should have
no problems. An implementation shouldn't terminate a program just
because it "thinks" you may be about to cause undefined behaviour. But
it's very helpful to terminate when you actually do so.

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


That may be what comes to your mind. But since when do you speak for
everybody?

[Snip.]

> 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?


What for? People who care about portability (in a given project or in
general) endeavour to write portably (in that project or in general),
and those who don't don't.
A more important aspect of writing code portably is separating
non-portable aspects of code (if there are any) from the portable
aspects. For example, one may be writing something that must access a
particular device. That is a non-portable endeavour; but some parts of
the code will essentially be portable. A budding coder needs to learn
how to separate the non-portable code that accesses the device from the
portable code that does other things. Make a web site about *that* and
you may just have something useful.

--
Dig the sig!

----------- Peter 'Shaggy' Haywood ------------
Ain't I'm a dawg!!
 
Reply With Quote
 
Ben Bacarisse
Guest
Posts: n/a
 
      02-20-2008
Peter 'Shaggy' Haywood <(E-Mail Removed)> writes:
<big snip>
> Sure they can. Take the expression *(&tangents + 1), for example.
> tangents may be allocated at the end of memory. Dereferencing a pointer
> pointing beyond it may yield a bogus value, even a trap that causes an
> immediate memory access error.


You seem to have missed much of this debate! I agree the construct is
undefined but it is very hard to see why any actual dereference
(i.e. memory access) will occur. The type means that the *(...)
object is an array, so it must be converted to a pointer to its first
element. This is a technical (i.e. letter of the law) problem, but is
probably not a practical one since that pointer is valid -- you can
construct it in other ways quite legally.

> Or it could just wrap to memory location
> 0, which just happens to be a null pointer on a particular
> implementation (very many of them, in fact).


If 'tangents' is allocated at "the top" of memory, C requires that
there be a valid pointer to a place just one past the end of it. This
often means that it is allocated "one element down" from the top but
other solutions are possible. On a system with fat pointers (that
encode the range as well as the start) the pointer '&tangets+1' must
be properly representable since that pointer is entirely valid.

The issue is whether the * is allowed. It clearly is not, but not
because the operation implies construction of an invalid (and possibly
wrapped) pointer. The * is not allowed "by fiat", even though it is
hard to show is can denotes an actual memory access.

--
Ben.
 
Reply With Quote
 
Richard Heathfield
Guest
Posts: n/a
 
      02-20-2008
Ben Bacarisse said:

> Peter 'Shaggy' Haywood <(E-Mail Removed)> writes:
> <big snip>
>> Sure they can. Take the expression *(&tangents + 1), for example.
>> tangents may be allocated at the end of memory. Dereferencing a pointer
>> pointing beyond it may yield a bogus value, even a trap that causes an
>> immediate memory access error.

>
> You seem to have missed much of this debate!


Perhaps - but *what* a sig!

--
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
 
Reply With Quote
 
 
 
Reply

Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
Questionable Olympus official appointed as new CFO!! RichA Digital Photography 0 04-11-2012 12:28 PM
Cisco Software Advisor Gary Cisco 2 11-15-2005 12:30 AM
Former NZ Exec appointed MS CFO Rob J NZ Computing 8 04-27-2005 02:20 AM
microsoft software advisor =?Utf-8?B?YWxleA==?= Microsoft Certification 1 12-10-2004 12:10 AM
SmartNavigation Crashing IE with Content Advisor Enabled Steve Roszko ASP .Net 0 12-04-2003 08:41 PM



Advertisments