I have been working for quite awhile on a 70,000 project - a database program of sorts.

Believe it or not, this is my first project, I have got about 10,000 lines of stubbs and "I'm still workin on it .... " funcs basically re-inventing the wheel. 99.44/100 'ths of what people have criticised me for, I have found substantiated as a reasonble method of approach in works such as Horstmann's Computing Concepts with C++ Essentials and Stroustrup's The C++ Programming Language,(Special Edition)

Trying to get answers often involves doing more science to understand the question and involves questions that do not lend themselves to simple 'look it up int the help files' approach:

Does anyone have any experience with:
"Compiler Construction: Principles and Practice : Principles and Practice"
by Kenneth C. Louden
and will it in fact allow me to write a simple compiler that will  generate P.E.
format execuatbles for the Win_32 programming model ?
[whether console mode or windows.h]

I have bought so many books that are really promising on the cover, but really right now need to invest in hardware and some other things and do not want to sink $100 into a book unless it will let me understand why:

const void* basePoint = static_cast<void*>(malloc(static_cast<size_t>(4096)));
is not the same as:
void* const basePoint = static_cast<void*>(malloc(static_cast<size_t>(4096)));

Many issues such as those discussed in Bulka's work do not lend themselves to investigation in online fora.

Any remarks, including quips, welcome.

nick

nick wrote:
> I have bought so many books that are really promising on the cover, but really right now need to invest in hardware and some other things and do not want to sink $100 into a book unless it will let me understand why:
> 
> const void* basePoint = static_cast<void*>(malloc(static_cast<size_t>(4096)));
> is not the same as:
> void* const basePoint = static_cast<void*>(malloc(static_cast<size_t>(4096)));
> 

Examples are probably most easily understood:

int i; // integer
const int i; // constant integer
int const i; // constant integer
const int * i; // pointer to constant integer
int const * i; // pointer to constant integer
int * const i; // constant pointer to integer
const int * const i; // constant pointer to constant integer
int const * const i; // constant pointer to constant integer

Of your two lines of code, the first defines a pointer to constant void, whereas the second defines a constant pointer to void.

Personally, I always write my pointers in the second style in the above examples - the * is separated from the rest by spaces, and the const comes to the right of what it affects. I.e. int const * const instead of const int * const. That way, right-to-left reading is always correct, and it's easy to tell at a glance what's what.

I presume this is what was confusing you.

nick escreveu:
[snipped]

> I have bought so many books that are really promising on the cover, but really
> right now need to invest in hardware and some other things and do not want to
> sink $100 into a book unless it will let me understand why:
> 
> const void* basePoint = static_cast<void*>(malloc(static_cast<size_t>(4096)));
> is not the same as:
> void* const basePoint = static_cast<void*>(malloc(static_cast<size_t>(4096)));
> 
If you try 'cdecl':
cdecl> explain const void* basePoint
declare basePoint as pointer to const void

cdecl> explain void* const basePoint
declare basePoint as const pointer to void

Does it help?

In article <dmfvj9$54$1@digitaldaemon.com>, Cesar Rabak says...
>
>nick escreveu:
>[snipped]
>
>> I have bought so many books that are really promising on the cover, but really right now need to invest in hardware and some other things and do not want to sink $100 into a book unless it will let me understand why:
>> 
>> const void* basePoint = static_cast<void*>(malloc(static_cast<size_t>(4096)));
>> is not the same as:
>> void* const basePoint = static_cast<void*>(malloc(static_cast<size_t>(4096)));
>> 
>If you try 'cdecl':

?  ...  __cdecl is a linkage declaration for a func() - the above is the use of a function, in this case mallloc, to obtain a pointer to some memory space. Where does __cdecl fit in to this line.


>cdecl> explain const void* basePoint
>declare basePoint as pointer to const void

A constant pointer is what I wanted so I could reset the typed pointer initialized from it to walk over the allocated space again, later in the func()

How could you have a constant void ?  ~   This is what I wrestled with that lead me to reading the help files for the compiler that stated that the constant keyword binds to the left, there for goes immediately to the right [in source code] of what it is I am trying to make stable.

