> Why the hell is *anyone* still using strcat in distributed software, for instance?
Blanket statements like this (and like "Goto is evil") do nothing to help improve the quality of software as we know it. strcat() is not evil. Using strcat on uncontrolled/unmonitored input on buffers whose memory allocation we are unsure of IS.
I have actually seen code like this in real production software:
s = malloc(strlen(a) + strlen(b) + 1);
strncpy(s, a, strlen(a));
strncat(s, b, strlen(b));
return s; }
Not only is this patently wasteful -- the strn* functions unnecessarily checking bounds AND the extra strlen() calls [depending on optimization] -- but it generates buggy code! For the string to be valid, s[strlen(a) + strlen(b)] must "just happen" to be zero.
ACK!
That error is caused by juvenile programmers thinking that "strcat is evil", which in turn suggests that "strncat is good".
Re:This is sort of cool, but...
on
Lego Logic Gates
·
· Score: 1
> It's EASY to make multi-state mechanical devices.
Yes, but his representation for digits were the concepts "push", and "pull". It's a LOT easier to build a mechanical device which knows the different between "push" and "pull" than it is build one that knows about 10 different dowel positions.
Re:Before one gets too enthused...
on
Lego Logic Gates
·
· Score: 1
> There's nothing like WIRES that can carry mechanical motion > without lots of mechanical inertia.
Actually, *that* particular problem could be addressed by making use of hydraulic fluid lines.
Actually, that might also solve the amplification problem, the same as the master cylinder / brake cylinder in a typical piston (disc) brake system. Although 1LOTD tells me I'm missing something, because that sounds suspiciously like free energy.:)
It *does* mean at the very least that buffers could be built -- "power brakes".
> due to being constantly exposed to your/you're and similar constructs, > I feel its quality has definitely decreased.
When proof reading, mentally expand all contractions (e.g. you're becomes you are), replace there with here, and replace your with his. If the sentence still makes sense, you're good to go.
I use the same types of tricks in french, expanding "a" to "avoir" and seeing if it changes the sense of the sentence (although that particular trick DOES mean you're proofing with mentally incorrect grammar).
Only their punctuation will get worse. Predictive-text systems are much faster to use than the push-push-push method, but require spelling skills in order to be useful. Unfortunately, these systems additionally complicate the entry of punctuation symbols.
The device you describe is very interesting -- and you're right -- using a PC is a very hackish solution. But for the basement hacker, it's doable today (well, in a week of evenings assuming you're competent C programmer familiar with the termios interface and Asterix or something similar).
> Given that they make money when calls terminate off their network it > will take some enterprising hardware hacker to build and market this device.
If there are any enterprising hardware hackers out there, Wavecom makes a 'WISMO' module which (I think) is available as a single ASIC that does everything I've described the WMO2 as doing. That would make a good starting point -- it's a full GSM phone on a chip with I/O lines instead of buttons and a screen. I'm not sure how the voice side is handled, but I'm pretty sure the chip encodes/decodes it as audio instead of just fobbing off the GSM data stream.
(googling..)
Hey, the WISMO Quick looks pretty interesting -- it's not an ASIC but it's tiny and designed to be plugged into a slot. There is also a CDMA version!
It's 58 x 32 x 6.5mm and weighs 11g. That's uh, about 2.25 x 1.5 x 0.25 inches and less than half an ounce for you 'mericans out there.:)
Let's see.. Definately does voice, has a 60 pin board-to-board connector with microphone and speaker i/o, pins for a GSM SIM, and seems to support the same AT command set as the WMOD2 (serial interface from 300 to 115.2kbps). So in theory, you could prototype/POC with the WMOD2 and a PC, then scale down to a WISMO Quick-based embedded device.
Compiled BASIC is (about) as fast as compiled C -- for equally well-written code.
The notable exception is garbage collection. But, with the advent of decent garbage collection research over the last N-years, that really isn't much of a problem any more.
I just realized "regular telephone" carries some caveats. "Regular telephone handset" would be more like it. I'm not sure the WMO2 would be happy if your VoIP gear threw 48VDC at it.
That said -- there must be software VoIP which can work from sound card inputs. I'll bet you could plug the WMO2 microphone/speaker signals into your sound card and have a WMO2+software solution with no extra hardware.
That's it's common application (and what I use it for), but according to the docs, you can also place voice calls with it and have access to call setup/completion info. If you get the right cable, it has a voice plug on it (the DB15 on the unit has DB9 serial, microphone and speaker pins).
So, you need to plug the WMO2 into an FXS(O? -- I'm not into VoIP) port, and have the computer control both pieces of hardware at once... i.e. receive the call on cellular, place a VoIP call, and a manage call completion. The WMO2 would be plugged into the VoIP gear as it were a regular telephone.
You could also go the other way (although I have no idea why you'd want to transfer a VoIP call to the cellular network).
Not the most elegant solution, but definately workable with COTS hardware.
Oh -- and you can run the WMO2 off the 12V line of your PC's power supply if you're trying to make something small. You can also extend the antenna easily, since it's just a coaxial connection to a whip.
> but when someones does a reverse lookup to my IP, nothing happens.
Look at your allocation through ARIN. Your IP needs to be assign to you, or remote DNS servers won't know where to look for your IP number!
204.8.140.181 -> Netrange 204.8.136.0 - 204.8.143.255 is assigned to Southwest Nineteen Networks and IN PTR resolution goes through
NameServer: NS1.EXO.COM NameServer: NS2.EXO.COM..so either you need to get your IP number/range allocated to you (fat chance), or you need to get exo.com to update their reverse DNS with your info.
> Is it now possible to put Sun's funky new filesystem straight into > Linux, or does someone have to rewrite it?
Solaris uses a VFS, and I suspect Linux does, too. Given that all the low-level access is probably abstracted as svr4 streams and that Linux probably abstracts their low-level access (they'd be fools not to!!!!) away from their filesystem implementations, I'd hazard guess saying that you could probably port zfs over to Linux by:
1. Writing the appropriate VFS glue 2. Writing Linux I/O svr4 streams compatible API 3. Tweaking anything unportable in zfs
Of course, these are all guesses.
If you don't know what a VFS is, read the docs in the Samba sources. Best explanation I've read yet.
> This is an interesting concept but what is really needed is a device > that provides cellular service but is a black box that allows interfacing to a phone system.
A Wavecom WMO2 could be made to do this without a lot of heartache. Long story short, it's a GSM cell phone.. except instead of a keypad and a screen, it has a serial port. And instead of a speaker and a microphone, it has a modular male end, like you plug into a standard telephone handset.
> He's one of those guys who'll rewrite 500 lines of code because he found somewhere he can > shave a millisecond of processing time out. > (Yeah, that's a bit obsessive, but I admire the dedication.)
The funny thing is, those guys are usually very counterproductive in real life. If he's not profiling his code to determine *where* it's slow, going for the micro-optimizations will yield almost no gain (and sometimes anti-gain!). It's much more effective to re-think your overall algorithm, toss around 50 lines of code and watch your software run twice as fast than it is to try and squeeze every last little bit of speed (for only that test case!) out of a 500 line routing which runs 1 percent of 1 percent of the program's system time.
Slashdot Mirror
> Why the hell is *anyone* still using strcat in distributed software, for instance?
Blanket statements like this (and like "Goto is evil") do nothing to help improve the quality of software as we know it. strcat() is not evil. Using strcat on uncontrolled/unmonitored input on buffers whose memory allocation we are unsure of IS.
I have actually seen code like this in real production software:
char *xyz(const char *a, const char *b)
{
char *s;
s = malloc(strlen(a) + strlen(b) + 1);
strncpy(s, a, strlen(a));
strncat(s, b, strlen(b));
return s;
}
Not only is this patently wasteful -- the strn* functions unnecessarily checking bounds AND the extra strlen() calls [depending on optimization] -- but it generates buggy code! For the string to be valid, s[strlen(a) + strlen(b)] must "just happen" to be zero.
ACK!
That error is caused by juvenile programmers thinking that "strcat is evil", which in turn suggests that "strncat is good".
This code is correct, AND cheaper;
char *xyz(const char *a, const char *b)
{
char *s;
if (!(s = malloc(strlen(a) + strlen(b) + 1))
return NULL;
strnpy(s, a);
strcat(s, b);
return s;
}
of course, being the huge Apache Runtime fan that I am, I would write something like this myself in most "real" cases:
char *xyz(apr_pool_t *pool, const char *a, const char *b)
{
return apr_pstrcat(pool, a, b, NULL);
}
> It's EASY to make multi-state mechanical devices.
Yes, but his representation for digits were the concepts "push", and "pull". It's a LOT easier to build a mechanical device which knows the different between "push" and "pull" than it is build one that knows about 10 different dowel positions.
> There's nothing like WIRES that can carry mechanical motion
:)
> without lots of mechanical inertia.
Actually, *that* particular problem could be addressed by making use of hydraulic fluid lines.
Actually, that might also solve the amplification problem, the same as the master cylinder / brake cylinder in a typical piston (disc) brake system. Although 1LOTD tells me I'm missing something, because that sounds suspiciously like free energy.
It *does* mean at the very least that buffers could be built -- "power brakes".
No kidding.
With push and pull as 1 and 0, I could make a D-type flip-flop from a piece of scotch tape.
> US could pressure problem countries such as China
> to crack down on businesses that abuse email
> and/or the company number.
Let me get this straight. You expect a government which can't stop China's human rights abuses to stop e-mail abuse?
What are you smoking, and can I have some??!
> tara reid (who is that?)
http://www.big-boys.com/articles/reidslip.html
Make sure you scroll all the way down.
Time Warp? WTF?
> due to being constantly exposed to your/you're and similar constructs,
> I feel its quality has definitely decreased.
When proof reading, mentally expand all contractions (e.g. you're becomes you are), replace there with here, and replace your with his. If the sentence still makes sense, you're good to go.
I use the same types of tricks in french, expanding "a" to "avoir" and seeing if it changes the sense of the sentence (although that particular trick DOES mean you're proofing with mentally incorrect grammar).
Only their punctuation will get worse. Predictive-text systems are much faster to use than the push-push-push method, but require spelling skills in order to be useful. Unfortunately, these systems additionally complicate the entry of punctuation symbols.
(ref: Tegic T9, Motorola iTAP, etc)
> and where would they get the money to pay him the millions M$ probably will?
They could pretend to want to run an NYT article again...
Wes
So, do all ham call signs start with VE3, or do you live around here somewhere?
> if it turns out the problem is Samba was built linked against the
> OpenLDAP libs instead of iPlanet libs
You wouldn't be the first person to do this.
Anyhow, "ldd <binary>" will list exactly which (shared) libraries a given binary has been linked against.
The device you describe is very interesting -- and you're right -- using a PC is a very hackish solution. But for the basement hacker, it's doable today (well, in a week of evenings assuming you're competent C programmer familiar with the termios interface and Asterix or something similar).
:)
> Given that they make money when calls terminate off their network it
> will take some enterprising hardware hacker to build and market this device.
If there are any enterprising hardware hackers out there, Wavecom makes a 'WISMO' module which (I think) is available as a single ASIC that does everything I've described the WMO2 as doing. That would make a good starting point -- it's a full GSM phone on a chip with I/O lines instead of buttons and a screen. I'm not sure how the voice side is handled, but I'm pretty sure the chip encodes/decodes it as audio instead of just fobbing off the GSM data stream.
(googling..)
Hey, the WISMO Quick looks pretty interesting -- it's not an ASIC but it's tiny and designed to be plugged into a slot. There is also a CDMA version!
It's 58 x 32 x 6.5mm and weighs 11g. That's uh, about 2.25 x 1.5 x 0.25 inches and less than half an ounce for you 'mericans out there.
Let's see.. Definately does voice, has a 60 pin board-to-board connector with microphone and speaker i/o, pins for a GSM SIM, and seems to support the same AT command set as the WMOD2 (serial interface from 300 to 115.2kbps). So in theory, you could prototype/POC with the WMOD2 and a PC, then scale down to a WISMO Quick-based embedded device.
Compiled BASIC is (about) as fast as compiled C -- for equally well-written code.
The notable exception is garbage collection. But, with the advent of decent garbage collection research over the last N-years, that really isn't much of a problem any more.
I just realized "regular telephone" carries some caveats. "Regular telephone handset" would be more like it. I'm not sure the WMO2 would be happy if your VoIP gear threw 48VDC at it.
That said -- there must be software VoIP which can work from sound card inputs. I'll bet you could plug the WMO2 microphone/speaker signals into your sound card and have a WMO2+software solution with no extra hardware.
> Looks like WMO2 only does messaging
That's it's common application (and what I use it for), but according to the docs, you can also place voice calls with it and have access to call setup/completion info. If you get the right cable, it has a voice plug on it (the DB15 on the unit has DB9 serial, microphone and speaker pins).
So, you need to plug the WMO2 into an FXS(O? -- I'm not into VoIP) port, and have the computer control both pieces of hardware at once... i.e. receive the call on cellular, place a VoIP call, and a manage call completion. The WMO2 would be plugged into the VoIP gear as it were a regular telephone.
You could also go the other way (although I have no idea why you'd want to transfer a VoIP call to the cellular network).
Not the most elegant solution, but definately workable with COTS hardware.
Oh -- and you can run the WMO2 off the 12V line of your PC's power supply if you're trying to make something small. You can also extend the antenna easily, since it's just a coaxial connection to a whip.
> but when someones does a reverse lookup to my IP, nothing happens.
..so either you need to get your IP number/range allocated to you (fat chance), or you need to get exo.com to update their reverse DNS with your info.
Look at your allocation through ARIN. Your IP needs to be assign to you, or remote DNS servers won't know where to look for your IP number!
204.8.140.181 -> Netrange 204.8.136.0 - 204.8.143.255 is assigned to Southwest Nineteen Networks and IN PTR resolution goes through
NameServer: NS1.EXO.COM
NameServer: NS2.EXO.COM
> Is it now possible to put Sun's funky new filesystem straight into
> Linux, or does someone have to rewrite it?
Solaris uses a VFS, and I suspect Linux does, too. Given that all the low-level access is probably abstracted as svr4 streams and that Linux probably abstracts their low-level access (they'd be fools not to!!!!) away from their filesystem implementations, I'd hazard guess saying that you could probably port zfs over to Linux by:
1. Writing the appropriate VFS glue
2. Writing Linux I/O svr4 streams compatible API
3. Tweaking anything unportable in zfs
Of course, these are all guesses.
If you don't know what a VFS is, read the docs in the Samba sources. Best explanation I've read yet.
> This is an interesting concept but what is really needed is a device
> that provides cellular service but is a black box that allows interfacing to a phone system.
A Wavecom WMO2 could be made to do this without a lot of heartache. Long story short, it's a GSM cell phone.. except instead of a keypad and a screen, it has a serial port. And instead of a speaker and a microphone, it has a modular male end, like you plug into a standard telephone handset.
They were robots?
> Doing better requires intimate insider knowledge, which no one has on any appreciable scale.
Except Martha Stewart.
> He's one of those guys who'll rewrite 500 lines of code because he found somewhere he can
> shave a millisecond of processing time out.
> (Yeah, that's a bit obsessive, but I admire the dedication.)
The funny thing is, those guys are usually very counterproductive in real life. If he's not profiling his code to determine *where* it's slow, going for the micro-optimizations will yield almost no gain (and sometimes anti-gain!). It's much more effective to re-think your overall algorithm, toss around 50 lines of code and watch your software run twice as fast than it is to try and squeeze every last little bit of speed (for only that test case!) out of a 500 line routing which runs 1 percent of 1 percent of the program's system time.
> Dr Spock? You're kidding, right?
He must be -- he's quoting Yoda.
> Wil, yet I also never found myself admiring you
;)
> until I began to read your blog
Dude, you're late to the game.
Wil worked on the Video Toaster. Yes, that Video Toaster. The freakin' Video Toaster !!!
That's about four quadrillion times cooler than any ol' blog.
> Uhhhh, we only support Windows. I don't think this computer can connect to the Internet.
.com"
A support technician of suspect intelligence once told me (and I quote): "I'm sorry sir, Suns don't work on the internet".
This was a Sun Enterprise 150 server; about 1999 -- when every third commericial on TV was "Sun: we're the dot in