www.digitalmars.com         C & C++   DMDScript  

c++.chat - const keyword binds to the left

reply nick <nick_member pathlink.com> writes:
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
Nov 27 2005
next sibling parent reply Deewiant <deewiant.doesnotlike.spam gmail.com> writes:
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.
Nov 28 2005
parent Nick <Nick_member pathlink.com> writes:
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 !"
Dec 02 2005
prev sibling parent reply Cesar Rabak <crabak acm.org> writes:
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)));
 

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?
Nov 28 2005
parent reply Does it help? <Does_member pathlink.com> writes:
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)));
 


? ... __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.
Dec 02 2005
parent reply Cesar Rabak <crabak acm.org> writes:
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
Dec 02 2005
parent reply Nick <Nick_member pathlink.com> writes:
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



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

Dec 03 2005
parent reply Cesar Rabak <crabak acm.org> writes:
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...



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.
Dec 04 2005
next sibling parent reply Nicholas Jordan <Nicholas_member pathlink.com> writes:
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...



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.

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.

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' ?
Dec 06 2005
parent reply Cesar Rabak <crabak acm.org> writes:
Nicholas Jordan escreveu:
 In article <dmvi9m$1okp$1 digitaldaemon.com>, Cesar Rabak says...
 

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.

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.

 

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' ?

Regards,
Dec 09 2005
next sibling parent reply Nicholas Jordan <Nicholas_member pathlink.com> writes:
In article <dnclgf$306q$1 digitaldaemon.com>, Cesar Rabak says...
Nicholas Jordan escreveu:
 In article <dmvi9m$1okp$1 digitaldaemon.com>, Cesar Rabak says...
 

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.

book drop us a line.

Obviously, from the depth of insight you provide, this is a totally serious statement. I have a demonstrated skill at reducing to what the beginner can understand; those difficulties we discuss here. I will get the book promptly and see what I can do with it - providing at 'creative commons' text for those who may follow.
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.


I looked up OTOH - my quip was a placeholder, I was out of time as I am now.
 

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!

I have had strong life experiences, I claim to be a "Class One Road Dog" - with a mastery of failure analysis.
 
 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.

I thought I would pull something like this out if I played straight.
 
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.

Building test suites screws back in to the same problem.
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 ;-)

Out of time, mark for gamesmanship: This probes for failure modes.
 
 
--
Cesar Rabak

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

huh - ? 'LEDA' ?

Regards,

Dec 10 2005
parent reply Cesar Rabak <crabak acm.org> writes:
Nicholas Jordan escreveu:
 In article <dnclgf$306q$1 digitaldaemon.com>, Cesar Rabak says...
 
Nicholas Jordan escreveu:

In article <dmvi9m$1okp$1 digitaldaemon.com>, Cesar Rabak says...



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.

Obviously, from the depth of insight you provide, this is a totally serious statement. I have a demonstrated skill at reducing to what the beginner can

Yes.
 understand; those difficulties we discuss here. I will get the book promptly
and
 see what I can do with it - providing at 'creative commons' text for those who
 may follow.

This is a great idea too.
 
 
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.

Clearly so.

The burns in my fingers are visible from so far! Oh, my... ;-)
 
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.

I looked up OTOH - my quip was a placeholder, I was out of time as I am now.

For this and any other you might still cross at in Internetese, see: http://www.catb.org/jargon/ [snipped]
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!

I have had strong life experiences, I claim to be a "Class One Road Dog" - with a mastery of failure analysis.

I see. I think you have been here, too: "Experience is that marvelous thing that enables you recognize a mistake when you make it again." -- F. P. Jones
 
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.

I thought I would pull something like this out if I played straight.

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

Building test suites screws back in to the same problem.

And make you feel not exactly smart as they point the errors you wish are not there. [snipped]
 Out of time, mark for gamesmanship: This probes for failure modes.
 

