comp.lang.c - 25 new messages in 6 topics - digest

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

comp.lang.c@googlegroups.com

Today's topics:

* Any exit status without explicitely using return /exit - 1 messages, 1
author
http://groups.google.com/group/comp.lang.c/t/6e91ccafedde0c25?hl=en
* Stylistic questions on UNIX C coding. - 10 messages, 5 authors
http://groups.google.com/group/comp.lang.c/t/51d2b24a60d73f18?hl=en
* Best way/library to draw individual pixels on screen? (for fractals) - 5
messages, 5 authors
http://groups.google.com/group/comp.lang.c/t/bf4e0288d8537985?hl=en
* usage of size_t - 4 messages, 3 authors
http://groups.google.com/group/comp.lang.c/t/19e0ad96d01b9898?hl=en
* Is there a better way to achieve this ? - 3 messages, 2 authors
http://groups.google.com/group/comp.lang.c/t/dd4de60290d2834a?hl=en
* help: gcc compilation difference - 2 messages, 2 authors
http://groups.google.com/group/comp.lang.c/t/c99c680c6b425b26?hl=en

==============================================================================
TOPIC: Any exit status without explicitely using return /exit
http://groups.google.com/group/comp.lang.c/t/6e91ccafedde0c25?hl=en
==============================================================================

== 1 of 1 ==
Date: Tues, Mar 2 2010 4:41 pm
From: Tim Rentsch

Keith Thompson <kst-u@mib.org> writes:

> Debanjan <debanjan4you@gmail.com> writes:
>> This actually bugging me from quite sometime now.The question is like
>> this : How to set the the exit status of a program to any value
>> without explicitly using return/exit in gcc ?
> [...]
>
> Some equally interesting questions:
>
> How can you add two numbers without using the "+" operator?
>
> How can you call a function without using a function call?
>
> How can you pound a nail without using a hammer?
>
> A more relevant question: Why don't you want to use return or exit?
> That's what they're for.

I'm sure it wasn't meant to sound this way, but as I read it this
response seemed rather harsh. The question seems to me to be a
fair question, perhaps even somewhat interesting. So even though
I probably agree with the implicit advice in the Socratic last
question, I hope it's reasonable to suggest giving friendlier and
more helpful answers, even in cases where the questioner may be
motivated by concerns that are stylistically suboptimal.

==============================================================================
TOPIC: Stylistic questions on UNIX C coding.
http://groups.google.com/group/comp.lang.c/t/51d2b24a60d73f18?hl=en
==============================================================================

== 1 of 10 ==
Date: Tues, Mar 2 2010 4:39 pm
From: William Ahern

In comp.unix.programmer Joe Wright <joewwright@comcast.net> wrote:
> Tim Streater wrote:
<snip>
> > Revolting. Looks like a DOS editor. When was this written, 1980?
> >
> It's WordStar for Unix. It's well written and functional. Why would you be
> revolted by it? What's wrong with a DOS editor? 1980 was a really great
> year. Get a grip.

In 1994 or 1995 I happened upon a BBS that allowed me to shell out to the
Slackware Linux host. A few weeks, and many, many hours downloading the
install set over my 2400 baud modem later, I was using this new "Linux"
thing almost exclusively.

joe was and perhaps is still the default editor on Slackware.

Around the same time I began taking a distance course at the University of
West Florida. The course was taught through e-mail and the university's
netnews system, introducing me to tin and elm (and joe again, because the
school used Slackware).

I'm reading this thread in tin, am typing this post in joe, and I only
switched from elm to mutt 3 or 4 years ago.

If it ain't broken....

== 2 of 10 ==
Date: Tues, Mar 2 2010 4:34 pm
From: Rich Webb

On Tue, 02 Mar 2010 23:12:18 +0000, Tim Streater
<timstreater@waitrose.com> wrote:

>On 02/03/2010 22:27, Joe Wright wrote:

>> My most used editor on Windows is EDIT.COM and on Unix of course, vi.
>
>Fortunately I don't deal with Windows. On OS X, I use vi only where I
>have to. Hmmm, vi, that has *modes* doesn't it, such as you can't use
>the arrow keys while in insert mode.

