twitter: comp.lang.c - 16 new messages in 5 topics

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

comp.lang.c@googlegroups.com

Today's topics:

* Warning to newbies - 5 messages, 3 authors
http://groups.google.com/group/comp.lang.c/t/9597fd702985dff4?hl=en
* free c text book advice.. - 1 messages, 1 author
http://groups.google.com/group/comp.lang.c/t/adf51d19d9b07faf?hl=en
* calling a singly-linked list - 6 messages, 5 authors
http://groups.google.com/group/comp.lang.c/t/163ef25eec8f0a79?hl=en
* A bit resistant to disruption - 2 messages, 2 authors
http://groups.google.com/group/comp.lang.c/t/a5ddb7c1aa07c7e5?hl=en
* Missing braces around {0} initializer?! - 2 messages, 1 author
http://groups.google.com/group/comp.lang.c/t/4e761f5803fec708?hl=en

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

== 1 of 5 ==
Date: Mon, Feb 8 2010 9:43 pm
From: spinoza1111

On Feb 9, 11:21 am, spinoza1111 <spinoza1...@yahoo.com> wrote:
> On Feb 9, 4:32 am, Keith Thompson <ks...@mib.org> wrote:

Keith: there is absolutely no comparision between myself and other
noble and fine spirits here such as Kenny and Navia, and creeps like
Seebach.

There is a certain sort of Creep
Who creeps, along the Way
As the shadows gather
At the end of day.

His Traffic is in lies
Rumor, and surmise
His purpose, to give Pain
The light, he does disdain.

Hellish hurt he tries to give
But he does not Succeed
The Knight who has a mission
To daemon pays no heed.

== 2 of 5 ==
Date: Mon, Feb 8 2010 11:47 pm
From: Richard Heathfield

spinoza1111 wrote:

<Seebs's parody code snipped>
>
> You've written this code and presented it as mine. This is egregious
> dishonesty and highly unprofessional.

It's called "parody", and is perfectly legal (except in North Dakota
during the summer months). As parody, it excels, since you think he's
presenting the code as if you'd written it, whereas in fact all he's
really doing is caricaturing your style. There is nothing dishonest or
unprofessional about parody.

> In my experience, incompetent
> programmers turn to lies and mockery when their incompetence is
> exposed.

You have demonstrated this on a number of occasions. Nevertheless, it
does not necessarily follow that all mockery comes from incompetent people.

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

== 3 of 5 ==
Date: Mon, Feb 8 2010 11:50 pm
From: Richard Heathfield

spinoza1111 wrote:
> On Feb 9, 4:32 am, Keith Thompson <ks...@mib.org> wrote:
>> Squeamizh <sque...@hotmail.com> writes:
>>
>> [...]
>>
>>> I don't know what's more funny- Spinoza's inability to get this simple
>>> problem right, or Seebs' continued childish insistence that he only
>
> As I said, I posted the code for COLLABORATIVE development and
> testing,

If that's true, why did you make it so hard to read? Or, if you think it
*should* be hard to read, why didn't you make it harder to read?

> and I received professional assistance from Santosh and Ike
> Naar, which helped me to complete the project.

If that's a complete project, I'm a Dutchman.

> That is what this ng was meant for: not for posting "satiric" code as
> mine in an actionably libelous lie.
>
> Santosh and Ike Naar found problems which I fixed in a few hours on
> Sunday.

And I found a problem that took you several hours to fix all by itself.
Deleting a single line can be terribly, terribly, difficult, can't it?

> Heathfield and Seebie have demonstrated that they are disruptive
> creeps.
>
> Don't you DARE compare me to them!

That's up to him, but I can't say I'm overly excited by the idea of
being in the same comparison as you, and I don't suppose Seebs is either.

<snip>

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

== 4 of 5 ==
Date: Mon, Feb 8 2010 11:55 pm
From: Seebs

