comp.lang.c - 12 new messages in 5 topics - digest

comp.lang.c
http://groups.google.com/group/comp.lang.c?hl=en

comp.lang.c@googlegroups.com

Today's topics:

* representation of register's fields - 2 messages, 2 authors
http://groups.google.com/group/comp.lang.c/t/ae3b5f4e576cfbd1?hl=en
* void * arithmetic - 1 messages, 1 author
http://groups.google.com/group/comp.lang.c/t/a33b3b6b3dba34c8?hl=en
* The C FAQ - 4 messages, 3 authors
http://groups.google.com/group/comp.lang.c/t/b75c0ae09abf3345?hl=en
* Motivation of software professionals - 4 messages, 3 authors
http://groups.google.com/group/comp.lang.c/t/21a3fdec4dd53e6a?hl=en
* array compound literal - 1 messages, 1 author
http://groups.google.com/group/comp.lang.c/t/74e5a77497c3f2b9?hl=en

==============================================================================
TOPIC: representation of register's fields
http://groups.google.com/group/comp.lang.c/t/ae3b5f4e576cfbd1?hl=en
==============================================================================

== 1 of 2 ==
Date: Thurs, Feb 11 2010 6:17 pm
From: "Mark"

James Kuyper wrote:
> That was, as I've already stated, my best guess as to what you were
> doing - I don't need to have such things explained to me.

Sorry, didn't mean to offend you, I thought there was some misunderstanding
about my environment, that's why I was gaving some trivial details.

> I was making two points: standard C provides no mechanism for defining
> such a constant. Therefore, you must be using an implementation-
> specific extension to C.
[snip]

And now I'm confused with your words. Just to make it clear and clean, here
is more accurate example, and we assume 'phy' and 'reg' can't contain values
bigger then 28 and 31 respectively:

#define REG_0 0x01u
#define SMI_READ 0u

unsigned int val, reg, phy;

val = (reg << 16) | (0u << 21) | (phy << 24) | (SMI_READ << 29) | (1u <<
30);

*(volatile unsigned int *)(REG_0) = val; /* XX */

The XX-marked statement is valid in the standard C, and doesn't require any
compiler's extensions, am I right ?

--
Mark
--
comp.lang.c.moderated - moderation address: clcm@plethora.net -- you must
have an appropriate newsgroups line in your header for your mail to be seen,
or the newsgroup name in square brackets in the subject line. Sorry.

== 2 of 2 ==
Date: Thurs, Feb 11 2010 8:23 pm
From: James Kuyper

Mark wrote:
> James Kuyper wrote:
...
>> I was making two points: standard C provides no mechanism for defining
>> such a constant. Therefore, you must be using an implementation-
>> specific extension to C.
> [snip]
>
> And now I'm confused with your words. Just to make it clear and clean,
> here is more accurate example, and we assume 'phy' and 'reg' can't
> contain values bigger then 28 and 31 respectively:
>
> #define REG_0 0x01u
> #define SMI_READ 0u
>
> unsigned int val, reg, phy;
>
> val = (reg << 16) | (0u << 21) | (phy << 24) | (SMI_READ << 29) | (1u
> << 30);
>
> *(volatile unsigned int *)(REG_0) = val; /* XX */
>
> The XX-marked statement is valid in the standard C, and doesn't require
> any compiler's extensions, am I right ?

I was using the term "extensions" loosely, to cover all
implementation-specific features of a compiler. Your code makes a couple
of seriously non-portable assumptions, beyond simply assuming that
unsigned int has 32 bits. It assumes that there are pointer values that
can, when dereferenced, refer to registers. It assumes, in particular,
that (volatile unsigned int*)0x01u is one such value. The C standard
says nothing to support those assumptions.

What the standard does say is that when you convert an arbitrary integer
to a pointer type, "the result is implementation-defined, might not be
correctly aligned, might not point to an entity of the referenced type,
and might be a trap representation." Note, in particular, that if any of
the nasty alternatives mentioned in that sentence is actually true for a
given implementation, virtually any attempt to actually make use of the
resulting pointer value (for instance, by dereferencing it) renders the
behavior of your entire program undefined.

The standard doesn't say these things arbitrarily - it says them because
there are real world machines where these possibilities actual happen.
There are some real-world machines which have registers specialized to
hold memory addresses, where even simply loading an invalid pointer
value into an address register will cause the program to be aborted.
There are many real-world machines where converting an arbitrary integer
value into a pointer will generally result in a pointer to memory that
your program doesn't have permission to access, with the same result.

