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

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

comp.lang.c@googlegroups.com

Today's topics:

* newbie question on understanding the main() function - 2 messages, 2 authors
http://groups.google.com/group/comp.lang.c/t/47facf1454751d70?hl=en
* UTF-8 and wchar_t - 1 messages, 1 author
http://groups.google.com/group/comp.lang.c/t/6e69f9f50e29243f?hl=en
* Knowing the implementation, are all undefined behaviours become
implementation-defined behaviours? - 3 messages, 2 authors
http://groups.google.com/group/comp.lang.c/t/4f8b56b26018cf4e?hl=en
* Stylistic questions on UNIX C coding. - 4 messages, 4 authors
http://groups.google.com/group/comp.lang.c/t/51d2b24a60d73f18?hl=en
* Warning to newbies - 1 messages, 1 author
http://groups.google.com/group/comp.lang.c/t/9597fd702985dff4?hl=en
* Is there a better way to achieve this ? - 1 messages, 1 author
http://groups.google.com/group/comp.lang.c/t/dd4de60290d2834a?hl=en
* Best way/library to draw individual pixels on screen? (for fractals) - 1
messages, 1 author
http://groups.google.com/group/comp.lang.c/t/bf4e0288d8537985?hl=en
* Reverse and Alphabetize in under 2kb - 5 messages, 3 authors
http://groups.google.com/group/comp.lang.c/t/11babfbf4fe82c07?hl=en
* usage of size_t - 5 messages, 1 author
http://groups.google.com/group/comp.lang.c/t/19e0ad96d01b9898?hl=en
* help: gcc compilation difference - 1 messages, 1 author
http://groups.google.com/group/comp.lang.c/t/c99c680c6b425b26?hl=en
* Any exit status without explicitely using return /exit - 1 messages, 1
author
http://groups.google.com/group/comp.lang.c/t/6e91ccafedde0c25?hl=en

==============================================================================
TOPIC: newbie question on understanding the main() function
http://groups.google.com/group/comp.lang.c/t/47facf1454751d70?hl=en
==============================================================================

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

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

> Philip Potter <pgp@doc.ic.ac.uk> writes:
>
>> On 08/02/2010 13:27, Ben Bacarisse wrote:
>>> An incorrect definition of
>>> main is not a constraint violation (I am not sure why, but there it
>>> is) so the compiler can be silent about it if it chooses to be.
>>
>> One reason might be that implementations are free to allow alternative
>> definitions of main() other than int main(void) and int main(int,
>> char**). For example, the fairly widely used
>> int main(int argc, char **argv, char **envp)
>> would violate any constraint requiring main to be one of the two
>> standard prototypes.
>
> I'd have thought that the wording could permit implementation-defined
> alternatives (without a diagnostic) but I take your point.
>
> Another way would be to do what is done with constant expressions --
> extensions are allowed but anything that is not a constant expression
> as defined by the standard must be diagnosed. [snip]

As far as I know implementation-specific constant expressions are
not required to be given a diagnostic (assuming 6.6p3 isn't
violated), since 6.6p10 explicitly and specifically allows them
as constant expressions. Do have a supporting citation? No
constraints are violated as far as I know.

== 2 of 2 ==
Date: Tues, Mar 2 2010 2:00 pm
From: Ben Bacarisse

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

> Ben Bacarisse <ben.usenet@bsb.me.uk> writes:
<snip>
>> Another way would be to do what is done with constant expressions --
>> extensions are allowed but anything that is not a constant expression
>> as defined by the standard must be diagnosed. [snip]
>
> As far as I know implementation-specific constant expressions are
> not required to be given a diagnostic (assuming 6.6p3 isn't
> violated), since 6.6p10 explicitly and specifically allows them
> as constant expressions. Do have a supporting citation?

No. I was miss-remembering something, though I don't know what exactly.

--
Ben.

==============================================================================
TOPIC: UTF-8 and wchar_t
http://groups.google.com/group/comp.lang.c/t/6e69f9f50e29243f?hl=en
==============================================================================

== 1 of 1 ==
Date: Tues, Mar 2 2010 1:16 pm
From: Nobody

On Tue, 02 Mar 2010 19:16:20 +0100, Ersek, Laszlo wrote:

> For the UTF-8 input coming from elsewhere: if you can stick with glibc,
> just call
>
> #include <iconv.h>
>
> convdesc = iconv_open("WCHAR_T", "UTF-8");