On 2010-02-09, Richard Heathfield <rjh@see.sig.invalid> wrote:
> spinoza1111 wrote:
><Seebs's parody code snipped>
>
>> You've written this code and presented it as mine. This is egregious
>> dishonesty and highly unprofessional.

> It's called "parody", and is perfectly legal (except in North Dakota
> during the summer months). As parody, it excels, since you think he's
> presenting the code as if you'd written it, whereas in fact all he's
> really doing is caricaturing your style. There is nothing dishonest or
> unprofessional about parody.

Allow me to quote my post to clarify:

>>>I just hope he never realizes that his implementation of a string length
>>>counter is not particularly overth^H^H^H^H^Hrobustly engineered. If he
>>>does, we'll get something like this:

(line breaks altered from the original).

Note: "something like this" is clearly intended to demonstrate that I am
talking about the *style* or *manner* of the Nilges code we've seen, such
as a hundred lines of extraordinarily bad code trying to solve a problem
that could easily be solved in about fifteen lines of code... and it
didn't even work after three or four edits to fix bugs introduced by
an overly baroque style.

I do not have any worries about people mistaking my parody code for
actual Nilges code, nor did I present it as such. For one thing, I
didn't use the sort of bastardized and botched systems Hungarian Nilges
uses. I can do a lot for art, but there are limits. For another thing,
I did manage in a few places to go beyond the level of insanity we
normally see in his code. For instance, <malloc.h> is silly, but
<emmintrin.h> is ridiculous. (It's, so far as I can tell, a gcc internal).

I also cleaned it up some by using ~0 rather than -1 as "true" -- I figure
if you're going to ask for all-bits-one, you might as well do it explicitly.

In short, to some extent, it's not a very good caricature; I didn't really
pick up some of the most odious stuff, but I think I did a reasonable job
of capturing the essence of over-engineering informed by mind-numbing
ignorance, coupled with random and misdirected vitriol and name dropping.

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

== 5 of 5 ==
Date: Mon, Feb 8 2010 11:57 pm
From: Seebs

On 2010-02-09, Richard Heathfield <rjh@see.sig.invalid> wrote:
> If that's true, why did you make it so hard to read? Or, if you think it
> *should* be hard to read, why didn't you make it harder to read?

This one's complicated. He's clearly doing some things badly purely out
of spite. However, I suspect he genuinely believes that the elaborate
naming conventions are helpful, even though this one looks like an over
the top parody.

>> Santosh and Ike Naar found problems which I fixed in a few hours on
>> Sunday.

> And I found a problem that took you several hours to fix all by itself.
> Deleting a single line can be terribly, terribly, difficult, can't it?

More importantly, why on earth would it take "a few hours" to fix something
this simple? One person found a problem with mine, which I fixed in, oh,
call it five or ten minutes -- that's including developing a more elaborate
version, then concluding that it was stupid and giving up on it.

> That's up to him, but I can't say I'm overly excited by the idea of
> being in the same comparison as you, and I don't suppose Seebs is either.

I think I would mostly just find it surreal. It's like trying to compare
someone to a cat; there's not enough commonality to make the comparison
informative in any meaningful way. ("Well, you're heavier than the cat,
but you do complete more crosswords, so I guess it's a tie.")

==============================================================================
TOPIC: free c text book advice..
http://groups.google.com/group/comp.lang.c/t/adf51d19d9b07faf?hl=en
==============================================================================

== 1 of 1 ==
Date: Mon, Feb 8 2010 10:21 pm
From: Richard Heathfield

Dag-Erling Smørgrav wrote:
> Richard Heathfield <rjh@see.sig.invalid> writes:
>> Dag-Erling Smørgrav <des@des.no> writes:
>>> Richard Heathfield <rjh@see.sig.invalid> writes:
>>>> Sometimes you just gotta. If your spec requires you to implement a
>>>> feature that cannot be achieved using only standard C89, then
>>>> obviously you have to go outside standard C89 in order to
>>>> implement that spec.
>>> Are you saying C89 is not Turing-complete?
>> Not at all. For example, the lack of sockets support in C89 does not
>> mean C89 is Turing-incomplete, does it? But if you need sockets, C89
>> on its own won't do. (Neither will C99, in this case, but never mind
>> that.)
>
> I believe the question was whether C99 had added features one couldn't
> do without - or at least, that's how I interpreted it.

Actually, so did I, but I couldn't think of any examples of that.

> I don't think it has.

Neither do I. Nevertheless, I don't insist that everybody sees things my
way. (It's nice when people return the compliment.)

> The matter of additional libraries is IMHO orthogonal to this
> discussion. There's very little you can do without going outside the
> standard library, no matter what version of the standard your compiler
> implements.

Well, perhaps we can agree to disagree on that.

--
Richard Heathfield <http://www.cpax.org.uk>
Email: -http://www. +rjh@
"Usenet is a strange place" - dmr 29 July 1999
Sig line vacant - apply within
--
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: calling a singly-linked list
http://groups.google.com/group/comp.lang.c/t/163ef25eec8f0a79?hl=en
==============================================================================

== 1 of 6 ==
Date: Mon, Feb 8 2010 10:33 pm
From: Phred Phungus

Alan Curry wrote:
> In article <7ta771FfioU1@mid.individual.net>,
> Phred Phungus <Phred@example.invalid> wrote:
> |#include <stdio.h>
> |#include <stdlib.h>
> |
> |struct list {
> | struct list *next;
> | int n;
> |};
> |
> |static int *read_numbers(struct list *list)
> [...]
>
> This code, which I posted in another thread, should not be used. It was a
> response to a "challenge" and should be considered mainly as a joke. It does
> technically do everything the challenge requested, while being useless for
> any practical purpose.
>
> In the very same article in which I posted it, I listed 3 reasons why the
> challenge (i.e. make a growable list/array-ish data structure without
> realloc) was stupid. And I also explained the particular shortcoming of my
> code which I was too lazy to fix: it provides no way for the caller to know
> how big the list is.

You mentioned passing a counter to a recursive function.

I didn't see a better posting than yours, and now it's Feb. 9 east of
Chicago.
>
> Yet somehow you missed all of that, and decided to hold on to that code and
> treat it as if it was worthy of further study, and start a new thread
> dedicated to analyzing it. Woosh!
>

I'm having trouble hooking up data structures with a platform and
extensions that are somewhat new to me. So I look for simpler toy
programs that do something similar.

It's not hard to mistake differing forms of lists. I was hoping to do
something with this from Unleashed:

//c11_022.c - naive single linked list, using an array.
#include <stdio.h>

typedef struct ITEM
{
char Title[30];
char Author[30];
int Next;
} ITEM;

int main(void)
{
ITEM List[] =
{
{"UNIX Unleashed", "Burk and Horvath", 2},
{"Algorithms in C", "Sedgewick", 9},
{"Builder Unleashed", "Calvert", 10},
{"C++ Unleashed", "Liberty", 12},
{"Linux Unleashed", "Husain and Parker", 8},
{"Teach Yourself BCB", "Reisdorph", 1},
{"Data Structures & Algorithms", "Lafore", 3},
{"DOS Programmers Reference", "Dettmann & Johnson", 11},
{"C Programming Language", "Kernighan & Ritchie", 6},
{"C++ Programming Language", "Stroustrup", 13},
{"C: How to Program", "Deitel & Deitel", 7},
{"C : A Reference Manual", "Harbison & Steele", 15},
{"The Standard C Library", "Plauger", 5},
{"C Programming FAQs", "Summit", 14},
{"Expert C Programming", "van der Linden", -1},
{"C Unleashed", "Heathfield & Kirby", 4}
};

int Current = 0;

while(Current != -1)
{
printf("Read %s, by %s.\n",
List[Current].Title,
List[Current].Author);
Current = List[Current].Next;
}

return 0;
}

// gcc -D_GNU_SOURCE -Wall -Wextra ll1.c -o out

I think the classification for what is a singly-linked list must be
fairly broad. In this, there aren't new nodes created dynamically.
--
fred

== 2 of 6 ==
Date: Mon, Feb 8 2010 10:51 pm
From: frank

bartc wrote:
> "Phred Phungus" <Phred@example.invalid> wrote in message

>> , am I correct to think that the list is visible to entire program?
>> My question is how main would correctly output what I input.
>
> read_numbers() returns a pointer to an array of ints, which is stored in
> numbers. At this point it's only visible to main().
>
> This example tries to print the results:
[code elided]
>
> But it doesn't quite work; I don't know what read_numbers does exactly:
> it seems to read one integer per line, following by 0 on a line by
> itself (and does this recursively, into an internal linked-list). Then
> returns an array of the numbers, however without a terminator, so main()
> doesn't know how many numbers there are.
>

Thanks bart, it's starting to look like something:

dan@dan-desktop:~/source/unleashed/ch11$ gcc -D_GNU_SOURCE -Wall
-Wextra ac2.c -o out
dan@dan-desktop:~/source/unleashed/ch11$ ./out
3
6
18
0
3
6
18
135153
dan@dan-desktop:~/source/unleashed/ch11$ cat ac2.c
#include <stdio.h>
#include <stdlib.h>

struct list {
struct list *next;
int n;
};

static int *read_numbers(struct list *list)
{
char buf[100];
int val, i, *ret;
struct list node, *p;
if(fgets(buf, sizeof buf, stdin)) {
if(sscanf(buf, "%d", &val)!=1) {
fprintf(stderr, "That's not a number\n");
exit(EXIT_FAILURE);
}
if(val!=0) {
node.n = val;
node.next = list;
return read_numbers(&node);
}
} else {
if(ferror(stdin)) {
perror("standard input");
exit(EXIT_FAILURE);
}
/* Naughty user sent EOF; pretend it was a 0 but with a warning */
fprintf(stderr, "Didn't get 0 terminator. List may be incomplete\n");
}

for(i=0,p=list;p;++i,p=p->next)
/*nothing*/;
ret = malloc(i * sizeof *ret);
if(!ret) {
perror("malloc");
exit(EXIT_FAILURE);
}
for(--i,p=list;p;--i,p=p->next)
ret[i] = p->n;
return ret;
}

int main(void)
{
int *numbers,*p;
numbers = read_numbers(0);
/* do stuff with numbers[] I guess */
p=numbers;
while (*p) printf("%d\n",*p++);
return 0;
}

// gcc -D_GNU_SOURCE -Wall -Wextra ac2.c -o out
dan@dan-desktop:~/source/unleashed/ch11$

Again with input as above, can we cheat in main somehow to determine how
many integers are in this array?
--
fred

== 3 of 6 ==
Date: Mon, Feb 8 2010 10:54 pm
From: Phred Phungus

Tom St Denis wrote:
> On Feb 8, 5:26 am, Phred Phungus <Ph...@example.invalid> wrote:
>> , am I correct to think that the list is visible to entire program? My
>> question is how main would correctly output what I input.
>
> There is no variable named "list" in the entire program. There is a
> struct named 'list' which is visible to the entire unit.
>
> Tom

So it doesn't go away until the entire program does, right?
--
fred

== 4 of 6 ==
Date: Mon, Feb 8 2010 11:47 pm
From: pacman@kosh.dhis.org (Alan Curry)

In article <7tcdtkF67uU1@mid.individual.net>,
Phred Phungus <Phred@example.invalid> wrote:
|Alan Curry wrote:
|>
|> In the very same article in which I posted it, I listed 3 reasons why the
|> challenge (i.e. make a growable list/array-ish data structure without
|> realloc) was stupid. And I also explained the particular shortcoming of my
|> code which I was too lazy to fix: it provides no way for the caller to know
|> how big the list is.
|
|You mentioned passing a counter to a recursive function.
|
|I didn't see a better posting than yours, and now it's Feb. 9 east of
|Chicago.

What part of everything I just said did you not understand?

Every program posted in that thread was awful, because the thread was
centered around a challenge to write a program around a ridiculous
restriction. The result is: the program comes out ugly.

Double woosh.

|
|I'm having trouble hooking up data structures with a platform and
|extensions that are somewhat new to me. So I look for simpler toy
|programs that do something similar.

This is not a toy. Just a bad program, written in response to a challenge
whose rules guaranteed that only bad programs would be submitted. Keep out of
reach of children. Do not taunt happy fun ball.

|
|It's not hard to mistake differing forms of lists. I was hoping to do
|something with this from Unleashed:

"Do something"?

|
|//c11_022.c - naive single linked list, using an array.
|#include <stdio.h>
|
|typedef struct ITEM
|{
| char Title[30];
| char Author[30];
| int Next;
|} ITEM;
|
|int main(void)
|{
| ITEM List[] =

This demonstrates something more useful: that an array plus an index is a lot
like a pointer, and if the array (base address) is implied (because all of
your structures live in one big array) then you can use integers as if they
were pointers, just by adding the base address when you need to dereference.

This one is the opposite of the "crazy recursion" program. It really is a
toy. You won't see statically-sized linked lists, initialized at compile
time, in grownup programs.

But the use of integers as pointers inside a cluster of objects with a common
base address isn't necessarily "naive". It's serialized! Ready to be
relocated with memcpy, or transferred to another process as a single hunk,
since the contents are not dependent on memory location.

--
Alan Curry

== 5 of 6 ==
Date: Mon, Feb 8 2010 11:57 pm
From: Richard Heathfield

Phred Phungus wrote:

<snip>

> I think the classification for what is a singly-linked list must be
> fairly broad. In this, there aren't new nodes created dynamically.

['this' is an illustration of the linked-list concept that uses an array
as the container]

Right. The concept of "linked list" depends purely on each item having a
link to some other item (or items) in the list so that a logical linear
progression exists. There's nothing in the rules that says the links
have to be pointers, or that the list has to be capable of arbitrary
expansion, or anything else. As far as the *concept* is concerned,
that's fluff. Highly important and significant fluff from a practical
point of view, but fluff nonetheless from the perspective of what
actually constitutes a linked list.

You have probably already noted that, in your source text, the author of
your example points out that the array implementation is "naive", and
shortly moves on to present pointer-based lists.

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

== 6 of 6 ==
Date: Tues, Feb 9 2010 12:06 am
From: Nick Keighley

On 9 Feb, 07:57, Richard Heathfield <r...@see.sig.invalid> wrote:
> Phred Phungus wrote:

> > I think the classification for what is a singly-linked list must be
> > fairly broad. In this, there aren't new nodes created dynamically.
>
> ['this' is an illustration of the linked-list concept that uses an array
> as the container]
>
> Right. The concept of "linked list" depends purely on each item having a
> link to some other item (or items) in the list so that a logical linear
> progression exists. There's nothing in the rules that says the links
> have to be pointers, or that the list has to be capable of arbitrary
> expansion, or anything else.

I learnt my data structures by "emulating" pointers with indexes into
large arrays. This was because the language used didn't have pointers.
In fact I wasn't even aware that this *was* a pointer emulation as I
didn't know about pointers either. I don't think it did me much harm
as far as learning about data structures and algorithms went.

> As far as the *concept* is concerned,
> that's fluff. Highly important and significant fluff from a practical
> point of view, but fluff nonetheless from the perspective of what
> actually constitutes a linked list.
>
> You have probably already noted that, in your source text, the author of
> your example points out that the array implementation is "naive", and
> shortly moves on to present pointer-based lists.

==============================================================================
TOPIC: A bit resistant to disruption
http://groups.google.com/group/comp.lang.c/t/a5ddb7c1aa07c7e5?hl=en
==============================================================================

== 1 of 2 ==
Date: Mon, Feb 8 2010 11:15 pm
From: Francois Grieu

Moi wrote :
> On Mon, 08 Feb 2010 07:26:45 +0100, Francois Grieu wrote:
>
>> Moi wrote :
>>
>>>> Can it be done? If yes, what is the minimum number of cells needed?
>>>> Give a proof.
>>> First shot: two hits in my cerebral hash-table 1) alternating
>>> bit-protocol (difficult with only one bit at a time ...)
>> Nice. However in the present problem there are no errors, only those
>> pesky disruptions.
>>
>>> 2) Leslie Lamport's reading <--> writing in opposite directions.
>> When I wrote "hard problem", I did not mean quite that hard...
>
> I think that your failed eeprom_reset_bit() and eeprom_set_bit()
> operations are more or less equivalent to Lamport's "sending messages to another process".
> Messages can be lost in transit, your eeprom-operations can fail
> because of a crash.
> The only difference is that in the eeprom-case there is a sort of tri-state
> logic; in the case of lost messages the domain stays restricted
> to just two cases.

Yes I see your point. One redeeming difference is that things are
strictly sequential / singe-process in my case.

> If I understood the problem correct:
> 1) the machine can be expected to crash *any moment*, so even while "in recovery mode"

