string generation

[Ken Human]

and crack() is the previously posted code
(
that checks every combination of those 62 characters with the
modification of knowing what to do with a "string format".

Forgive me, I did not post the correct address to the code in question.
It is
news://news.comcast.giganews.com:119/[email protected]

 

[Simon Biber]

Heh ;-)


I am quite not sure here what you mean by "possible". Length 10
at 2^30 per second would take about 24 3/4 years, but that's
-possible-.

Yes, but if computers capable of 2^30 per second are not available until
2005, and it takes 24 3/4 years, then it won't finish by the year 2016,
will it?

I mean that the earliest possible completion date is 2016, and that will
only be possible if you wait until around 2012 to buy the computer, so
it will complete in only 4 years.

 

[Michael Wojcik]

Hours or days? You'd better buy a sweater; it's going to get chilly
after the sun burns out (which will happen long before this thing is
finished).

Yes, but it still sounds like a cracking device, Dangermouse!

Of course, there's no need to generate them anyway. We already have
the list, in a handy compressed form that allows random access. Just
pick an integer between 0 and 62**16-1 and convert it into its base-
62 representation. A function implementing that algorithm serves as
the "array" of values, and its parameter as the "index".

Iteration is slower than iterating through an actual array, but since
constructing the actual array is, er, infeasible, that hardly matters.

(64 characters would actually be better here, since converting a
number in "pure binary" representation to base 64 is easier than
converting to base 62, but neither is difficult.)

 

[CBFalconer]

Yes, but it still sounds like a cracking device, Dangermouse!

Of course, there's no need to generate them anyway. We already
have the list, in a handy compressed form that allows random
access. Just pick an integer between 0 and 62**16-1 and convert
it into its base-62 representation. A function implementing that
algorithm serves as the "array" of values, and its parameter as
the "index".

Iteration is slower than iterating through an actual array, but
since constructing the actual array is, er, infeasible, that
hardly matters.

(64 characters would actually be better here, since converting a
number in "pure binary" representation to base 64 is easier than
converting to base 62, but neither is difficult.)

Having a handy number to stream in base routine, I tried diddling
it to go up to base 64, basically by modifying the digit conversion
routine below:

/* Mask and convert digit to hex representation */
/* Output range is 0..9 and a..v only (base 32) */
static int hexify(unsigned int value)
{
static char hexchars[] = "0123456789abcdef"
"ghijklmnopqrstuv"
"wxyzABCDEFGHIJKL"
"MNOPQRSTUVWXYZ@#";

/* allow for terminal '\0' */
#define MAXBASE 64 /*(sizeof(hexchars)-1)*/

return (hexchars[value & (MAXBASE-1)]);
} /* hexify */

What I want to do is keep hexchars private, and export the value of
MAXBASE, computed from the actual hexchars definition. Doesn't
work, because hexchars is undefined when the macro is expanded.
Can I get around this? The macro needs to be evaluated at the
declaration point.

--
Some useful references about C:
<http://www.ungerhu.com/jxh/clc.welcome.txt>
<http://www.eskimo.com/~scs/C-faq/top.html>
<http://benpfaff.org/writings/clc/off-topic.html>
<http://anubis.dkuug.dk/jtc1/sc22/wg14/www/docs/n869/> (C99)
<http://www.dinkumware.com/refxc.html> (C-library}
<http://gcc.gnu.org/onlinedocs/> (GNU docs)

 

[Michael Wojcik]

static int hexify(unsigned int value)
{
static char hexchars[] = "0123456789abcdef"
"ghijklmnopqrstuv"
"wxyzABCDEFGHIJKL"
"MNOPQRSTUVWXYZ@#";

/* allow for terminal '\0' */
#define MAXBASE 64 /*(sizeof(hexchars)-1)*/

return (hexchars[value & (MAXBASE-1)]);
} /* hexify */