Or you can write your own UTF-8 encoder/decoder. Personally, I wouldn't
make iconv a requirement just for UTF-8. If you're going to be using iconv
anyhow, then you may as well use it for this as well.

==============================================================================
TOPIC: Knowing the implementation, are all undefined behaviours become
implementation-defined behaviours?
http://groups.google.com/group/comp.lang.c/t/4f8b56b26018cf4e?hl=en
==============================================================================

== 1 of 3 ==
Date: Tues, Mar 2 2010 2:12 pm
From: Tim Rentsch

Seebs <usenet-nospam@seebs.net> writes:

> On 2010-02-14, Richard Tobin <richard@cogsci.ed.ac.uk> wrote:
>> In article <slrnhngdv0.8ao.usenet-nospam@guild.seebs.net>,
>> Seebs <usenet-nospam@seebs.net> wrote:
>>>It could be that the loop was written because the programmer wasn't *sure*
>>>it couldn't be null, but the compiler has proven it and thus feels safe
>>>optimizing.
>
>> All the more reason for a warning. Then the programmer can sleep
>> soundly, and perhaps modify the code accordingly. (And modify the
>> comment about it that he no doubt wrote.)
>
> Hmm.
>
> The problem is, this becomes a halting problem case, effectively. It's like
> the warnings for possible use of uninitialized variables.

There is one very important difference -- in one case the
compilers says the code /might/ not work they way you /think/ it
does, and in the other case the compiler says the code /won't/
work they way you said it /should/ work. Any optimizations
predicated on previous undefined behavior fall into the second
category, and warnings for these are "fool proof", because they
happen only when the compiler is doing something it's /sure/ is
dangerous, not when you're doing something that only /might/ be dangerous.

> We *know* that
> those warnings are going to sometimes be wrong, or sometimes be omitted when
> they were appropriate, so the compiler has to accept some risk
> of error.

Good compilers do only one of these for uninitialized variables,
namely, they sometimes warn that variables might be used without
initialization even though they aren't. No decent compiler that
purports to give warnings on uninitialized variable use ever
misses a case when this might happen.

> I
> think this optimization is in the same category -- there's too many boundary
> cases to make it a behavior that people rely on or expect.

I expect if you think about it a little longer you'll reach
a different conclusion.

== 2 of 3 ==
Date: Tues, Mar 2 2010 2:17 pm
From: Tim Rentsch

raltbos@xs4all.nl (Richard Bos) writes:

> richard@cogsci.ed.ac.uk (Richard Tobin) wrote:
>
>> In article <slrnhng9pl.2mq.usenet-nospam@guild.seebs.net>,
>> Seebs <usenet-nospam@seebs.net> wrote:
>>
>> > while (ptr != 0) {
>> > /* blah blah blah */
>> > ptr = get_ptr();
>> > x = *ptr;
>> > }
>> >
>> >gcc might turn the while into an if followed by an infinite loop, because
>> >it *knows* that ptr can't become null during the loop, because if it did,
>> >that would have invoked undefined behavior.
>>
>> As I've said before, the fact that the compiler can do this sort of
>> optimisation is often an indication of an error in the code. Why
>> would the programmer repeatedly test the pointer if it couldn't be
>> null? I would much rather that the compiler warned about this, instead
>> of just treating it as an opportunity to remove some code.
>
> I'd much rather that it did both. I can see why you'd want a warning,
> but I still want my compiler to optimise away a test which I'd not
> realised was superfluous (or perhaps more likely, which is superfluous
> on one architecture but not on another).

Definitely - as long as the compiler provides an option to give
the warning, I also want the option to do the optimization.

== 3 of 3 ==
Date: Tues, Mar 2 2010 2:26 pm
From: Seebs

On 2010-03-02, Tim Rentsch <txr@x-alumni2.alumni.caltech.edu> wrote:
> Good compilers do only one of these for uninitialized variables,
> namely, they sometimes warn that variables might be used without
> initialization even though they aren't. No decent compiler that
> purports to give warnings on uninitialized variable use ever
> misses a case when this might happen.

I do not believe this to be the case.

> I expect if you think about it a little longer you'll reach
> a different conclusion.

Well, actually. The reason I hold my current belief is that I have had
opportunities to discuss "may be used uninitialized" warnings with gcc
developers. And it turns out that, in fact, spurious warnings are
consistently reported as bugs, and that at any given time, gcc is usually
known both to give spurious warnings and to miss some possible uninitialized
uses. In each case, the goal of the developers seems to be to maximize
the chances that gcc is correct.