Take a look at gvim (graphic + vi + improved). It still has the ability
to work over a simple terminal, with the separate command and insert
modes, but nowadays it can also work just like a "regular" text editor
with the expected behavior of the arrow keys, home/end, mouse drag to
select text, and the whole nine yards.

--
Rich Webb Norfolk, VA

== 3 of 10 ==
Date: Tues, Mar 2 2010 4:50 pm
From: Tim Rentsch

Rich Webb <bbew.ar@mapson.nozirev.ten> writes:

> On Wed, 24 Feb 2010 11:10:21 -0800 (PST), Julienne Walker
> <happyfrosty@hotmail.com> wrote:
>
>>On Feb 24, 1:35 pm, Poster Matt <postermatt@no_spam_for_me.org> wrote:
>>> Hi,
>>>
>>> I've a few questions concerning style when programming C on UNIX systems. I
>>> don't want to look like an amateur. :)
>
>>> 3. Is there an accepted maximum line length? I've got a 24" monitor, if I reach
>>> 120 chars I start thinking this might not look great in someone else's editor.
>>
>>I try to keep each line under 100 characters (80 if possible). It's
>>less about monitor size than it is about easily reading my code at a
>>glance.
>
> Typographers, who study this thing with the fervor that programmers
> bring to brace styles, would tend to agree. There are always reasonable
> exceptions but a line length that's 70-80 characters (monospaced) seems
> to be a sweet spot for comprehension.

Granted (well more or less), but notice that there is an
important difference. The reading mode for prose (ordinary
written text) is very different than the reading mode for
program source. Source code is not read as a single linear
text; it chunkifies into very particular units, and these
units are more easily comprehended when grouped in some
spatial patterns than others.

Not to say that I disagree with the conclusion necessarily, the
number 80 may be right for both. But it's a mistake to think
that the same reasoning must apply to both domains, because
the reading modes in those respective domains are so different.

== 4 of 10 ==
Date: Tues, Mar 2 2010 4:54 pm
From: Tim Rentsch

Ben Bacarisse <ben.usenet@bsb.me.uk> writes:

> Richard Heathfield <rjh@see.sig.invalid> writes:
>
>> Anand Hariharan wrote:
>> <snip>
>>
>>> Haven't seen anyone point this out:
>>>
>>> Rather than -
>>>
>>> #define MAXNUMFILES 1024
>>>
>>> - prefer -
>>>
>>> const int MaxNumFiles = 1024;
>>>
>>>
>>> That way your preprocessor won't do as much damage.
>>
>> Fine in C99, I think, but an issue in C90 if he's using it to define
>> an array size.
>
> It's a problem in C99 too, if the array is defined at file scope or it
> has internal linkage. There are other reasons why it's not a great
> idea in C99. They stem from the fact that MaxNumFiles is not
> permitted as part of a constant expression. [snip elaboration]

Minor clarification -- MaxNumFiles is _permitted_ as part of a constant
expression, albeit an implementation-specific constant expression;
it just isn't _required_ to be a portable constant expression.

== 5 of 10 ==
Date: Tues, Mar 2 2010 5:10 pm
From: Tim Rentsch

"robertwessel2@yahoo.com" <robertwessel2@yahoo.com> writes:

> On Feb 25, 11:15 pm, Kelsey Bjarnason <kbjarna...@gmail.com> wrote:
>> On Thu, 25 Feb 2010 19:48:06 -0800, Ben Pfaff wrote:
>> > Kelsey Bjarnason <kbjarna...@gmail.com> writes:
>>
>> >> My take on this has always been to standardize the format "checked in",
>> >> then use indent or some equivalent, on check in and check out, to
>> >> convert between the "checkin format" and the individual coder's
>> >> preferred format.
>>
>> > I've heard of this approach, but I always assumed that it was a joke.
>> > You really use it?
>>
>> I have, repeatedly, over the years.
>>
>> The problem with _not_ doing it is that you tend to get a lot of checkins
>> where the "diff" is wildly out of sync with what actually got changed,
>> particularly if the coder's tools do things such as switching tabs to
>> spaces or re-organizing braces, etc, etc, etc, which many tools do.
>>
>> By using indent or an equivalent on checkin, you ensure a standard format
>> going in, such that only "real" changes are recorded, and by using it on
>> checkout, you deliver to the coder whatever flavour he's happiest with.
>>
>> Or, you can skip it on checkout and just let him use whatever tools he
>> likes, but I've found delivering to the developer something which he is
>> maximally comfortable with, right out of the gate, tends to produce
>> maximum productivity and minimum frustration.
>
>
> A problem with that approach is that it will trash any special/careful
> formatting that you might use to clarify a complex section of code.
> [snip]