Yes. Notice this is very real-world.

> 2) an undefined cell (either rewritten or partially cleared) produces a random
> value; subsequent reads may yield different values.

Yes, with one exception: if a cell/bottle was erased/empty, and you
erase/empty it again while a disruption occurs, it remains erased/empty.
The makers of EEPROM will reluctantly accept to give this insurance,
which is self-evident with bottles. There is no equivalent in the other
direction, for you can't program/fill a cell/bottle unless it is fully
erased/empty [or so insisted the makers of my EEPROM].

> My current approach uses a state machine with a kind of graycodes
> (maybe necklaces:http://www.theory.csc.uvic.ca/~cos/inf/neck/NecklaceInfo.html ; I am not
> sure yet how this should be named)
> The guiding idea is that in any state there is a maximal number of
> bits that could be undefined (tri-state): the bits that could have been affected
> by the previous or next state in the graph.
> While recovering this number is two, in "normal operation" it may perhaps be just one.
>
> My guess is I need three or four bits / bottles.
> ... still working on it ...

You are the first poster with a proposition that I won't contradict, and
are so far untouched by the "at least one public change of mind" curse!

> AvK

Francois Grieu

== 2 of 2 ==
Date: Mon, Feb 8 2010 11:42 pm
From: Seebs

On 2010-02-09, Francois Grieu <fgrieu@gmail.com> wrote:
> You are the first poster with a proposition that I won't contradict, and
> are so far untouched by the "at least one public change of mind" curse!