Now, maybe that makes gcc "not a good compiler", but it certainly makes gcc
the sort of compiler that customers appear to want, which is one which does
its best to minimize errors rather than accepting a larger number of errors
in order to ensure that they're all of the same sort.

Keep in mind that, stupid though it may be, many projects have a standing
policy of building with warnings-as-errors, so a spurious warning can cause
a fair bit of hassle.

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

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

== 1 of 4 ==
Date: Tues, Mar 2 2010 2:27 pm
From: Joe Wright

Tim Streater wrote:
> On 02/03/2010 18:23, Branimir Maksimovic wrote:
>> Nick Keighley wrote:
>>> On 2 Mar, 09:11, Branimir Maksimovic <bm...@hotmail.com> wrote:
>>>> Nick Keighley wrote:
>>>>> On 27 Feb, 16:39, Rich Webb <bbew...@mapson.nozirev.ten> wrote:
>>>>>> On Sat, 27 Feb 2010 08:30:16 -0800 (PST), Nick Keighley
>>>>>> <nick_keighley_nos...@hotmail.com> wrote:
>>>>>>> On 27 Feb, 08:39, James Harris <james.harri...@googlemail.com>
>>>>>>> wrote:
>>>
>>>
>>>>>>>> [...] what do Windows
>>>>>>>> users use to enter and edit source code?
>>>>>>> the IDE, ConText, emacs, Word
>>>>>> vi! Nowadays likely in its gvim incarnation, of course.
>>>>> VI VI VI!
>>>>> the editor of the beast
>>>> Well, when I used VI it was because there wasn;t anything
>>>> better on machine. Who said: VI editor that beeps and corrupts you
>>>> files?
>>>> Once I encrypted my source code by accident with that thing.
>>>
>>>
>>> "The Real Programmer wants a "you asked for it, you got it"
>>> text editor--complicated, cryptic, powerful, unforgiving,
>>> dangerous. TECO, to be precise."
>> Heh, I prefer Joe Allen's editor and using it for development ;)
>>
>> http://joe-editor.sourceforge.net/index.html
>>
>> Best editor out there IMO! ;)
>
> 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.

My most used editor on Windows is EDIT.COM and on Unix of course, vi. I do
use the GUI IDE from Visual FoxPro but normally write C and xBASE from the
command line with EDIT.

--
Joe Wright
"If you rob Peter to pay Paul you can depend on the support of Paul."

== 2 of 4 ==
Date: Tues, Mar 2 2010 3:12 pm
From: Tim Streater

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

>> Revolting. Looks like a DOS editor. When was this written, 1980?
>>
> It's WordStar for Unix. It's well written and functional.

Look, I could edit the bits on the disk with a bar magnet and a
magnifying glass. But why would I want to?

> Why would you be revolted by it? What's wrong with a DOS editor?
> 1980 was a really great year. Get a grip.

Why make life difficult for yourself?

> 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. I've used emacs twice (more or less
by accident each time). On both occasions it took me 20 mins to find out
how to quit it.

> I do use the GUI IDE from Visual FoxPro but normally write C and
> xBASE from the command line with EDIT.

Odd. You'll be using TECO next. I expect an editor, as a mere tool, not
to get in my way and expect me to have to "learn" it.

More than 20 years ago, the first unix boxes came in the door where I
was working. As a longtime user of VM/CMS I thought you had to spend
time learning how to use editors. The guys were all debating about which
editor should become the standard for everyone learn and use - vi,
emacs, jove, ...

Since they were arguing and I had work to do, I got hold of Notepad and
started using that (this was on a Sun box). Some six months later the
guys were still arguing about which one would be the "right" one. I
think they considered this important as they expected to have to give
classes/tutorials on the "chosen" editor. I then suddenly realised that,
in fact, *I* was using the right editor. It had taken me 5 mins to get a
quick mental image of which commands were on which menus and get on with
my work. No classes needed.

I guess they must still be arguing and that this argument has now spread
into c.l.c. I can't see the point of clunky keyboard-based editors on
24x80 little windows. A bit like paper tape and teletypes. Marvels in
their day, or course, but museum pieces now.

--
Tim

"That the freedom of speech and debates or proceedings in Parliament
ought not to be impeached or questioned in any court or place out of
Parliament"

Bill of Rights 1689

== 3 of 4 ==
Date: Tues, Mar 2 2010 3:38 pm
From: Branimir Maksimovic