>
>cdecl> explain void* const basePoint
>declare basePoint as const pointer to void

That's *exactly* what I did, it's just that the constant keyword goes on the opposite side that one's brain tells to.

>
>Does it help?

Any reply at this point is helpful.

Nick  [escreveu - snip, snip]  ;-)


Nick's Law: The only dumb question is one you should have asked and didn't.

In article <dmevpb$269m$1@digitaldaemon.com>, Deewiant says...
>
>nick wrote:
>> I have bought so many books that are really promising on the cover, but really right now need to invest in hardware and some other things and do not want to sink $100 into a book unless it will let me understand why:
>> 
>> const void* basePoint = static_cast<void*>(malloc(static_cast<size_t>(4096)));
>> is not the same as:
>> void* const basePoint = static_cast<void*>(malloc(static_cast<size_t>(4096)));
>> 
>
>Examples are probably most easily understood:
>
>int i; // integer
>const int i; // constant integer
>int const i; // constant integer
>const int * i; // pointer to constant integer
>int const * i; // pointer to constant integer
>int * const i; // constant pointer to integer
>const int * const i; // constant pointer to constant integer
>int const * const i; // constant pointer to constant integer
>
>Of your two lines of code, the first defines a pointer to constant void, whereas the second defines a constant pointer to void.
>
>Personally, I always write my pointers in the second style in the above examples - the * is separated from the rest by spaces, and the const comes to the right of what it affects. I.e. int const * const instead of const int * const. That way, right-to-left reading is always correct, and it's easy to tell at a glance what's what.
>
>I presume this is what was confusing you.

Yes, and I've adopted the style your response suggests.  Largely, it was a probe question into the workings of the compiler - I really need to study compiler science to achieve the reliability I am trying to attain.

I do not understand how a non-typed pointer can point to a const, i.e. how can void be constant ?  (a suble, but real question)


Nick's Law: The only dumb question is one you should have asked and didn't. Confutatis Maledictis: Latratus Maximus, Canni Sonti est Which means:"When Titans clash, I try to stay out of the whey !"

Does it help? escreveu:
> In article <dmfvj9$54$1@digitaldaemon.com>, Cesar Rabak says...
> 
>>nick escreveu:
>>[snipped]
>>
>>
>>>I have bought so many books that are really promising on the cover, but really
>>>right now need to invest in hardware and some other things and do not want to
>>>sink $100 into a book unless it will let me understand why:
>>>
>>>const void* basePoint = static_cast<void*>(malloc(static_cast<size_t>(4096)));
>>>is not the same as:
>>>void* const basePoint = static_cast<void*>(malloc(static_cast<size_t>(4096)));
>>>
>>
>>If you try 'cdecl':
> 
> 
> ?  ...  __cdecl is a linkage declaration for a func() - the above is the use of
> a function, in this case mallloc, to obtain a pointer to some memory space.
> Where does __cdecl fit in to this line.
> 
> 

We're talking about different cdecls. The one I suggested you is a command line program:

$apropos cdecl
c++decl [cdecl]      (1)  - Compose C and C++ type declarations
cdecl                (1)  - Compose C and C++ type declarations

The 'cdecl>' you see below is the prompt for it.

> 
>>cdecl> explain const void* basePoint
>>declare basePoint as pointer to const void
> 
> 
> A constant pointer is what I wanted so I could reset the typed pointer
> initialized from it to walk over the allocated space again, later in the func()

This declaration (the above from cdecl) says that you can have basePoint to point to an object of type void whose content you do not intend to change.

I cannot see a lot of use for this, except perhaps in the parameter list of a function.

> 
> How could you have a constant void ?  ~   This is what I wrestled with that lead
> me to reading the help files for the compiler that stated that the constant
> keyword binds to the left, there for goes immediately to the right [in source
> code] of what it is I am trying to make stable.

Yes, for 'void' it is weird. But remember the syntax works for other PODs, so if you had, say, a pointer to cont int or pointer to const char, you could change the value of the pointer without changing the contents they point to.

