Cryptography-Digest Digest #975, Volume #9 Tue, 3 Aug 99 02:13:03 EDT
Contents:
Re: With all the talk about random... ("Douglas A. Gwyn")
Re: With all the talk about random... ("Douglas A. Gwyn")
Re: Cryptanalysis of R250
Re: With all the talk about random... ("Douglas A. Gwyn")
Re: With all the talk about random... ("Douglas A. Gwyn")
Re: With all the talk about random... ("Douglas A. Gwyn")
Re: How to write REALLY PORTABLE code dealing with bits (Was: How Big is ("Douglas
A. Gwyn")
Re: How to write REALLY PORTABLE code dealing with bits (Was: How Big ("Douglas A.
Gwyn")
Re: bits and bytes (david thompson)
Re: bits and bytes ("Douglas A. Gwyn")
Re: Modified Vigenere cipher ("Douglas A. Gwyn")
Re: What the hell is XOR? (david thompson)
Re: How to write REALLY PORTABLE code dealing with bits (Was: How Big ("Douglas A.
Gwyn")
Re: How to write REALLY PORTABLE code dealing with bits (Was: How Big ("Douglas A.
Gwyn")
Re: bits and bytes (david thompson)
Re: Warning! The eclipse approaches... {5.6b}
(Airbrush4u)
Re: [OT] What the hell is XOR? (david thompson)
----------------------------------------------------------------------------
From: "Douglas A. Gwyn" <[EMAIL PROTECTED]>
Subject: Re: With all the talk about random...
Date: Tue, 03 Aug 1999 03:52:24 GMT
[EMAIL PROTECTED] wrote:
> So you are saying that some things are not bounded by a set of rules?
There are rules, very definite, mathematical ones.
However, they don't give classical "billiard-ball" kinds of
predictions, because at the quantum level the world just isn't
properly described by billiard-ball physics.
------------------------------
From: "Douglas A. Gwyn" <[EMAIL PROTECTED]>
Subject: Re: With all the talk about random...
Date: Tue, 03 Aug 1999 03:56:30 GMT
"John McDonald, Jr." wrote:
> Most of the time, in 10 years, I could care less how "secret" that
> information was.... So at what point is encryption "good enough?"
The working standard among the pros is, 50 years against the best
foes, assuming a reasonable extrapolation of capability based on
past experience.
That is actually a very stiff standard.
------------------------------
From: [EMAIL PROTECTED] ()
Subject: Re: Cryptanalysis of R250
Date: 3 Aug 99 03:41:55 GMT
[EMAIL PROTECTED] wrote:
: The Evil Anti-Rick ([EMAIL PROTECTED]) wrote:
: : Does anyone have any cryptanalysis information on the R250 PRNG
: : algorithm and/or cryptanalysis information of byte-wise XOR stream
: : ciphers?
: Thus, it
: would have been useful if you described R250 in your post, or at least
: gave an indication as to what class of pseudorandom-number generator it
: belongs to.
Well, I followed another bit of my own advice, and did a little web
search. Even on a text-browser, noting that q=103 happens to give a number
that makes 250 when added to 147...
has led me to the conclusion that R250 is also known as the Tausworth
generator, and the algorithm is as follows:
I(n) = I(n-147) XOR I(n-250)
so one is running a trinomial linear shift register in parallel for each
bit of whatever you're generating. Let's assume you're generating 8-bit
bytes, since you've referred to byte-wide encryption.
Since the initial state of the shift register is 250 bytes, generated
"randomly" by some other means, if that means is assumed to be perfect,
messages shorter than 250 bytes cannot be compromised.
But if I had a message that was, say, 1000 bytes long, and I knew 250
bytes of the plaintext with certainty, then I could recover the shift
register contents, and solve for the rest of the message trivially, since
the design of the shift register is a known constant.
*Without* known plaintext of that length, though, or at least snatches of
known plaintext that happen to be well placed, this is a long enough shift
register to create problems. However, the fact that it is simply a
trinomial leaves some avenues of attack still open (despite the fact that
for the purpose of a PRNG, it is very high quality - for Monte Carlo
computer runs).
Let us say that our R250 output sequence is being used to encipher a
high-redundancy plaintext, such as uncompressed English text in ASCII.
Your first 250 characters of ciphertext are, therefore, the first 250
characters of the keystream ... XORed to ASCII text.
The next 147 characters of ciphertext are keystream characters 1 through
147 XOR keystream characters 104 through 250 XOR some more ASCII text, but
different ASCII text.
Thus, you have 147 sets of equations, of the form
Keystream(50) xor Plain(50) = Cipher(50)
Keystream(154) xor Plain(154) = Cipher(154)
Keystream(50) xor Keystream(154) xor Plain(300) = Cipher(300)
and the three Cipher values are known, and the three Plain values, since
they represent bytes of plain ASCII text, are highly constrained.
The overwhelming majority of characters in plain ASCII text are lowercase
alphabetic characters. For these characters, the first three bits in the
byte are constant: (010). Thus, because there will be many cases where the
three Plain values are known, with enough plaintext it should be possible
to solve for the first three bits in the shift register quite easily.
Now you will have a glimpse into the pattern of the plaintext you are
trying to read. It will look like this:
Aaa aaa aaaa aaaa a aaaaaaa aaaa...
where A stands for any uppercase letter, or @, [, \, ], ^, or _, and where
a stands for any lowercase letter, or backwards quote, {, |, }, ~, or DEL,
and where the space usually is a space, but might be a digit or any other
special character or punctuation mark. If you see two of them in a row
between sequences of letters, likely the first one is a comma, period, or
other punctuation mark, and the second one is a space.
Statistical methods on the letters will probably be needed, but just
knowing where the space characters are will give you quite a window on the
other five bits.
John Savard
------------------------------
From: "Douglas A. Gwyn" <[EMAIL PROTECTED]>
Subject: Re: With all the talk about random...
Date: Tue, 03 Aug 1999 03:50:43 GMT
Patrick Juola wrote:
> As much as I admired the late Professor Feynman, he's wrong, dead
> wrong, in this little snippet.
Almost anybody can be made to appear wrong when interpreted out of
context. Of course Feynman did know of which he spoke.
------------------------------
From: "Douglas A. Gwyn" <[EMAIL PROTECTED]>
Subject: Re: With all the talk about random...
Date: Tue, 03 Aug 1999 03:39:34 GMT
[EMAIL PROTECTED] wrote:
> Well the laws of physics will dictate how a falling dice will land.
> So I would say that's not random.
The trouble with "floating abstractions" is that debates involving
them cannot be settled, because they don't have definite properties.
Try *defining* fairly rigorously the meaning of "random" and *then*
the issue might be resolvable. (Although more likely we'll just
argue about whether your definition properly captures the essence
of the concept.)
I'd say that fair dice, rolled in a reasonable manner, realize a
random process about as well as anything we could devise. (One
could do slightly better with intrinsically quantum processes,
such as radiation counters.)
------------------------------
From: "Douglas A. Gwyn" <[EMAIL PROTECTED]>
Subject: Re: With all the talk about random...
Date: Tue, 03 Aug 1999 03:48:51 GMT
[EMAIL PROTECTED] wrote:
> Nothing is truly random though. Why do you think we have laws of
> physics and developing laws of quantum mechanics? Just cuz you
> can't explain something doesn't mean it's random.
That is not what randomness means in quantum physics.
> I think there is a misconception. A truly random number just occurs.
> Nothing dictates what it will be or when it will be (such as counting
> or detecting alpha particles).
Numbers don't "just occur"; they are produced by processes involving
humans. What is produced is determined by the nature of the objects,
how they interact, the environment, etc.
Radioactive decay proceeds according to well understood laws of
physics, and can be very closely modeled by a simple stochastic
process characterized by a single parameter.
> If you could look at a piece of amercium and see alpha particles leave
> you could predict what your counter will produce, but since that's
> believed to be difficult we assume it's 'random'. Simple as that.
No, that is quite contrary to wjat we know about quantum principles.
It is *in principle impossible* to predict the moment at which an
*individual* alpha particle will be emitted, but it is fairly easy to
predict the long-term *statistical* behavior of such a system.
> I am no phyisic person so if some of my facts are off please note.
> But the idea still remains. Nothing is truly random.
The idea *doesn't* remain, because the physics is egregious.
------------------------------
From: "Douglas A. Gwyn" <[EMAIL PROTECTED]>
Subject: Re: How to write REALLY PORTABLE code dealing with bits (Was: How Big is
Date: Tue, 03 Aug 1999 04:10:59 GMT
[EMAIL PROTECTED] wrote:
> That's not true. There is no definition of 'byte' in ANSI C.
I don't know what you mean by "ANSI C", but the standard for the
C programming language certainly does define "byte", and it is
nearly synonymous with "char".
------------------------------
From: "Douglas A. Gwyn" <[EMAIL PROTECTED]>
Subject: Re: How to write REALLY PORTABLE code dealing with bits (Was: How Big
Date: Tue, 03 Aug 1999 04:46:37 GMT
"Lame K. Irony" wrote:
> ... the fact that no other such word exists is
> ample evidence that "byte" fits the bill.
The fact that such a word as "octet" *does* exist and *is* used
is ample evidence that "byte" does *not* "fit the bill".
------------------------------
From: david thompson <[EMAIL PROTECTED]>
Subject: Re: bits and bytes
Date: Tue, 03 Aug 1999 00:08:31 -0400
Mon, 02 Aug 1999 13:16:12 -0400,
"Trevor L. Jackson; III" <[EMAIL PROTECTED]> responded:
> Thomas Pornin wrote:
>
> [in C for signed char] the [minimum] range is -127..127, not
> > -128..127. This is for computers that store signed types with a sign
> > bit and the absolute value; this was the case for the PDP-11 (I think,
> > correct me if I am wrong). This is rare nowadays since it makes addition
> > and substraction a bit more complicated, and it also means that there is
> > a 'negative 0' that is not equal to 0 in memory.
>
> The name for this arithmetic ones-complement as opposed to the alternate
> twos-complement arithmetic (TCA). PDP-8, PDP-11, LSI-11, DECsystem 10 & 20,
> and VAXen all use TCA
The name for what he described is sign-and-magnitude,
and way back when some computers did use it.
One's complement represents negative numbers by the
bitwise complement of their magnitude, and like S&M
has a negative zero and symmetric extremes.
I've seen abbreviations 1sC and 2sC but not OCA, TCA.
LSI-11 was really just a model of PDP-11. Also using 2sC
are (at least) "big iron" IBM S/360/370/390 (and clones);
all other DEC machines I know of, definitely -6, -7, -9;
all(?) general-purpose microprocessors: Intel 8080 and x86
(and embedded chips), Motorola 68K, PowerPC, SPARC, MIPS, ...
[big snip]
> > You might also use bit fields. This is a feature of C rarely used, and
> > therefore not very optimized in many compilers. However, if you want
> > to be portable, that is pretty convenient.
>
> Bit fields are in no way portable, and they are absolutely not
> interoperable.. They are one of the first features to avoid when writing
> multi-platform software.
>
*Support* for bitfields is required by the standard,
except that defaulting to signed or unsigned is impl-spec,
so computing on bitfield values you have stored yourself
and specified as to signedness is completely portable.
*Placement* of bitfields in memory within a struct
(i.e. endianness and alignment) is implementation-specified,
and does vary a lot, so writing out and reading in structs
containing bitfields is often not interoperable.
(CCed) david.thompson at but not for trintech.com
------------------------------
From: "Douglas A. Gwyn" <[EMAIL PROTECTED]>
Subject: Re: bits and bytes
Date: Tue, 03 Aug 1999 04:08:16 GMT
karl malbrain wrote:
> The distinction on the ranges of signed numbers in C is designed to
> cover for ONES COMPLEMENT arithmetic, ...
The intent of C89, spelled out explicitly in C9x, is to permit
conforming implementations to choose twos-complement, ones-complement,
or signed-magnitude representation (but no others) for integers,
and to optionally have "padding bits" that occupy storage but are not
included in the representation. This flexibility allows "natural"
representations to be used on all the known C platforms.
------------------------------
From: "Douglas A. Gwyn" <[EMAIL PROTECTED]>
Subject: Re: Modified Vigenere cipher
Date: Tue, 03 Aug 1999 04:53:20 GMT
Castover80 wrote:
> I'm still trying to find some of the crypto stuff that has been
> recently declassified. The NSA site gives a huge list of what
> has been turned over to archives, but those documents don't seem
> to be available on-line at NARA yet.
I doubt they will ever be "on-line" via NARA; that's not their
function. If you want to see them you need to obtain a Researcher
ID card (after consulting with a Staff member about your project)
and visit the Archives (II) in person. For the RG 457 stuff, the
department to contact is the Modern Military History section.
But don't try to phone them and ask them to find things for you;
you have to do the footwork yourself.
Being in the public domain, this material could be published on
the Web by anyone who has a copy. I've been scan-converting one
classic document with the intention of making it available some day.
------------------------------
From: david thompson <[EMAIL PROTECTED]>
Subject: Re: What the hell is XOR?
Date: Tue, 03 Aug 1999 00:19:08 -0400
(mostly OT -- except to the extent that C is suitable
and popular for implementation of crypto operations)
29 Jul 1999 13:46:18 GMT,
[EMAIL PROTECTED] (John M. Gamble) responded:
> In article <[EMAIL PROTECTED]>,
> fungus <[EMAIL PROTECTED]> wrote:
... [re swapping object contents by back-and-forth XOR]
> >And don't forget that doing this via pointers is
> >dangerous, eg. (in C)
> >
> >void swap(int *a, int *b)
> >{
> > *a ^= *b;
> > *b ^= *a;
> > *a ^= *b;
> >}
> >
> >Will fail if a and b both point to the same int. Watch out
> >for hard-to-find bugs if you ever do anything like this.
> >
> But good heavens, why would you do it like that?
>
> /*
> ** Swap via the three-xor method, contained in a single line.
> */
> #define swap(a, b) (a ^= (b ^= (a ^= b)))
>
> And you'll note that i commented my code, which no one else
> seems to have bothered. Frankly, if a programmer didn't know
> the exchange by XOR method (hell, i knew it before i became a
> programmer), and didn't bother to comment his/her code (but
> it's obviouse, right? - no, nothing is obvious, espacially at
> 2AM), then i'd have serious doubts about hiring this person.
1) Like many other C macros, this will malfunction,
probably silently, if an argument includes a
non-idempotent side-effect. It would also
malfunction if an argument contained an exposed
operator with precedence below assignment, but
in this case there is none such (, can't occur).
2) This single-statement method is technically
undefined behavior according the the C (or C++) standard,
which means an implementation is *not* required to
give the "obviously correct" result *or* diagnose
the error, and is even permitted to crash or go nuts.
In the real world, on a machine where XOR (and especially
XOR with a memory destination) is a single instruction,
any sensible implementation will execute it as intended;
and on a machine where XOR has to be synthesized,
*very likely* it will do nothing worse than storing a
wrong result, but you probably don't want to use it on
such a machine anyway because it wouldn't give you the
performance gain you are presumably seeking.
Before you point to the parentheses, they are only used
(and are not necessary) for parsing, they do *not*
completely control the actual sequence of store and fetch.
See the comp.lang.c FAQ section 3 especially 3.3b, the
referenced portions of the standard(s), or search c.l.c
for "sequence point[s]" and you will find thousands
of threads by other people making this same mistake.
fungus' function, which a good compiler can inline,
avoids these problems, and has only the problem he noted
and you did nothing to fix -- it doesn't work for
swapping an object with itself, which no sensible
programmer does intentionally but sometimes falls out
as an edge case in more complex algorithms.
DScott's original post suggested this (only) in
(PDP-11) assembler for registers -- which (as
on most computer architectures) *cannot* alias.
Or in GNU C, you could "force" inlining in a typesafe
and fully defined manner using a statement expression.
Personally, in C I would declare the pointers
(not their targets!) const, to document that
I *want* elision of the pointers when possible,
although the dataflow analysis here is trivial
and will almost certainly be done automatically.
In C++ I would use a reference for the same reason.
3) the comment you claim such pride in adds no information
at all to the code -- we can see it's a single line
and has three XORs just by glancing at it. I agree
I wouldn't hire someone who didn't know or at least
immediately figure out why this method works -- when
correctly implemented and used -- but neither would I
hire someone who normally writes comments like that.
Now a comment like *this* might be useful:
/* this is the only way to persuade the obsolete
Defecto Mark III.7 compiler to generate optimal
code for the MIL-BLETCH 1066 processor.
** It must be used only for simple 16-bit or 32-bit
unsigned objects, and be re-checked when porting */
(CCed) david.thompson at but not for trintech.com
------------------------------
From: "Douglas A. Gwyn" <[EMAIL PROTECTED]>
Crossposted-To: alt.comp.lang.learn.c-c++,comp.lang.c++,microsoft.public.vc.language
Subject: Re: How to write REALLY PORTABLE code dealing with bits (Was: How Big
Date: Tue, 03 Aug 1999 04:47:17 GMT
Guenther Brunthaler wrote:
> Sure, and following this, we will discuss the correct abbreviation of
> "ternary digit".
It's usually called a "trit"; sorry about that.
------------------------------
From: "Douglas A. Gwyn" <[EMAIL PROTECTED]>
Subject: Re: How to write REALLY PORTABLE code dealing with bits (Was: How Big
Date: Tue, 03 Aug 1999 04:44:35 GMT
Guenther Brunthaler wrote:
>> subset <stdint.h> ...
> What, there is also another such fine header file?
It's essentially the subset of <inttypes.h> that pertains to the
language only; so it lacks declarations for the hosted library
functions and printf/scanf formats. <inttypes.h> will #include
<stdint.h> (in effect if not in fact) in C9x implementations.
> 1. my copy of inttypes.h does NOT define constants such as
> UINT_LEAST8_MAX. Is this correct?
> 2. Definitions such as UINT_FAST8_C() are also missing?
Early versions of <inttypes.h> were missing some of the features
that ended up in the C9x spec. The C9x requirement (for an
implementation to conform to the standard) is that the header
must define *every* one of the macros and types that it *can*
(i.e., for every type that is supported by the implementation).
In turn, the programmer can test the associated macros to
determine which of these types are supported.
> 3. (Unrelated to inttypes.h) The ANSI-C standard requires modulo-2
> arithmetic on integers and that an 'int' has at least 16 bits. Does
> the standard also include a mandatory 2's complement representation
> of negative integers, and does it require that the value 65535 can
> be represented in an 'int' (i. e. all 16 bits are also available for
> the value to be stored)?
No, a conforming implementation can use twos-complement,
ones-complement, or signed-magnitude representation for integers,
optionally with padding bits that do not form part of the value.
The type "int" is signed, and must be capable of representing any
integer value from -32767 through 32767 (i.e., it must have at leasr
16 non-padding bits). The type "unsigned int" can represent from 0
through at least 65535. Only the unsigned types have guaranteed
"modular" arithmetic (not mod-2, but modulo the maximum value + 1).
> Ummmm. But it at least my general assumption correct, that
> processing should be done with the "fast" types unless memory
> requirements do matter, in which cases the "least" types should
> be preferred?
That would be one rational programming practice, but actually we
expect modern compiler optimizers to do a good job of making the
code fast without special hints. The "fast" types are most useful
with older compiler technology, in which case the "register"
keyword might actually be more helpful. There were committee
members who didn't want the "fast" types specified at all,
partly out of concern that users would misunderstand their
utility and complain when they occasionally turned out to not be
the very fastest choice in some instances.
> And - did they say anything? Is Microsoft also a member of those
> committees?
It has been a long time since Microsoft has sent a representative
to J11/WG14. On the other hand, they do seem to eventually track
the C and C++ standards.
> I would really like to experience a windows.h file one day that
> uses inttypes.h-style definitions in the primary API definitions
There have been many attempts at this. In constant-width character
display days, there was the "curses" library (and termcap database).
We also have X-Windows, which is built on a network protocol (and
is available for all major platforms, even if Microsoft doesn't
bundle it with their OSes). And there is the TK/TCL toolkit,
which has been adapted for use with other languages than TCL.
The main problem with an MFC-like API is that Microsoft's notion
of windowing sucks, and an attempt to force better designs to
work within that straitjacket will just be ignored.
> (Especially in expectation of Win64! And who knows that 64 bit
> processors are the ceiling? Perhaps 128 or even 256 bit word
> machines will be common one day.)
I've been programming on 64-bit platforms for over a decade.
An upper limit would probably be a wordsize capable of counting
every particle in the universe at every resolvable moment of time,
so 128 bits is getting there.
Note that a word size of > 256 bits forces one to denote the
bit-within-word using a number bigger than an octet, which may
give the engineers pause.
------------------------------
From: david thompson <[EMAIL PROTECTED]>
Subject: Re: bits and bytes
Date: Tue, 03 Aug 1999 01:04:35 -0400
Mon, 02 Aug 1999 13:16:12 -0400,
"Trevor L. Jackson; III" <[EMAIL PROTECTED]> responded:
> Thomas Pornin wrote:
>
> [in C for signed char] the [minimum] range is -127..127, not
> > -128..127. This is for computers that store signed types with a sign
> > bit and the absolute value; this was the case for the PDP-11 (I think,
> > correct me if I am wrong). This is rare nowadays since it makes addition
> > and substraction a bit more complicated, and it also means that there is
> > a 'negative 0' that is not equal to 0 in memory.
>
> The name for this arithmetic ones-complement as opposed to the alternate
> twos-complement arithmetic (TCA). PDP-8, PDP-11, LSI-11, DECsystem 10 & 20,
> and VAXen all use TCA
The name for what he described is sign-and-magnitude,
and way back when some computers did use it.
One's complement represents negative numbers by the
bitwise complement of their magnitude, and like S&M
has a negative zero and symmetric extremes.
I've seen abbreviations 1sC and 2sC but not OCA, TCA.
LSI-11 was really just a model of PDP-11. Also using 2sC
are (at least) "big iron" IBM S/360/370/390 (and clones);
all other DEC machines I know of, definitely -6, -7, -9;
all(?) general-purpose microprocessors: Intel 8080 and x86,
Moto 68K, PowerPC, HP-PA, SPARC, MIPS, ...
[big snip]
> > You might also use bit fields. This is a feature of C rarely used, and
> > therefore not very optimized in many compilers. However, if you want
> > to be portable, that is pretty convenient.
>
> Bit fields are in no way portable, and they are absolutely not
> interoperable.. They are one of the first features to avoid when writing
> multi-platform software.
>
*Support* for bitfields is required by the standard,
except that defaulting to signed or unsigned is impl-spec,
so computing on bitfield values you have stored yourself
and specified as to signedness is completely portable.
*Placement* of bitfields in memory within a struct
(i.e. endianness and alignment) is implementation-specified,
and does vary a lot, so writing out and reading in structs
containing bitfields is usually NOT interoperable.
(CCed) david.thompson at but not for trintech.com
------------------------------
From: [EMAIL PROTECTED] (Airbrush4u)
Crossposted-To:
sci.geo.petroleum,alt.pets.ferrets,alt.sport.bowling,comp.os.ms-windows.ce,comp.os.linux.misc,soc.culture.europe,alt.prophecies.nostradamus,alt.catastrophism,alt.prophecies.cayce,alt.messianic,alt.atheism,sci.skeptic,sci.astro,sci.archaeology,alt.current-events.earth-changes
Subject: Re: Warning! The eclipse approaches... {5.6b}
Date: 03 Aug 1999 05:48:19 GMT
>That "monstriferous" Comet Lee will be seen during the
>solar eclipse this August 11th, followed by WWIII, the
>1300-meter "King of Terror" meteoroid impact before 10
>October 1999,....(Snip)
I want to hear a public apology by you on October 11th so that the world may
know that Nostrodamus was indeed a false prophet!!!
Mike V
------------------------------
From: david thompson <[EMAIL PROTECTED]>
Subject: Re: [OT] What the hell is XOR?
Date: Tue, 03 Aug 1999 00:58:14 -0400
(now diverging into the wilds of C)
29 Jul 1999 13:46:18 GMT,
[EMAIL PROTECTED] (John M. Gamble) responded:
> In article <[EMAIL PROTECTED]>,
> fungus <[EMAIL PROTECTED]> wrote:
... [re swapping object contents by back-and-forth XOR]
> >And don't forget that doing this via pointers is
> >dangerous, eg. (in C)
> >
> >void swap(int *a, int *b)
> >{
> > *a ^= *b;
> > *b ^= *a;
> > *a ^= *b;
> >}
> >
> >Will fail if a and b both point to the same int. Watch out
> >for hard-to-find bugs if you ever do anything like this.
> >
> But good heavens, why would you do it like that?
>
> /*
> ** Swap via the three-xor method, contained in a single line.
> */
> #define swap(a, b) (a ^= (b ^= (a ^= b)))
>
> And you'll note that i commented my code, which no one else
> seems to have bothered. Frankly, if a programmer didn't know
> the exchange by XOR method (hell, i knew it before i became a
> programmer), and didn't bother to comment his/her code (but
> it's obviouse, right? - no, nothing is obvious, espacially at
> 2AM), then i'd have serious doubts about hiring this person.
1) Like many other C macros, this will malfunction,
probably silently, if an argument includes a
non-idempotent side-effect. It would also
malfunction if an argument contained an exposed
operator with precedence below assignment, but
in this case there is none such (, can't occur).
2) This single-statement method is technically
undefined behavior according the the C (or C++) standard,
which means an implementation is *not* required to
give the "obviously correct" result *or* diagnose
the error, and is even permitted to crash or go nuts.
In real life, on a machine where XOR (and especially
XOR with a memory destination) is a single instruction,
any sensible implementation will execute it as intended;
and on a machine where XOR has to be synthesized,
*very likely* it will do nothing worse than storing a
wrong result, but you probably don't want to use it on
such a machine anyway because it wouldn't give you the
performance gain you are presumably seeking.
Before you point to the parentheses, they are only used
(and are not necessary) for parsing, they do *not*
completely control the actual sequence of store and fetch.
See the comp.lang.c FAQ section 3 especially 3.3b, the
portions of the standard reference there, or search c.l.c
for "sequence point[s]" and you will find thousands
of threads by other people making this same mistake.
fungus' function, which a good compiler can inline,
avoids these problems, and has only the problem he noted
and you did nothing to fix -- it doesn't work for
swapping an object with itself, which no sensible
programmer does intentionally but sometimes falls out
as an edge case in more complex algorithms.
DScott's original post suggested this (only) in
(PDP-11) assembler for registers -- which (as
on most computer architectures) *cannot* alias.
Or in GNU C, you could "force" inlining in a typesafe
and fully defined manner using a statement expression.
Personally, in C I would declare the pointers
(not their targets!) const, to document that
I *want* elision of the pointers when possible,
although the dataflow analysis here is trivial
and will almost certainly be done automatically.
In C++ I would use a reference for the same reason.
3) the comment you claim such pride in adds no information
at all to the code -- we can see it's a single line
and has three XORs just by glancing at it. I agree
I wouldn't hire someone who didn't know or at least
immediately figure out why this method works -- when
correctly implemented and used -- but neither would I
hire someone who normally writes comments like that.
Now a comment like *this* might be useful:
/* this is the only way to persuade the obsolete
Defecto Mark III.7 compiler to generate optimal
code for the MIL-BLETCH 1066 processor.
** It must be used only for simple 16-bit or 32-bit
unsigned objects, and be re-checked when porting */
(CCed) david.thompson at but not for trintech.com
------------------------------
** FOR YOUR REFERENCE **
The service address, to which questions about the list itself and requests
to be added to or deleted from it should be directed, is:
Internet: [EMAIL PROTECTED]
You can send mail to the entire list (and sci.crypt) via:
Internet: [EMAIL PROTECTED]
End of Cryptography-Digest Digest
******************************