The tricky part, so far as I can tell, is that we can't tell what a
partially-written bit might look like. On the other hand, in theory,
only one write can be interrupted, as I understand it.

Hmm.

Okay, here's an approach. Imagine without loss of generality that our
goal is to toggle the bit in cell 0, and that we have additional bits to
toggle. The bit is "T".

Let's see. Okay, when toggle() is called, we'll start by clearing a working
area. So we have some unspecified number of bits which is our working area,
call them W[0] ... W[N].

The first thing we need to do is be sure that we can recover the previous
value in the event of a disruption. So, necessarily, we need a bit to hold
the known-previous-value. Let's call that W0. But how do we know whether
W0 holds a bit we care about? We need a flag for whether W0 has been written.
Let's call that W1. So, read() should do something like:
if (W1)
return W0
else
return T

What about toggle()? If W1 is set, then it was interrupted during an
operation. It should try to extract the value from W0 and push it back
into T. Once it has done that, it can clear W1 (because it no longer
needs to be able to remember the value in W0), then W0. That reduces us
to the default state, which is that T holds the current bit and we wish
to toggle it.

Given that, we then:
* Copy T into W0
* Set W1
* Erase T
* if T was previously 0, program T
* erase W1
* erase W0

The rationale of this ordering is that, at every time:
* if W1 is set, W0 holds the correct value of T
* if W1 is unset, T is known to be correct