If your implementation does in fact define that the result of converting
0x01u to volatile unsigned int* is a pointer that, when dereferenced,
gives your code access to a particular register, then your code is
perfectly fine - for that implementation. However, only your
implementation's documentation can tell you whether or not byte-swapping
is needed when making use of such a pointer; standard C is deliberately
silent on such issues.
--
comp.lang.c.moderated - moderation address: clcm@plethora.net -- you must
have an appropriate newsgroups line in your header for your mail to be seen,
or the newsgroup name in square brackets in the subject line. Sorry.

==============================================================================
TOPIC: void * arithmetic
http://groups.google.com/group/comp.lang.c/t/a33b3b6b3dba34c8?hl=en
==============================================================================

== 1 of 1 ==
Date: Thurs, Feb 11 2010 6:39 pm
From: Keith Thompson

Balban <bilgehan.balban@gmail.com> writes:
> On my compiler (gcc), if I add an integer value to a void pointer the
> integer is interpreted as signed instead of unsigned. Is this expected
> behavior?

I don't think that's what's happening.

As has already been mentioned, arithmetic on void* is a gcc-specific
extension; in standard C, it's a constraint violation, requiring a
diagnostic.

But the same thing applies to arithmetic on char*, which is well
defined by the standard.

Adding a pointer and an integer (p + i) yields a new pointer value
that points i elements away from where p points. For example, if p
points to the element 0 of an array, then (p + 3) points to element 3
of the same array. If p points to element 7 of an array, then (p - 2)
points to element 5 of the same array.

It would have been helpful if you had shown us an example of what
you're talking about. But suppose we have:

char arr[10];
char *p = arr + 5;
int i = -1;
unsigned int u = -1;

Let's assume a typical system where int and pointers are 32 bits.

So p points to arr[5]. The expression (p + i) points to arr[4].
But consider (p + u).

Since u is unsigned, it can't actually hold the value -1. During
initialization, that value is implicitly converted from signed
int to unsigned int, and the value stored in u is 4294967295.
In theory, then, (p + u) would point to arr[4294967300], which
obviously doesn't exist. So the behavior is undefined, if you try
to evaluate (p + u), anything can happen.

What probably will happen on typical modern systems is that the
addition will quietly wrap around. Let's assume that pointer values
are represented as 32-bit addresses that look like unsigned integers
(nothing like this is required by the standard, but it's a typical
implementation), and let's say that arr is at address 0x12345678.
Then p points to address 0x1234567d, and (p + 4294967295) would
theoretically point to address 0x11234567c. But this would require 33
bits, and we only have 32-bit addresses. Typically, an overflowing
addition like this will quietly drop the high-order bit(s) yielding an
address of 0x1234567c -- which just happens to be the address of
arr[4].

