twitter: comp.lang.c - 25 new messages in 9 topics

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

comp.lang.c@googlegroups.com

Today's topics:

* Got stuck with quicksort code from the "Unleashed C". - 1 messages, 1 author
http://groups.google.com/group/comp.lang.c/t/0fb91f93b991c210?hl=en
* An interview question - 4 messages, 3 authors
http://groups.google.com/group/comp.lang.c/t/c93105672f793e63?hl=en
* how to get out of double for loops? - 4 messages, 3 authors
http://groups.google.com/group/comp.lang.c/t/535cb24e8f02aec3?hl=en
* Call for papers: SETP-10, USA, July 2010 - 1 messages, 1 author
http://groups.google.com/group/comp.lang.c/t/fc2be90d49f4fc70?hl=en
* efficiency question - 1 messages, 1 author
http://groups.google.com/group/comp.lang.c/t/ac42317db6371cec?hl=en
* Stylistic questions on UNIX C coding. - 7 messages, 3 authors
http://groups.google.com/group/comp.lang.c/t/51d2b24a60d73f18?hl=en
* Has thought been given given to a cleaned up C? Possibly called C+. - 4
messages, 3 authors
http://groups.google.com/group/comp.lang.c/t/5954dc70a43f9f8e?hl=en
* A Minor Problem With atoi() And Negative Numbers - 2 messages, 2 authors
http://groups.google.com/group/comp.lang.c/t/5218f6623a71b4c1?hl=en
* problem 1.13 The C programming language - 1 messages, 1 author
http://groups.google.com/group/comp.lang.c/t/e3b5a2688181479c?hl=en

==============================================================================
TOPIC: Got stuck with quicksort code from the "Unleashed C".
http://groups.google.com/group/comp.lang.c/t/0fb91f93b991c210?hl=en
==============================================================================

== 1 of 1 ==
Date: Sun, Mar 7 2010 12:29 pm
From: grishin-mailing-lists@minselhoz.samara.ru

Thanks for the replies, guys.

No, It's not a coursework, I've graduated 5 years ago. Just taking
some disciplines for myself (and on my own).
I thought that it's possible to get feedback from [one of] the
author[s] of the book. 10 years have past since publication. I'm
unlikely the first who found the bug (IS it a bug or typographical
error or peculiarities of Russian edition?).
Well, I'm able to trace programs, BTW thank you for fprintf trick.
I've had few crashes before and noticed a weird printf behavior.

==============================================================================
TOPIC: An interview question
http://groups.google.com/group/comp.lang.c/t/c93105672f793e63?hl=en
==============================================================================

== 1 of 4 ==
Date: Sun, Mar 7 2010 12:31 pm
From: Moi

On Sun, 07 Mar 2010 21:26:59 +0100, Moi wrote:

