Re: [SLUG] C-Pointers and Perl ?
At Fri, 30 Sep 2005 07:58:22 +1000, Telford Tendys wrote: How about writing a network protocol stack. You get a packet and all you know about it is that here is a block of memory. You then have to figure out what sort of packet it is, how long it is and what structure to give it. C handles this very nicely with pointers to structures that can be cast into whatever you need. Since you dared me, here's some (untested) perl5 code that will parse a TCP header, including network byte order conversions and bitfields: my ($source, $dest, $seq, $ack_seq, $off, undef, undef, $urg, $ack, $psh, $rst, $syn, $fin, $window, $check, $urg_ptr) = unpack 'n2 N2 C B8 n3', $tcpdata; $off = 0x0F; (this is fun ;) -- - Gus -- SLUG - Sydney Linux User's Group Mailing List - http://slug.org.au/ Subscription info and FAQs: http://slug.org.au/faq/mailinglists.html
Re: [SLUG] Keeping passwords safe
quote who=Erik de Castro Lopo Does anybody have any recomendations for a program that can be used to store passwords, bank account details etc in an encrypted file? You're going to smack me for this, but... gpg? :-) - Jeff -- Ubuntu USA Europe Tour: Oct-Nov 2005http://wiki.ubuntu.com/3BT Blessed are the cracked, for they let in the light. - Spike Milligan -- SLUG - Sydney Linux User's Group Mailing List - http://slug.org.au/ Subscription info and FAQs: http://slug.org.au/faq/mailinglists.html
WAS - Re: [SLUG] Your top-ten linux desktop apps
Matthew Hannigan wrote:
On Fri, Sep 30, 2005 at 10:09:40AM +1000, O Plameras wrote:
and as C is closely bound
to hardware architecture you must have said something about these data
Actually, C is not necessarily that closely bound to hardware architecture.
The the following C program illustrates the relationship of C and
hardware architecture on
16-bit and 32-bit (Two different architectures). We cannot use 32-bit
and 64-bit (AMD) to
illustrate because the int size are the same in both. This is an
aberration for AMD CPUs, I
think.
Many documentations says that a 64-bit should really have int size=8
instead of 4
(see http://www.osdata.com/topic/language/asm/datarep.htm
-DEC VAX *16* *bit* [2 *byte*] *word*; 32 bit [4 *byte*] longword; 64
bit [8 *byte*]quadword;
132 bit [16 *byte*] octaword; data may be unaligned at a speed penalty *...*
)
There are other documentations similar to the above assertions on the net.
But check the C-codes.
#include stdio.h
struct verify {
char initials[2];
int birthdate;
};
int main(void)
{
struct verify holes;
printf (%d\n, sizeof(holes.initials[0]));
printf (%d\n, sizeof(holes.initials));
printf (%d\n, sizeof(holes.birthdate));
printf (%d\n, sizeof(holes));
return 0;
}
Given that the word-byte
In 16-bit computer = 2 bytes word the output is,
1
2
2
4
in 32-bit computer = 4 bytes word the output is,
1
2
4
8
Two things are different due to computer architecture.
1. The same struct have different memory sizes allocated.
2. The struct has no hole in 16-bit and has 2-byte hole in 32-bit
because C-compiler always
align int data types beginning at the next word byte.
The following quote is from wikipedia
(http://en.wikipedia.org/wiki/C_variable_types_and_declarations#Size)
There is some confusion in novice C programmers as to how
big these types are. The standard is specifically vague
in this area:
* A short int must not be larger than an int.
* An int must not be larger than a long int.
* A short int must be at least 16 bits long.
* A long int must be at least 32 bits long.
The standard does not require that any of these sizes are
necessarily different. It is perfectly valid, for example,
that all 3 types be 64 bits long.
--
Matt
--
O Plameras
http://www.acay.com.au/~oscarp/tutor
--
SLUG - Sydney Linux User's Group Mailing List - http://slug.org.au/
Subscription info and FAQs: http://slug.org.au/faq/mailinglists.html
Re: [SLUG] C-Pointers and Perl ?
At Thu, 29 Sep 2005 18:38:31 +1000, Oscar Plameras wrote:
Is their equivalent codes for ff in perl 6 ?
Sure, perl6 (just as in perl5) has coderefs. In fact, these can be
references to anonymous functions or dynamically created closures,
which certainly can't be done in C.
[EMAIL PROTECTED] oscarp]# cat f.c
int main(void)
{
int (*get_f())();
static int arr[] = { -1, 0, 1, 0, 2, +9, +3200, -3500 };
int *ptr, *pastend;
int (*fptr)();
pastend = arr + sizeof(arr)/sizeof(arr[0]);
for (ptr = arr; ptr pastend; ptr++)
if (fptr = get_f(ptr))
fptr(ptr);
return 0;
}
int (*get_f(ptr))()
int *ptr;
{
int is_neg(), is_pos();
static int (*cmds[])() = {
(int (*)())0,
is_neg,
is_pos
};
int index = 0;
if (*ptr 0)
index = 1;
if (*ptr 0)
index = 2;
return(cmds[index]);
}
is_neg (iptr)
int *iptr;
{
printf(%d is negative\n, *iptr);
}
is_pos (iptr)
int *iptr;
{
printf(%d is positive\n, *iptr);
}
Deliberately reproducing the structure of the C program:
#!/usr/bin/pugs
use v6;
sub get_f (Int $i) {
our @cmd is private //=
(undef, { say $^a is negative }, { say $^a is positive });
my $index = 0;
if( $i 0 ) { $index = 1 }
elsif ( $i 0 ) { $index = 2 }
return @cmd[$index];
}
my int @arr = (-1, 0, 1, 0, 2, 9, 3200, -3500);
for @arr {
my $fptr = get_f($_);
$fptr($_) if $fptr;
}
But you are choosing awkward examples around trivial numerical
operations. Basic numeric operations and branching are things C can
do quite easily (provided the numbers fit within C's types). Try
common coding needs that C can't handle easily, like string
manipulation or memory management during error recovery. Oscar, I
suggest you actually use a high level language for a while and then
try going back to C. Doing anything in C (or even java for that
matter) is just so much tedious typing.
--
- Gus
--
SLUG - Sydney Linux User's Group Mailing List - http://slug.org.au/
Subscription info and FAQs: http://slug.org.au/faq/mailinglists.html
Re: [SLUG] C-Pointers and Perl ?
Angus Lees wrote:
At Thu, 29 Sep 2005 18:38:31 +1000, Oscar Plameras wrote:
Is their equivalent codes for ff in perl 6 ?
Sure, perl6 (just as in perl5) has coderefs. In fact, these can be
references to anonymous functions or dynamically created closures,
which certainly can't be done in C.
[EMAIL PROTECTED] oscarp]# cat f.c
int main(void)
{
int (*get_f())();
static int arr[] = { -1, 0, 1, 0, 2, +9, +3200, -3500 };
int *ptr, *pastend;
int (*fptr)();
pastend = arr + sizeof(arr)/sizeof(arr[0]);
for (ptr = arr; ptr pastend; ptr++)
if (fptr = get_f(ptr))
fptr(ptr);
return 0;
}
int (*get_f(ptr))()
int *ptr;
{
int is_neg(), is_pos();
static int (*cmds[])() = {
(int (*)())0,
is_neg,
is_pos
};
int index = 0;
if (*ptr 0)
index = 1;
if (*ptr 0)
index = 2;
return(cmds[index]);
}
is_neg (iptr)
int *iptr;
{
printf(%d is negative\n, *iptr);
}
is_pos (iptr)
int *iptr;
{
printf(%d is positive\n, *iptr);
}
Deliberately reproducing the structure of the C program:
#!/usr/bin/pugs
use v6;
sub get_f (Int $i) {
our @cmd is private //=
(undef, { say $^a is negative }, { say $^a is positive });
my $index = 0;
if( $i 0 ) { $index = 1 }
elsif ( $i 0 ) { $index = 2 }
return @cmd[$index];
}
my int @arr = (-1, 0, 1, 0, 2, 9, 3200, -3500);
for @arr {
my $fptr = get_f($_);
$fptr($_) if $fptr;
}
But you are choosing awkward examples around trivial numerical
operations. Basic numeric operations and branching are things C can
do quite easily (provided the numbers fit within C's types). Try
common coding needs that C can't handle easily, like string
manipulation or memory management during error recovery. Oscar, I
suggest you actually use a high level language for a while and then
try going back to C. Doing anything in C (or even java for that
matter) is just so much tedious typing.
Thanks for that.
I know that the codes are meaningless at face value, but you
can look at it as a prototype for many programming formats. I've used
this format myself in real applications.
The use of numerics are trivial. The static array could be commands,
or something else, or could be replaced by structures.
--
O Plameras
http://www.acay.com.au/~oscarp/tutor
--
SLUG - Sydney Linux User's Group Mailing List - http://slug.org.au/
Subscription info and FAQs: http://slug.org.au/faq/mailinglists.html
Re: [SLUG] Keeping passwords safe
On Sat, Oct 01, 2005 at 11:29:56AM +1000, Erik de Castro Lopo wrote: Does anybody have any recomendations for a program that can be used to store passwords, bank account details etc in an encrypted file? There's passwordsafe: http://passwordsafe.sourceforge.net/. It was written originally by Bruce Schneier, but has long passed out of his hands. It's for windows, but see the 'related projects' link. -- Matt -- SLUG - Sydney Linux User's Group Mailing List - http://slug.org.au/ Subscription info and FAQs: http://slug.org.au/faq/mailinglists.html
[SLUG] googleearth/worldwind for linux
Some time ago I wrote: On Fri, Jul 22, 2005 at 05:28:37PM +1000, Matthew Hannigan wrote: On Fri, Jul 22, 2005 at 11:43:23AM +1000, QuantumG wrote: Well, there's no linux version available from their web site, if that's the question. [ .. ] I presume (without any evidence to back me up :-) that it will come. btw, there is an open source thingy like google earth from NASA. The catch is that it requires .NET and DirectX :-) http://worldwind.arc.nasa.gov Apparently quite a bit clunkier than google earth. It has been ported to Linux: http://ww2d.berlios.de/ -- Matt -- SLUG - Sydney Linux User's Group Mailing List - http://slug.org.au/ Subscription info and FAQs: http://slug.org.au/faq/mailinglists.html
Re: [SLUG] C-Pointers and Perl ?
Angus Lees wrote: Oscar, I suggest you actually use a high level language for a while and then try going back to C. Doing anything in C (or even java for that matter) is just so much tedious typing. I don't program anymore as a way of living. It's just one of the many in my arsenals. I know high level programming too. I wrote an entire Financial Systems for a foreign government in High Level language in Unix whilst working for a very refutable and large International Company. This was from 1985 to 1988. I work for a number of very refutable International Companies and have programmed off and on using high-level languages. I can program in perl if required but I don't consider my expertise in that field competitive. It also depends as to what you consider high-level programming. If Fortran, Cobol, PHP, etc you consider high-level my skills in these areas are still competitive. It's just that C-language is a convenient language I used to query and to illustrate many things in computers. For modelling mainly. And as well 99 percent of softwares I download from the Internet are mainly in C. I suspect most people do too. C-language is an excellent language to leverage for my kind of interest. Oh, I started by career as Assembler Programmer on IBM S/360. -- O Plameras http://www.acay.com.au/~oscarp/tutor -- SLUG - Sydney Linux User's Group Mailing List - http://slug.org.au/ Subscription info and FAQs: http://slug.org.au/faq/mailinglists.html
[SLUG] Linux Australia Episode 6 Now Available
This fortnight we talk to Con Zymaris about the Live LAMP project and have a chat with Jeff Waugh about Gnome, Ubuntu and anything else that sprang to mind at the time. http://la-pod.k-sit.com -- James Purser Chief Talking Guy - Linux Australia Update http://k-sit.com - My Blog http://la-pod.k-sit.com - Linux Australia Update Blog and Forums Skype: purserj1977 -- SLUG - Sydney Linux User's Group Mailing List - http://slug.org.au/ Subscription info and FAQs: http://slug.org.au/faq/mailinglists.html
[SLUG] LUG Roundup Episode 6 Now Available
This fortnight we chat with Chris Walker from Bundy LUG for the LUG In Focus and catch up with Alastair Horne from Townsville LUG about their Software Freedom Day activities. http://la-pod.k-sit.com -- James Purser Chief Talking Guy - Linux Australia Update http://k-sit.com - My Blog http://la-pod.k-sit.com - Linux Australia Update Blog and Forums Skype: purserj1977 -- SLUG - Sydney Linux User's Group Mailing List - http://slug.org.au/ Subscription info and FAQs: http://slug.org.au/faq/mailinglists.html
Re: WAS - Re: [SLUG] Your top-ten linux desktop apps
On Sunday 02 October 2005 10:00, [EMAIL PROTECTED] wrote: On Fri, Sep 30, 2005 at 10:09:40AM +1000, O Plameras wrote: and as C is closely bound to hardware architecture you must have said something about these data Actually, C is not necessarily that closely bound to hardware architecture. The the following C program illustrates the relationship of C and hardware architecture on 16-bit and 32-bit (Two different architectures). We cannot use 32-bit and 64-bit (AMD) to illustrate because the int size are the same in both. This is an aberration for AMD CPUs, I think. NO IT DOES NOT It shows how the compiler writer CHOOSE to implement. He'd be daft to NOT but she is not constrained, except by the basic rules (ints are not longer than longs etc) Hence no abberation is present. Likewise the POSIX C does not mandate struture alignment. James -- SLUG - Sydney Linux User's Group Mailing List - http://slug.org.au/ Subscription info and FAQs: http://slug.org.au/faq/mailinglists.html
Re: WAS - Re: [SLUG] Your top-ten linux desktop apps
James wrote: On Sunday 02 October 2005 10:00, [EMAIL PROTECTED] wrote: Likewise the POSIX C does not mandate struture alignment. The POSIX C stuff has nothing to do here with the issue if you examine the post. Read my post ! The statement was that data type is closely bound to computer architecture. Secondly, the alignment has been shown to start at the next word boundary. You cannot dispute this on 32-bit PC (intel or AMD). If you do, good luck to your programming. --- O Plameras http://www.acay.com.au/~oscarp/tutor -- SLUG - Sydney Linux User's Group Mailing List - http://slug.org.au/ Subscription info and FAQs: http://slug.org.au/faq/mailinglists.html
Re: [SLUG] C-Pointers and Perl ?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Fri, Sep 30, 2005 at 10:10:25AM +1000, Robert Collins wrote: On Fri, 2005-09-30 at 07:58 +1000, [EMAIL PROTECTED] wrote: How about writing a network protocol stack. You get a packet and all you know about it is that here is a block of memory. You then have to figure out what sort of packet it is, how long it is and what structure to give it. C handles this very nicely with pointers to structures that can be cast into whatever you need. Its straight forward in python and smalltalk. you have an array of octets, do what you need. What you don't have is something that can be pointed at a random memory region and used to bypass the type system and vm ;0 So with an array of octets you need an equation to reconstruct a 32 bit number from the array and another equation to reconstruct the octets from a number. Then you write functions something like: read_u32_from_octet_array( array, index ) -- returns u32 write_u32_into_octet_array( array, index, data ) -- updates the array ...and so on for all the different things that are going to be in the array. Excellent, you can now work on your network packets... but you have now reconstructed the entire concept of a struct and done it in explicit functions with explicit equations. Not only do you have the slowest network stack in the whole world but worse than that, you still have no type safety because if you write data from an index which is off by one and then read it back you get completely bogus data. Some of those bogus values could be packet length so when you get them wrong you read off the end of the array... Oh, goody, python and smalltalk are protected from reading off the end of the array but how is that going to help? You won't crash but will instead throw a runtime exception which is only mildly more useful than a crash. Sure, you can't have a bad pointer, and your program won't crash. On the other hand, you have to carefully juggle the array index values all the time and one mistake will still leave an unrecoverable situation. All your high level language with type protection hasn't done a thing towards improving the correctness of your final program nor has it made it any more difficult to make an error. A much better method is to do what perl does which is to treat the network packet as a binary blob and then provide special pack and unpack commands that turn a binary blob into local language constructs and then turn local language constructs back into a blob again. This is still slow, but each packet only needs to be packed and unpacked a few times. Then all the difficult magic is tied up in getting the right codes for the pack and unpack, once you get that right, the rest is reasonably stable. Mind you, if you want to handle a range of network protocols, you need a whole bunch of different pack/unpack combos that pop into action. At the end of the day though, C code to do the same thing using pointers will be smaller, faster and probably easier to read as well. - Tel -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.1 (GNU/Linux) iQIVAwUBQz9gAsfOVl0KFTApAQKvsRAAouogH1xkowFocR6MtUppt7DIn5aY2N2F 8pGUqMEnEVc61jDTzTfomU2OpGS948o97QtdSfg2owonOl5A4XjkPYESlmhmoren M9MKcHBEVz3Uo334SKjaih5rp17bpF0xFnGV7nWk5TAi1qznMlU57NE2wE34LzE5 FlbBXfceL8tctXewiRwQwFOsyb7MJp9NiFMM/l6qwE+amx+as23bUPyWYrmbjbvr fml5IQNlQbhMR2JxINHDtEkxGYUivkQQyNuBwGYfE+v8pezSKXEpWQtEP2f03D79 Wvn3aVR+JOFXwTF/XaoB7Rae/sTmY0eyBiVmlw8k8pH/jeg6Lcxl7M+atOD/jykj HRiXrIWyQ+Nj8mod6OvHvSMFNO4l93IYOXDOCNnshG3PaP9jeN/TGS8v8y2UtWzv Dm+A2iWEagwu+GAvOwMH2BzDzJKXVEdd9MtcMLXhdM9MQpGiiw2AUSqmubH32EuL KFDL9Kyzk0UYab92YgGSHiFiJe34i6Koa9uCvGhY1odPVo4X+3W+uINPUegB2Q/h viU9hLt849RMSjQjSXnAdxoCrmvcehE2oMMxGlI+d7f+KXnSkKqs1cEPr1zdeaWD /lVTaNMXukuIqkqBgxuYTU7pK/xyEXq4HUOH6TRCckvnL0oQkyAGN83ujVsKzyAh 4NHG1JJdTI4= =UQi3 -END PGP SIGNATURE- -- SLUG - Sydney Linux User's Group Mailing List - http://slug.org.au/ Subscription info and FAQs: http://slug.org.au/faq/mailinglists.html