Tim Streater wrote:
>
> I guess they must still be arguing and that this argument has now spread
> into c.l.c. I can't see the point of clunky keyboard-based editors on
> 24x80 little windows. A bit like paper tape and teletypes. Marvels in
> their day, or course, but museum pieces now.
>
Well you have to have some editor on server when you connect with ssh.
For me it's either vi or joe. I can compile joe in a second
and make it functional when I need it;)
But Im used to wordstar from CP/M so it is more familiar to me
then vi.
Also I used Lyrix word processor on at&t unix to write some serious text
processing work.
I had only 24x80 terminals, had to tweak termcap a bit.
On VOS there was Emacs.

Greets

== 4 of 4 ==
Date: Tues, Mar 2 2010 4:00 pm
From: Ben Bacarisse

Tim Streater <timstreater@waitrose.com> writes:
<snip>
> More than 20 years ago, the first unix boxes came in the door where I
> was working. As a longtime user of VM/CMS I thought you had to spend
> time learning how to use editors. The guys were all debating about
> which editor should become the standard for everyone learn and use -
> vi, emacs, jove, ...
>
> Since they were arguing and I had work to do, I got hold of Notepad
> and started using that (this was on a Sun box). Some six months later
> the guys were still arguing about which one would be the "right"
> one. I think they considered this important as they expected to have
> to give classes/tutorials on the "chosen" editor. I then suddenly
> realised that, in fact, *I* was using the right editor.

Everyone comes to the same realisation sooner or later (unless they are
being deliberately masochistic).

> It had taken
> me 5 mins to get a quick mental image of which commands were on which
> menus and get on with my work. No classes needed.
>
> I guess they must still be arguing and that this argument has now
> spread into c.l.c.

They were arguing about what editor *other* people should use and that
is widely thought to be an argument that never ends. :-)

<snip>
--
Ben.

==============================================================================
TOPIC: Warning to newbies
http://groups.google.com/group/comp.lang.c/t/9597fd702985dff4?hl=en
==============================================================================

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

Tim Rentsch <txr@x-alumni2.alumni.caltech.edu> writes:
<snip>
> Ben Bacarisse <ben.usenet@bsb.me.uk> writes:
>> ... I should have written
>>
>> strlen(src) - matches*mlen + matches*rlen + 1
>>
>> because it will work for a wider range of inputs.
>
> Eh? If SIZE_MAX > INT_MAX (and it almost certainly is), these
> two expressions will have exactly the same value. Are you
> worried about the case where SIZE_MAX <= INT_MAX?

Well, there is that but that was not going through my head at the
time. At some point I'd had some code that adjusted a pointer in
this way and there is matters if the addition happens before the
subtraction. I carried that worry over to an unsigned calculation
where it does not.

--
Ben.

==============================================================================
TOPIC: Is there a better way to achieve this ?
http://groups.google.com/group/comp.lang.c/t/dd4de60290d2834a?hl=en
==============================================================================

== 1 of 1 ==
Date: Tues, Mar 2 2010 2:37 pm
From: Peter Nilsson

Tim Rentsch <t...@x-alumni2.alumni.caltech.edu> wrote:
> Francis Moreau <francis.m...@gmail.com> writes:
> > I have the following requierement: 3 ints (a, b, limit).
> > The sum of 'a' and 'b' shouldn't be bigger than limit
> > otherwise 'a' should be adjusted so that the sum of 'a'
> > and 'b' is equal to 'limit'.

There seem to be more criteria, e.g. a and b are non-negative.

> > Basically this can be written in C like this:
<snip>
> > Can anybody think to something more 'elegant' ?
>
>     if(  a<0 || b<0 || limit<b  )  goto end;
>     if(  a > limit - b  )  a = limit - b;
>     /* Here a >= 0, b >= 0, a+b <= limit */

The purely general case is...