> On Sun, 07 Mar 2010 13:38:43 +0000, Ben Bacarisse wrote:
>
>> Moi <root@invalid.address.org> writes:
>>
>>> On Sat, 06 Mar 2010 18:56:00 -0800, Keith Thompson wrote:
>>>
>>>> Tim Rentsch <txr@x-alumni2.alumni.caltech.edu> writes:
>>>>> Eric Sosman <esosman@ieee-dot-org.invalid> writes:
>>>>>> On 3/6/2010 9:48 AM, Tim Rentsch wrote:
>>>>>>> Eric Sosman<esosman@ieee-dot-org.invalid> writes:
>>>>
>>>>
>>>>
>
>>> IMHO the sizeof operator evaluates to a size_t, or at least to a
>>> unsigned type that is compatible with a size_t.
>>>
>>> So basically you could use the "sizeof expression" syntax:
>>>
>>> unsigned sizeofsizeof;
>>>
>>> sizeofsizeof = sizeof sizeof 0+0;
>>
>> Did you mean that? It parses as (sizeof (sizeof 0)) + 0. What is the
>> 0+0 for?
>>
>>
> To catch your attention. The essence is that sizeof yields a size_t
> *even if size_t has not been typedeffed yet*
>
>
>> I can't see how knowing the size of a size_t helps here. Calling a
>> function with the wrong type of argument is UB even if the size of the
>> argument is correct. In practical terms, getting the size right (for
>> an integer argument) is often the thing that matters so I suppose that
>> might have been part of the intent of the question.
>
> Knowing the size could be useful to create fake function declarations
> for malloc() or strlen().
>
> unsigned long long mystrlen(const char *str) {
>
> if (sizeofsizeof == sizeof (unsigned long)) {

oops that should of course have been

if (sizeofsizeof == sizeof (unsigned long long)) {
> unsigned long long strlen(char const *str); return strlen (str);

AvK

== 2 of 4 ==
Date: Sun, Mar 7 2010 1:35 pm
From: Eric Sosman

On 3/7/2010 3:26 PM, Moi wrote:
> On Sun, 07 Mar 2010 13:38:43 +0000, Ben Bacarisse wrote:
>
>> Moi<root@invalid.address.org> writes:
>>> [...]
>>> unsigned sizeofsizeof;
>>> sizeofsizeof = sizeof sizeof 0+0;
>>
>> Did you mean that? It parses as (sizeof (sizeof 0)) + 0. What is the
>> 0+0 for?
>
> To catch your attention. The essence is that sizeof yields a size_t
> *even if size_t has not been typedeffed yet*

Yes, of course. Everybody knows that. It doesn't help.

>> I can't see how knowing the size of a size_t helps here. Calling a
>> function with the wrong type of argument is UB even if the size of the
>> argument is correct. In practical terms, getting the size right (for an
>> integer argument) is often the thing that matters so I suppose that
>> might have been part of the intent of the question.
>
> Knowing the size could be useful to create fake function declarations for
> malloc() or strlen().

How? On every system I've used, size_t is the same size as
one or the other of float or double, but it doesn't follow that

void *malloc(float);
double strlen(const char*);

... could be correct declarations, or even close to correct. Size
is an attribute of (object) type, but size is not type.

> unsigned long long mystrlen(const char *str)
> {
>
> if (sizeofsizeof == sizeof (unsigned long)) {
> unsigned long long strlen(char const *str);
> return strlen (str);
> }
> else if (sizeof sizeof == sizeof (unsigned long)) {
>
> unsigned long strlen(char const *str);
> return strlen(str);
> }
> else ...
> }
>
> This enables one to perform the call without size_t typedeffed.

No, it does not. If size_t has the same size as unsigned int
(for example), it does not follow that size_t *is* unsigned int,
or is passed to and from functions the same way unsigned int is.
On all systems, char and unsigned char have the same size, and on
many systems both are unsigned. It does not follow that char *is*
unsigned char.

> (which of course is silly, just as the interview question
> was silly in the first place)

Time to drag this horse to the glue factory, I think.

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

== 3 of 4 ==
Date: Sun, Mar 7 2010 2:08 pm
From: Seebs

On 2010-03-07, Eric Sosman <esosman@ieee-dot-org.invalid> wrote:
> ... could be correct declarations, or even close to correct. Size
> is an attribute of (object) type, but size is not type.

True.

You can come pretty close by observing that if you can find an unsigned
integer type t such that sizeof(t) == sizeof(sizeof(1)), it's probable
that t is the same type as size_t, but I think it's only probable, not
certain. The sizeof(float) question is less relevant; we are promised
that size_t is an unsigned integer type.

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

== 4 of 4 ==
Date: Sun, Mar 7 2010 2:38 pm
From: Eric Sosman

On 3/7/2010 5:08 PM, Seebs wrote:
> On 2010-03-07, Eric Sosman<esosman@ieee-dot-org.invalid> wrote:
>> ... could be correct declarations, or even close to correct. Size
>> is an attribute of (object) type, but size is not type.
>
> True.
>
> You can come pretty close by observing that if you can find an unsigned
> integer type t such that sizeof(t) == sizeof(sizeof(1)), it's probable
> that t is the same type as size_t, but I think it's only probable, not
> certain. The sizeof(float) question is less relevant; we are promised
> that size_t is an unsigned integer type.

On my machine, sizeof(unsigned int) == sizeof(size_t) and
sizeof(unsigned long) == sizeof(size_t). Which of unsigned int
and unsigned long (if either) actually *is* size_t?

(It so happens that unsigned int and unsigned long and size_t
values are all passed to and from functions with identical code,
so -- on my machine -- the resulting undefined behavior would
turn out to be "what you wanted." Doesn't make it right, though.)

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

==============================================================================
TOPIC: how to get out of double for loops?
http://groups.google.com/group/comp.lang.c/t/535cb24e8f02aec3?hl=en
==============================================================================

== 1 of 4 ==
Date: Sun, Mar 7 2010 12:37 pm
From: cri@tiac.net (Richard Harter)

On Sun, 7 Mar 2010 12:06:42 -0800 (PST), James Harris
<james.harris.1@googlemail.com> wrote:

>On 7 Mar, 14:16, Ben Bacarisse <ben.use...@bsb.me.uk> wrote:
>...
>> In a language (or programming style) without break and goto one can
>> make strong arguments about the behaviour of loops. =A0After
>>
>> =A0 while (E) { S; }
>>
>> one can assert that !E is true (there may not be an "after" of
>> course).
>
>(As you know) that's not much of a deduction. So what advantage can
>similar reasoning be expected to give in imperative programming? (Not
>functional programming which is another matter.) I've seen people
>write about advantages of certain control structures but I've never
>come across an explanation of the principles, if there are any.
>
>For example the most general imperative loop construct would be of the
>form
>
> for (;;) {
> <code>
> if (c1) break;
> <more code>
> if (c2) break;
> <even more code>
> if (c3) break;
> <etc>
> }
>
>Top and bottom decision loops as well as arbitrary mid decisions can
>all be expressed using such a control structure. Is there something
>about that form which inhibits reasoning?

One issue is that the termination condition is
c1 || c2 || c3 ...
In other words we know that one of them is true but we don't know
which one. This may not matter.

Another issue is that the breaks can be buried with nested code.

>
>
>> =A0Banning continue and non-terminal return statements also
>> simplifies the reasoning about the interaction of S and E.
>
>I'm glad to hear it but in what way or ways does *continue* work
>against reasoning?
>
>I guess you are referring to mid-routine return statements. They can
>return no value or a value of the wrong type. Any other problems with
>them from the point of view of reasoning?
>
>
>James

Richard Harter, cri@tiac.net
http://home.tiac.net/~cri, http://www.varinoma.com
It's not much to ask of the universe that it be fair;
it's not much to ask but it just doesn't happen.

== 2 of 4 ==
Date: Sun, Mar 7 2010 12:38 pm
From: cri@tiac.net (Richard Harter)

On 7 Mar 2010 17:58:33 GMT, ram@zedat.fu-berlin.de (Stefan Ram)
wrote:

>cri@tiac.net (Richard Harter) writes:
>>In some languages, not C of course, you can escape (break) from a
>>simple delimited block. If you could do this in C you could
>>write:
>> {
>> if ((result = something()) == BAD) break;
>> if ((result = somethingelse()) == BAD) break;
>> }
>>
>> if (result == BAD) {
>
> if
> ( ( result = something() ) == BAD )||
> ( result = somethingelse() )== BAD ))
> {

Well yes, but I don't think it generalizes.

Richard Harter, cri@tiac.net
http://home.tiac.net/~cri, http://www.varinoma.com
It's not much to ask of the universe that it be fair;
it's not much to ask but it just doesn't happen.

== 3 of 4 ==
Date: Sun, Mar 7 2010 1:36 pm
From: lacos@ludens.elte.hu (Ersek, Laszlo)

In article <0.5f6388a70cf15b366ed5.20100307191435GMT.87ocj054h0.fsf@bsb.me.uk>, Ben Bacarisse <ben.usenet@bsb.me.uk> writes:
> lacos@ludens.elte.hu (Ersek, Laszlo) writes:
>
>> In article <4n1b67-33b.ln1@jones.homeip.net>, lawrence.jones@siemens.com writes:
>>> Eric Sosman <esosman@ieee-dot-org.invalid> wrote:
>>>>
>>>> Yes (most of the time). They should have stakes driven
>>>> through their hearts -- but as has been pointed out here oft
>>>> and again, the C language itself doesn't use a stake ...
>>>
>>> You keep making puns like that and you're going to be in a heap of
>>> trouble.
>>
>> Care to explain what "use a stake" means here? I tried to look it up,
>> with not much success.
>
> It's a pun. Eric is playing on the oft quoted phrase "C does not use
> a stack". Hence Lawrence's "heap" pun in reply.
>
> Eric's did register on my humour meter but Lawrence is talking a load
> of mallocs.

Okay, thanks :) I got the "heap of trouble" (even without understanding
the stack/stake pun) and also your malloc()'s/bollocks pun. I even
considered shortly what some witty response to Lawrence's pun might be,
with "stack" in it. I was completely oblivious to the fact that the
original pun ran with "stack" already. "stake" doesn't rhyme with
"stack" when pronounced, and I didn't notice the eye rhyme(?).

http://en.wikipedia.org/wiki/Eye_rhyme

Thanks,
lacos

== 4 of 4 ==
Date: Sun, Mar 7 2010 3:32 pm
From: Ben Bacarisse

James Harris <james.harris.1@googlemail.com> writes:

I was simplifying and obviously went too far. You also have a loop
invariant, P, and it is this along with !E that forces the
post-condition, R, that the code intends to set up. On its own P
says very little but P /\ !E => R.

> (Not
> functional programming which is another matter.) I've seen people
> write about advantages of certain control structures but I've never
> come across an explanation of the principles, if there are any.
>
> For example the most general imperative loop construct would be of the
> form
>
> for (;;) {
> <code>
> if (c1) break;
> <more code>
> if (c2) break;
> <even more code>
> if (c3) break;
> <etc>
> }
>
> Top and bottom decision loops as well as arbitrary mid decisions can
> all be expressed using such a control structure. Is there something
> about that form which inhibits reasoning?

That one is not too bad because it is structured. It means

do {
<code>
if (!c1) {
<more code>
if (!c2) {
<even more code>
if (!c3) {
<etc>
}
}
}
} while (!c1 && !c2 && !c3);

(barring side-effects in the ci). The breaks imply a nesting that
complicates the reasoning but that is not the fault of the break. If
the loop has to be this complex because that is what is needed then
the break form is just a neater way to write it.

The problems come when break is used in far less structured ways. One
could argue that the problem is then not the break but the fact that
the code is a mess, and I'd probably go along with that.
Well-organised uses of break don't cause a lot of trouble.

>> Banning continue and non-terminal return statements also
>> simplifies the reasoning about the interaction of S and E.
>
> I'm glad to hear it but in what way or ways does *continue* work
> against reasoning?

This is likely to come out all hand-waving... When continue is used
in messy ways, for example:

while (E) {
if (C1) {
S1;
if (C2) {
S2;
continue;
}
}
S3;
}

you end up having to roll up lots of steps in the reasoning so as to
reason about the whole loop body. You can't use the usual rules about
if statements because the continue ties the inner if to the semantics
of the whole loop body.

> I guess you are referring to mid-routine return statements. They can
> return no value or a value of the wrong type.

Yes, by 2non-terminal" I meant mid-function return statements but I
don't follow what you mean here.

> Any other problems with
> them from the point of view of reasoning?

They have the same effect as on the continue example except the linkage
is to the enclosing function.

--
Ben.

==============================================================================
TOPIC: Call for papers: SETP-10, USA, July 2010
http://groups.google.com/group/comp.lang.c/t/fc2be90d49f4fc70?hl=en
==============================================================================

== 1 of 1 ==
Date: Sun, Mar 7 2010 12:42 pm
From: James Heralds

It would be highly appreciated if you could share this announcement
with your colleagues, students and individuals whose research is in
software engineering, software testing, software quality assurance,
software design and related areas.

Call for papers: SETP-10, USA, July 2010

The 2010 International Conference on Software Engineering Theory and
Practice (SETP-10) (website: http://www.PromoteResearch.org ) will be
held during 12-14 of July 2010 in Orlando, FL, USA. SETP is an
important event in the areas of Software development, maintenance, and
other areas of software engineering and related topics.

The conference will be held at the same time and location where
several other major international conferences will be taking place.
The conference will be held as part of 2010 multi-conference
(MULTICONF-10). MULTICONF-10 will be held during July 12-14, 2010 in
Orlando, Florida, USA. The primary goal of MULTICONF is to promote
research and developmental activities in computer science, information
technology, control engineering, and related fields. Another goal is
to promote the dissemination of research to a multidisciplinary
audience and to facilitate communication among researchers,
developers, practitioners in different fields. The following
conferences are planned to be organized as part of MULTICONF-10.

• International Conference on Artificial Intelligence and Pattern
Recognition (AIPR-10)
• International Conference on Automation, Robotics and Control
Systems (ARCS-10)
• International Conference on Bioinformatics, Computational Biology,
Genomics and Chemoinformatics (BCBGC-10)
• International Conference on Computer Communications and Networks
(CCN-10)
• International Conference on Enterprise Information Systems and Web
Technologies (EISWT-10)
• International Conference on High Performance Computing Systems
(HPCS-10)
• International Conference on Information Security and Privacy
(ISP-10)
• International Conference on Image and Video Processing and Computer
Vision (IVPCV-10)
• International Conference on Software Engineering Theory and Practice
(SETP-10)
• International Conference on Theoretical and Mathematical Foundations
of Computer Science (TMFCS-10)

MULTICONF-10 will be held at Imperial Swan Hotel and Suites. It is a
full-service resort that puts you in the middle of the fun! Located
1/2 block south of the famed International Drive, the hotel is just
minutes from great entertainment like Walt Disney World® Resort,
Universal Studios and Sea World Orlando. Guests can enjoy free
scheduled transportation to these theme parks, as well as spacious
accommodations, outdoor pools and on-site dining — all situated on 10
tropically landscaped acres. Here, guests can experience a full-
service resort with discount hotel pricing in Orlando.

We invite draft paper submissions. Please see the website
http://www.PromoteResearch.org for more details.

Sincerely
James Heralds

==============================================================================
TOPIC: efficiency question
http://groups.google.com/group/comp.lang.c/t/ac42317db6371cec?hl=en
==============================================================================

== 1 of 1 ==
Date: Sun, Mar 7 2010 12:53 pm
From: Bob

On Fri, 05 Mar 2010 17:11:00 +0200, Bob <bobbe@gmail.com> wrote:

Thank you very much for your answers :-)

Bob

>Hello,
>
>Please see my question below :
>
>type 'data2' is defined :
>
>typedef struct data2
>{
> int m;
> float n;
>
>} data2;
>
>
>data1 is defined :
>
>typedef struct data1
>{
> int a;
> float b;
> data2 *d2 // pointer to a data2 type
>
>} data1;
>
>
>I have a function with 3 arguments :
>
>void func(data1 *x, data2* y, char z)
>{
> .
> .
> .
>}
>
>I can also write this function as
>
>void func(data1 *x, char z)
>{
> data2 *y = x->d2
> .
> .
> .
>}
>
>I use the function 'func' millions of times,
>which implementation from the above two, will be quicker ?
>
>(the first variation allocates 3 places on the stack, the second only
>2, but it also has an extra line for assigning the pointer of data2)
>
>Thanks :-)
>
>Bob

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

== 1 of 7 ==
Date: Sun, Mar 7 2010 1:26 pm
From: lacos@ludens.elte.hu (Ersek, Laszlo)

In article
<0.487c45f99df6405ef9e4.20100307192325GMT.87iq98542a.fsf@bsb.me.uk>,
Ben Bacarisse <ben.usenet@bsb.me.uk> writes:

> lacos@ludens.elte.hu (Ersek, Laszlo) writes:
>
>> In article
>> <0.8e8fb4cfddc834871af3.20100307151405GMT.87hbos6u6a.fsf@bsb.me.uk>,
>> Ben Bacarisse <ben.usenet@bsb.me.uk> writes:

>>> Rainer Weikusat <rweikusat@mssgmbh.com> writes:
>>>
>>>> Ben Bacarisse <ben.usenet@bsb.me.uk> writes:
>>>>> Rainer Weikusat <rweikusat@mssgmbh.com> writes:
>>>>>> pete <pfiland@mindspring.com> writes:
>>>>>>
>>>>>>> To count down through an array with N elements, I use
>>>>>>>
>>>>>>> size_t i = N;
>>>>>>>
>>>>>>> while (i-- != 0) {
>>>>>>> array[i];
>>>>>>> }

>> size_t i = N;
>>
>> while (0u < i) {
>> --i;
>>
>> array[i];
>> array[i];
>> array[i];
>> }
>
> If the loop body changes so that is includes some break statements,
> pete's loop makes normal and abnormal loop exit easy to distinguish.
> It's not a big deal, but I do prefer pete's formulation for this
> reason.

Yeah... I was thinking, "who will be the first one to say 'linear
search'?" :) "0u == i" doesn't say anything after the loop.

Cheers,
lacos

== 2 of 7 ==
Date: Sun, Mar 7 2010 1:52 pm
From: Rainer Weikusat

Keith Thompson <kst-u@mib.org> writes:
> Rainer Weikusat <rweikusat@mssgmbh.com> writes:
>> Ben Bacarisse <ben.usenet@bsb.me.uk> writes:
>>> Rainer Weikusat <rweikusat@mssgmbh.com> writes:
>>>> pete <pfiland@mindspring.com> writes:
>>>>
>>>> [...]
>>>>
>>>>> To count down through an array with N elements, I use
>>>>>
>>>>> size_t i = N;
>>>>>
>>>>> while (i-- != 0) {
>>>>> array[i];
>>>>> }
>>>>
>>>> And you excuse for writing confusing code which requests that the
>>>> machine does useless things is that software to work around you has
>>>> already been developed, right?
>>>
>>> Why not show everyone what you consider to be the right way to do this
>>> so that we can all have the chance to write better/clearer loops? Not
>>> everyone will agree, of course, but it is surely better to give
>>> examples of good code than to criticise code you don't like.
>>
>> Isn't this obvious?
>
> No -- or at least it's not nearly as obvious as you seem to think
> it is.

It is completely obvious from the difference of meaning of the code
which was written down vs the part of the code which actually performs
some sensible function. Spelled out, the condition means (assuming
that x is also a variable of type size_t)

x = i, i = i - 1, x != 0

Since the loop is only supposed to run until the counter has reached
the value zero, decrementing an i whose value is zero when the
condition is checked for the last time is just a pointless contortion.

>> As written above, the calculation oversteps,
>> because the postdecrement will return zero when i already had this
>> value before decrementing it again.
>
> It does, but I don't think this is a significant problem.

If you desire to argue against my position, why don't you do so? I
explained why I consider this to be a serious problem in the text
below.

> The most
> common form of loop for iterating *up* through an array is:
>
> for (i = 0; i < N; i ++) [
> ... array[i] ...
> }
>
> oversteps the upper bound of the array.

So, your reasoning goes roughly "well, ok, it is nonsense, but that's
what we always do". That you always write code which requests that
superflouus calculations are performed is no reason why doing so
should be desirable.

>> Also, the condition is known to be
>> true so checking it before the first execution of the loop body is a
>> pointless exercise.
>
> That's true *only* if you know that you're iteratingover the entire
> array.

This is always true for the context the text which was following this
statement was supposed to make sense in. It doesn't matter what over
contexts you can dream up. That was the one I was using. Call it 'a
precondition' if you like.

[...]

>> A sensible way to express this in C would be
>>
>> do array[--i]; while (i);
>
> This fails rather catastrophically when N is 0.

It fails even more catastrophically when i was initially zero and
traversing the array in order of ascending indices was intended and
yet more catastrophically when, instead of traversing an array, the
string "Are you perhaps resorting to sophististry because you don't
have any arguments for your position" should have been printed. But
since none if this is/ was the case, that's quite besides the point.

If you desire to address the point I was trying to make, feel free to
do so. These sideline battles are useless exercises.

== 3 of 7 ==
Date: Sun, Mar 7 2010 2:14 pm
From: Seebs

On 2010-03-07, Nick Keighley <nick_keighley_nospam@hotmail.com> wrote:
> On 5 Mar, 18:26, Seebs <usenet-nos...@seebs.net> wrote:
>> On 2010-03-05, Richard Heathfield <r...@see.sig.invalid> wrote:
>> Actually, I'm not exactly talking about English. �I'm talking about the
>> underlying cognitive structures English (and every other language) maps to.

> ah! A disciple of Chompsky.I didn't know it had been proven beyond
> doubt that such a Deep Structure existed

It hasn't been, but if you can find a counterexample to the claim that
people generally distinguish between topic and comment, I'd love to see it.

> to write lisp you pretty well have to have support from your editor. I
> seem to nest stuff deeper than most people- maybe this is something
> computer programmers tend to do but lisp easily busts my internal
> stack.

Yeah. I had some of that trouble with it.

>> For me, swapping the "natural" order of a comparison (I expect the "topic"
>> to be first) is one extra layer, similar to an indirection, extra set of
>> parentheses, or whatever. �I don't know how common that is, but I'm pretty
>> sure it's not going to change in the forseeable future.

> I'll suffer the pain of an extra translation stage if I think it buys
> me much. In this case I'd rather have the test the "right" way round.

In my case, I have a lot more bugs from cognitive stack overflows than I
have ever had from mistakenly assigning things in tests, so it makes sense
for me to pick the style that doesn't make the big problem dramatically
bigger. :)

== 4 of 7 ==
Date: Sun, Mar 7 2010 2:16 pm
From: Seebs

On 2010-03-07, Rainer Weikusat <rweikusat@mssgmbh.com> wrote:
> Don't try to play 'stupid' with me. You understood me quite well, have
> 'surprisingly' completely ignored my text in order to construct a
> straw man

This raises a question that, while not strictly topical, I find fascinating.

Have you found a set of circumstances in which declaring that you know what
other people think, and they are lying, has ever produced any kind of positive
or desireable outcome? Do you in fact have the telepathic ability you've
claimed, or are you just dogmatically proclaiming what someone else actually
thought without any kind of evidence or support?

== 5 of 7 ==
Date: Sun, Mar 7 2010 2:25 pm
From: Rainer Weikusat

Rainer Weikusat <rweikusat@mssgmbh.com> writes:
> Keith Thompson <kst-u@mib.org> writes:

[...]

>> The most
>> common form of loop for iterating *up* through an array is:
>>
>> for (i = 0; i < N; i ++) [
>> ... array[i] ...
>> }
>>
>> oversteps the upper bound of the array.
>
> So, your reasoning goes roughly "well, ok, it is nonsense, but that's
> what we always do".

I should have read this more carefully :->. You are actually already
here (voluntarily) misinterpreting my statement, since none of the
increments which are supposed to be performed by the code quoted above
are technically useless, meaning, what I called 'overstepping the loop
counter' does not occur here. You are just hoping that a careless
reader (like me, for instance) takes your statement at face value,
without recognizing that you are already writing about a completely
different case.

== 6 of 7 ==
Date: Sun, Mar 7 2010 2:36 pm
From: Rainer Weikusat

Seebs <usenet-nospam@seebs.net> writes:
> On 2010-03-07, Rainer Weikusat <rweikusat@mssgmbh.com> wrote:
>> Don't try to play 'stupid' with me. You understood me quite well, have
>> 'surprisingly' completely ignored my text in order to construct a
>> straw man
>
> This raises a question that, while not strictly topical, I find fascinating.
>
> Have you found a set of circumstances in which declaring that you know what
> other people think, and they are lying, has ever produced any kind of positive
> or desireable outcome?

I count your nice declaration as one, for example, since it
communicates more about you than about me.

== 7 of 7 ==
Date: Sun, Mar 7 2010 5:06 pm
From: Seebs

On 2010-03-07, Rainer Weikusat <rweikusat@mssgmbh.com> wrote:
> Seebs <usenet-nospam@seebs.net> writes:
>> On 2010-03-07, Rainer Weikusat <rweikusat@mssgmbh.com> wrote:
>>> Don't try to play 'stupid' with me. You understood me quite well, have
>>> 'surprisingly' completely ignored my text in order to construct a
>>> straw man

>> Have you found a set of circumstances in which declaring that you know what
>> other people think, and they are lying, has ever produced any kind of positive
>> or desireable outcome?

> I count your nice declaration as one, for example, since it
> communicates more about you than about me.

That's non-responsive.

You asserted that someone else understood what you meant, but you have done
nothing to show that this is true; instead, you just accused someone of
lying, without any evidence, and honestly, I don't see why you would expect
that someone would have understood you "quite well" and then "played stupid",
when it seems much more likely that someone misunderstood you.

It's Usenet. People *constantly* misunderstand each other.

I have not in general found that it is productive or rewarding to accuse
people of lying on the basis that they claim to have misunderstood me, because
for the most part, it turns out to be much more common that they actually
misunderstood me. Similarly, out of the hundreds of times people have
asserted that I knew something perfectly well, it has been true perhaps once
or twice. Usually, what's at issue is that I don't agree with them and
they'd prefer to use a violent and derisive response than acknowledge the
possibility of a genuine disagreement.

==============================================================================
TOPIC: Has thought been given given to a cleaned up C? Possibly called C+.
http://groups.google.com/group/comp.lang.c/t/5954dc70a43f9f8e?hl=en
==============================================================================

== 1 of 4 ==
Date: Sun, Mar 7 2010 2:13 pm
From: Ian Collins

jacob navia wrote:
>
> C is still being used, and many important projects are based on it. My
> thesis is that a simple language is necessary and useful. Adding
> a general and extensible container interface for C doesn't change at all
> the language but gives C programmer the advantages of not having to
> program the same data structures over and over.
>
> The proliferation of libraries that do the same thing WITHOUT a standard
> in C means that each big project in C has several versions of the same
> data structure because library XYZ uses lists with the "Next" field
> in the fiorst position and library"XXX" uses a list with Next in the
> second position. Besides all APIs are different, etc.

One interesting question is why, after over 30 years of use, there
hasn't appeared a widely accepted a general and extensible container
interface for C?

The C++ STL appeared fairly early on in that language's evolution and
was rapidly and widely accepted by C++ developers. The widespread use
resulted in it being incorporated into the standard library in first
language standard.

Why hasn't the same thing happened with C?

--
Ian Collins
--
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 4 ==
Date: Sun, Mar 7 2010 2:14 pm
From: Thomas Richter

jacob navia wrote:
> Thomas Richter a �crit :
>> jacob navia wrote:
>>> o The library is an unchanged copy of the C library of 1980. Using
>>> the same software today after 30 years of development (and what a
>>> development) in this field is plain nonsense.
>>
>> Given the amount of existing code that builds on the existing C
>> library, replacing it is actually plain nonsense.
>>
>
> Nobody is proposing that. This is an old trick in this discussions. Any
> improvement to C is impossible because the old code. That is plainly not
> true. The old code and the associated functions can be kept, but C
> should be able to use BUFFERS of KNOWN length, avoiding the most common
> cause of buffer overflows. Let's be explicit:
>
> typedef struct {size_t length; char data[];} Buffer;
>
> memset can be done as "Memset", for instance like this
> bool Memset(Buffer *dest, int char_val);

memset already takes a byte count argument, why do I need another
function? In fact, memset is as safe as it gets.

> This is an easy example. Strcpy is just as trivial, but with a character
> buffer.

There is already a secure version of strcpy, see below.

>> I don't think they're wrong. They require care, care some people forgot.
>
> This has been discussed and discussed, and the essential point is that
> if somebody makes a mistaken once, it is his/her fault. Ifvthousands of
> programmers make always the same errors it is the tool's fault.

Then C is not the right tool for the job. As said below, there are other
languages that can help. If you want to use C, there are also secured
functions with buffer sizes that help. But even they won't prevent you
from shooting yourself into the foot. C has no means to prevent bad
pointers being dereferences, to give another example. If you want a
child-proof C, use Java - it does have all the features you seem to
miss. (And no, I've absolutely nothing against Java, no irony here.)

> I am sure you can be proved wrong too.

Of course I make mistakes, who wouldn't? And your point is? Again, if
"avoiding errors" is your concern, use another tool and make other
errors. Just that languages like java or C++ are neither the right tool
for *some* jobs.

>> As for example checking for the proper buffer size. A "strcpy" can be
>> absolutely correct if you have control on the size of the input
>> string, and it can be completely fatal if not.
>
> Exactly. A better version would use COUNTED buffers!

There is a version, so use it. I don't understand your complaint. If I
use strcpy, then under controlled conditions where I do have control on
the input and the output buffer, as in allocating the output buffer from
the size of the input.

The problem is not strcpy, the problem is that C "string handling" is
considerably broken - for security aspects, but also for all kind of
string handling. It is just too low level. I don't have a problem with
that - if I do need to do massive string handling, I use other languages.

>> If you want to avoid the hassle, go for C++, or use the limiting
>> functions.
>
> Here we have it again. Any development of C is always answered with
> "Go to C++" even by committee members. C should remain full of warts
> so that C++ can be seen as the only alternative. There should be NO
> simpler language than C++, all development of C as a language should
> STOP.

If you want ultimate security, *DO NOT USE C*. It is not the language
for that job. It is a low-level language. Buffer overruns are just *one*
of the problems of C. Pointers are another. Should we ban pointers from
C just because they can be used for dangerous tasks?

> You are confirming what I say about committee members.

You don't understand the most basic rule: Use the right tool for the job.

>> Why should there? C is a very small language, and I really don't see
>> the need for such simple data structures in the standard.
>
> Then, each C programmer needs to port a library that does lists,
> flexible arrays, or find and debug one and port it, etc.

No, the programmer would rather need to look for a better tool for the
job. Writing pograms in C just to use C is a bad idea. Use a language
that offers such functionalities if you need them. Or use readily
available libraries if you want to - I'm sure you'd find plenty.

>> If you need library support for that, and a richer structure that
>> helps you with such containers, use C++ and the STL.
>
> OF COURSE that is the solution.

Then where is the damn problem?

> Yu are (again) confirming what I said:
> All development in C should stop and we should swallow C++ if we want to
> do the simplest tasks!

And why is that a problem?

> If we want to use (portably) a list, we are forced to use C++ and
> their STL...

Or any other language that offers that. Java, python, ....

I still don't see the problem.

> C is still being used, and many important projects are based on it. My
> thesis is that a simple language is necessary and useful.

Then keep it simple. If writing a list or a tree is not simple for you,
you are in the wrong field for applying C for that task. Or look for a
library that helps you. C is a small language; why whould that stuff be
required in the language core - it would often not fit into the
application because C doesn't have all the mechanisms of higher
languages to hide the implementation behind the design.

> This is SO OBVIOUS that doesn't even need to be discussed. But C should
> be kept in its present state so taht the only alternative is to swallow
> C++

It's obvious that you want to use C just for the means of it. Get over
it, C is not the "saves all my problems" language. It is good in some
cases, and bad in others. String manipulation and generic container
support are not the strong parts of C, so why force it? If you want to
make C another language, I again ask why. There *are* already other
languages in first place you can use.

Greetings,
Thomas
--
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.

== 3 of 4 ==
Date: Sun, Mar 7 2010 4:03 pm
From: jacob navia

Thomas Richter a écrit :
> Then C is not the right tool for the job. As said below, there are other
> languages that can help.

[snip]

> Again, if
> "avoiding errors" is your concern, use another tool and make other
> errors.

[snip]

> The problem is not strcpy, the problem is that C "string handling" is
> considerably broken - for security aspects, but also for all kind of
> string handling. It is just too low level. I don't have a problem with
> that - if I do need to do massive string handling, I use other languages.
>
[snip]
>
> If you want ultimate security, *DO NOT USE C*. It is not the language
> for that job. such simple data structures in the standard.
>>
>> Then, each C programmer needs to port a library that does lists,
>> flexible arrays, or find and debug one and port it, etc.
>
> No, the programmer would rather need to look for a better tool for the
> job. Writing pograms in C just to use C is a bad idea. Use a language
> that offers such functionalities if you need them.

>>> If you need library support for that, and a richer structure that
>>> helps you with such containers, use C++ and the STL.
>>
>> OF COURSE that is the solution.
>
> Then where is the damn problem?
>
>> Yu are (again) confirming what I said:
>> All development in C should stop and we should swallow C++ if we want to
>> do the simplest tasks!
>
> And why is that a problem?
>

[snip]

>
> I still don't see the problem.
>
>
>> This is SO OBVIOUS that doesn't even need to be discussed. But C should
>> be kept in its present state so taht the only alternative is to swallow
>> C++
>
> It's obvious that you want to use C just for the means of it. Get over
> it, C is not the "saves all my problems" language. It is good in some
> cases, and bad in others. String manipulation and generic container
> support are not the strong parts of C, so why force it? If you want to
> make C another language, I again ask why. There *are* already other
> languages in first place you can use.
>

There is no point in discussing with you

Let's agree that we disagree, and go on using your pet language,
whatever that is.

My opinion is that C should be developed further, exactly BECAUSE is
a simple language. Adding a container library to C doesn't make the
language any bigger or more complicated but makes programs COMPATIBLE
because it is possible to interchange data with standard API/containers.

There is no way in C to return a list of the files in a directory. Nor
there is a standard way to return a flexible array, or similar
containers.

I have been developing a library like that, that is extensible and
patterned after the STL.The only difference is that is way faster and
smaller than the STL. I see that the C++ people will start crying that
that is an heresy of course.

You (and the other C++ avocates here) seem to believe that complexity is
better in sofwtare construction. My thesisis the opposite. I believe
that a simple language is better than a completely bloated like C++.
--
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.

== 4 of 4 ==
Date: Sun, Mar 7 2010 4:04 pm
From: jacob navia

Ian Collins a écrit :
> jacob navia wrote:
>
> One interesting question is why, after over 30 years of use, there
> hasn't appeared a widely accepted a general and extensible container
> interface for C?
>
> The C++ STL appeared fairly early on in that language's evolution and
> was rapidly and widely accepted by C++ developers. The widespread use
> resulted in it being incorporated into the standard library in first
> language standard.
>
> Why hasn't the same thing happened with C?
>

Because the C standards committee has always decided NOT to add such
an improvement to the language. The C++ standard committee decided that
such an improvement WAS NECESSARY, and they develop one.

I have written most of the STL clone (AVL trees, RB trees, bitstrings,
flexible arrays, lists (double/single linked) and the whole library
is extremely fast and compact. It is just less than 100K when you use
all of it. If you use just the lists module it is less than 5K.

But apparently all this work is a waste of time. The committee decided
a feature freeze already, and I will not be ready to present this to
the next meeting in April.
--
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: A Minor Problem With atoi() And Negative Numbers
http://groups.google.com/group/comp.lang.c/t/5218f6623a71b4c1?hl=en
==============================================================================

== 1 of 2 ==
Date: Sun, Mar 7 2010 3:46 pm
From: Marcelo De Brito

Hi!

I have implemented a simple program to convert temperatures from
Celsius to Fahrenheit and vice-versa, printing them on a simple table.

The max temperature (that is, the maximum value until which the table
must be printed) is passed through command line to the program:

./temp_convert 100

This command tells the program to print a table of temperatures until
the max value 100 is reached.

When passing negative values, such as:

./temp_convert -100

The program does not work at all.

For getting the value through command line, I used the "atoi()"
function in this way:

max_temp = atoi(argv[1]);

Does this problem have something to do with the "atoi()" function?

I appreciate your comments and suggestions.

Best Regards!

Marcelo

== 2 of 2 ==
Date: Sun, Mar 7 2010 3:57 pm
From: Ian Collins

Marcelo De Brito wrote:
> Hi!
>
> I have implemented a simple program to convert temperatures from
> Celsius to Fahrenheit and vice-versa, printing them on a simple table.
>
> The max temperature (that is, the maximum value until which the table
> must be printed) is passed through command line to the program:
>
> ../temp_convert 100
>
> This command tells the program to print a table of temperatures until
> the max value 100 is reached.
>
> When passing negative values, such as:
>
> ../temp_convert -100
>
> The program does not work at all.
>
> For getting the value through command line, I used the "atoi()"
> function in this way:
>
> max_temp = atoi(argv[1]);
>
> Does this problem have something to do with the "atoi()" function?

You should post a working example - atoi will work fine with negative
numbers. What type is max_temp?

You should look at using strtol rather than atoi, the latter doesn't
give you any indication of failure.

--
Ian Collins

==============================================================================
TOPIC: problem 1.13 The C programming language
http://groups.google.com/group/comp.lang.c/t/e3b5a2688181479c?hl=en
==============================================================================

== 1 of 1 ==
Date: Sun, Mar 7 2010 4:09 pm
From: Flash Gordon

joag wrote:
> I'll try the next week to update the program with your suggestions, I
> also added a topic on my page www.nixheiser.org (guides - problem 1.13
> section) so other people can reach the same topic and comment about it
> there because there is a little forum for comments;

You will find a number of solutions to various of the exercises at
http://clc-wiki.net/
Obviously do each exercise yourself before looking at other peoples
solutions.

> in the rest of the
> month I'll try to do what follows in the book (The C programming
> language by K&R). I've been told by other people to start with this
> book and I never did this and now I see why people recommend it, it is
> great ^n book.

It is a good book.
--
Flash Gordon

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

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

twitter

Sunday, March 7, 2010

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

0 Comments:

Post a Comment

About Me

Previous Posts