Okay, I'll admit, it was my bad. I wasn't thinking about it. I failed to strip companyname/companyname out of a log I was
sending. E-mail policy about sending login information is clearly all we have to protect our servers.
skztr
@skztr
Best posts made by skztr
Latest posts made by skztr
-
Please don't send login information over e-mail!
-
RE: War on right clickers, tides have turned!
@Cloaked User said:
...There is currently no technical way to prevent people from simply saving it and using it as they see fit, but that neither makes it legal nor makes the picture public property...
The real wtf has been identified.
-
RE: The best encryption ever
@newfweiler said:
@RandomPoster said:
With my limited knowledge of COBOL:
PIC 99999 is an integer of length 5, so 12345
PIC 9(5) is an integer with a length of 5
PIC 999.99 is a double with two decimal places and takes up 6 characters, so 123.45
PIC 999V99 is a double with two decimal places but the decimal is assumed, so 12345 would actualy be 123.45
I don't know much about COMP fields
Now, Strings are represented by PIC X
PIC X is one character
PIC X(9) is 9 characters
I don't really know much about the language itself, just the way data is stored (COBOL CopyBooks)
PIC [or PICTURE] 99999 is a string of length 5, with characters constrained to decimal digits, so "12345". It represents a decimal integer. It can be converted to a binary integer, a decimal integer, a binary fixed-point number, a decimal fixed-point number, or a binary floating-point number. USAGE is DISPLAY by default. USAGE DISPLAY means that it is a string of [ASCII or EBCDIC or UTF-8 or whatever] characters.
PIC 9(5) is the same as PIC 99999.
PIC 999.99 is a string of length 6, consisting of 3 decimal digits, a decimal point, and two decimal digits. It represents a fixed-point decimal rational number in the range 000.00 through 999.99. It can be converted to a binary or decimal fixed-point number or a binary floating-point number. This format is usually used to convert from a binary or decimal number in order to print it with the decimal point.
PIC 999V99 is a string of length 5 consisting of 5 decimal digits with an implied decimal point. It represents a fixed-point decimal rational number in the range 000.00 through 999.99. This format is usually used for input, to be converted to a binary or decimal number.
PIC AAAAA is a string of length 5, with characters constrained to letters of the alphabet. It cannot be converted to a number.
PIC XXXXX is a string of length 5, of any characters at all. It cannot be converted to a number.
COMP [or USAGE COMPUTATIONAL] specifies that the data is a number stored in a form that can be used for arithmetic. The exact representation is implementation-defined. On the IBM 370, COMP is binary fixed-point, COMP-1 is short-precision floating point, COMP-2 is long-precision floating point, and COMP-3 is binary coded decimal fixed-point.
Note that some of these representations are not available on all hardware and must be partially simulated in software. COBOL requires up to 18 decimal digits of precision. The IBM 370 has binary integer arithmetic up to 31 bits plus sign but not binary fixed-point. Larger numbers and radix point calculations must be handled by library routines. COMP-1 and COMP-2 are native floating-point format. The IBM 370 has fixed-point binary coded decimal arithmetic up to 15 decimal digits; larger numbers must be handled by library routines. Most microprocessors do not have native fixed-point binary coded decimal arithmetic.
COMPUTE is a verb in a procedural statement, as "COMPUTE A = B + C."
COMPUTATIONAL is a USAGE option in a data statement, as "77 FOO PICTURE IS 99999 USAGE IS COMPUTATIONAL."
1) O_o.. thanks
2) You mean there's a LONGER way to type these things?!
-
RE: The best encryption ever
actually they converted to and from a pic9something into a pic9something comp-3, something like that. EMP is part of a huge-ass structure (as is everything, including the temporary variables and the encrypt constant), and nobody uses COMPUTE, though I don't know why. I assume the pic9 <-> comp3 conversion and lack of compute is all done for performance reasons, as unlike most of the transformations in this file, this one was /not/ arbitrarily dropping decimal places
-
The best encryption ever
Porting some transformation routines for a major insurance company, I came across a novel encryption algorithm. I can tell it's an encryption algorithm because the comment says so:
[code]
*
* Code added to decrypt emp
*
[/code]Not wanting to copy and paste all the copybooks involved to truly appreciate the intricacies of this complex and ultra-secure scheme, I'll translate the COBOL into C for you:
[code]
if (emp > 0)
emp -= ENCRYPT_CONSTANT;
[/code]
(I love how COBOL gets people to turn that into 7 lines with 2 temporary variables, but that's COBOL's wtf, not the insurance company's)Bonus points if you can figure out what "emp" stands for. It's not "employee". Meanwhile, not knowing COBOL, I don't actually know what happens when emp is less than ENCRYPT_CONSTANT (which it can very easily be)
-
RE: MySQL Bug Report WTF
"Overlapping" doesn't mean they have the same start/end points. I in no way meant to imply that.
But in this case, you only got the "overlapping" error because every now and then it was trying to copy data on top of itself. Were it merely "overlapping" that might be a separate issue, but here we can clearly see that this is a case of a source and destination column being the same thing. Were they not the same thing, they would not overlap.
-
RE: MySQL Bug Report WTF
I guess I should clarify:
"The solution" == "The solution used"
Changing memcpy(TheSamePointer, TheSamePointer, 1); to memmove(TheSamePointer, TheSamePointer, 1); is stupid no matter what db you're using.
-
MySQL Bug Report WTF
While looking for something else, I ran across this:
http://bugs.mysql.com/bug.php?id=12194A short summary:
Someone noticed valgrind was reporting an overlapping memcpy.
The warning clearly shows the problem being memcpy(Pointer, EquivalentPointer, 1);
The solution? Of course! Use memmove() instead, since it allows overlapping pointers.
WTF's include:
Why are you copying the same data on top of itself in the first place?
Why are you modifying your code to suppress what (by chance) is a valid warning?
Even if you knew it to not be valid, why modify it in that way anyway, since memcpy(TheSamePointer, TheSamePointer, Anything); can't ever effect anything anyway? (yeah, they overlap.. but oh no! you might copy parts of the destination (which is the source) on to the destination, instead of the source (which is the destination) on to the destination!)
Valgrind showing things in somebody else's library is always annoying, yeah. But wtf?