If we are interrupted while setting W1, we were interrupted before we modified
T, so that's not a problem -- T is still at its correct old value. If we
are interrupted while setting W0, we were interrupted before we set W1, so
that's not a problem -- T is still at its correct old value. If we are
interrupted during any of the erasing or programming of T, that's not a
problem -- W0 and W1 are set, so we'll pick up the right value next time
we come in. If we are interrupted during the erase of W1, that's fine. If
it gets erased, it's clear and T has the right value. If it doesn't get
erased, it's still set, and W0 still holds the correct "previous value",
so we'll be in one of the trustworthy intermediate states.

So I think that's it.

So!

// Read a designated EEPROM cell; always returns 0 or 1.
extern int eRead(int j);
// Erase a designated EEPROM cell.
// After undisrupted eErase, eRead returns 0 until eProgram is invoked.
extern void eErase(int j);
// Program a designated *ERASED* EEPROM cell.
// After undisrupted eProgram, eRead returns 1 until eErase is invoked.
// Programming a cell that is not erased cause undefined behavior.
extern void eProgram(int j);

/* default state:
* bit 0 holds the current Durable Bit
* bit 1 is undefined
* bit 2 is clear
*
* during a toggle:
* bit 2 is set
* bit 1 holds the current Durable Bit
* bit 0 is undefined.
*
*/