Regards, -- Cesar Rabak
Dec 10 2005
next sibling parent Nicholas Jordan <Nicholas_member pathlink.com> writes:
In article <dnes0o$1oko$1 digitaldaemon.com>, Cesar Rabak says...

[snipped]

Yes.

[snipped]
This is a great idea too.

I am swamped, I intend to get to the bookstore this afternoon; but as science is exploratory in nature - I have below something I worked on for several hours this morning. I am assuming you have powerful editors and the skills to use them at your fingertips - It may raise some questions that need raising when much of our society spends massive capital 'online' / thinks peewee number 5412 at aol.com is a secure password....I have one 'William L. Grimes' who has been on my credit report for twenty years, nearly thirty now. I wrote a well worded letter to the credit company with hand-delivered copies to Congressman, a legal services firm that does work for nearly 600 licensed attorneys, and one or two honchos in the C.S. field. I showed it to an engineer who holds a United States Patent - who said it was good work as such things go. I have yet to rc'v even a screw-off letter from any of them. The pasted work, though lenghty and in need of study of the thunking layer - is a well thought out probing of some of the questions we as those who write the code should address professionally and under the scorch of peer review.
The burns in my fingers are visible from so far! Oh, my... ;-)

For this and any other you might still cross at in Internetese, see: 
http://www.catb.org/jargon/

[snipped]

I see. I think you have been here, too:

"Experience is that marvelous thing that enables you recognize a mistake 
  when you make it again."
-- F. P. Jones

them. That's why I post the work below, but this knowledge was aquired by the method cited.
LOL.

[snipped]

And make you feel not exactly smart as they point the errors you wish 
are not there.