> 
> 
>>cdecl> explain void* const basePoint
>>declare basePoint as const pointer to void
> 

Now the pointer content (its value) is constant, so your intention is not changing it.

> 
> That's *exactly* what I did, it's just that the constant keyword goes on the
> opposite side that one's brain tells to.

Well C language has some funny rules. That's why the embrionic version of 'cdecl' appears in K&R 2nd ed.

> 
> 
>>Does it help?
> 
> 
> Any reply at this point is helpful.

HTH

In article <dmqn56$m8j$1@digitaldaemon.com>, Cesar Rabak says...
>
>Does it help? escreveu:
>> In article <dmfvj9$54$1@digitaldaemon.com>, Cesar Rabak says...

[snipped]

>We're talking about different cdecls. The one I suggested you is a command line program:
>
>$apropos cdecl
>c++decl [cdecl]      (1)  - Compose C and C++ type declarations
>cdecl                (1)  - Compose C and C++ type declarations
>
>The 'cdecl>' you see below is the prompt for it.]

My apologies ... I am not familiar with it.

>>>cdecl> explain const void* basePoint
>>>declare basePoint as pointer to const void
>> 
[snipped]
>
>I cannot see a lot of use for this, except perhaps in the parameter list of a function.
>
>> 
>> How could you have a constant void ?  ~   This is what I wrestled with that lead me to reading the help files for the compiler that stated that the constant keyword binds to the left, there for goes immediately to the right [in source code] of what it is I am trying to make stable.
>
>Yes, for 'void' it is weird. But remember the syntax works for other PODs, so if you had, say, a pointer to cont int or pointer to const char, you could change the value of the pointer without changing the contents they point to.

That's what I thought it did, I was asking that to thwart blunders later.

As verbosly detailed below, it's the pointer I want to remian constant, the data area it's self to be used as a buffer.

>>>cdecl> explain void* const basePoint
>>>declare basePoint as const pointer to void
>
>Now the pointer content (its value) is constant, so your intention is not changing it.

??? -> this looks like one of those questions that seems to be to frequently emerge - a pattern has *clearly* emerged in my coding practice attempts - trying to frame the question often provides clear, effective solutions to the problem and leads to coding directly in C/C++ what it is that is going on in my mind.

I was not aware + it seemed intuitive that it could not be that void could have a const attribute, quality, nature. Let me describe in plain old words what it is I intend:

I want to implement a "sliding window" search function that takes various
dictionaries and runs them through my hashing function, building up an int 'map
key' dataset,... then run a character buffer or file
{being examined for good words or bad words}
through a 'second pass' looking for hits and misses - all quite tricky and
**guarenteed** to get me hit and hit again by the seasoned pros and decent
students ~ of all skill levels. But the first time I had a runaway ::strlen(),
there would be no further question that I would re-invent the wheel as many
times and to whatever degree it took to get a version I coded myself to work on
[large or small] dictionaries or examined buffers.

To do this, I have to reset the int pointer to the base of the keyspace frequently, or at least several times. The idea I had was to declare a constant basepoint, the use that as the initalizer list for a mutable pointer, then re-initialize the mutable pointer whenever needed using the copy operator.

void* const p = malloc(4096);// gets me a const pointer to a mutable data ?

It took me awhile to learn the const_cast<> syntax, but it is common to grind while one builds up thinking and coding skills.

The data in the allocated memory should [generally] be mutuable, changable - a buffer; It may be re-written on subsequent passes if the dictionary and/or examined character buffer do not reduce to a few pages on reducing them to a keyset: I forget at the moment, but I think the dic I found has 128,000 words in it - the 'sliding window' needs to be able to examine huge files.

Therefore, the keyset *may* need to be regenerated. I have not made this design decision yet, storing *anything* that can be decompiled or guessed at by intruders is an obvious security blunder, and I have had too many teeth lost to dental carries to let any go to:

'Silas P. Stealer' - Redneck of Dem Hills of Hell

//////////////

[snipped]

