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)));
 


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?
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)));
 


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


 




[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)
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...




 


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




 


[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' ?
Dec 06 2005
parent reply Cesar Rabak <crabak acm.org> writes:
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,
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...
 


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.


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.


Clearly so.

 

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.


 


[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!


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


http://www.algorithmic-solutions.com/

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






[snipped]


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.


ok.

[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... ;-)


Then you will comperehend the issues probed in my work below.

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


bookmarked.


[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


By now, I see them from fifty feet away and two days before the others make
them. That's why I post the work below, but this knowledge was aquired by the
method cited.

LOL.


I see you have experience with this, you will love my trolling below !

[snipped]

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


I work on a machine, the s-100 bus of which is corroded, accelerates mistakes.
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

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






[snipped]


Just a note, this can get convoluted.

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






[snipped]


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]


I have tried for two weekends to comprehend the book - not 'finished' ~ but
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ą.

 


[snipped]


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.
 


Yes. Been there done that. A lot.


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