So you initialized u with the value -1, computed (p + u), and
got the same result you would have gotten for (p + (-1)). But in
the process, you generated an intermediate result that was out of
range, resulting in undefined behavior. (This is really the worst
possible consequence of undefined behavior: having your program
behave exactly as you expected it to. It means your code is buggy,
but it's going to be very difficult to find and correct the problem.)

This kind of thing is very common with 2's-complement systems. The
2's-complement representation is designed in such a way that addition
and subtraction don't have to care whether the operands are signed or
unsigned. But you shouldn't depend on this. The behavior of addition
and subtraction operations, either on integers or on pointers, is well
defined only when the mathematical result is within the required
range. Adding 0xFFFFFFFF to a pointer can appear to work "correctly",
as if you had really added -1, but it's better to just add a signed
value -1 in the first place.

Even if your code never runs on anything other that the system you
wrote it for, an optimizing compiler may assume that no undefined
behavior occurs. For example, if you write (p + u), it can assume
that p is in the range 0 to 5, and perform optimizations that depend
on that assumption.

--
Keith Thompson (The_Other_Keith) kst-u@mib.org <http://www.ghoti.net/~kst>
Nokia
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"

==============================================================================
TOPIC: The C FAQ
http://groups.google.com/group/comp.lang.c/t/b75c0ae09abf3345?hl=en
==============================================================================

== 1 of 4 ==
Date: Thurs, Feb 11 2010 7:38 pm
From: Simon Connah

On 2010-02-07 18:56:13 +0000, Joe Wright said:

> Richard Tobin wrote:
>> In article <3rWdnfcLoolZYfPWnZ2dnUVZ_hudnZ2d@giganews.com>,
>> Joe Wright <joewwright@comcast.net> wrote:
>>
>>> MSDOS and CP/M are still very much "now" to me.
>>
>> MSDOS and CP/M seem older than they are because they were out of date
>> when they were designed.
>>
>> -- Richard
>
> The target of CP/M was the Intel 8080A. In what way was CP/M out of
> date in 1979?

Unix had been out for years before that and was a vastly better system
even then. Even Microsoft had their own Unix OS (at a later date
obviously).

== 2 of 4 ==
Date: Thurs, Feb 11 2010 7:45 pm
From: Simon Connah

On 2010-02-07 10:11:10 +0000, Flash Gordon said:

> Andrew Poelstra wrote:
>
> <snip>
>
>> In any case, I do not believe that the memory limitations
>> discussed in the FAQ are at all frequently met. In fact, I
>> doubt that most C programmers encounter /any/ memory limits
>> on desktop PC's anymore. Certainly not when they're learning
>> and need a FAQ.
>
> The specific values mentioned in the FAQ may be no longer relevant, but
> we *do* have learners posting code which attempts to allocate local
> variable which are so large the allocation fails causing the program to
> crash. So there *are* still limits, and learners *do* still hit them!
>
> We also have had people post things similar to, "...but I've got 4GM of
> RAM!" when this is pointed out.

Then a discussion on the stack versus heap sounds like it would be in
order rather than issues relating to an outdated, little used operating
system wouldn't you say?

== 3 of 4 ==
Date: Thurs, Feb 11 2010 11:19 pm
From: Richard Heathfield

bartc wrote:
> "Richard Heathfield" <rjh@see.sig.invalid> wrote in message
> news:oZ6dnfHDudMsG-nWnZ2dnUVZ8gKdnZ2d@bt.com...
>> bartc wrote:
>>>
>> <snip>
>>
>>>
>>> Anyone who sees the MSDOS stuff in the FAQ is going to wonder how
>>> old, out-of-date, irrelevant and unreliable the rest of it is going
>>> to be.
> ....
>> If you think the FAQ is unreliable, by the way, I suggest you send a
>> patch to Steve Summit. Did you have a specific question in mind whose
>> answer you consider unreliable?
>
> I'm talking about what newcomers might think after glancing through
> section 19, which could do with an overhaul.

Which bits of section 19 do you think newcomers would think were unreliable?

<snip>

--
Richard Heathfield <http://www.cpax.org.uk>
Email: -http://www. +rjh@
"Usenet is a strange place" - dmr 29 July 1999
Sig line vacant - apply within

== 4 of 4 ==
Date: Thurs, Feb 11 2010 11:58 pm
From: Nick Keighley

On 10 Feb, 08:17, jacob navia <ja...@nospam.org> wrote:
> gwowen a écrit :
>
> > On Feb 10, 3:06 am, Ted DeLoggio <tdelog...@gmail.com> wrote:
>
> >> Remember that C is used in other contexts than writing PC software.
>
> >> The 8051 has 256 bytes of ram and the options for programming it are
> >> Assembly and C...  I prefer C   :)
>
> > True, but its pretty hard to see the relevance of that to the *DOS-
> > specific* parts.  I've never used an 256 byte embedded system that
> > prints "Abort, Retry, Ignore" as an error, or that had the concept of
> > "TSR programs".
>
> Exactly.
>
> All this reactions have something in common:
>
> MSDOS is surely not dead in the mind of some people here. They
> are still in those times, and a FAQ of those times looks very
> modern to them.
>
> With age, some people loose the ability to realize change
> and adapting to new stuff. They close themselves from the present
> and prefer living in some glorious past, long gone but still
> present in their minds.
>
> I have mixed feeling when I see them. There is (of course) the
> fear that I could be like them in the future, there is the pity
> looking at them and their endless remembrance of times long gone,
> and their lost future.
>
> Those people have completely lost the future as a tense: they
> never speak about it. Any change is a challenge, any change
> is a threat and they perceive it as such.
>
> Look in this group:
>
> Any change to C is perceived as a threat. The overwhelming reaction
> to a proposal of getting rid of MSDOS in the FAQ proves beyond
> any doubt where those people are living.
>
> That is why I am so despised in this group, now it is at least
> clearer. I want to change stuff, and I try to project myself into
> the future, and (worst) I even speak about the future of C.
>
> Everybody (with a few exceptions) sees C as a thing of the past,
> joined by a few nostalgic old C programmers that live in 1989,
> with MSDOS and Turboc.
>
> The fact that those times were TWENTY years ago doesn't bother them.
>
> They want to STAY there, in their untouched glorious past.