>Well C language has some funny rules. That's why the embrionic version of 'cdecl' appears in K&R 2nd ed.

<humor>You cite the perennial test for newbies: bowing to K&R any ed.</humor>

I have been on enough large projects (not coding) to understand, in detail, the actual mechnisim by which this evolution occurs. An appealing study in chaotics.

Not dissimilar to what I find on the open web and why I am trying to implement a powerful tool,... a titanium-grade shell that I wrote myself and understand it's operation in fine detail exploiting the full power of a 32-bit keyspace.

>> 
>> 
>>>Does it help?
>> 
>> 
>> Any reply at this point is helpful.
>
>HTH
HTH : 'help the helpless' ? (humor)

Nick escreveu:
> In article <dmqn56$m8j$1@digitaldaemon.com>, Cesar Rabak says...
> 
>>Does it help? escreveu:
>>
>>>In article <dmfvj9$54$1@digitaldaemon.com>, Cesar Rabak says...
> 
[snipped]

>>We're talking about different cdecls. The one I suggested you is a command line program:
>>
>>$apropos cdecl
>>c++decl [cdecl]      (1)  - Compose C and C++ type declarations
>>cdecl                (1)  - Compose C and C++ type declarations
>>
>>The 'cdecl>' you see below is the prompt for it.]
> 
> 
> My apologies ... I am not familiar with it.

OK. Never mind. There are clashes with names everywhere.

[snipped]
>>>How could you have a constant void ?  ~   This is what I wrestled with that lead
>>>me to reading the help files for the compiler that stated that the constant
>>>keyword binds to the left, there for goes immediately to the right [in source
>>>code] of what it is I am trying to make stable.
>>
>>Yes, for 'void' it is weird. But remember the syntax works for other PODs, so if you had, say, a pointer to cont int or pointer to const char, you could change the value of the pointer without changing the contents they point to.
> 
> 
> That's what I thought it did, I was asking that to thwart blunders later.
> 
> As verbosly detailed below, it's the pointer I want to remian constant, the data
> area it's self to be used as a buffer.

So, if that's the way you decide to go, this is the construct.

> 
> 
>>>>cdecl> explain void* const basePoint
>>>>declare basePoint as const pointer to void
>>
>>Now the pointer content (its value) is constant, so your intention is not changing it.
> 
> 
> ??? -> this looks like one of those questions that seems to be to frequently
> emerge - a pattern has *clearly* emerged in my coding practice attempts - trying
> to frame the question often provides clear, effective solutions to the problem
> and leads to coding directly in C/C++ what it is that is going on in my mind.
> 
> I was not aware + it seemed intuitive that it could not be that void could have
> a const attribute, quality, nature. Let me describe in plain old words what it
> is I intend:
> 
> I want to implement a "sliding window" search function that takes various
> dictionaries and runs them through my hashing function, building up an int 'map
> key' dataset,... then run a character buffer or file
> {being examined for good words or bad words}
> through a 'second pass' looking for hits and misses - all quite tricky and
> **guarenteed** to get me hit and hit again by the seasoned pros and decent
> students ~ of all skill levels. But the first time I had a runaway ::strlen(),
> there would be no further question that I would re-invent the wheel as many
> times and to whatever degree it took to get a version I coded myself to work on
> [large or small] dictionaries or examined buffers.

I see. I did not understand how did arrive at a 'runaway ::strlen()', though.

OTOH, it seems, to me, that you're using a too low level approach if you want to use C++.

Although I concede you have greater immersion in the analysis of the problem, I would first give a look on higher constructs available in STL and BOOST, to name the free ones¹.
> 
> To do this, I have to reset the int pointer to the base of the keyspace
> frequently, or at least several times. The idea I had was to declare a constant
> basepoint, the use that as the initalizer list for a mutable pointer, then
> re-initialize the mutable pointer whenever needed using the copy operator.
> 
> void* const p = malloc(4096);// gets me a const pointer to a mutable data ?
> 

That's the idea.

> It took me awhile to learn the const_cast<> syntax, but it is common to grind
> while one builds up thinking and coding skills.
> 