if (b < 0)
{
if (limit <= INT_MAX + b)
if (limit - b < a)
a = limit - b;
else
{
if (limit < INT_MIN + b)
goto end; /* a needs to be < INT_MIN : ERROR! */
if (limit - b < a)
a = limit - b;
}

--
Peter

==============================================================================
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 1 ==
Date: Tues, Mar 2 2010 4:00 pm
From: Wolfnoliir

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 (e.g. Mandelbrot
or Julia). So it is important that the method be speed efficient.
I would also be interested in knowing (very briefly) how one would go
about making a video player inside a GTK application.

I have some knowledge of SDL and OpenGL already.

==============================================================================
TOPIC: Reverse and Alphabetize in under 2kb
http://groups.google.com/group/comp.lang.c/t/11babfbf4fe82c07?hl=en
==============================================================================

== 1 of 5 ==
Date: Tues, Mar 2 2010 3:13 pm
From: Chad

Here is the job interview question that I drew a blank on.

Make a C program that:

Accepts a string input
Displays the original string
Reverses the order of words in the string ("This is a string" =
"string a is This")
Alphabetizes the letters in each word individually ("hisT is a
ginrst")

It all has to be under 2kb and I can't use strtok().

== 2 of 5 ==
Date: Tues, Mar 2 2010 3:23 pm
From: Eric Sosman

On 3/2/2010 6:13 PM, Chad wrote:
> Here is the job interview question that I drew a blank on.
>
> Make a C program that:
>
> Accepts a string input
> Displays the original string
> Reverses the order of words in the string ("This is a string" =
> "string a is This")
> Alphabetizes the letters in each word individually ("hisT is a
> ginrst")
>
> It all has to be under 2kb and I can't use strtok().

Seems simple enough except for the "under 2kb" part.
What's that supposed to mean? Less than 2KB of source code?
All other "2KB" measures I can think of (code size, data
size, stack size, heap size, ...) would be entirely platform-
dependent and not directly controllable by the way you use
the C language. Even HelloWorld probably takes more than
2KB of executable code on most implementations.

--
Eric Sosman
esosman@ieee-dot-org.invalid

== 3 of 5 ==
Date: Tues, Mar 2 2010 3:39 pm
From: Chad

On Mar 2, 3:23 pm, Eric Sosman <esos...@ieee-dot-org.invalid> wrote:
> On 3/2/2010 6:13 PM, Chad wrote:
>
> > Here is the job interview question that I drew a blank on.
>
> > Make a C program that:
>
> > Accepts a string input
> > Displays the original string
> > Reverses the order of words in the string ("This is a string" =
> > "string a is This")
> > Alphabetizes the letters in each word individually ("hisT is a
> > ginrst")
>
> > It all has to be under 2kb and I can't use strtok().
>
>      Seems simple enough except for the "under 2kb" part.
> What's that supposed to mean?  Less than 2KB of source code?
> All other "2KB" measures I can think of (code size, data
> size, stack size, heap size, ...) would be entirely platform-
> dependent and not directly controllable by the way you use
> the C language.  Even HelloWorld probably takes more than
> 2KB of executable code on most implementations.
>
> --

Yeah, the 2kb part is what confused me. I was just assuming they meant
the size of the executable file.

== 4 of 5 ==
Date: Tues, Mar 2 2010 3:39 pm
From: "bartc"

"Chad" <cdalten@gmail.com> wrote in message
news:d66e64ad-0553-4127-a2b8-422b9ebc2e7c@c37g2000prb.googlegroups.com...
> Here is the job interview question that I drew a blank on.
>
> Make a C program that:
>
> Accepts a string input
> Displays the original string
> Reverses the order of words in the string ("This is a string" =
> "string a is This")
> Alphabetizes the letters in each word individually ("hisT is a
> ginrst")

What do you mean by alphabetize? And what happened to reversal, or did you
want this separately from the alphabetizing?

I got:

"ginrst a is This"

by reversing the words and sorting the characters in each word (but all
upper case come before all lower case).

--
Bartc

== 5 of 5 ==
Date: Tues, Mar 2 2010 4:06 pm
From: Chad

On Mar 2, 3:39 pm, "bartc" <ba...@freeuk.com> wrote:
> "Chad" <cdal...@gmail.com> wrote in message
>
> news:d66e64ad-0553-4127-a2b8-422b9ebc2e7c@c37g2000prb.googlegroups.com...
>
> > Here is the job interview question that I drew a blank on.
>
> > Make a C program that:
>
> > Accepts a string input
> > Displays the original string
> > Reverses the order of words in the string ("This is a string" =
> > "string a is This")
> > Alphabetizes the letters in each word individually ("hisT is a
> > ginrst")
>
> What do you mean by alphabetize? And what happened to reversal, or did you
> want this separately from the alphabetizing?
>
> I got:
>
> "ginrst a is This"
>
> by reversing the words and sorting the characters in each word (but all
> upper case come before all lower case).
>

I figured they wanted reversal and alphabetizing done separately.

==============================================================================
TOPIC: usage of size_t
http://groups.google.com/group/comp.lang.c/t/19e0ad96d01b9898?hl=en
==============================================================================

== 1 of 5 ==
Date: Tues, Mar 2 2010 3:40 pm
From: Tim Rentsch

Seebs <usenet-nospam@seebs.net> writes:

> On 2010-02-21, Francis Moreau <francis.moro@gmail.com> wrote:
>> So I took a look to the C99 spec and see what it tells about size_t:
>> and it's the type of the retuned value by sizeof() (6.5.3.4 p4) and
>> its max value is 65535 (7.18.3 p2).
>
> You are incorrect.
>
> Its max value is *AT LEAST* 65535.
>
> It may be much, much, much, larger.
>
>> size_t doesn't seem to be the good type to use when the variable of
>> that type describes the number of elements of a buffer whose type is
>> not 'char' and if the buffer size is less than 65535 bytes.
>
>> Is that correct ?
>
> I don't understand what you are trying to do.
>
> Use size_t for sizes. If you are recording the number of items in a thing,
> and it's zero or more, use size_t, that's what size_t is for. It doesn't
> matter what the type is or whether or not it's 65535 bytes or more or
> less. If you can have a buffer of over 65535 bytes, then size_t will be
> able to represent sizes over 65535.

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.

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

santosh <santosh.k83@gmail.com> writes:

> Francis Moreau <francis.moro@gmail.com> writes:
>> On Feb 21, 4:49 pm, santosh <santosh....@gmail.com> wrote:
>>> Francis Moreau <francis.m...@gmail.com> writes:
>>>
>>> > size_t doesn't seem to be the good type to use when the variable
>>> > of that type describes the number of elements of a buffer whose
>>> > type is not 'char' and if the buffer size is less than 65535
>>> > bytes.
>>>
>>> > Is that correct ?
>>>
>>> Why do you say it's not a good type to represent the size of
>>> non-char objects? What's your reasoning for this?
>>
>> Well, size_t is the type of the value returned by sizeof(). And
>> sizeof() returns the number of bytes (ie char) of its operand. So I
>> assumed that size_t was introduced to represent a number of char.
>
> As far as I know, the purpose of size_t seems to be to serve as a
> portable type to hold the sizes of objects. However it's also the
> only type guaranteed to hold the number of elements of an object, in
> a strict sense. [snip]

Where in the Standard do you find this guarantee? As far
as I know there is no such requirement.

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

richard@cogsci.ed.ac.uk (Richard Tobin) writes:

> In article <M-SdnUFuaLJKpB_WnZ2dnUVZ8kSdnZ2d@bt.com>,
> Richard Heathfield <rjh@see.sig.invalid> wrote:
>
>>> It requires the reader to remember the
>>> difference between --i and i--, and it requires them to be aware of
>>> the implicit int-to-bool conversion.
>
>>I would expect any serious C programmer to be aware of both of these
>>without having to think too strenuously about it
>
> I also think it's unclear, but not because the reader is likely to
> be unaware of the difference. The trouble is that it seems natural
> for a test at the top of a loop to be testing the value that will
> be used in the loop, but here it is testing a different value.
>
> I suppose you could use
>
> for(i=N-1; i != (size_t)-1; i--)
>
> but it's not pretty.

Why not just this:

for(i=N-1; i != -1; i--)

which works for any integer type, either signed or
unsigned, whose conversion rank is at least that of int.

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

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?

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

raltbos@xs4all.nl (Richard Bos) writes:

> Keith Thompson <kst-u@mib.org> wrote:
>
>> Kelsey Bjarnason <kbjarnason@gmail.com> writes:
>> > On Wed, 24 Feb 2010 17:16:24 +0000, Richard Bos wrote:
>> >> Yes, but you are on record as never having had to contend with tiny,
>> >> small, medium, compact, large and huge memory models. Things could
>> >> get... interesting.
>> >
>> > Particularly since two pointers which actually point to the same thing
>> > may not compare equal, due to segment:offset varations.
>> >
>> > At least huge pointers normalized. :)
>> >
>> > (It is *so* nice not to have to deal with that crap anymore.)
>>
>> If two pointers that point to the same thing don't compare equal,
>> then the implementation is non-conforming. C99 6.5.9p6:
>
> IIRC the only way to get two such pointers was by pointer manipulation
> that would be considered to have undefined behaviour in ISO C, BICBW.

That seems highly unlikely, since the implementation-defined conversions
between pointers and integers almost certainly suffice to construct
the offending pointer values without relying on undefined behavior.

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

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

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. Or if you think there
is, what section in the Standard defines it?

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

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

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