as a pastiche of spinoza this isn't bad (cod psychology, a touch of
sociology) but it's got a long way to go. You need to attack the
capitalist system (and in particular american business practices) you
need some literary references to show how well read you are. You
forgot to mention your degree or that you wrote all nash's (beautiful
mind) programs for him.

==============================================================================
TOPIC: Motivation of software professionals
http://groups.google.com/group/comp.lang.c/t/21a3fdec4dd53e6a?hl=en
==============================================================================

== 1 of 4 ==
Date: Thurs, Feb 11 2010 10:53 pm
From: Leif Roar Moldskred

In comp.lang.java.programmer Wojtek <nowhere@a.com> wrote:
>
> And at the time Y2K was created it was not a bug. It was a money saving
> feature. Probably worth many millions.

Not really. Remember, you can pack 256 years into a single 8 bit byte if
you want to, but in most cases of the Y2K problem people had stored a
resolution of 100 years into two bytes -- quite wasteful of space.

In some cases it came from a too tight adherence to the manual business
process that was modeled -- remember the paper forms with "19" pre-printed
and then two digits worth of space to fill out? Those got computerised
and the two-digit year tagged along.

In other cases it boiled down to "this is how we've always done it."

--
Leif Roar Moldskred

== 2 of 4 ==
Date: Thurs, Feb 11 2010 11:11 pm
From: Leif Roar Moldskred

In comp.lang.java.programmer Brian <coal@mailvault.com> wrote:
>
> Imagine driving by a house and seeing a car in front with
> this sign -- "Free car."

Imagine the cook at a soup kitchen storing raw and fried
chicken in the same container.

Or imagine a company giving out away a free game as a marketing
stunt and the game turns out to have been infected with a virus
that formats the users' hard-drives.

Or imagine the author of an open-source product not paying
sufficent attention and accepting a patch from a third party
which turns out to have included a backdoor, providing full
access to any system where the program is running.

--
Leif Roar Moldskred

== 3 of 4 ==
Date: Thurs, Feb 11 2010 11:16 pm
From: Richard Heathfield

Wojtek wrote:
<snip>
>
> So the decision to drop the century from the date was not only based on
> management but on hard economics.

It was common practice to take 6 bytes to store YYMMDD, despite the fact
that 5 bytes is easily sufficient to store CCYYMMDD.

<snip>

> And at the time Y2K was created it was not a bug. It was a money saving
> feature. Probably worth many millions.

No, it was a bug that wasted a byte and threw away data. And it's still
a bug - some of the "solutions" adopted by the industry just shifted the
problem on a little, by using a "century window" technique. That will
catch up with us eventually.

--
Richard Heathfield <http://www.cpax.org.uk>
Email: -http://www. +rjh@
"Usenet is a strange place" - dmr 29 July 1999
Sig line vacant - apply within

== 4 of 4 ==
Date: Fri, Feb 12 2010 12:08 am
From: Nick Keighley

On 11 Feb, 09:58, Michael Foukarakis <electricde...@gmail.com> wrote:
> On Feb 10, 6:54 pm, Seebs <usenet-nos...@seebs.net> wrote
> > On 2010-02-10, Michael Foukarakis <electricde...@gmail.com> wrote:

> > > Nobody knows how to build earthquake-immune buildings, yet engineers
> > > give certain guarantees. When those are failed to be met, (s)he is
> > > held liable. Maybe it's about time some "software engineers" were held
> > > liable for their unreliable code in the same way.
>
> > Why?
>
> > Do you have any evidence to suggest that this kind of liability is actually
> > reasonable, justified, and/or necessary?
>
> I am not an expert at law, so I cannot reason about justification or
> necessity. However, I do recall quite a few "mishaps" and software
> bugs that cost both money and lives.
> Let's see: a) Mariner I, b) 1982, an F-117 crashed, can't recall if
> the pilot made it, c) the NIST has estimated that software bugs cost
> the US economy $59 billion annually, d) 1997, radar software
> malfunction led to a Korean jet crash and 225 deaths, e) 1995, a
> flight-management system presents conflicting information to the
> pilots of an American Airlines jet, who got lost, crashed into a
> mountain, leading to the deaths of 159 people, f) the crash of Mars
> Polar Lander, etc. Common sense tells me that certain people bear
> responsibility over those accidents.