Yes.

> The data in the allocated memory should [generally] be mutuable, changable - a
> buffer; It may be re-written on subsequent passes if the dictionary and/or
> examined character buffer do not reduce to a few pages on reducing them to a
> keyset: I forget at the moment, but I think the dic I found has 128,000 words in
> it - the 'sliding window' needs to be able to examine huge files.

I start to get into the problem.

> 
> Therefore, the keyset *may* need to be regenerated. I have not made this design
> decision yet, storing *anything* that can be decompiled or guessed at by
> intruders is an obvious security blunder, and I have had too many teeth lost to
> dental carries to let any go to:
> 
> 'Silas P. Stealer' - Redneck of Dem Hills of Hell

You mention 'intruders' so I see you have additional concers with security. Will the dictionary also be included in the binary of your programm or an external file it will consult?

[snipped

>>HTH
> 
> HTH : 'help the helpless' ? (humor)
> 

You seem to spared the sense of humour in face of lowing teeth!

--
Cesar Rabak

[1] could see LEDA if the project is academic and gives you rights to get a reasonable license.

In article <dmvi9m$1okp$1@digitaldaemon.com>, Cesar Rabak says...
>
>Nick escreveu:
>> In article <dmqn56$m8j$1@digitaldaemon.com>, Cesar Rabak says...
>> 
>>>Does it help? escreveu:
>>>
>>>>In article <dmfvj9$54$1@digitaldaemon.com>, Cesar Rabak says...
>> 
>[snipped]
>
>>>We're talking about different cdecls. The one I suggested you is a command line program:
>>>
>>>$apropos cdecl
>>>c++decl [cdecl]      (1)  - Compose C and C++ type declarations
>>>cdecl                (1)  - Compose C and C++ type declarations
>>>
>>>The 'cdecl>' you see below is the prompt for it.]
>> 
>> 
>> My apologies ... I am not familiar with it.
>
>OK. Never mind. There are clashes with names everywhere.
I call this 'name saturation' - likely the arena in which the need for namespace facility originally devolved/evolved, concepted & designed. The basis for my 'taking too low level approach' as chided later ...
>
>[snipped]
>>>>How could you have a constant void ?  ~   This is what I wrestled with that lead me to reading the help files for the compiler that stated that the constant keyword binds to the left, there for goes immediately to the right [in source code] of what it is I am trying to make stable.
>>>
>>>Yes, for 'void' it is weird. But remember the syntax works for other PODs, so if you had, say, a pointer to cont int or pointer to const char, you could change the value of the pointer without changing the contents they point to.
>> 
>> 
>> That's what I thought it did, I was asking that to thwart blunders later.
>> 
>> As verbosly detailed below, it's the pointer I want to remian constant, the data area it's self to be used as a buffer.
>
>So, if that's the way you decide to go, this is the construct.

Thanx, there is much knowledge I need to attain
[to achieve the robustness I desire]
Many of these questions may be answered in Kenneth Louden's compiler book.
>
>> 
>> 
>>>>>cdecl> explain void* const basePoint
>>>>>declare basePoint as const pointer to void
>>>
>>>Now the pointer content (its value) is constant, so your intention is not changing it.
>> 
>> 
>> ??? -> this looks like one of those questions that seems to be to frequently emerge - a pattern has *clearly* emerged in my coding practice attempts - trying to frame the question often provides clear, effective solutions to the problem and leads to coding directly in C/C++ what it is that is going on in my mind.
>> 
>> I was not aware + it seemed intuitive that it could not be that void could have a const attribute, quality, nature. Let me describe in plain old words what it is I intend:
>> 
>> I want to implement a "sliding window" search function that takes various
>> dictionaries and runs them through my hashing function, building up an int 'map
>> key' dataset,... then run a character buffer or file
>> {being examined for good words or bad words}
>> through a 'second pass' looking for hits and misses - all quite tricky and
>> **guarenteed** to get me hit and hit again by the seasoned pros and decent
>> students ~ of all skill levels. But the first time I had a runaway ::strlen(),
>> there would be no further question that I would re-invent the wheel as many
>> times and to whatever degree it took to get a version I coded myself to work on
>> [large or small] dictionaries or examined buffers.
>
>I see. I did not understand how did arrive at a 'runaway ::strlen()', though.
Early, crude attempts at coding; misused or other mistake - mistakes which *can* propogate into untested code.
>
>OTOH, it seems, to me, that you're using a too low level approach if you want to use C++.
>
>Although I concede you have greater immersion in the analysis of the problem, I would first give a look on higher constructs available in STL and BOOST, to name the free ones¹.