Perhaps it will if the tool is poor, but it doesn't have to.
Certainly indent-like tools can be written that don't just
disregard all white space but filter it in or out selectively,
doing just enough to make the indentation and brace placement
right but still preserving column alignments appropriately when
the input warrants it.

The benefits of having such a tool, especially for a large group,
clearly outweigh the cost of providing it.

== 6 of 10 ==
Date: Tues, Mar 2 2010 5:11 pm
From: Tim Rentsch

Tim Streater <timstreater@waitrose.com> writes:

> On 26/02/2010 02:56, Kelsey Bjarnason wrote:
>> On Wed, 24 Feb 2010 22:09:43 +0000, Scott Lurndal wrote:
>>
>>> James Harris<james.harris.1@googlemail.com> writes:
>>>> On 24 Feb, 20:53, BruceS<bruce...@hotmail.com> wrote:
>>>>
>>>> ...
>>>>
>>>>> I would like to add that, as long as you're trying to use good style,
>>>>> for God's sake don't use the wrong indentation style. =A0If you put
>>>>> your opening braces on the same line as your conditional, you'll just
>>>>> look like a fool in front of your friends and colleagues.
>>>>
>>>> Snobbish nonsense!
>>>>
>>>>
>>>>
>>> Indeed.
>>>
>>> if (condition) {
>>>
>>> is preferred over
>>>
>>> if (condition)
>>> {
>>
>> Not by me, it ain't. :)
>>
>>> Makes it much more likely that a properly written function will fit on a
>>> single page/screen.
>>
>> And less likely to catch proper vs improper bracing and indentation, when
>> the braces don't line up with the indents.
>>
>>> In 30 years of C programming, no employer or project has used the latter
>>> form.
>>
>> This is one of those cases where there really are legitimate reasons for
>> each approach, with the deciding factor being preference.
>>
>> My take on this has always been to standardize the format "checked in",
>> then use indent or some equivalent, on check in and check out, to convert
>> between the "checkin format" and the individual coder's preferred format.
>
> My preferred approach is to do like this:
>
> function wiggy ()
> {
> if (cond)
> {
> dostuff;
> }
> else {
> dootherstuff;
> }
> }
>
> This has been my approach ever since I was writing BCPL in the 70s -
> it has the braces lining up so that the matching can be seen easily.

Does this mean you've never tried alternate approaches since then?
Did you try any other approaches earlier?

== 7 of 10 ==
Date: Tues, Mar 2 2010 5:20 pm
From: Tim Rentsch

Tim Woodall <devnull@woodall.me.uk> writes:

> [snip various comments on brace placement]
>
> Obviously, the major advantage to putting the '{' on the same line as
> the conditional is that it reduces paper usage when typesetting

Certainly this could count as an advantage, but it is not "the
major" advantage, or an especially important one.

> and hence why you will normally see it in books.

K&R uses the same bracing style, AFAIAA, that Ken Thompson
and Dennis Ritchie use in their own programming. I expect
most people use in their books the same style that they
use themselves when programming. And there are plenty of
books that put open braces on separate lines rather than
on the same lines as if, etc.

== 8 of 10 ==
Date: Tues, Mar 2 2010 5:31 pm
From: Tim Rentsch

Ben Pfaff <blp@cs.stanford.edu> writes:

> Kelsey Bjarnason <kbjarnason@gmail.com> writes:
>[snip]
>
>> By using indent or an equivalent on checkin, you ensure a standard format
>> going in, such that only "real" changes are recorded, and by using it on
>> checkout, you deliver to the coder whatever flavour he's happiest with.
>
> Doesn't it screw up any careful formatting, e.g. of comments?
> And sometimes careful placement of white space can make the code
> much easier to read.

Better indent-style tools will preserve such extra formatting
and/or alignments in the reformatted source. Obviously this
can't be done to work in every imaginable situation, but IME
the coverage of different scenarios can be good enough so that
the limitations are felt hardly ever if at all. Not perfect,
but practically speaking good enough (and much better than
some of the more restrictive alternatives).

== 9 of 10 ==
Date: Tues, Mar 2 2010 5:38 pm
From: Ian Collins

Tim Rentsch wrote:
> Ben Bacarisse <ben.usenet@bsb.me.uk> writes:
>
>> Richard Heathfield <rjh@see.sig.invalid> writes:
>>
>>> Anand Hariharan wrote:
>>> <snip>
>>>
>>>> Haven't seen anyone point this out:
>>>>
>>>> Rather than -
>>>>
>>>> #define MAXNUMFILES 1024
>>>>
>>>> - prefer -
>>>>
>>>> const int MaxNumFiles = 1024;
>>>>
>>>>
>>>> That way your preprocessor won't do as much damage.
>>> Fine in C99, I think, but an issue in C90 if he's using it to define
>>> an array size.
>> It's a problem in C99 too, if the array is defined at file scope or it
>> has internal linkage. There are other reasons why it's not a great
>> idea in C99. They stem from the fact that MaxNumFiles is not
>> permitted as part of a constant expression. [snip elaboration]
>
> Minor clarification -- MaxNumFiles is _permitted_ as part of a constant
> expression, albeit an implementation-specific constant expression;
> it just isn't _required_ to be a portable constant expression.

What? You could say just about any nonsense is permitted as part of an
implementation-specific expression.

That doesn't alter that fact that in C90 or C99, MaxNumFiles is not
permitted as part of a constant expression.

--
Ian Collins

== 10 of 10 ==
Date: Tues, Mar 2 2010 6:02 pm
From: Keith Thompson

Ian Collins <ian-news@hotmail.com> writes:
> Tim Rentsch wrote:
>> Ben Bacarisse <ben.usenet@bsb.me.uk> writes:
>>> Richard Heathfield <rjh@see.sig.invalid> writes:
>>>> Anand Hariharan wrote:
>>>> <snip>
>>>>> Haven't seen anyone point this out:
>>>>>
>>>>> Rather than -
>>>>>
>>>>> #define MAXNUMFILES 1024
>>>>>
>>>>> - prefer -
>>>>>
>>>>> const int MaxNumFiles = 1024;
>>>>>
>>>>>
>>>>> That way your preprocessor won't do as much damage.
>>>> Fine in C99, I think, but an issue in C90 if he's using it to define
>>>> an array size.
>>> It's a problem in C99 too, if the array is defined at file scope or it
>>> has internal linkage. There are other reasons why it's not a great
>>> idea in C99. They stem from the fact that MaxNumFiles is not
>>> permitted as part of a constant expression. [snip elaboration]
>>
>> Minor clarification -- MaxNumFiles is _permitted_ as part of a constant
>> expression, albeit an implementation-specific constant expression;
>> it just isn't _required_ to be a portable constant expression.
>
> What? You could say just about any nonsense is permitted as part of
> an implementation-specific expression.
>
> That doesn't alter that fact that in C90 or C99, MaxNumFiles is not
> permitted as part of a constant expression.

I think Tim is referring to C99 6.6p10:

An implementation may accept other forms of constant expressions.

(I just noticed that this doesn't use the term
"implementation-defined" implying, I think, that an implementation
can accept other forms of constant expressions but isn't required
to document them.)

My understanding is that code that uses extensions in general (as
permitted by C99 4p6) still require diagnostics if the code violates a
constraint, but code that uses "other forms of constant expressions"
does not.

I'd say Tim's statement is correct, but I'd place the emphasis very
differently: MaxNumFiles is not permitted as part of a constant
expression (unless the implementation permits it under C99 6.6p10).

Are there any real-world C implementations that take advantage of this
permission? Specifically, is there a C compiler that accepts
additional forms of constant expressions in (what it claims to be)
conforming mode?

And why is that permission there in the first place? What benefit
does it really provide beyond the existing permission to provide
extensions?

--
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: Best way/library to draw individual pixels on screen? (for fractals)
http://groups.google.com/group/comp.lang.c/t/bf4e0288d8537985?hl=en
==============================================================================

== 1 of 5 ==
Date: Tues, Mar 2 2010 4:46 pm
From: Seebs

On 2010-03-03, Wolfnoliir <wolfnoliir@gmail.com> wrote:
> Hello,
> I would like to know what library and method you would recommend for
> displaying individual pixels on the screen in the scope of producing
> representations of fractals based on complex iteration

Something suitable to my target platform. The answer would be very different
for the iPhone than it would for a Linux desktop...

Which is to say, this has very little to do with C. Try a group related to
the platform.

-s
--
Copyright 2010, all wrongs reversed. Peter Seebach / usenet-nospam@seebs.net
http://www.seebs.net/log/ <-- lawsuits, religion, and funny pictures
http://en.wikipedia.org/wiki/Fair_Game_(Scientology) <-- get educated!

== 2 of 5 ==
Date: Tues, Mar 2 2010 6:38 pm
From: Wolfnoliir

Seebs a écrit :
> On 2010-03-03, Wolfnoliir <wolfnoliir@gmail.com> wrote:
>> Hello,
>> I would like to know what library and method you would recommend for
>> displaying individual pixels on the screen in the scope of producing
>> representations of fractals based on complex iteration
>
> Something suitable to my target platform. The answer would be very different
> for the iPhone than it would for a Linux desktop...
>
> Which is to say, this has very little to do with C. Try a group related to
> the platform.
>
> -s
Thanks but I would prefer something platform independent.

== 3 of 5 ==
Date: Tues, Mar 2 2010 5:46 pm
From: Ian Collins

Wolfnoliir wrote:
> Seebs a �crit :
>> On 2010-03-03, Wolfnoliir <wolfnoliir@gmail.com> wrote:
>>> Hello,
>>> I would like to know what library and method you would recommend for
>>> displaying individual pixels on the screen in the scope of producing
>>> representations of fractals based on complex iteration
>> Something suitable to my target platform. The answer would be very different
>> for the iPhone than it would for a Linux desktop...
>>
>> Which is to say, this has very little to do with C. Try a group related to
>> the platform.
>>
> Thanks but I would prefer something platform independent.

There isn't anything platform independent.

--
Ian Collins

== 4 of 5 ==
Date: Tues, Mar 2 2010 5:51 pm
From: Peter Nilsson

Seebs <usenet-nos...@seebs.net> wrote:
> Wolfnoliir <wolfnol...@gmail.com> wrote:
> > I would like to know what library and method you would
> > recommend for displaying individual pixels on the screen
> > in the scope of producing representations of fractals
> > based on complex iteration
>
> Something suitable to my target platform.  The answer would
> be very different for the iPhone than it would for a Linux
> desktop...

I wouldn't recommend it, but as a one off I might run the
following and open the resultant mand.html file on either
platform.

#include <stdio.h>
#include <stdlib.h>

#define T -0.65
#define B -0.75

#define L -0.33
#define R -0.23

#define ROWS 300
#define COLS 300

#define Jre .5
#define Jim -.2

#define MAXITER 1000

#define SZ 1

#define FILENAME "mand.html"

double scale(double a, double b, double c, double v, double w)
{
return v + (a - b) / (c - b) * (w - v);
}

size_t mand(double cre, double cim, size_t max)
{
double re, im;
double nre, nim;
size_t iter;

re = Jre;
im = Jim;
for (iter = 0; iter < max; iter++)
{
nre = re * re - im * im + cre;
nim = 2 * re * im + cim;
re = nre;
im = nim;
if (re * re + im * im >= 4.0) return iter;
}

return iter;
}

int main(void)
{
FILE *fp;
size_t r, c;

fp = fopen(FILENAME, "w");
if (!fp) { puts("ERROR"); return 0; }

fputs("<table border=1><tr><td>\n", fp);
fputs("<table cellpadding=0 cellspacing=0>\n", fp);

for (r = 0; r < ROWS; r++)
{
fputs("<tr>\n", fp);
for (c = 0; c < COLS; c++ )
{
double x = scale(c, 0, COLS - 1, L, R);
double y = scale(r, 0, ROWS - 1, T, B);
size_t i = mand(x, y, MAXITER);
unsigned g = i * 255.0 / MAXITER;
g = 255 - g;
g = g % 16;
g = g * 17;

fprintf(fp, "<td width=\"%d\" height=\"%d\"", SZ, SZ);
fprintf(fp, "bgcolor=\"#%02X%02X%02X\"", g, g, g);
fprintf(fp, "<td></td>\n");
}
fputs("</tr>\n", fp);
}

fputs("</table>\n", fp);
fputs("</td></tr></table>\n", fp);

fclose(fp);
return 0;
}

> Which is to say, this has very little to do with C.

I'm sure this would come as a highly confusing shock to the OP
if they had read your statement elsewhere that Facebook can be
implemented in C.

> Try a group related to the platform.

That, I agree with.

--
Peter

== 5 of 5 ==
Date: Tues, Mar 2 2010 6:05 pm
From: Keith Thompson

Ian Collins <ian-news@hotmail.com> writes:
> Wolfnoliir wrote:
>> Seebs a écrit :
>>> On 2010-03-03, Wolfnoliir <wolfnoliir@gmail.com> wrote:
>>>> Hello,
>>>> I would like to know what library and method you would recommend for
>>>> displaying individual pixels on the screen in the scope of producing
>>>> representations of fractals based on complex iteration
>>> Something suitable to my target platform. The answer would be very different
>>> for the iPhone than it would for a Linux desktop...
>>>
>>> Which is to say, this has very little to do with C. Try a group related to
>>> the platform.
>>>
>> Thanks but I would prefer something platform independent.
>
> There isn't anything platform independent.

Well, you could print one character per pixel, but I'm sure that's not
what the OP is looking for.

Or you could write an image file in some specified format (some
formats are binary, others are plain text) and leave the job of
displaying it up to some other platform-specific tool.

But you're right, there is no platform independent way to display
individual pixels on a screen. (Not all platforms even have screens.)

--
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: usage of size_t
http://groups.google.com/group/comp.lang.c/t/19e0ad96d01b9898?hl=en
==============================================================================

== 1 of 4 ==
Date: Tues, Mar 2 2010 4:47 pm
From: Seebs

On 2010-03-02, Tim Rentsch <txr@x-alumni2.alumni.caltech.edu> wrote:
> Certainly that seems to be the expectation, but I don't
> think it's required or necessarily guaranteed. I'm
> pretty sure a conforming implementation could have
> SIZE_MAX == 65535 but still allow
>
> char too_big[ 100000 ];
>
> for example. And that's only one way of getting a buffer of
> more than SIZE_MAX bytes.

I can't see how. If it does that, what does it give you for sizeof(too_big)?

-s
--
Copyright 2010, all wrongs reversed. Peter Seebach / usenet-nospam@seebs.net
http://www.seebs.net/log/ <-- lawsuits, religion, and funny pictures
http://en.wikipedia.org/wiki/Fair_Game_(Scientology) <-- get educated!

== 2 of 4 ==
Date: Tues, Mar 2 2010 5:30 pm
From: Ian Collins

Tim Rentsch wrote:
> Malcolm McLean <malcolm.mclean5@btinternet.com> writes:
>
>> On Feb 22, 5:23 pm, santosh <santosh....@gmail.com> wrote:
>>> Right, but size_t is maximally portable (whatever that means) while
>>> unsigned long is not.
>>>
>> size_t is the only type that is guaranteed to be able to index any
>> array. [snip]
>
> Oh? Which paragraphs in the Standard provide that guarantee?

The result type of the sizeof() operator is size_t, so the range of
size_t has to be large enough to index any array.

--
Ian Collins

== 3 of 4 ==
Date: Tues, Mar 2 2010 5:33 pm
From: Ian Collins

Tim Rentsch wrote:
>
> Certainly that seems to be the expectation, but I don't
> think it's required or necessarily guaranteed. I'm
> pretty sure a conforming implementation could have
> SIZE_MAX == 65535 but still allow
>
> char too_big[ 100000 ];
>
> for example. And that's only one way of getting a buffer of
> more than SIZE_MAX bytes.

No, it couldn't. That would break sizeof().

--
Ian Collins

== 4 of 4 ==
Date: Tues, Mar 2 2010 5:38 pm
From: Keith Thompson

Tim Rentsch <txr@x-alumni2.alumni.caltech.edu> writes:
> Malcolm McLean <malcolm.mclean5@btinternet.com> writes:
>> On Feb 22, 5:23 pm, santosh <santosh....@gmail.com> wrote:
>>> Right, but size_t is maximally portable (whatever that means) while
>>> unsigned long is not.
>>>
>> size_t is the only type that is guaranteed to be able to index any
>> array. [snip]
>
> Oh? Which paragraphs in the Standard provide that guarantee?

size_t is the type yielded by the sizeof operator. The sizeof
operator may be applied to any type or expression, and yields the
size in bytes of the type or expression. There is no permission
for this to fail. Since the number of elements of an array cannot
exceed its size in bytes, it follows that the number of elements
can be represented as a size_t.

Finding the relevant paragraphs in the Standard is left as an
exercise. (You'll likely disagree with some of my reasoning anyway.)

--
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: Is there a better way to achieve this ?
http://groups.google.com/group/comp.lang.c/t/dd4de60290d2834a?hl=en
==============================================================================

== 1 of 3 ==
Date: Tues, Mar 2 2010 4:48 pm
From: "Mark"

Tim Rentsch wrote:
[snip]
>> Can anybody think to something more 'elegant' ?
>
> if( a<0 || b<0 || limit<b ) goto end;
> if( a > limit - b ) a = limit - b;

Why can't we make it as 'if (a+b > limit)' ?

> /* Here a >= 0, b >= 0, a+b <= limit */

--
Mark

== 2 of 3 ==
Date: Tues, Mar 2 2010 5:33 pm
From: Peter Nilsson

On Mar 3, 11:48 am, "Mark" <mark_cruzNOTFORS...@hotmail.com> wrote:
> Tim Rentsch wrote:
> >    if(  a<0 || b<0 || limit<b  )  goto end;
> >    if(  a > limit - b  )  a = limit - b;
>
> Why can't we make it as 'if (a+b > limit)' ?

Because a + b can overflow, whereas limit - b can't if
they're all non-negative.

--
Peter

== 3 of 3 ==
Date: Tues, Mar 2 2010 6:42 pm
From: "Mark"

Peter Nilsson wrote:
> On Mar 3, 11:48 am, "Mark" <mark_cruzNOTFORS...@hotmail.com> wrote:
>> Tim Rentsch wrote:
>>> if( a<0 || b<0 || limit<b ) goto end;
>>> if( a > limit - b ) a = limit - b;
>>
>> Why can't we make it as 'if (a+b > limit)' ?
>
> Because a + b can overflow, whereas limit - b can't if
> they're all non-negative.

But you implicitly check 'b' for being negative:

if (b < 0)
{
if (limit <= INT_MAX + b)
if (limit - b < a)

.. then here 'b' is already negative?

--
Mark

==============================================================================
TOPIC: help: gcc compilation difference
http://groups.google.com/group/comp.lang.c/t/c99c680c6b425b26?hl=en
==============================================================================

== 1 of 2 ==
Date: Tues, Mar 2 2010 5:19 pm
From: Ben Bacarisse

Tim Rentsch <txr@x-alumni2.alumni.caltech.edu> writes:

> Ben Bacarisse <ben.usenet@bsb.me.uk> writes:
>
>> santosh <santosh.k83@gmail.com> writes:
>>
>>> new <luvraghu@gmail.com> writes:
>>>
>>>> Richard,Keith and all thanks a ton for your replies.
>>>> I have one more question.
>>>> In the code if I add the following line:
>>>> ------------------------------------
>>>> z = s[p[0]]++; // say z is declared as int
>>>> ------------------------------------
>>>> what would be the value of z and how it is evaluated?
>>>>
>>>> Thanks a lot in advance.
>>>
>>> Since you don't initialise the s array, it's members could contain
>>> any garbage value, normally the value that was last written to the
>>> memory location. So by extension, we cannot say z contains any useful
>>> value after your assignment. In standard C parlance, it's value is
>>> indeterminate, and reading an indeterminate object, as in the RHS of
>>> your assignment statement, invokes undefined behaviour, again in the
>>> standard's terminology.
>>
>> Is this really true? I don't think it is, at least not in the general
>> way that is often presented here. An indeterminate value is either a
>> valid value of the type or it is a trap representation. Thus, on
>> system with no trap representations for objects interpreted as having
>> type T, accessing an indeterminate value of type T must simply be
>> unspecified.
>>
>> Now, in this case, s was of type char. 6.2.6.1 p5 which defines and
>> discusses trap representations states that:
>>
>> Certain object representations need not represent a value of the
>> object type. If the stored value of an object has such a
>> representation and is read by an lvalue expression that does not
>> have character type, the behavior is undefined. If such a
>> representation is produced by a side effect that modifies all or any
>> part of the object by an lvalue expression that does not have
>> character type, the behavior is undefined. Such a representation is
>> called a trap representation.
>>
>> I read that as forbidding UB when a trap representation is accessed
>> via an lvalue expression of type char which is the case here, is it
>> not?
>
> I believe that's a misreading. What the passage says is that if the
> access type is a non-character type then the behavior is undefined.
> It does not say that if the access type is a character type then the
> behavior is defined. Access through a character type interprets the
> stored value (ie, the representation) according to the type used to do
> the read; if the access type is (char) or (signed char) and the
> representation read is a trap representation for that type, it's still
> undefined behavior, because there's no (Standard-)defined way to
> produce a value from a trap representation.

OK, that's reasonable (and was how I first read it): access via a
character type is undefined or defined depending on whether the byte
is or is not a trap representation for the character type used.

What, then, is the effect of the second sentence of the quote? It
must be to add a further blanket undefined for all accesses to one
type's trap representations when accessed via another type. I.e. that
given

union { int si; unsigned ui; } u;

access to u.ui is undefined when u.si holds a trap representation even
when unsigned int has no trap representations of its own.

If that is right there are two things that puzzled me and cause me to
over-think the clause in question. First, it seems odd to give signed
char this odd half-way position and, second, it seems at odds with the
explanation of unions in 6.5.2.3 p3. At the very least the footnote
should surely be expanded to cover the case where some other union
member is trap representation.

Neither of these are arguments for my reading. They are there to
explain why I thought the way I did.

--
Ben.

== 2 of 2 ==
Date: Tues, Mar 2 2010 5:30 pm
From: Peter Nilsson

Tim Rentsch <t...@x-alumni2.alumni.caltech.edu> wrote:
> Ben Bacarisse <ben.use...@bsb.me.uk> writes:
> > 6.2.6.1 p5 which defines and discusses trap representations
> > states that:
> >
> > Certain object representations need not represent a value
> > of the object type. If the stored value of an object has
> > such a representation and is read by an lvalue expression
> > that does not have character type, the behavior is
> > undefined. If such a representation is produced by a side
> > effect that modifies all or any part of the object by an
> > lvalue expression that does not have character type, the
> > behavior is undefined. Such a representation is called a
> > trap representation.
> >
> > I read that as forbidding UB when a trap representation is
> > accessed via an lvalue expression of type char which is the
> > case here, is it not?
>
> I believe that's a misreading.

If it misreads the intent, it's because the intent is not
clear. ;)

> What the passage says is that if the access type is a non-
> character type then the behavior is undefined. It does not say
> that if the access type is a character type then the behavior
> is defined. Access through a character type interprets the
> stored value (ie, the representation) according to the type
> used to do the read; if the access type is (char) or (signed
> char) and the representation read is a trap representation for
> that type, it's still undefined behavior, because

To put it another way, the last time this discussion came up,
the majority view was that trap representations are possible for
all types except unsigned char (and unsigned bit-fields).
Access to trap representations for non character types is
explicitly undefined. Access to trap representations for signed
character types is _implicitly_ undefined due to a lack of
specification!

Note that "[It is implementation-defined] whether the value
with sign bit 1 and all value bits zero (for the first two),
or with sign bit and all value bits 1 (for ones' complement),
is a trap representation or a normal value." does not
exclude application to signed character types.

Thus, signed character types can have trap representations.
Whether they can be accessed is a separate issue.

The question remains, why does 6.2.6.1p5 _explicitly_ exclude
character types?

> there's no (Standard-)defined way to
> produce a value from a trap representation.

What's the standard way to produce a value from a non trap
representation for an integer type? Why wouldn't that apply?

--
Peter

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

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