Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Newsgroups | comp.lang.c |
| Subject | Re: C programming in 2011 |
| Date | 2011-06-02 08:48 -0700 |
| Organization | None to speak of |
| Message-ID | <lnhb88kzdo.fsf@nuthaus.mib.org> (permalink) |
| References | (11 earlier) <9879610a-8794-4ed7-8553-5c37716fc662@b1g2000yql.googlegroups.com> <lnpqmyogp9.fsf@nuthaus.mib.org> <307fb2d6-7e7f-475d-ae7d-ef4a8a121639@d1g2000yqm.googlegroups.com> <lnsjrtmuie.fsf@nuthaus.mib.org> <34987001-82df-4e25-9173-e79d84b6e340@h7g2000yqa.googlegroups.com> |
"Kleuskes & Moos" <kleuske@xs4all.nl> writes:
> On Jun 1, 5:38 pm, Keith Thompson <ks...@mib.org> wrote:
>> "Kleuskes & Moos" <kleu...@xs4all.nl> writes:
>> > On May 31, 8:41 pm, Keith Thompson <ks...@mib.org> wrote:
[...]
>> >> How do you know what's involved in relative jump instructions on a
>> >> hypothetical system that might not even exist?
>>
>> > What other methods of doing relative jumps did you have in mind? Since
>> > you think there's an alternative, it's up to you to name it.
>>
>> I have no idea, and no, it's not up to me to name it. You've made an
>> assertion about how relative jump instructions work, presumably on *all*
>> systems.
>
> I have, since it's the only plausible way to implement them, simply
> because the simplest definition of a relative jump is
>
> PC <-- PC+offset
>
> and, frankly, i don't see any other way to implement one. But that may
> be just my lack of imagination, so if you do know of another method,
> then please.
> <snip>
Ok, a relative jump is basically
PC <-- PC+offset
Not that it's necessarily the case that a CPU must directly support
relative jumps, but that's beside the point. (And no, I'm not claiming
that there are CPUs that don't support relative jumps, or that there
aren't; it's just not particularly relevant to C.)
But nothing in that description implies unsigned arithmetic.
Presumably the offset is signed. Why can't the PC (program counter)
be signed?
(Asserting that it's unsigned does not answer the above question.)
>> > Ah. Another hypothetical system that defies the laws of common
>> > sense... Great, what advantages does your hypothetical system with
>> > signed memory addresses have? More importantly, how does that jive
>> > with the electronics of the address-bus of that hypothetical system?
>>
>> ("jibe")
>>
>> I wasn't aware that signed addresses defied the laws of common
>> sense. Perhaps they do. I do not claim that such systems have
>> any particular advantages, or even that they necessarily exist (I
>> honestly don't know whether they do or not), merely that they're
>> possible.
>
> As pointed out elsthread, signed or unsigned is in the eye of the
> beholder. Viewing them as unsigned is simply more convenient, having
> an address range [0...MemSize>.
Sometimes you argue that signed addresses defy the laws of common sense.
And sometimes you argue that addresses can be viewed as either signed or
unsigned, whichever is more convenient. I see a contradiction.
>> Now that I think about it, perhaps a virtual machine would be more
>> likely to have such characteristics, especially if it's implemented
>> in a language that doesn't support unsigned arithmetic (Pascal,
>> for example).
>
> Implementing a virtual machine in Pascal? Sure it's possible, pascal
> is turing-complete, after all.
>
>> I have some documentation on the old UCSD Pascal system;
>> I'll look into it later.
>
> I'd be interested, but i was talking about _real_ processors. Virtual
> ones have quite a different set of constraints and design
> considerations.
Virtual processors are just as valid a target for a C implementation as
real ones.
>> > Objections concerning some hypothetical system which uses signed
>> > integers as memory addresses and do not support nsigned integers are
>> > not quite taken seriously on my side of the NNTP-server. Why not
>> > invent a hypothetical system which uses pink bunnies to address
>> > memory?
>>
>> Why not? There's no particular reason such a system coulnd't
>> support a conforming C implementation.
>
> True, but the chances of one actually getting a) designed b)
> implemented and c) bought and used are approaching 0 with a
> frightening speed and such systems do not interest me.
You spend a great deal of time arguing about something that doesn't
interest you.
> <snip>
>
>> > Yes. And the chip-select signal might be delivered by invisible pink
>> > unicorns, the Carry Flag might be hoisted by Daffy Duck and interrupts
>> > might be implemented by Yosemity Sam, firing his guns at the hootenest-
>> > tootenest-shootenest programmable interrupt controller north, east,
>> > south AAAAND west of the Pecos.
>>
>> And you find these as plausible as UINT_MAX==INT_MAX?
>
> Slightly less plausible. I'm surprized at having to explain such an
> obvious rethorical remark.
>
>> > To me, the flurry of hypotheticals merely indicates that i was right,
>> > but you don't like admitting it, so you're grasping at hypothetical
>> > straws.
>>
>> You were right about what, exactly?
>
> UINT_MAX == INTE_MAX is only valid in hypothetical cases, as i've
> already explained several times.
As you've already *asserted* several times.
[...]
>> But this is comp.lang.c, not comp.arch, and the main point I've been
>> making is that such systems are permitted by the C standard. (I'm
>> reasonably sure I'm right about that; if you agree, that doens't mean
>> you're admitting defeat.)
>
> The C standard, by it's very nature, is stated as generally as
> possible, and, as i've stated upthread, the standard allows for a lot
> of implausible implementations including ones in which the condition
> in question is true, simply to give compiler-makers enough leeway to
> cater to even the most obscure hardware. That's a good thing.
>
> That does not mean that every possibility allowed by the standard
> should be taken into consideration, especially those that, by their
> very nature, are _very_ implausible.
The C standard is stated very generally, but *not* "as generally as
possible". There are plenty of characteristics, some of them things
that have existed in real-world systems, that are excluded (some of
which can be worked around in software). Some examples: Bytes must
be at least 8 bits. Type int must be at least 16 bits. Data must
be represented in binary. Signed integers must be represented in
either 2's-complement, 1s'-complement, or sign-and-magnitude (biased
representations are not permitted). Floating-point is mandatory.
Most of the flexibility is there either because there have been
real-world systems that need it, or because a greater range of
permitted characteristics is simpler to describe. It's fairly
safe to assume that there are no systems with 137-bit bytes, but
the standard doesn't go out of its way to forbid it.
> Even if it's allowed by the standard, i would not expect any system to
> launch the complete nuclear arsenal of the western world every time
> someone invokes undefined behavior, nor do i take that into account
> when designing software.
Not if the hardware doesn't actually interact with the nuclear
arsenal. But some systems do exactly that, and if they're
implemented in C (which, personally, I hope they're not) they had
bloody well better avoid anything approaching undefined behavior.
Perhaps more realistically, you might assume that a C program with
undefined behavior can't possibly reformat your hard drive -- but
if the process it's running in has the capability of invoking the
"please reformat my hard drive" routine, and a function pointer
somewhere gets clobbered, it could very well do that.
[...]
>> > Besides, a pattern of bits on the address bus, and this would be the
>> > best objection you can make, can be interpreted as signed _or_
>> > unsigned at the whim of whomsoever is interpreting it. It really makes
>> > no difference, it's just a question of how you interpret them.
>>
>> But ok, let's say we have a system with a 16-bit address space,
>> with addresses ranging from 0 to 65535, and with each byte in that
>> range being addressible. What happens if you start with a pointer
>> to memory location 65535, and then increment it?
>
> I'm sure you can figure that one out for yourself.
That wasn't the point of the question.
>> Unless there's hardware checking, the result will probably point to
>> address 0.
>> Or, equivalently, we started with address -1 and incremented it to
>> address 0.
>
> That seems plausible. What's the point?
The point, which you've acknowledged, is that it can be perfectly
reasonable to think of memory addresses as signed integers.
Which means that you can't reasonably use memory addresses as an
argument that all systems *must* support unsigned arithmetic.
>> > But, given the practicalities of hardware design, they are usually
>> > interpreted as being unsigned, simply because it's more convenient.
>>
>> If address arithmetic doesn't check for overflow or wraparound, it may
>> be *conceptually* more convenient to think of addresses as unsigned, but
>> the hardware doesn't necessarily care.
>
> That was the point i made above.
That's one of the two contradictory points you made. The other point
you made is that the "practicalities of hardware design" imply somehow
that addresses are necessarly unsigned.
> <snip>
>
>> > How does a CPU add 1 and 1 and arrive at the (correct) answer: 2?
>>
>> Magic. 8-)} Seriously, I'm not much of a hardware guy, but we can
>> agree that CPUs can add.
>>
>> > How do signed and unsigned versions of this operation differ?
>>
>> Depends on the system. On some systems, there might be a hardware trap
>> on overflow; the conditions in which that trap will be triggered might
>> differ for signed and unsigned add instructions. Maybe. And no, I
>> don't have concrete examples.
>
> On 2's complement systems, they do not differ. As explained
> elsethread, that's one of the main reasons 2's-complement is the de-
> facto standard nowadays.
And as I explained, *if the system traps on signed overflow*,
there is a very real difference between signed and unsigned addition.
>> > The question "why doesn't anyone design a computer that does not
>> > support unsigned arithmatic" should be obvious, if you got the above
>> > two questions right, and hypothetical, highly unpractical systems
>> > should then be laid to rest.
>>
>> >> The point is that C is designed to be implementable with reasonable
>> >> efficiency on a wide variety of systems.
>>
>> > True. But i doubt you'll find ANY that match the exotic, nay,
>> > excentric hardware you describe. I still dare yoou to name a single
>> > CPU that does not support unsigned integers, and i'm very confident
>> > you won't find any.
>>
>> Again, I've never claimed that such a CPU exists.
>
> Non-existent CPU's are also non-interesting.
Again, you've spent a great deal of time discussing something that you
find non-interesting. Are you trying to convince me that I shouldn't be
interested in them either?
--
Keith Thompson (The_Other_Keith) kst-u@mib.org <http://www.ghoti.net/~kst>
Nokia
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"
Back to comp.lang.c | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll thread
C programming in 2011 Duncan Bayne <dhgbayne@gmail.com> - 2011-05-25 20:27 -0700
Re: C programming in 2011 Shao Miller <sha0.miller@gmail.com> - 2011-05-25 22:33 -0500
Re: C programming in 2011 Duncan Bayne <dhgbayne@gmail.com> - 2011-05-25 20:58 -0700
Re: C programming in 2011 Duncan Bayne <dhgbayne@gmail.com> - 2011-05-25 21:06 -0700
Re: C programming in 2011 Shao Miller <sha0.miller@gmail.com> - 2011-05-25 23:24 -0500
Re: C programming in 2011 Angel <angel+news@spamcop.net> - 2011-05-26 07:51 +0000
Re: C programming in 2011 Chris H <chris@phaedsys.org> - 2011-05-26 11:15 +0100
Re: C programming in 2011 James Kuyper <jameskuyper@verizon.net> - 2011-05-26 06:53 -0400
Re: C programming in 2011 Ian Collins <ian-news@hotmail.com> - 2011-05-27 09:12 +1200
Re: C programming in 2011 Nizumzen <chicken@mcnuggets.com> - 2011-05-29 00:39 +0100
Re: C programming in 2011 Noob <root@127.0.0.1> - 2011-06-01 17:38 +0200
Re: C programming in 2011 Nizumzen <chicken@mcnuggets.com> - 2011-06-01 22:34 +0100
Re: C programming in 2011 Angel <angel+news@spamcop.net> - 2011-06-01 21:42 +0000
Re: C programming in 2011 Nizumzen <chicken@mcnuggets.com> - 2011-06-02 00:33 +0100
Re: C programming in 2011 Duncan Bayne <dhgbayne@gmail.com> - 2011-05-26 03:41 -0700
Re: C programming in 2011 Jorgen Grahn <grahn+nntp@snipabacken.se> - 2011-05-28 00:46 +0000
Re: C programming in 2011 Chad <cdalten@gmail.com> - 2011-05-26 14:09 -0700
Re: C programming in 2011 Keith Thompson <kst-u@mib.org> - 2011-05-26 15:07 -0700
Re: C programming in 2011 Angel <angel+news@spamcop.net> - 2011-05-27 07:42 +0000
Re: C programming in 2011 James Kuyper <jameskuyper@verizon.net> - 2011-05-27 07:30 -0400
Re: C programming in 2011 Phil Carmody <thefatphil_demunged@yahoo.co.uk> - 2011-05-29 01:15 +0300
Re: C programming in 2011 Angel <angel+news@spamcop.net> - 2011-05-28 22:24 +0000
Re: C programming in 2011 Keith Thompson <kst-u@mib.org> - 2011-05-28 16:08 -0700
Re: C programming in 2011 Angel <angel+news@spamcop.net> - 2011-05-28 23:47 +0000
Re: C programming in 2011 Geoff <geoff@invalid.invalid> - 2011-05-28 16:58 -0700
Re: C programming in 2011 Keith Thompson <kst-u@mib.org> - 2011-05-28 18:49 -0700
Re: C programming in 2011 Pierre Habouzit <madcoder@debian.org> - 2011-05-29 11:13 +0000
Re: C programming in 2011 Jorge <jorge@jorgechamorro.com> - 2011-06-04 08:05 -0700
Re: C programming in 2011 Angel <angel+news@spamcop.net> - 2011-06-04 16:20 +0000
Re: C programming in 2011 Nizumzen <chicken@mcnuggets.com> - 2011-05-29 14:35 +0100
Re: C programming in 2011 Keith Thompson <kst-u@mib.org> - 2011-05-29 12:49 -0700
OT: Brackets, parentheses, etc. (Was: C programming in 2011) Shao Miller <sha0.miller@gmail.com> - 2011-05-29 16:13 -0500
Re: OT: Brackets, parentheses, etc. (Was: C programming in 2011) "Morris Keesan" <mkeesan@post.harvard.edu> - 2011-05-30 12:17 -0400
Re: OT: Brackets, parentheses, etc. (Was: C programming in 2011) Shao Miller <sha0.miller@gmail.com> - 2011-05-30 12:52 -0500
Re: C programming in 2011 Nizumzen <chicken@mcnuggets.com> - 2011-05-29 23:58 +0100
Re: C programming in 2011 Chris H <chris@phaedsys.org> - 2011-05-30 14:42 +0100
Re: C programming in 2011 Nizumzen <chicken@mcnuggets.com> - 2011-05-30 17:40 +0100
Re: C programming in 2011 Sjouke Burry <burrynulnulfour@ppllaanneett.nnll> - 2011-05-30 22:38 +0200
Re: C programming in 2011 "J. J. Farrell" <jjf@bcs.org.uk> - 2011-05-30 00:38 +0100
Re: C programming in 2011 Phil Carmody <thefatphil_demunged@yahoo.co.uk> - 2011-05-30 11:14 +0300
Re: C programming in 2011 Malcolm McLean <malcolm.mclean5@btinternet.com> - 2011-05-29 06:55 -0700
Re: C programming in 2011 Keith Thompson <kst-u@mib.org> - 2011-05-28 18:47 -0700
Re: C programming in 2011 Phil Carmody <thefatphil_demunged@yahoo.co.uk> - 2011-05-30 15:02 +0300
Re: C programming in 2011 Phil Carmody <thefatphil_demunged@yahoo.co.uk> - 2011-05-30 11:01 +0300
Re: C programming in 2011 Angel <angel+news@spamcop.net> - 2011-05-30 08:51 +0000
Re: C programming in 2011 Nobody <nobody@nowhere.com> - 2011-05-31 01:54 +0100
Re: C programming in 2011 Angel <angel+news@spamcop.net> - 2011-05-31 12:00 +0000
Re: C programming in 2011 Seebs <usenet-nospam@seebs.net> - 2011-05-31 16:44 +0000
Re: C programming in 2011 Keith Thompson <kst-u@mib.org> - 2011-05-31 11:43 -0700
Re: C programming in 2011 Chris H <chris@phaedsys.org> - 2011-05-26 11:13 +0100
Re: C programming in 2011 Francois Grieu <fgrieu@gmail.com> - 2011-05-26 16:04 +0200
Re: C programming in 2011 Branimir Maksimovic <bmaxa@hotmail.com> - 2011-05-26 16:21 +0200
Re: C programming in 2011 Francois Grieu <fgrieu@gmail.com> - 2011-05-26 17:23 +0200
Re: C programming in 2011 Branimir Maksimovic <bmaxa@hotmail.com> - 2011-05-26 19:15 +0200
Re: C programming in 2011 Willem <willem@toad.stack.nl> - 2011-05-26 17:29 +0000
Re: C programming in 2011 Branimir Maksimovic <bmaxa@hotmail.com> - 2011-05-26 20:10 +0200
Re: C programming in 2011 Pierre Habouzit <madcoder@debian.org> - 2011-05-26 17:35 +0000
Re: C programming in 2011 Willem <willem@toad.stack.nl> - 2011-05-26 17:53 +0000
Re: C programming in 2011 Malcolm McLean <malcolm.mclean5@btinternet.com> - 2011-05-26 11:13 -0700
Re: C programming in 2011 James Kuyper <jameskuyper@verizon.net> - 2011-05-26 21:57 -0400
Re: C programming in 2011 Tim Rentsch <txr@alumni.caltech.edu> - 2011-05-31 01:13 -0700
Re: C programming in 2011 Branimir Maksimovic <bmaxa@hotmail.com> - 2011-05-26 20:06 +0200
Re: C programming in 2011 Ralf Damaschke <rwspam@gmx.de> - 2011-05-26 17:57 +0000
Re: C programming in 2011 Keith Thompson <kst-u@mib.org> - 2011-05-26 11:31 -0700
Re: C programming in 2011 Ralf Damaschke <rwspam@gmx.de> - 2011-05-26 20:43 +0000
Re: C programming in 2011 Keith Thompson <kst-u@mib.org> - 2011-05-26 14:53 -0700
Re: C programming in 2011 Tim Rentsch <txr@alumni.caltech.edu> - 2011-05-31 01:03 -0700
Re: C programming in 2011 "Kleuskes & Moos" <kleuske@xs4all.nl> - 2011-05-31 01:59 -0700
Re: C programming in 2011 "Kleuskes & Moos" <kleuske@xs4all.nl> - 2011-05-31 02:55 -0700
Re: C programming in 2011 James Kuyper <jameskuyper@verizon.net> - 2011-05-31 06:36 -0400
Re: C programming in 2011 "Kleuskes & Moos" <kleuske@xs4all.nl> - 2011-05-31 05:57 -0700
Re: C programming in 2011 James Kuyper <jameskuyper@verizon.net> - 2011-05-31 09:23 -0400
Re: C programming in 2011 "Kleuskes & Moos" <kleuske@xs4all.nl> - 2011-05-31 07:50 -0700
Re: C programming in 2011 Keith Thompson <kst-u@mib.org> - 2011-05-31 11:41 -0700
Re: C programming in 2011 "Kleuskes & Moos" <kleuske@xs4all.nl> - 2011-06-01 01:46 -0700
Re: C programming in 2011 Ike Naar <ike@iceland.freeshell.org> - 2011-06-01 10:07 +0000
Re: C programming in 2011 "Kleuskes & Moos" <kleuske@xs4all.nl> - 2011-06-01 04:12 -0700
Re: C programming in 2011 "Kleuskes & Moos" <kleuske@xs4all.nl> - 2011-06-01 07:46 -0700
Re: C programming in 2011 Seebs <usenet-nospam@seebs.net> - 2011-06-01 17:53 +0000
Re: C programming in 2011 lawrence.jones@siemens.com - 2011-06-01 16:28 -0400
Re: C programming in 2011 "Kleuskes & Moos" <kleuske@xs4all.nl> - 2011-06-01 23:28 -0700
Re: C programming in 2011 Uno <Uno@example.invalid> - 2011-06-09 21:24 -0600
Re: C programming in 2011 James Kuyper <jameskuyper@verizon.net> - 2011-06-01 10:04 -0400
Re: C programming in 2011 "Kleuskes & Moos" <kleuske@xs4all.nl> - 2011-06-01 08:21 -0700
Re: C programming in 2011 "Kleuskes & Moos" <kleuske@xs4all.nl> - 2011-06-01 09:37 -0700
Re: C programming in 2011 James Kuyper <jameskuyper@verizon.net> - 2011-06-01 12:55 -0400
Re: C programming in 2011 "Kleuskes & Moos" <kleuske@xs4all.nl> - 2011-06-01 11:52 -0700
Re: C programming in 2011 "J. J. Farrell" <jjf@bcs.org.uk> - 2011-06-02 00:00 +0100
Re: C programming in 2011 "Kleuskes & Moos" <kleuske@xs4all.nl> - 2011-06-01 23:19 -0700
Re: C programming in 2011 James Kuyper <jameskuyper@verizon.net> - 2011-06-01 12:53 -0400
Re: C programming in 2011 "Kleuskes & Moos" <kleuske@xs4all.nl> - 2011-06-01 11:55 -0700
Re: C programming in 2011 Keith Thompson <kst-u@mib.org> - 2011-06-01 08:41 -0700
Re: C programming in 2011 Noob <root@127.0.0.1> - 2011-06-01 17:12 +0200
Re: C programming in 2011 "Kleuskes & Moos" <kleuske@xs4all.nl> - 2011-06-01 09:28 -0700
Re: C programming in 2011 Keith Thompson <kst-u@mib.org> - 2011-06-01 08:38 -0700
Re: C programming in 2011 "Kleuskes & Moos" <kleuske@xs4all.nl> - 2011-06-02 01:00 -0700
Re: C programming in 2011 Willem <willem@toad.stack.nl> - 2011-06-02 09:13 +0000
Re: C programming in 2011 "Kleuskes & Moos" <kleuske@xs4all.nl> - 2011-06-02 02:52 -0700
Re: C programming in 2011 Willem <willem@toad.stack.nl> - 2011-06-02 11:41 +0000
Re: C programming in 2011 "Kleuskes & Moos" <kleuske@xs4all.nl> - 2011-06-02 05:53 -0700
Re: C programming in 2011 "Kleuskes & Moos" <kleuske@xs4all.nl> - 2011-06-02 06:49 -0700
Re: C programming in 2011 Willem <willem@toad.stack.nl> - 2011-06-02 14:18 +0000
Re: C programming in 2011 Seebs <usenet-nospam@seebs.net> - 2011-06-02 21:02 +0000
Re: C programming in 2011 "Kleuskes & Moos" <kleuske@xs4all.nl> - 2011-06-02 23:55 -0700
Re: C programming in 2011 Angel <angel+news@spamcop.net> - 2011-06-03 08:37 +0000
Re: C programming in 2011 James Kuyper <jameskuyper@verizon.net> - 2011-06-03 06:49 -0400
Re: C programming in 2011 Angel <angel+news@spamcop.net> - 2011-06-03 11:52 +0000
Re: C programming in 2011 "Kleuskes & Moos" <kleuske@xs4all.nl> - 2011-06-03 11:11 -0700
Re: C programming in 2011 Angel <angel+news@spamcop.net> - 2011-06-03 18:23 +0000
Re: C programming in 2011 Seebs <usenet-nospam@seebs.net> - 2011-06-03 18:59 +0000
Re: C programming in 2011 Angel <angel+news@spamcop.net> - 2011-06-03 19:48 +0000
Re: C programming in 2011 "Kleuskes & Moos" <kleuske@xs4all.nl> - 2011-06-03 15:02 -0700
Re: C programming in 2011 Keith Thompson <kst-u@mib.org> - 2011-06-03 12:19 -0700
Re: C programming in 2011 "Kleuskes & Moos" <kleuske@xs4all.nl> - 2011-06-03 13:40 -0700
Re: C programming in 2011 Keith Thompson <kst-u@mib.org> - 2011-06-03 15:11 -0700
Re: C programming in 2011 "Kleuskes & Moos" <kleuske@xs4all.nl> - 2011-06-03 15:24 -0700
Re: C programming in 2011 Keith Thompson <kst-u@mib.org> - 2011-06-03 15:34 -0700
Re: C programming in 2011 "Kleuskes & Moos" <kleuske@xs4all.nl> - 2011-06-03 17:10 -0700
Re: C programming in 2011 Keith Thompson <kst-u@mib.org> - 2011-06-03 17:34 -0700
Re: C programming in 2011 James Kuyper <jameskuyper@verizon.net> - 2011-06-04 09:47 -0400
Re: C programming in 2011 James Kuyper <jameskuyper@verizon.net> - 2011-06-02 10:02 -0400
Re: C programming in 2011 Angel <angel+news@spamcop.net> - 2011-06-02 12:17 +0000
Re: C programming in 2011 Keith Thompson <kst-u@mib.org> - 2011-06-02 08:48 -0700
Re: C programming in 2011 "Kleuskes & Moos" <kleuske@xs4all.nl> - 2011-06-02 10:35 -0700
Re: C programming in 2011 gordonb.jpem8@burditt.org (Gordon Burditt) - 2011-06-05 23:32 -0500
Re: C programming in 2011 "Kleuskes & Moos" <kleuske@xs4all.nl> - 2011-06-06 00:12 -0700
Re: C programming in 2011 gordonb.5k8u2@burditt.org (Gordon Burditt) - 2011-06-06 05:18 -0500
Re: C programming in 2011 "Kleuskes & Moos" <kleuske@xs4all.nl> - 2011-06-06 08:16 -0700
Re: C programming in 2011 Michael Press <rubrum@pacbell.net> - 2011-06-03 18:06 -0700
Re: C programming in 2011 gordonb.zourz@burditt.org (Gordon Burditt) - 2011-06-05 21:25 -0500
Re: C programming in 2011 "Kleuskes & Moos" <kleuske@xs4all.nl> - 2011-06-06 01:14 -0700
Re: C programming in 2011 gordonb.donaz@burditt.org (Gordon Burditt) - 2011-06-06 04:36 -0500
Re: C programming in 2011 "Kleuskes & Moos" <kleuske@xs4all.nl> - 2011-06-06 09:02 -0700
Re: C programming in 2011 gordonb.k6ruq@burditt.org (Gordon Burditt) - 2011-06-06 18:36 -0500
Re: C programming in 2011 "Kleuskes & Moos" <kleuske@xs4all.nl> - 2011-06-07 10:14 -0700
Re: C programming in 2011 "J. J. Farrell" <jjf@bcs.org.uk> - 2011-05-31 19:56 +0100
Re: C programming in 2011 Noob <root@127.0.0.1> - 2011-06-01 14:54 +0200
Re: C programming in 2011 Angel <angel+news@spamcop.net> - 2011-06-01 13:07 +0000
Re: C programming in 2011 pete <pfiland@mindspring.com> - 2011-06-01 14:10 -0400
Re: C programming in 2011 James Kuyper <jameskuyper@verizon.net> - 2011-06-01 19:58 -0400
Re: C programming in 2011 Willem <willem@toad.stack.nl> - 2011-06-01 09:07 +0000
Re: C programming in 2011 James Kuyper <jameskuyper@verizon.net> - 2011-06-01 09:29 -0400
Re: C programming in 2011 David Thompson <dave.thompson2@verizon.net> - 2011-06-07 02:18 -0400
Re: C programming in 2011 "Kleuskes & Moos" <kleuske@xs4all.nl> - 2011-06-07 09:31 -0700
Re: C programming in 2011 Patrick Scheible <kkt@zipcon.net> - 2011-06-09 14:55 -0700
Re: C programming in 2011 Tim Rentsch <txr@alumni.caltech.edu> - 2011-06-01 02:35 -0700
Re: C programming in 2011 Francois Grieu <fgrieu@gmail.com> - 2011-05-31 21:57 +0200
Re: C programming in 2011 Francois Grieu <fgrieu@gmail.com> - 2011-05-31 22:03 +0200
Re: C programming in 2011 Kenneth Brody <kenbrody@spamcop.net> - 2011-05-26 12:27 -0400
Re: C programming in 2011 Nobody <nobody@nowhere.com> - 2011-05-26 18:02 +0100
csiph-web