What I am doing, the approch which works for me; Try to use these tools implemented by accomplished authors .... then when they work or don't work, figure out why as a learning template - what devolves is that I can express fluently and effectively exactly what it is I want to do.

>> 
>> To do this, I have to reset the int pointer to the base of the keyspace frequently, or at least several times. The idea I had was to declare a constant basepoint, the use that as the initalizer list for a mutable pointer, then re-initialize the mutable pointer whenever needed using the copy operator.
>> 
>> void* const p = malloc(4096);// gets me a const pointer to a mutable data ?
>> 
>
>That's the idea.
>
>> It took me awhile to learn the const_cast<> syntax, but it is common to grind while one builds up thinking and coding skills.
>> 
>
>Yes.
>
>> The data in the allocated memory should [generally] be mutuable, changable - a buffer; It may be re-written on subsequent passes if the dictionary and/or examined character buffer do not reduce to a few pages on reducing them to a keyset: I forget at the moment, but I think the dic I found has 128,000 words in it - the 'sliding window' needs to be able to examine huge files.
>
>I start to get into the problem.

Case analysis: This machine I am on seems - emphasis seems - to be .... let me put it this way -> I recently had an opportunity to talk at length with someone who claimed to be writing real malware.

Not being much of a social engineer, it was all I could do to remain calm while he spoke for a few days, eventuall revealing limited skills and borderline intent.  Then I put before him the ultimate security question I had.

His reply: "Oh, NO ! - Not the honest person who is trying to fix their computer !  THEY DO THE ***STUUUPIIIDDDESST things !!"

Therefore, I have to address questions like the normal user will not keep a 'password' longer than they will keep the wrapper off of a candy bar.

Digging out and recovering data after someone has fouled up the machine suggests to me deep thinking and preparation.

>
>> 
>> Therefore, the keyset *may* need to be regenerated. I have not made this design decision yet, storing *anything* that can be decompiled or guessed at by intruders is an obvious security blunder, and I have had too many teeth lost to dental carries to let any go to:
>> 
>> 'Silas P. Stealer' - Redneck of Dem Hills of Hell
>
>You mention 'intruders' so I see you have additional concers with security. Will the dictionary also be included in the binary of your programm or an external file it will consult?

That is an interesting 'probe' - obviously, I can only save the hash keys, but as so often the proof_in_the_pudding - don't make this design decision too early. My crude attempts at testing my hashing algorithim suggest that it is effective at distributing strings longer than sizeof(int)/sizeof(char) over a 32 bit keyspace - if more power is required, I will learn that later and make revised design decisions based on increased knowledge and skills, experience and testing.

>
>[snipped
>
>>>HTH
>> 
>> HTH : 'help the helpless' ? (humor)
>> 
>
>You seem to spared the sense of humour in face of lowing teeth!

Huh ? 'losing teeth' ?

>
>--
>Cesar Rabak
>
>[1] could see LEDA if the project is academic and gives you rights to get a reasonable license.

huh - ? 'LEDA' ?

Nicholas Jordan escreveu:
> In article <dmvi9m$1okp$1@digitaldaemon.com>, Cesar Rabak says...
> 
snipped]
>>>
>>>My apologies ... I am not familiar with it.
>>
>>OK. Never mind. There are clashes with names everywhere.
> 
> I call this 'name saturation' - likely the arena in which the need for namespace
> facility originally devolved/evolved, concepted & designed. The basis for my
> 'taking too low level approach' as chided later ...

