Uh.....so what is so special about SQL? Why are SQL worms so prevalent compared to C worms, or PHP worms, or Java worms, etc...?
OK, so SQL injection doesn't require the kind of in-depth knowledge to exploit that buffer overflows in C do, so I imagine SQL exploits might be easier to craft to begin with... but surely they're easier to spot. If you're pasting values into an SQL string instead of using named/positional parameters, you're vulnerable. That sort of thing should be much easier to do an automated search for in your source than buffer size tracking through C sources.
Also, does anyone else think the following does not make much sense: "Most [botnet hosts that perform the scans] are not running exposed SQL themselves..."? Why not "...running badly-written SQL..." or "vulnerable SQL"? Seems like a really weird choice of words.
"I don't see why an int should be 64 bits wide on a 64-bit machine."
Um, because it would make sense for an unadorned "int" to be the same size as the native integer type for any given arch. On a 64-bit arch, the native integer type ought to be 64-bits. That's what a 64-bit architecture is.
"It's not any faster; it doesn't save any cycles anywhere."
Really? There are no (and will be no) 64-bit architectures where working with 32-bit ints isn't slower (due to needing to mask the value, or correctly do overflow, or...) than 64-bit ints? What about when 128-bit arches come out? Will using a 32-bit "int" still make sense then? 64-bit arches are not just x86-64...
"[long long] was created because people needed integers longer than 32 bits."
And "long" is perfectly capable of being defined as 64-bit and dealing with that need. But no-one defines "long" as 64 bits. Why might that be?
"long long was added to create an integer which is at least 64 bits in size."
Yes, but long long was not invented by the C99 standards committee. It originated as a proprietary extension in compilers (I think GCC had it first) as there was/is a *lot* of code out there that does make assumptions about "int" and "long" sizes. People needed to start using 64-bit integers, but the compiler folks couldn't alter "long" to do that as all the existing code that relies on "long" being 32-bit would break.
Yes, all that code does make bad assumptions that are not backed up by the C standard. Yes, that sucks. But, being the pragmatists that they are, compiler vendors still realised that if they (never mind how legitimately) changed those assumptions and broke users code, users would not upgrade to new versions of the compiler, or would just use a different compiler instead. So, the compiler vendors added "long long" as a workaround.
A large part of the job of the C99 standardisation committee (and the C89 committee) was to codify existing practice as much as possible and to break as little existing code as possible. "long long" going into it is a result of this. The exact defintion is what it is in order to be inline with code that was already out there. "int[foo]_t" is their (much more rational, IMO) attempt to codify other existing practice (plenty of people define their own fixed-size data types) and make the language more future-proof. What happens when they want to add 128-bit numbers to the standard? Would you prefer that "long long long int" be added? Or does int128_t make a bit more sense?
And I think your function will fuck up if char is 16-bits. You'll put 8-bits of x into each of 4 16-bit chars, and then write out 4 16-bit bytes, making 64 bits in total written. Whereas fwrite(&x, sizeof(x), 1, f) would still work if x was an int32_t on a system with 16-bit bytes. (For values of "work" that do not include endianness issues:-)
Uh, how about for reading and writing binary data formats?
How about struct sockaddr_in, which uses a u_int16_t? Or struct in_addr which uses a u_int32_t? Or struct sockaddr_in6?
How about describing structs to read ELF headers into? You'd probably want a number of these to read and write (for example) 32 and 64 bit executables on not-necessarily-native architectures if you want to play with them. What about JPG or PNG headers?
Not all people who design binary file formats are "giant dumbasses who write integers directly to binary files" - they *need* to specify the sizes of fields in the format so that portable readers/writers can be written that work on multiple platforms. Text formats are kind of interesting, but they're not useful in *all* circumstances.
Previously, all programs pretty much needed their own autoconf or other deep magic/wizardry to probe the system they're being compiled on and generate their own typedefs for these types. Which is a lot of work and prone to fuckups. Having standardised names for these types is entirely sensible for the legitimate cases where they are needed.
And as far as I'm concerned, long long is more of a fuck up than the named types. The only reason that's there is to support dumbasses who assumed that short is 16 bits, int is 32 bits and long is 32 bits, and whose shitty code would break if any of these changed.
But this does remind me of one good use for the fixed types though. IMO, of 64-bit systems, int should be 64 bits. long therefore ought to be 128 bits. What about short? Hmmm....probably 32 bits. Now what if you need 16-bit integers? e.g. as a struct member for loading binary data. Or as a means to parsing UTF-16 (or UCS-2) text? Sure, you could use char[2] and then convert it/them yourself to and from 32-bit shorts, but that's going to be a real pain. Much easier to just use an int16_t.
Really, if you want to ensure 64 bits, you should use int64_t. Unless you might be porting to systems that don't have 64-bit ints, but might have other longer ints which would suffice, in which case use int_least64_t. Of course, if you just want as big an int as the architecture can handle, use intmax_t.
Sorry, Wine doesn't run on my Linux/PPC or my Linux/Sparc systems or my NEO1973. Got any other ideas for opening those documents on Linuxen other than Linux/x86-32?
I have that. But it's not "the latest version of flash", or 100% fully compatible with it. Yet.
Yes, the developers are doing great work, and I have a lot of respect for them, and I couldn't ask for anything more from them given the hurdles and reverse-engineering they're having to surmount. But if the BBC is requiring "the latest version of Flash" then swfdec (or Gnash) just can't cut it at this time.
"Let's put it this way: if you need to ask a lawyer whether what you do is "right" or not, you are morally corrupt. Let's not go there. We don't base our morality on law."
Why have a leap hour in 600 years time? Surely it would be easier for all countries to just change their local time offset to UTC by 1 hour. So, for example, instead of Pacific time being UTC-0800/UTC-0700, it would become UTC-0700/UTC-0600. (Or maybe 0900/0800)
Sorry, I'm a huge Debian fan (I run Sid on all my systems) but I feel forced to point out that even they do not support releases for 6 years. 6 years ago the current release was Potato, released in August 2000. Neither that, nor Woody released in July 2002, are still supported by Debian. Sarge, released in June 2005, will likely only be supported for another 6 months until April 2008 if the Debian Security FAQ on release lifespan[0] is accurate.
Yes, there are upgrade paths to new versions of Debian, but they also exist from old to new versions of Windows.
OK, that statement has been retracted. But Mozilla have got serious security bugs analysed, fixed, QA tested on 3 different platforms, and out to tens of millions of customers within a week of the report being filed. And they're not getting paid for it.
That depends. I have a couple of friends who do have a fair amount of leisure time. They work part-time by choice, about 15-20 hours per week, in fairly low-paying jobs. They make enough to cover the rent, food and bills, and have a bit left over for entertainment.
They don't have *that* much left over; they don't have plasma TVs or huge CD/DVD collections, and they don't need to maintain a car due to a) a decent and relatively inexpensive public transport system in their area, and b) being close enough to most of the places they go on a regular basis to walk most of the time. And they don't have huge apartments. But they don't need much left over, as they don't need any of those things. They're pretty active members of the local library, and sort out a fair amount of their own entertainment. One is a hobbyist composer/musician, the other roleplays in a number of games, GMing one or two of them.
So, they don't work that much, and the jobs they do aren't that demanding (they're university graduates) and they don't let the jobs get to them. If they get much hassle about "not being involved" they just move on to something similar. There are plenty of those kinds of jobs around.
And they're happy.
You can live healthily and happily in a modern technological society without working 35-hour weeks. It's just that most people don't because they're keeping up with the Joneses and want all the latest shiny that they don't really need.
Meh. If you've got nanotech, why not create mechanical solid-state memory? According to [Drexler] pp. 366, you ought to be able to get, conservatively, 10^21 bits/cm^3 (a billion terabytes/cm^3) with a nanoscale mechanical mass-storage system, and better seek times than a traditional HD.
[Drexler] Nanosystems: Molecular machinery, manufacturing and computation; Drexler, K. Eric; 1992.
"if you manually edited any files (probably/etc/X11/xorg.conf, if you did) then you may want to make a backup copy of them"
You shouldn't need to do this, as dpkg (the program at the heart of the package management/upgrade process) will do it for you. After an upgrade you should see a ".dpkg-old" version of the configuration file alongside the new one. So, for X, inside/etc/X11 you'll have an "xorg.conf" and an "xorg.conf.dpkg-old". You can then just see what the differences are, or use diff(1), or whatever.
No, the P-members that voted in September are the ones who will get to decide at the Ballot Resolution Meeting next year. If it happens. While this means that no demoted P-members can be kicked off, it also means that no new P-members can be added to that meeting. Which might have been a bigger problem if MS had kept bribingrejuvenating countries that have had no previous interest in standards setting.
That's utter crap! The point of de jure standards - the kind produced by ISO, where "a standard" is "a specification" - is to *prevent* monopolies, by providing a common specification that *anyone*, as opposed to a single company, can implement. This allows purchasers to pick from multiple interoperable suppliers of goods, providing competition, and reducing the chances that monopolies will form.
(Note, this is different from de facto standards, which use the word "standard" in the context of "it is standard" simply means "common" or "widespread". The.doc file format is an example. It is standard. It is not a standard. Also, de jure standards may well become de facto standards, but the reverse does not hold.)
NTSC/PAL being TV standards that mean that Disney, ABC, HBO, etc... all transmit TV in the same way, and that Sony, Phillips, Samsung, etc... can all receive it from any of these. If Disney transmitted in a secret, non-standardised format and required you to purchase a Disney TV to view Disney channels, they'd have a monopoly on TV sales from anyone who wanted to watch Disney on TV.
You could use almost any standard in any field of engineering for the same argument. I'd be hard pressed to find any that support yours. Name 5... no, 3 - name 3 de jure standards that have enabled or supported monopolies. Go on.
It seems to me that it would be worth the trouble to mechanize startup so that each step is isolated from all the others and knows which previous step it's dependent on and waits for only that step, while everything else cruises ahead in parallel.
how many of us really have the wherewithal to make an architecture jump from x86?
Um, anyone running Debian. I recently changed (painlessly) from x86 to x86-64 (AMD64), but I'd be just as happy if the hardware were cheap and easily available to go to Sparc, Alpha, PPC or ARM.
Even things like Cygwin only emulate [fork() on Windows] with threads.
Sorry, but that's bollocks.
Cygwin fork() does create a new process. It calls CreateProcess() and then copies the current process into the new one. See the relevant Cygwin API FAQ for a full explanation.
Slashdot Mirror
Uh.....so what is so special about SQL? Why are SQL worms so prevalent compared to C worms, or PHP worms, or Java worms, etc...?
... but surely they're easier to spot. If you're pasting values into an SQL string instead of using named/positional parameters, you're vulnerable. That sort of thing should be much easier to do an automated search for in your source than buffer size tracking through C sources.
OK, so SQL injection doesn't require the kind of in-depth knowledge to exploit that buffer overflows in C do, so I imagine SQL exploits might be easier to craft to begin with
Also, does anyone else think the following does not make much sense: "Most [botnet hosts that perform the scans] are not running exposed SQL themselves..."? Why not "...running badly-written SQL..." or "vulnerable SQL"? Seems like a really weird choice of words.
"I don't see why an int should be 64 bits wide on a 64-bit machine."
...) than 64-bit ints? What about when 128-bit arches come out? Will using a 32-bit "int" still make sense then? 64-bit arches are not just x86-64...
:-)
Um, because it would make sense for an unadorned "int" to be the same size as the native integer type for any given arch. On a 64-bit arch, the native integer type ought to be 64-bits. That's what a 64-bit architecture is.
"It's not any faster; it doesn't save any cycles anywhere."
Really? There are no (and will be no) 64-bit architectures where working with 32-bit ints isn't slower (due to needing to mask the value, or correctly do overflow, or
"[long long] was created because people needed integers longer than 32 bits."
And "long" is perfectly capable of being defined as 64-bit and dealing with that need. But no-one defines "long" as 64 bits. Why might that be?
"long long was added to create an integer which is at least 64 bits in size."
Yes, but long long was not invented by the C99 standards committee. It originated as a proprietary extension in compilers (I think GCC had it first) as there was/is a *lot* of code out there that does make assumptions about "int" and "long" sizes. People needed to start using 64-bit integers, but the compiler folks couldn't alter "long" to do that as all the existing code that relies on "long" being 32-bit would break.
Yes, all that code does make bad assumptions that are not backed up by the C standard. Yes, that sucks. But, being the pragmatists that they are, compiler vendors still realised that if they (never mind how legitimately) changed those assumptions and broke users code, users would not upgrade to new versions of the compiler, or would just use a different compiler instead. So, the compiler vendors added "long long" as a workaround.
A large part of the job of the C99 standardisation committee (and the C89 committee) was to codify existing practice as much as possible and to break as little existing code as possible. "long long" going into it is a result of this. The exact defintion is what it is in order to be inline with code that was already out there. "int[foo]_t" is their (much more rational, IMO) attempt to codify other existing practice (plenty of people define their own fixed-size data types) and make the language more future-proof. What happens when they want to add 128-bit numbers to the standard? Would you prefer that "long long long int" be added? Or does int128_t make a bit more sense?
And I think your function will fuck up if char is 16-bits. You'll put 8-bits of x into each of 4 16-bit chars, and then write out 4 16-bit bytes, making 64 bits in total written. Whereas fwrite(&x, sizeof(x), 1, f) would still work if x was an int32_t on a system with 16-bit bytes. (For values of "work" that do not include endianness issues
Uh, how about for reading and writing binary data formats?
How about struct sockaddr_in, which uses a u_int16_t? Or struct in_addr which uses a u_int32_t? Or struct sockaddr_in6?
How about describing structs to read ELF headers into? You'd probably want a number of these to read and write (for example) 32 and 64 bit executables on not-necessarily-native architectures if you want to play with them. What about JPG or PNG headers?
Not all people who design binary file formats are "giant dumbasses who write integers directly to binary files" - they *need* to specify the sizes of fields in the format so that portable readers/writers can be written that work on multiple platforms. Text formats are kind of interesting, but they're not useful in *all* circumstances.
Previously, all programs pretty much needed their own autoconf or other deep magic/wizardry to probe the system they're being compiled on and generate their own typedefs for these types. Which is a lot of work and prone to fuckups. Having standardised names for these types is entirely sensible for the legitimate cases where they are needed.
And as far as I'm concerned, long long is more of a fuck up than the named types. The only reason that's there is to support dumbasses who assumed that short is 16 bits, int is 32 bits and long is 32 bits, and whose shitty code would break if any of these changed.
But this does remind me of one good use for the fixed types though. IMO, of 64-bit systems, int should be 64 bits. long therefore ought to be 128 bits. What about short? Hmmm....probably 32 bits. Now what if you need 16-bit integers? e.g. as a struct member for loading binary data. Or as a means to parsing UTF-16 (or UCS-2) text? Sure, you could use char[2] and then convert it/them yourself to and from 32-bit shorts, but that's going to be a real pain. Much easier to just use an int16_t.
Really, if you want to ensure 64 bits, you should use int64_t. Unless you might be porting to systems that don't have 64-bit ints, but might have other longer ints which would suffice, in which case use int_least64_t. Of course, if you just want as big an int as the architecture can handle, use intmax_t.
Sorry, Wine doesn't run on my Linux/PPC or my Linux/Sparc systems or my NEO1973. Got any other ideas for opening those documents on Linuxen other than Linux/x86-32?
Tag should be "setec astronomy", not "ctec astronomy"
I have that. But it's not "the latest version of flash", or 100% fully compatible with it. Yet.
Yes, the developers are doing great work, and I have a lot of respect for them, and I couldn't ask for anything more from them given the hurdles and reverse-engineering they're having to surmount. But if the BBC is requiring "the latest version of Flash" then swfdec (or Gnash) just can't cut it at this time.
"This means that Windows, Mac and Linux users can stream programs on iPlayer as long as their computer has the latest version of Flash."
So, we're just waiting on Adobe to release Flash for Linux/x86-64, Linux/PPC, Linux/Alpha, Linux/Sparc, Linux/ARM, etc...
*tumbleweed rolls by...*
Yeah, right. Thought so.
After all, it's not like there aren't truly cross-platform streaming formats out there. Oh no, wait, there are!
Aaaaaarrrghhhhh!!!!
AND STOP SAYING "LINUX" WHEN YOU MEAN LINUX/X86-32 . Linux is *so* much more than Linux/x86-32.
It's one of the reasons I run Linux -
"Let's put it this way: if you need to ask a lawyer whether what you do is "right" or not, you are morally corrupt. Let's not go there. We don't base our morality on law."
-- Linus Torvalds
Sorry, but as this is an English village it would never have sidewalks anyway. TFA should have said that the roads are too narrow for pavements.
Why have a leap hour in 600 years time? Surely it would be easier for all countries to just change their local time offset to UTC by 1 hour. So, for example, instead of Pacific time being UTC-0800/UTC-0700, it would become UTC-0700/UTC-0600. (Or maybe 0900/0800)
Sorry, I'm a huge Debian fan (I run Sid on all my systems) but I feel forced to point out that even they do not support releases for 6 years. 6 years ago the current release was Potato, released in August 2000. Neither that, nor Woody released in July 2002, are still supported by Debian. Sarge, released in June 2005, will likely only be supported for another 6 months until April 2008 if the Debian Security FAQ on release lifespan[0] is accurate.
Yes, there are upgrade paths to new versions of Debian, but they also exist from old to new versions of Windows.
[0] http://www.debian.org/security/faq#lifespan
"10 Fucking days"
-- Mike Shaver.
OK, that statement has been retracted. But Mozilla have got serious security bugs analysed, fixed, QA tested on 3 different platforms, and out to tens of millions of customers within a week of the report being filed. And they're not getting paid for it.
"Technology hasn't increased leisure time."
That depends. I have a couple of friends who do have a fair amount of leisure time. They work part-time by choice, about 15-20 hours per week, in fairly low-paying jobs. They make enough to cover the rent, food and bills, and have a bit left over for entertainment.
They don't have *that* much left over; they don't have plasma TVs or huge CD/DVD collections, and they don't need to maintain a car due to a) a decent and relatively inexpensive public transport system in their area, and b) being close enough to most of the places they go on a regular basis to walk most of the time. And they don't have huge apartments. But they don't need much left over, as they don't need any of those things. They're pretty active members of the local library, and sort out a fair amount of their own entertainment. One is a hobbyist composer/musician, the other roleplays in a number of games, GMing one or two of them.
So, they don't work that much, and the jobs they do aren't that demanding (they're university graduates) and they don't let the jobs get to them. If they get much hassle about "not being involved" they just move on to something similar. There are plenty of those kinds of jobs around.
And they're happy.
You can live healthily and happily in a modern technological society without working 35-hour weeks. It's just that most people don't because they're keeping up with the Joneses and want all the latest shiny that they don't really need.
Meh. If you've got nanotech, why not create mechanical solid-state memory? According to [Drexler] pp. 366, you ought to be able to get, conservatively, 10^21 bits/cm^3 (a billion terabytes/cm^3) with a nanoscale mechanical mass-storage system, and better seek times than a traditional HD.
[Drexler] Nanosystems: Molecular machinery, manufacturing and computation; Drexler, K. Eric; 1992.
"if you manually edited any files (probably /etc/X11/xorg.conf, if you did) then you may want to make a backup copy of them"
/etc/X11 you'll have an "xorg.conf" and an "xorg.conf.dpkg-old". You can then just see what the differences are, or use diff(1), or whatever.
You shouldn't need to do this, as dpkg (the program at the heart of the package management/upgrade process) will do it for you. After an upgrade you should see a ".dpkg-old" version of the configuration file alongside the new one. So, for X, inside
Ahem.
No, the P-members that voted in September are the ones who will get to decide at the Ballot Resolution Meeting next year. If it happens. While this means that no demoted P-members can be kicked off, it also means that no new P-members can be added to that meeting. Which might have been a bigger problem if MS had kept bribingrejuvenating countries that have had no previous interest in standards setting.
That's utter crap! The point of de jure standards - the kind produced by ISO, where "a standard" is "a specification" - is to *prevent* monopolies, by providing a common specification that *anyone*, as opposed to a single company, can implement. This allows purchasers to pick from multiple interoperable suppliers of goods, providing competition, and reducing the chances that monopolies will form.
.doc file format is an example. It is standard. It is not a standard. Also, de jure standards may well become de facto standards, but the reverse does not hold.)
... no, 3 - name 3 de jure standards that have enabled or supported monopolies. Go on.
(Note, this is different from de facto standards, which use the word "standard" in the context of "it is standard" simply means "common" or "widespread". The
NTSC/PAL being TV standards that mean that Disney, ABC, HBO, etc... all transmit TV in the same way, and that Sony, Phillips, Samsung, etc... can all receive it from any of these. If Disney transmitted in a secret, non-standardised format and required you to purchase a Disney TV to view Disney channels, they'd have a monopoly on TV sales from anyone who wanted to watch Disney on TV.
You could use almost any standard in any field of engineering for the same argument. I'd be hard pressed to find any that support yours. Name 5
No, but they do measure up as being very corrupt according to the CPI.
/. article.
See in particular the previous
Of course, that could just be a complete coincidence. No, really.
We're working on it...
Um, anyone running Debian. I recently changed (painlessly) from x86 to x86-64 (AMD64), but I'd be just as happy if the hardware were cheap and easily available to go to Sparc, Alpha, PPC or ARM.
Doh. the relevant API FAQ.
Sorry, but that's bollocks.
Cygwin fork() does create a new process. It calls CreateProcess() and then copies the current process into the new one. See the relevant Cygwin API FAQ for a full explanation.
See also - Unskilled and unaware of it - How difficulties in recognising one's own incompetence lead to inflated self-assessments