int
bRead(void) {
if (eRead(2)) {
return eRead(1);
} else {
return eRead(0);
}
}

void
bToggle(void) {
int t;
if (eRead(2)) {
t = eRead(1);
eErase(0);
if (t)
eProgram(0);
eErase(2);
}
t = eRead(0);
eErase(1);
if (t)
eProgram(1);
eProgram(2);
eErase(0);
if (!t)
eProgram(0);
eErase(2);
}

I realized on consideration that I don't need to finish this with
eErase(1), because bit 1 is undefined. Thus, if eErase(2) completes
at the end of bToggle(), the toggle is complete and bit 0 holds the
newly toggled bit. If it doesn't complete, 1 still holds the right
value.

Note that there exists at least one case (previous value was zero, and
a disruption occurred) where 0 is erased twice without having been
programmed.

==============================================================================
TOPIC: Missing braces around {0} initializer?!
http://groups.google.com/group/comp.lang.c/t/4e761f5803fec708?hl=en
==============================================================================

== 1 of 2 ==
Date: Mon, Feb 8 2010 11:32 pm
From: Richard Heathfield

Tor Rustad wrote:
> Richard Heathfield wrote:
>> Tor Rustad wrote:
>>> I am puzzled by a warning, I get when using {0} as initializer.
>>
>> That warning has irritated me for *years*.
>>
>> I really wish gcc's warnings were independently configurable.
>
> Like e.g.
>
> -Wno-missing-braces
>
> ?

Well well well, there's a thing. :-)

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

== 2 of 2 ==
Date: Mon, Feb 8 2010 11:38 pm
From: Richard Heathfield

Ben Bacarisse wrote:
> Richard Heathfield <rjh@see.sig.invalid> writes:
>
>> Tor Rustad wrote:
>>> I am puzzled by a warning, I get when using {0} as initializer.
>> That warning has irritated me for *years*.
>>
>> I really wish gcc's warnings were independently configurable. (Perhaps
>> they are, but that's strictly a matter for a gcc group.)
>
> It's the word "strictly" that prompts me to post.
>
> You accept topicality drift within a thread -- into the merits of
> Norman Wisdom's slapstick for example -- but you seem to be suggesting
> that how one might configure gcc's warnings is beyond the pale.

No sir, I am suggesting that for me to launch an entire subthread by
seeking advice in this group on configuring gcc's warnings would be most
hypocritical indeed. By comparison, a one-line indulgence of someone
else's topic drift is of little consequence (or at least would have
been, had it not prompted this response).

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

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

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

Tuesday, February 9, 2010

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

0 Comments:

Post a Comment

About Me

Previous Posts