I am not formally trained in anything, I walked out of U.T. Austin after 17 hours and got a job for six dollars a day working for a circus. But I can tell that any platform that accelerates my mistakes will catalyze my efforts, science usually progresses by making sufficient number of mistakes that one of them is not a mistke. I seek them out, the make for forward progress. /*======LENGTHY POST =======*/ /*==skip if got something to do==*/ Welcome to Camp Code Puppies ! /*==skip if got something to do==*/ /*======LENGTHY POST =======*/ Ok, since you are craft-competent; Much to the dismay of newbies and Shell Clowns, I dismissed the debugger as too much for the 16-bit spindle on which the entire sys32 [32 ? - really ? Yeah, right.] hinges, or rather comes un-hinged at the sight of a mouse. Some code was blowing out, I put in several trace lines in the source and got: /*===begin trace results===*/ read_size: 4096 word_count: 420 buf_ at end of read loop: 7635329 dic_ at end of read loop: 7802478 Program status word at end of read loop: 3258 word_count at termination: 420 Sliding window at termination: 7631232 Dictionary buffer at termination: 7802478 File buffer pointer at termination: 8798244 Sliding window end point at termination: 7635328 Dictionary end point at termination: 8798224 File buffer end point at termination: 8802340 Program status word at termination: 3258 Loop called 1 times at termination. /*===end trace results===*/ The next few lines may have been over-optimized, they blow out... do { *linebuf = *dic_; .......... Seems to me the pointer vals were reasonable... dm/'s the best compiler I have found - the others are really too damn close to the sales department to be reliable as a skill-development platform: <code> /*==== begin generation of integer keys ====*/ char fluffy_[64]={0};// start off with the 64\ // byte TLB cache line size \ //as a default buffer size char* linebuf = &fluffy_[0000]; char* const lineBase(linebuf); </code> Doesn't sound to me like I am making any new ground in computer science or anything that should blow Creatures from the Crystal Blue Lagoon all the way out of Camp .... But some of the vals in the debug window look more like 64/128 bit addressing schemes and the 'look & feel' of the numerics given as addresses suggest it's not just me, it's not the machine I am on getting weak on corroded bus contacts; There's some sort of void art going on here where the linguistics of an 80 line 033 make a buzzard's paradize where howling scowls and braggard jowls can laugh run amok at the Road Dogs who have wondered in and have wildly runaway pointers walking through their code segment.... All the while thinking they are going to discover some new computer science. <blockquote Author="Wortman"> Well let's see if these guys can unpack man-pages-1_31_tar, that oughta keep'em busy awhile while they figure out how do decode those things ... If they get through that, we can ask them if they know how to link to dxdiagn.dll !!.. </blockquote> Well, I got news for ya' tootsie, ever heard of an 028 ? Ever heard of 'The Wortman Mod ? You may have heard of an 028 but you never heard of the Wortman Mod, I guarentee you haven't because it never made it out of the shop. <select name="Reasons Why"> <option>No money from investor participation. <option>Susan Creighton told us not to. <option>It was not marketable. <option>Wortman was secretive about it's workings. </select> After you select your reason, consider that Mr. Wortman sent me home one night with the front-plate off of an 028. I was tired at 2-3 am, but I knew his methods and treeks. I left the spring out that I had left out from being tired, it was one-too-many rebuilds to get it where it was supposed to go ~ and he would know that the *only* way I could apologize for not putting the spring back in was if I had gotten it out in the first place: You cannot get this spring out without dis-assembling the *entire* front plate, there is no way. I came in the next morning and apologize, watching closely his face. It sort of resembled the elephant trainer who had taught me one of life's lessons that remain with me still to this day. There was this 10,000 # elehnant name elsie, I had been eating my lunch and Wino - that was the trainers name - told my that elsie would crush me like a mouse if I ate lunch in front of the elephants, even thought they were tied up with steel cables. Just like my cat, 'Rat Trap' 'e can make it all the way from one end of the corridor to the other in one leap ~ preferrably leaving a dent in the wall. The mouse was dead ten minutes ago; Lining up like a Golfer on a par 4, he lets pause for paws then catches the thing b4 it hits the floor. I'v got 5 inches of scars in my left arm where 'e shows affection, losing the need for Tuna and wishing for some of whatever it is I have, even though I gave 'm several bites already and he didn't like it. One of those studies in chaos where no matter where you get, you havn't gotten there [ or something ] The elephant trainer pushed me over with one finger, he was a real Road Dog and could see that I was ready for the lesson. A lesson I have neither forgot nor ex- pect anyone to really understand unless they have had a runaway pointer in a on-air product rollout. I laugh when 'Rat Trap' bites me, it's so much easier to deal with than digging out calls to Keyboard Language Indicator Shell Hook extension asking you to have your credit card ready for Ben Dover. But what to do when Helpful Harvy won't sit on his hands when the system becomes unstable and starts trying to recover data on a sys that pivots on (0x00000005 & mask), I think I'll get a "A TechnicalFoundation for 3D Programming" and make a graphic called 'Slim Jim' and animation of a slender Stove Pipe Hat personna with a 0.080 " slim jim - If at any time the user calls this GDI, just lock the pwl and so on and prepare the entire database for recovery by someone with a baccalaureate in computer science and let them dig out the stuff on a system that packs a file's file time and date into an unsigned short ! Mean time, Imma Gonna go get Rat Trap some Tuna because: "Cats Cannot Talk" - and that's a lot easier to deal with than people who think C:\wino\nick.pwl is a way to break into my ahem - Moonbase.
Dec 11 2005
prev sibling next sibling parent Nicholas Jordan <Nicholas_member pathlink.com> writes:
In article <dnes0o$1oko$1 digitaldaemon.com>, Cesar Rabak says...
Nicholas Jordan escreveu:
 In article <dnclgf$306q$1 digitaldaemon.com>, Cesar Rabak says...
 
Nicholas Jordan escreveu:

In article <dmvi9m$1okp$1 digitaldaemon.com>, Cesar Rabak says...




I got up and was staring at my own ' debug output ' - obviously, from experience, it is probably an off by one or loop logic error. I see one of the buffer pointers pointing one past the end, my immediate question for bringing that up was why the debugger had such funny numbers in it. I assume it is because is several shells out from where the actual execution hit an access violation. There is so much to watch out for - I was putting the question before someone who had deeper insight into the moment; and is why later, in the trolling, I carped about the whole system pivoting on a 16-bit spindle. Case in point: The machine I am on has just been secured using: [Trend Micro Virus Pattern] product. Given that the system adminstrator is accomplished, why did sys admin not see this last year when poor operation was presented to me for opinion. I had to keep my mouth shut at that time because I did not have the credibility to weigh in so heavily as to retain an outer band of credibility. This sort of thinking underlies all of my inquiries and probed questions. I took a quick glance at your url provided; I can assume from the look and feel of the index page that this will focus on sore, long standing problems and ask that you retain a sense of perspective in the interlocution. Nick - docdubya.com/belvedere/cpp/cppfaq.htm One day, when I was sitting in my office, I thought of this little scheme, which would reinvigorate computer-think. ...... The motif was that STL would be the only way to go if you wanted to retain your sanity.."
Dec 13 2005
prev sibling next sibling parent Nicholas Jordan <Nicholas_member pathlink.com> writes:
In article <dnes0o$1oko$1 digitaldaemon.com>, Cesar Rabak says...
Nicholas Jordan escreveu:
 In article <dnclgf$306q$1 digitaldaemon.com>, Cesar Rabak says...
 
Nicholas Jordan escreveu:

In article <dmvi9m$1okp$1 digitaldaemon.com>, Cesar Rabak says...




I worked on this for hours, got up and ran full-tilt-boogie, without reservations - It is my best work and is a straight up:
Just to have feedback on this when you finish with the research in this 
book drop us a line.



From thousands of hours of life experience, a real and hard-won report. **** LENGTHY POST **** 9113 characters, 1616 words, 282 lines I re-ran the "test" - at "5 am" when my best work occurs - using KISS, [keep it simple, stupid == common engineering speak] I got some headway, meaning I thought about what I was doing and where I am at and refreshed my overview of the entire project and it's long term planning. What I am trying to do (I had forgot) is apply an entrophy test to the keys generated by a non-random feed into: /* inline signed int _stdcall chopper(char * in_,size_t len_) * takes a generic string and returns an int from * XOR'ing the string over an integer array of * random integer and bit shifting by index into the key pattern.*/ __inline signed int __stdcall chopper(char * in_ = 0,size_t len_ = 0); I doubt my entrophy test is working decently, but it looks like I get a low order out of 0 % entrophy (by LZW) if I (rand xor rand) for a feed into it. Makes obvious senes in that if I (rand xor rand) I should get low entropy out. (spare me) One of my early design decisions being that if I get near zero entrophy out for near zero entrophy fed in, I can move on to flattening of something with known patterns. (As a test philosophy - for writing code and test harnesses) So to get some measure of flattening, I chose to feed Cristo.txt, "The Count of Monte Cristo" into ::chopper(), thinking a beginner trying to do a triple- buffered dictionary search with look-ahead branch prediciton and tri-state return taking variable buffer in sizes ought to result in some significant progress or useful code snippets for use in an AI shell sniffer that watches for Frank Abagnal while allowing for routine use of the computer by authorized users; thwarting DIK - 'Dorothy in Kansas' blunders by failure to sit on hands. base_p at termination: 7631232 // * const to base of buffer dict_p at termination: 7798800 // * const to base of dictionary file_p at termination: 8798244 // setvbuf(fp_,file_p,_IOFBF, page_size) // sliding window, moveable pointer into buffer buf_ at termination: 7631232 // dictionary pointer: should equal base_p + (count * sizeof(int)) dic_ at termination. 7802478 // word delimiters encountered. word_count at termination: 420 /*===to do this, I should track end points during cut and paste===*/ Sliding window end point at termination: 7635328 Dictionary end point at termination: 8798224 File buffer end point at termination: 8802340 /*===and keep a loop count, to see if it makes sense ===*/ Loop called 1 times at termination. So far, so good: 1680 equal to 1680 At least the dictionary pointer is not off the deep end. But I just went deep trolling in an open channel with a world-class coder, complaining that my debugger blew out .. it must be that I fixed something right before I ran off with my test results.... Let me guess, been there / done that ..... right ? Okay, here are my cast in no-write-back design decisions. I want you climb up about 1,000 feet in a P-51 WW II Mustang and shove the throttle to the dashboard so that it torques over the top to the left and cork-screw in with all six or eight wing barrels locked full on and hit me with your best shots. Let the others fall where they may on a low-level strafing run. Only Creatures from The Crystal Blue Lagoon will have followed us this far, the Shell Clowns from Boggy Muck will have fallen out long ago and will be far away. <ul> <li> 32-bit keys are sufficient - 4+ billion possible vals. <li> Save the keys, not the strings which we look for. <li> Use some type of XOR to generate those keys. <li> Write ::chopper() early, it's critical - central engine. <li> Utilize the power of the 32-bit programing model. <li> Be open to examine the work of others, where allowed. <li> Have to save the keys, known potential blunder weakness. <li> Sue B. Good at Cuttham, Burnham & Runn is watching. </ul> Now pictue me, on a 486 trying to write my first version of ::chopper() - a VERY busy expression and the first thing I do is decide to try to use STL to do it. Can you figure out where my runaway ::strlen() came from now ? Let me give you a hint: At that time, I could not code int someint; Forget about curly braces and ::printf("Hello, World."); Forget about signature for main; I was like the questor who asked: "How come it won't compile my program ? I followed all the directions. " ROFL yet ? It gets better, really better. *REALLY, REALLY* better. If Cats could talk, I could explain to Rat Trap why he doesn't know what he wants: It's in the nature of the thing. Rat Trap is a Barn Cat - that is; Spending recent months or years in an abandoned building, searching for rodents for food, native responses are at the pivot point. To shallow-run with native, survival biology at the control or pivot point, you (a person generally) have to be *completely* lunar - as in New World Order. There are so many life experiences I would like to relate, but we are in an open channel. I can speak of these matters quickly, openly and effectively with my social engineer - he in fact was the Sales Manager for a multi-billion dollar, global empire. (I like to abbreviate this as VWE - vast world empires) And could tell him about our entire conversations at an open table in a restaurant in a few words, shorthand. Easily, if it's not morning hours. Breaking deep into STL code with my runaway ::strlen(), usually less than illuminating - I knew better. I knew that whatever it was that the code was trying to do, this would be known cs that had been explored by professionals, and that they would have resorted to KISS, and that I could use this knowledge later in a hyper-threaded shell that could snag: <html> Reply to </a href="mailto:Igor.Knucleorski crimea.ussr.kgb"> Goldie Locks </a> For your Tunguskan Snake Oil Sales Kit today ! </html> to keep L:\out\exe\itc.EXE from blowing out But that's not my real security risk, my most important security risk will have been explored by Mitnik and others and be available for study in books on the bookshelf at mall bookstores. All known science, breaking into C:/wino/run and D:/clown/have/fun and so on, ad hoc, ad infinitum. My problem, revealing something of my inner-self and exposing a weakenss in the design philosopy is: <script engine="hollywood"> char Frank Abagnale as "Service Call Repairman" char Goldie Locks as "Darling Dolittle" char Sue B. Good as "Counsel of Record" char Exec D. Customer as "Really Important Customer" Scene: Executive Suite, Exec is looking at our new Global Information Security Net Exec: (silent, looking at terminal) Our people: "This new system is ......" Cut to: Front Desk, Goldie Locks is looking at door. Pan to: Abagnale, in the door: "Hi, I have a root kit. I need to clean out your computer." Goldie Locks: "The terminal's over there." Cut to: Executive Suite Sue B. Good: (mild concern on face) Exec D. Customer: (softens) Medium on: Our people Sue B. Good: "Uh, sir..." Our people: (looks at monitor, stiffens) Exec D. Customer: "I like this." Tight on Exec D. Customer: "So this system is really reliable ?" </script> Break a gut laughing ? I doubt it, we are now on known ground for me and my social engineer, with whom I could cross-cut jokes and crunching croutons and this discussion without drooling bread crumbs on my plate. But for you, this will be terra terrible, not even discussable in the open channel; because you'll already be ten shades of chartruse and thinking of cyanotic sunrise, wondering about my methods and motives, wondering if CPR will get there in time. If you aren't, be sure to let me know because we are doing real science , deep running in the Crystal Blue Lagoon at Camp Code Puppies and there will be zillions of Shell Clowns who would love for me to tell them how to prevent all this from happening. We can't. Because we live in the real world. We are writing a real-time operating system. Because we live in the real world. It operates a machine that tracks 96 bit RFID's Something that could stand up to this type of security challenge will be known computer science. But, not implemented on a world-class scale. Why ? No system cannot be broken into ? I had an insight today, because of your availment as an interlocutor, I asked myself: "Where is all of this leading up to ?" Some sort of hyper-threaded, AI implementation that will look for Frank Abagnale at the shell level. It will never happen, no known commercial entity will pay for it. So what is it I am looking for ? Thus: Recently, I had a "tightening of the temporal lobes" At a VWE, I watched Darling Dolittle lock onto a GUI that had a button flashing at a repitition rate that was straight out of a teenager's ninja psy ops manual. Textbook implementation of: "Drive 'em crazy in a matter of minutes with this really easy plans for a thought scattering device." These people believe, totally, that a four digit pin is a Personal Identification Number. They are the True Believers of Shell Ops and a'la Wienbaum, will tell us, in Toto, what to do and where to do it. Allright, lets write a system that can be recovered after one of these Darling Dolittle's has been sold a Tunguskan Snake Oil Sales Kit, and there are Fed investigators looking into pension plan chicanery.... Nicholas Jordan is an Internet Alias, I may be brave, but I'm not stupid. They are trying to build a New World Order and I don't want to be 0xdeadbeef The only dumb question is one you should have asked and didn't.
Dec 15 2005
prev sibling parent Nicholas Jordan <Nicholas_member pathlink.com> writes:
I went and looked at the website from the provided URL.

I had not expected such heavy credentials, but could clearly see that I was
dealing with someone of this caliber - I had expected more of a business end
than a scientific end.  I think you will be able to digest my last 10kb
hyper-thesis  (too much coffee, allowing exploration of unchanneled constructs)
, but to be cited by someone of your caliber will require that I put heavier
energies into grammer and spelling: 

I think I have something to contribute to the computing community, and I rest
easy that you will (in general agree) but I have never checked several of my
pages for grammer.  Please bear this in mind before citing me broadly in front
of professionals for whom this sometimes bears more weight than the content.

[what's the smiley for hair pullin ?]

I just got a call from the bookstore, the compiler book is in.

Many observers, here in the open channel, will not fully comprehend some of the
issues we discuss. As this is the environment in which I choose the work to
proceed, I have provided my true identity by email.

Please note that the email account name is it's self a password.

This may suggest to some of the more astute observers that I take much of my
rant seriously, but to you it will be proof prima facia that I do.


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

p.s - raw X-15 code would be raw binary......wouldn't it ?
Dec 16 2005
prev sibling next sibling parent Nicholas Jordan <Nicholas_member pathlink.com> writes:
In article <dnclgf$306q$1 digitaldaemon.com>, Cesar Rabak says...
Just to have feedback on this when you finish with the research in this 
book drop us a line.

[snipped]

obviously the book's market is tri-state: Category One: The astute who intends to carry on with the work in formal education or work at that grade of hacking - may well have one of the Unice already loaded, possibly even have done a kernel build or something. Value="3 months flippin burgers Burger Bitch" Category Two: Seeks to build a reliable code base by independent study or is found self in a commercial coding environment. Value="If you have the money, this book goes beside 3-Vol Knuth boxed set" Category Three: Wants books to put on bookshelf, impress visitors. Value="Go to the mall and spend your hundred elsewhere. Much better value for the money - this book is for those who value content above cover." Nick - "The only dumb question is one you should have asked and didn't"
Dec 22 2005
prev sibling parent Nicholas Jordan <nomail somemail.pit> writes:
I have thought about this and thought about this, it is remarkable
that too many people we see do not want the machine to work. Jack,
a degreed Industrial Engineer, told me not to try to program away
the idiot - which is why the posts I made here are hard to read:
Trying to program away the idiot.....

I thought the remark that I gleaned from the borderline intruder
was telling, very telling, of exactly what the problem is. At the
time of the original posts in this thread, I did not have an actual
customer. Today, I have a real design challenge, in the real world,
a real customer ... one of remarkable postitioning. I have gained
the ablility to do DES-56 and AES using Java, I even went so far as
to make available to my team lead your resources if we needed them.

The problem remains, now with a real-world run to provide
foundation for my hard to pin-down posting manner. The project was
some $25 million in overall value, we had what amounts to AES locks
on physical storage. At some point, as I knew he would, the
authority on the project ( had Total Authority ) drove past my
truck and announced: "There's no point in having keys." Which I
already knew - the ultimate challenge in IT Security appears to be
the human mind.

In an unspoken effort to achieve effectiveness in that arena, I
have chosen AI as the primary focus of my efforts now. I have
gravitated towards storing HMAC's and so on rather than keeping
actual data in persistent storage. Recent code reflects some of my
concerns:

/*
 * I waste too much time trying to write
 * comments other people can understand.
 * Correct source code is self documenting.
 */
public class LogonShell  ( Java code )

that's the first few lines on part of a supposed screen, it checks
and rejects some 800+ common aliases

I cannot find a solution, you had asked me about storing something,
probably keys or something, in persistent storage. I just cannot
get over the remark about the class 5 Data Center, I don't even
know what a class 5 Data Center is, but I sure know the problem
domain......

It would be no guess on my part that you know all too well just
exactly what trying to work this issue brings with it - and we do
not want them to get too close. Suffice it to say Control and
Insturmentation would never allow some of the coding that Business
Practices find routine. In fact, business practices have to have
some "null pointers" laying around to keep their businesses in
business. Very close in concept to obfusication in crypto.

I think we could make a market here, people with 1+ million on the
wire do not have any slack for poor protections and would have an
interest in making a traceable discovery available for business
controls....at least the survivors of the current crunch will.

I never did get very far with the compiler book, keep thinking
about this.
Dec 14 2008
prev sibling parent Nicholas Jordan <Nicholas_member pathlink.com> writes:
In article <dmvi9m$1okp$1 digitaldaemon.com>, Cesar Rabak says...
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.



Probably an advanced tool that would be beyond my comprehension right now. Like another said in present fora: <cite author="- RB"> I remain amazed at the prompt replies to me and at the hard work, intelligence and attention to detail that are evident from the dialogues in the news forum, on the part of individuals (like yourselves) who must be extraordinarily busy. </cite>
[snipped]

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ą.
 


I think we need to clarify for anyone that may be looking in that you probably hold advanced degrees, and looking at your url cited - probably have heavy-hauler equipment in all directions that is capable of chewing up a *tremendous* amount of overhead (code bloat && Translation Lookahead Buffer misses), along with deep - and I mean deep - comprehension of the inner workings of IT systems generally; Where I look, I see vast oceana of: <blockquote> (wondering what these) flags mean, and hope get it right, all on an if: "It just might work under (version),when the real objective (for this non-Computer Science person)is to get an (work done)." </blockquote>
[snipped]

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

<parenthetically> 'programm' the only disclosure of nation in what is otherwise totally flat N.A. street english - you are to be complemented on your style in open fora here.) </parenthetically> On the basis described in the Preface to: "Efficient C++: Performance Programming Techniques" - Dov Bulka, Ph.D. and David Mayhew, Ph.D. as being applications "....where execution speed is not up for negotiation." I have chosen to write in raw 'C', except when and where I can get off the fast path. Looking for "intruders" - subject to expansion to include 'non-Computer Science' efforts to fix deficiencies, and the inevitable ...... Brother, this is where it gets lengthy. I told my social engineer what I told you - just the sentence as worded in the channel, not the two or three sentences I spoke of. (Boost style guide says to use "social engineering" - so I use it here as correct jargon of field cs.) Frank can: "Experience is that marvelous thing that enables you recognize a mistake when you are in the middle of one and make the people involved think the mistake is not there." to a degree that is attained only by masters of social engineering. Better than Frank Abagnale as protrayed in "Catch Me if You Can" (from Hollywood ~ this work portrays a master of deception that is in the classics reference section of many libraries) - we often communicate non-verbally or by sublties in mood, tone and inflection of voice and choice of words under a given social environment and Frank would think... uh, oh - which Frank am I talking about! my(Frank)'s answer, as expected, (if vocalized in words) - "You don't let that happen." - was not vocalized because discussion of those matters leads to thought of those matters, then temptation. The only way to do this, in my opinion, is hash *EVERYTHING* that comes in and do a bsearch on a saved keyset
 
 Therefore, the keyset *may* need to be regenerated. 


but often searched. To hash some serial number or model number or logon attempt as it comes in on the command line or shell link can only be hidden from routine use of the platform for security purposes by doing it in "real time" i.e. faster than the keystrokes on the machine I am using can make it into the browser textarea, because by life experience: <blockquote author="ac968201 ampersand sw bell dot net"> "It is easier to kick a ten thousand pound elephant in the shins than it is to extract one's self from a mess that a Frank Abagnale has gotten going. </blockquote> Often, as discussed on the cover of Mitnik's current mall bookshelf stuffer, people are the only intrusion route; The machine cannot be broken into.
 Early, crude attempts at coding; misused or other mistake - 
mistakes which *can* propogate into untested code.
 


I saw somewhere A.C.M. after your name. This is interesting to me just now, because I was talking to the business type from Dell over the Thanksgiving holidays, and I took it as a priori that he would mention weakness of Winnie the Poo operating system, and opine with a stressed look on his face. Luckily, he had worked for the Revenue Service, and was prompted to bring this up. This is extremely fortunate for my position, over the last two days I have fleshed out my init() stubb to oh, 50 - 100 lines. It launches two threads: init()// initializes struct ___ {int a[16];int b[16];int c[16]int d[16]}; and calls _beginthread() on: Seeker();// Which uses all of b[] - to look for signatures in file headers DictionarySearch();// I guess that will use c[], all sixteen of them, to look for signature work as discussed by the style guide you cite. All of a[] will just do thread management. I guess I'll use d[] in during shutdown(); A quick look a HKEY_CLASSES_ROOT and a cursory thought of .dll hell will arrive you to the same conclusion the above cited business type arrived at with no formal degree in computer science. LOL - means nothing where I am going. ((sizeof(int)*16) eq_ sizeof(TLB cache line)) == stop "The Bourne Supremacy" malarky from taking me down,... in arenas where execution speed is not up for negotiation.
HTH

HTH='hope this helps' , figured it out.

You seem to have a sparse sense of humour in face of losing teeth.

Sometimes, the axioma upon which the process of business moves are not as axial as the managers of a given business entity would have their minions believe. Usually, they hold up. Nicholas Jordan - internet alias. //eof Mission Statement: Belvedere Computer Services: http://www.docdubya.com/belvedere/statement/index.html It is the intent of Belvedere Computer Services to find and conduct legitimate business in free markets using the skills discussed in this document.
Jan 02 2006