What I want to do is keep hexchars private, and export the value of
MAXBASE, computed from the actual hexchars definition. Doesn't
work, because hexchars is undefined when the macro is expanded.
Can I get around this? The macro needs to be evaluated at the
declaration point.

I can't see any way of doing that - sizeof needs an object of complete
type.

As an alternative, you could always make MAXBASE a fixed value in your
header, then do a compile-time check to verify that it's the same as
sizeof hexchars in the C file:

#include "hexify.h"

static int hexify(unsigned int value)
{
static char hexchars[] = "0123456789abcdef"
"ghijklmnopqrstuv"
"wxyzABCDEFGHIJKL"
"MNOPQRSTUVWXYZ@#";

#if sizeof hexchars != MAXBASE
#error "MAXBASE is defined incorrectly"
#endif

Not as satisfying as having MAXBASE computed automatically, but it
does at least catch skew between the header and the implementation.

--
Michael Wojcik (e-mail address removed)

[After the lynching of George "Big Nose" Parrot, Dr. John] Osborne
had the skin tanned and made into a pair of shoes and a medical bag.
Osborne, who became governor, frequently wore the shoes.
-- _Lincoln [Nebraska] Journal Star_

 

[Old Wolf]

As an alternative, you could always make MAXBASE a fixed value in your
header, then do a compile-time check to verify that it's the same as
sizeof hexchars in the C file:

static int hexify(unsigned int value)
{
static char hexchars[] = "0123456789abcdef"
"ghijklmnopqrstuv"
"wxyzABCDEFGHIJKL"
"MNOPQRSTUVWXYZ@#";

#if sizeof hexchars != MAXBASE
#error "MAXBASE is defined incorrectly"
#endif

Not as satisfying as having MAXBASE computed automatically, but it
does at least catch skew between the header and the implementation.

You can't use 'sizeof' in a preprocessor test, because the
preprocessing is done before the compiling!

Although I have seen a preprocessor that supports what you
suggest, it is uncommon and non-standard.

 

[Michael Wojcik]

You can't use 'sizeof' in a preprocessor test,

Ugh. Right. Didn't engage my brain.

You'd have to use a macro for the size of the hexchars array in the
first place; the appropriate thing would be to put MAXBASE in the
header and then use it as the explicit length of the hexchars array.

because the preprocessing is done before the compiling!

Well, no, it isn't, strictly speaking. "Preprocessing" is trans-
lation phase 4. The standard doesn't define "compiling", but I'd
consider it the entire translation process. You might consider, say,
translation phase 7 "compiling", but the term is open to interpre-
tation.

(I also note that the grammar in C90 Annex B implies that you *can*
use sizeof in a #if expression, as constant-expressions include
relational-expressions which can include unary-expressions which
include the sizeof operator applied to another unary-expression;
but this is just another case where the grammar is not the whole
story. The constraints in 6.8.1 include other restrictions.)

--
Michael Wojcik (e-mail address removed)

Thanatos, thanatos! The labourer, dropping his lever,
Hides a black letter close to his heart and goes,
Thanatos, thanatos, home for the day and for ever. -- George Barker

 

[Keith Thompson]

You can't use 'sizeof' in a preprocessor test, because the
preprocessing is done before the compiling!

Although I have seen a preprocessor that supports what you
suggest, it is uncommon and non-standard.

Dennis Ritchie posted something on this topic in comp.std.c back in
1998 (sorry, groups.google.com mangled some of the headers):

] From: Dennis Ritchie <[email protected]>
] Subject: Re: Computing sizeof() during compilation
] Date: 1998/05/08
] Message-ID: <[email protected]>#1/1
] References: <[email protected]> <[email protected]>
] Organization: Bell Labs, Lucent Technologies
] Reply-To: (e-mail address removed)
] Newsgroups: comp.std.c
]
]
] > You are right. It was nice back in the days when things like
] >
] > #if (sizeof(int) == 8)
] >
] > actually worked (on some compilers).
]
] Must have been before my time.
]
] Dennis