I can appreciate that.

[snipped]

>>>As verbosly detailed below, it's the pointer I want to remian constant, the data
>>>area it's self to be used as a buffer.
>>
>>So, if that's the way you decide to go, this is the construct.
> 
> 
> Thanx, there is much knowledge I need to attain
> [to achieve the robustness I desire]
> Many of these questions may be answered in Kenneth Louden's compiler book.
> 
Just to have feedback on this when you finish with the research in this book drop us a line.

[snipped]

>>
>>I see. I did not understand how did arrive at a 'runaway ::strlen()', though.
> 
> Early, crude attempts at coding; misused or other mistake - mistakes which *can*
> propogate into untested code.

Yes. Been there done that. A lot.

> 
>>OTOH, it seems, to me, that you're using a too low level approach if you want to use C++.
>>
>>Although I concede you have greater immersion in the analysis of the problem, I would first give a look on higher constructs available in STL and BOOST, to name the free ones¹.
> 
> 
> What I am doing, the approch which works for me; Try to use these tools
> implemented by accomplished authors .... then when they work or don't work,
> figure out why as a learning template - what devolves is that I can express
> fluently and effectively exactly what it is I want to do.
> 
OK.
> 
[snipped]

>>>The data in the allocated memory should [generally] be mutuable, changable - a
>>>buffer; It may be re-written on subsequent passes if the dictionary and/or
>>>examined character buffer do not reduce to a few pages on reducing them to a
>>>keyset: I forget at the moment, but I think the dic I found has 128,000 words in
>>>it - the 'sliding window' needs to be able to examine huge files.
>>
>>I start to get into the problem.
> 
> 
> Case analysis: This machine I am on seems - emphasis seems - to be .... let me
> put it this way -> I recently had an opportunity to talk at length with someone
> who claimed to be writing real malware.
> 
> Not being much of a social engineer, it was all I could do to remain calm while
> he spoke for a few days, eventuall revealing limited skills and borderline
> intent.  Then I put before him the ultimate security question I had. 
> 
> His reply: "Oh, NO ! - Not the honest person who is trying to fix their computer !  THEY DO THE ***STUUUPIIIDDDESST things !!"
> 
> Therefore, I have to address questions like the normal user will not keep a
> 'password' longer than they will keep the wrapper off of a candy bar.

Quite strong, but nice analogy! I'll probably will cite you!

> 
> Digging out and recovering data after someone has fouled up the machine suggests
> to me deep thinking and preparation.
> 

Yep. We had a situation where a fine package running in a class 5 data center had a table erased due a 'business error' which there was no means to recover by technological means.

> 
>>>Therefore, the keyset *may* need to be regenerated. I have not made this design
>>>decision yet, storing *anything* that can be decompiled or guessed at by
>>>intruders is an obvious security blunder, and I have had too many teeth lost to
>>>dental carries to let any go to:
>>>
>>>'Silas P. Stealer' - Redneck of Dem Hills of Hell
>>
>>You mention 'intruders' so I see you have additional concers with security. Will the dictionary also be included in the binary of your programm or an external file it will consult?
> 
> 
> That is an interesting 'probe' - obviously, I can only save the hash keys, but
> as so often the proof_in_the_pudding - don't make this design decision too
> early. My crude attempts at testing my hashing algorithim suggest that it is
> effective at distributing strings longer than sizeof(int)/sizeof(char) over a 32
> bit keyspace - if more power is required, I will learn that later and make
> revised design decisions based on increased knowledge and skills, experience and
> testing.

OK. Ultimately only testing will reassure and give you confidence, given the kind of system you're building.

>>You seem to spared the sense of humour in face of lowing teeth!
> 
> 
> Huh ? 'losing teeth' ?

I did not think of you breaking but rather grinding them. . . (more humour ;-)

> 
> 
>>--
>>Cesar Rabak
>>
>>[1] could see LEDA if the project is academic and gives you rights to get a reasonable license.
> 
> 
> huh - ? 'LEDA' ?
> 
> 
http://www.algorithmic-solutions.com/

Regards,