http://catless.ncl.ac.uk/risks

> How can anybody ignore this? Do more people have to die for us to
> start educating software engineers about responsibility, liability,
> consequences? Right now, CS students learn that an error in their
> program is easily solved by adding carefully placed printf()'s or
> running inside a debugger, and that the worst consequence if the TA
> discovers a bug in their project solution is maybe 1/10 lesson
> credits.
>
> I was exposed to the same mentality, but it's totally fucked up.
>
> > > That's absolutely right. But we can't sit and wait for software
> > > development to be refined on its own, we should probably do something
> > > about it. Collectively or whatnot.
>
> > I agree.  I just don't think that rants about liability or certification
> > are going to do anything.  Neither of those has a thing to do with learning
> > to write more reliable software.
>
> So what? We already know how to write more reliable software, it's
> just that we don't care.

==============================================================================
TOPIC: array compound literal
http://groups.google.com/group/comp.lang.c/t/74e5a77497c3f2b9?hl=en
==============================================================================

== 1 of 1 ==
Date: Thurs, Feb 11 2010 11:47 pm
From: Luca Forlizzi

On 11 Feb, 21:03, Keith Thompson <ks...@mib.org> wrote:
> Luca Forlizzi <luca.forli...@gmail.com> writes:

> Do you mean lcc or lcc-win? lcc, as I recall, only supports C90;
> lcc-win has reasonably good C99 support (I don't know whether it's
> complete).
>

lcc-win. The compilers output is as follows.
this is my test program:

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

int b;

int main(void) {

int (*ap)[2];

int *pi;
int ai[4]={ 1,2,3,4};

struct st {
float a;
char b;
int c;
} st_v;

st_v = (struct st){ 2.3, 3, 300};
pi = ai;
pi = ( int [2] ){ 1, 3 };
ap = &( (int [2]){ 4, 5});

printf(" pi[0] = %d, pi[1] = %d\n", pi[0], pi[1]);
printf(" (*ap)[0] = %d, (*ap)[1] = %d\n", (*ap)[0], (*ap)[1]);

}
------------------------------------------------

Compiled with "gcc -Wall -pedantic -std=c99" gives no diagnostics and
the program
prints the expected values.

Digital Mars Compiler produces the following diagnostics:

PS D:\temp\prove_c> dmc -A99 compound_literal.c
st_v = (struct st){ 2.3, 3, 300};
^
compound_literal.c(18) : Error: expression expected
pi = ( int [2] ){ 1, 3 };
^
compound_literal.c(20) : Error: expression expected
ap = &( (int [2]){ 4, 5});
^
compound_literal.c(21) : Error: expression expected
--- errorlevel 1

It seems dmc does not support compound literal, even for stucture
types

Lcc-win gives the following diagnostics:

PS D:\temp\prove_c> lc -ansic compound_literal.c
Error compound_literal.c: 20 the left hand side of the assignment
can't be assigned to
Error compound_literal.c: 21 the left hand side of the assignment
can't be assigned to
2 errors, 0 warnings
1 error

So the compound literal for the structure type is ok (as confirmed by
other tests which successfully compile and run as expected), but the
ones for array types are not.

@Ian Collins
Both lcc-win and DMC support many C99 features. dmc has compiler
options for C89, C95, C99 and others. I don't know if they claim to be
C99 fully conformant, probably not.

==============================================================================

You received this message because you are subscribed to the Google Groups "comp.lang.c"
group.

To post to this group, visit http://groups.google.com/group/comp.lang.c?hl=en

To unsubscribe from this group, send email to comp.lang.c+unsubscribe@googlegroups.com

To change the way you get mail from this group, visit:
http://groups.google.com/group/comp.lang.c/subscribe?hl=en

To report abuse, send email explaining the problem to abuse@googlegroups.com

==============================================================================
Google Groups: http://groups.google.com/?hl=en