Unless you're using a network like iDEN that can set up direct calls, the signal will have to go all the way to the base station controller and back again. It's unlikely to go any further than that - unless one of you is roaming, in which case it has to go all the way to the home network and back again...
I remember what kind of lightbulbs we had back in 1983, and I avoid using them where possible. I save energy and money by using compact fluorescent bulbs instead.
So if it gets popular, you should buy one and do the opposite of what it suggests... until everyone figures that out, at which point you switch to doing what it says... rinse, repeat.
It's a valid shell script (though it's not always parsed by the shell) that controls compilation, so yes it is a requirement.
Re:Several lines are still in use
on
Gnumeric Turns 5
·
· Score: 1
The set should be a mathematical set, in the sense that all the variables in the array should refer to the same knowledge domain.
That's a very weird sense of "set". A mathematical set is an unordered collection with no duplicates.
No it doesn't. I defended this all along. Using
char* arg[] I'm passing by value a reference to an array of unknown size. I think its valid under standard C, and you've failed to prove me wrong.
It's valid, and I never said it wasn't, but it's inconsistent with the way every other type is passed. If you teach people that this is a way of passing arrays rather than pointers then you're misinforming them. If you're teaching C then please make sure your students know how it really works. If you're teaching programming in general then why don't you use a different language?
Re:Several lines are still in use
on
Gnumeric Turns 5
·
· Score: 1
It assumes arrays are always allocated in contigous memory
That's practically the definition of arrays.
and therefore pointer arithmetics are valid on array variables
The whole purpose of pointer arithmetic is for working with pointers to array elements! The meaning of pointer arithmetic is undefined and generally unmeaningful except within arrays. As you know, an array can be implicitly converted to such a pointer and hence participate in pointer arithmetic; this implicit conversion is allowed for compatibility with the original implementation of arrays in C.
It seems to me you are trying to express that
char* arg[] could be interpreted as the passing by reference of an array, since in parameters * means a pass by reference rather than by value. More, you seem to be saying that explicitely passing an array by reference is invalid, since arrays are always passed by reference.
C only supports call-by-value and pointers don't change that because they are created explicitly. So a parameter declaration that looks like an array declaration should declare an array parameter that's passed by value. Instead it declares a pointer parameter that's passed by value. If the function is called with an array then it's almost as if the array is passed by reference - which is inconsistent. Further, it isn't really call-by-reference - for example, sizeof(argv) returns sizeof(char**) not sizeof(char*)*argc.
Re:Several lines are still in use
on
Gnumeric Turns 5
·
· Score: 1
We prove that char* arg[] is the same as char** arg, in the context of assembly code generation.
Identical machine code proves nothing. You could change the int to long and still get the same working machine code on many platforms, but the program would be incorrect. However, I do understand that the two ways of declarating pointer parameters are equivalent. My point was that they are not equivalent when declaring any other variable. The meaning of [] in parameter declarations is an anomaly and potentially confusing.
As for the correctness of using
char** arg as opposed to char* arg[], the most I can say is that I never read of the usage of [] being deprecated in function call argument declarations. I'd thank if you if you'd give me some solid reference as to the deprecation.
I never said it was deprecated, only that it's for ancient compatibility. Originally C did not have an array type, and arrays really were just appropriately initialised pointer variables. So it sort of made sense to use [] rather than * to indicate a pointer to array. Now that means something quite different in every case except parameter declarations.
Re:Several lines are still in use
on
Gnumeric Turns 5
·
· Score: 1
When declaring a variable, char *[] is not the same as char **. The odd meaning of char * argv[] in a function declaration is there for ancient compatibility and I suspect it will only serve to confuse the novice. main does not receive an array of strings, because arrays can't be passed by value in C.
WindowsXP has a slightly better idea in that it will quick log you off if you ask it to... Of course gnome/kde stole that idea before MS was able to integrate it into XP/2k:)
Windows NT has always done this, with the limitation that only an administrator can log-off the previous user.
Re:Gnumeric _does_ support Open/StarOffice format
on
Gnumeric Turns 5
·
· Score: 1
The trouble with this is, new features in the application will often require additional data to be stored in the files. An interchange format is good for transferring lowest common denominator data, but there's still room for application-specific formats. XML-based interchange formats could be extensible (it's what the X stands for!) to allow applications to add features without making their files unreadable. This will only work as long as the extensions aren't critical to correct interpretation of the file, e.g. macros in a spreadsheet that are written in a non-standard language.
Re:Several lines are still in use
on
Gnumeric Turns 5
·
· Score: 1
There are many mainstream GTK- or GNOME-based apps without an initial G (e.g. Nautilus, Evolution, Sylpheed, Pan) and with several that do, it stands for GNU anyway (e.g. the Gimp).
stunnel can fake its address somehow when running under Linux, so the wrapped daemon sees the client address. The man page says you have to use the "transparent" option and daemon mode, but I know I had this working in inetd mode somehow.
It doesn't need to support SSL. SSL is an adapter layer for stream-based protocols - it fits in between TCP and anything that can run on top of TCP (except that I don't think out-of-band TCP messages will work).
Bels are "units" on a base-10 logarithmic scale of electrical voltage or whatever the equivalent is in sound. A decibel is of course a tenth of a bel. So doubling power makes a difference of 10*log10(2) ~= 3 dB. Since power is proportional to the square of voltage, assuming constant resistance, doubling voltage makes a difference of 10*log10(2*2) ~= 6 dB.
Yes, that's right. It will ask the OS to read just under 4GB of data from the file, which will result in reading the whole of the rest of the file into a buffer that's only a few bytes in size (the heap manager probably rounds up the 0-3 bytes to a minimum of 8 bytes). The result is that other parts of the heap get overwritten. Quite how this can reliably be exploited, I don't know.
You seem to be talking about XML namespaces. These have nothing to do with the resolution of relative URLs in attributes. What XML namespaces do is identify the semantics of some elements and attributes used in the document, and allow several sets of elements and attributes to be combined. They do have some serious problems but this is not one of them.
It's OK if you've got loads of bandwidth, but it's hardly an optimal solution.
Equally, the central mail store isn't a great idea over a WAN.
I really don't feel it needs a lot of bandwidth, but if you've got a narrow WAN connection shared between a lot of users then I see it might be a problem. In that case it seems to me that dividing or replicating mail between servers becomes necessary.
The only reason I can see for central storage of emails is for backup, which can just as easily be sorted with a mailbox into which everything is dumped on receipt.
So when a luser loses his mail, he gets back every mail he ever received, instead of the hierarchy of saved mail he had before? That would suck. Which is why clueful mail administrators clue use real mail storage solutions.
Also consider what happens when users want to switch to another mail client, e.g. web-mail or a PDA while out of the office.
I see some of my other comments have been modded down - it looks like the pro-M$ mods are on toight.
Slashdot Mirror
That would make it time for a sexual harassment suit, I think.
Unless you're using a network like iDEN that can set up direct calls, the signal will have to go all the way to the base station controller and back again. It's unlikely to go any further than that - unless one of you is roaming, in which case it has to go all the way to the home network and back again...
I remember what kind of lightbulbs we had back in 1983, and I avoid using them where possible. I save energy and money by using compact fluorescent bulbs instead.
Since cryptome is slashdotted, it might be better to go back to the source:
So if it gets popular, you should buy one and do the opposite of what it suggests... until everyone figures that out, at which point you switch to doing what it says... rinse, repeat.
Ironically TrafficGauge failed to predict congestion on its own web site.
Secondly, why is that classified as a 403 error? The problem is with the server so the error code should be 5xx.
It does affect humans, though perhaps less seriously and furthermore it is endemic. Beware of your moggy!
It's a valid shell script (though it's not always parsed by the shell) that controls compilation, so yes it is a requirement.
That's a very weird sense of "set". A mathematical set is an unordered collection with no duplicates.
It's valid, and I never said it wasn't, but it's inconsistent with the way every other type is passed. If you teach people that this is a way of passing arrays rather than pointers then you're misinforming them. If you're teaching C then please make sure your students know how it really works. If you're teaching programming in general then why don't you use a different language?
That's practically the definition of arrays.
The whole purpose of pointer arithmetic is for working with pointers to array elements! The meaning of pointer arithmetic is undefined and generally unmeaningful except within arrays. As you know, an array can be implicitly converted to such a pointer and hence participate in pointer arithmetic; this implicit conversion is allowed for compatibility with the original implementation of arrays in C.
C only supports call-by-value and pointers don't change that because they are created explicitly. So a parameter declaration that looks like an array declaration should declare an array parameter that's passed by value. Instead it declares a pointer parameter that's passed by value. If the function is called with an array then it's almost as if the array is passed by reference - which is inconsistent. Further, it isn't really call-by-reference - for example, sizeof(argv) returns sizeof(char**) not sizeof(char*)*argc.
Identical machine code proves nothing. You could change the int to long and still get the same working machine code on many platforms, but the program would be incorrect. However, I do understand that the two ways of declarating pointer parameters are equivalent. My point was that they are not equivalent when declaring any other variable. The meaning of [] in parameter declarations is an anomaly and potentially confusing.
I never said it was deprecated, only that it's for ancient compatibility. Originally C did not have an array type, and arrays really were just appropriately initialised pointer variables. So it sort of made sense to use [] rather than * to indicate a pointer to array. Now that means something quite different in every case except parameter declarations.
When declaring a variable, char *[] is not the same as char **. The odd meaning of char * argv[] in a function declaration is there for ancient compatibility and I suspect it will only serve to confuse the novice. main does not receive an array of strings, because arrays can't be passed by value in C.
Windows NT has always done this, with the limitation that only an administrator can log-off the previous user.
The trouble with this is, new features in the application will often require additional data to be stored in the files. An interchange format is good for transferring lowest common denominator data, but there's still room for application-specific formats. XML-based interchange formats could be extensible (it's what the X stands for!) to allow applications to add features without making their files unreadable. This will only work as long as the extensions aren't critical to correct interpretation of the file, e.g. macros in a spreadsheet that are written in a non-standard language.
Why do you think that is superior?
Gtk was created for and is named after GIMP.
stunnel can fake its address somehow when running under Linux, so the wrapped daemon sees the client address. The man page says you have to use the "transparent" option and daemon mode, but I know I had this working in inetd mode somehow.
It doesn't need to support SSL. SSL is an adapter layer for stream-based protocols - it fits in between TCP and anything that can run on top of TCP (except that I don't think out-of-band TCP messages will work).
You mean "Fuck Off Puritans Day" (thanks to Greg Proops).
Units on a logarithmic scale of power, even.
Bels are "units" on a base-10 logarithmic scale of electrical voltage or whatever the equivalent is in sound. A decibel is of course a tenth of a bel. So doubling power makes a difference of 10*log10(2) ~= 3 dB. Since power is proportional to the square of voltage, assuming constant resistance, doubling voltage makes a difference of 10*log10(2*2) ~= 6 dB.
Yes, that's right. It will ask the OS to read just under 4GB of data from the file, which will result in reading the whole of the rest of the file into a buffer that's only a few bytes in size (the heap manager probably rounds up the 0-3 bytes to a minimum of 8 bytes). The result is that other parts of the heap get overwritten. Quite how this can reliably be exploited, I don't know.
Pop-under adverts.
You seem to be talking about XML namespaces. These have nothing to do with the resolution of relative URLs in attributes. What XML namespaces do is identify the semantics of some elements and attributes used in the document, and allow several sets of elements and attributes to be combined. They do have some serious problems but this is not one of them.
I really don't feel it needs a lot of bandwidth, but if you've got a narrow WAN connection shared between a lot of users then I see it might be a problem. In that case it seems to me that dividing or replicating mail between servers becomes necessary.
So when a luser loses his mail, he gets back every mail he ever received, instead of the hierarchy of saved mail he had before? That would suck. Which is why clueful mail administrators clue use real mail storage solutions.
Also consider what happens when users want to switch to another mail client, e.g. web-mail or a PDA while out of the office.
Nope, you're just clueless.