Return Styles: Pseud0ch, Terminal, Valhalla, NES, Geocities, Blue Moon.

Pages: 1-4041-8081-

What will this output?

Name: Anonymous 2016-06-19 12:21

What will this program output?
Good luck, you'll need it!

#include <iostream>
using namespace std;

int main() {
class c {
public:
c() {
void f();
f();
}
};

c my_c();
}

void f() {
cout << "VALID C++" << endl;
}

The answer is absolutely nothing because c my_c(); is a fucking function declaration.

Name: Anonymous 2016-06-19 12:23

Can we just consider all of C harmful already and call it a day?

Name: Anonymous 2016-06-19 13:38

>>2
Don't try to blame C for your shortcomings, Sepples.

Name: Anonymous 2016-06-19 13:50

Check em

Name: Cudder !cXCudderUE 2016-06-19 16:13

If it can be parsed as a function declaration, it will be. You can't claim to know C++ if you don't know this.

Name: AiHasBeenSolved 2016-06-19 20:42

The Perl AGI http://ai.neocities.org should output a thought stemming from only a limited set of sources: an idea stored in the knowledge base; a new idea generated by logical inference; or a sentence generated as the expression of information arriving from the senses, as for example when the AGI is describing what it sees in a visual scene. There should be no random and potentially erroneous associations from random subject to random verb and to random object.

As we start coding ghost163.pl and we simply press [Enter] with no input to see what output results, the EnNounPhrase() module defaults to 701=I as a subject. Immediately a t=753 $verblock is found which locks the AI into an output of "I HELP KIDS" from the innate knowledge base. Currently the SpreadAct() module is being called from EnNounPhrase() when the AI outputs the 528=KIDS direct object, but perhaps the call should wait until after ReEntry() inserts the idea into the moving front of the knowledge base.

The output of a thought, even from memory, is the result of spreading activation and should not lead to more spreading activation until the same thought becomes a form of input during ReEntry(). There must be some way to delay the calling of SpreadAct() until a new-line or [Enter] is registered. In OldConcept() we could set the $actpsi with the $oldpsi value, but not call SpreadAct() until the end of the input or re-entry.

We have created a new $quapsi variable "by which" the final noun ($psi) from InStantiate() can go into SpreadAct() from the ReEntry() module and possibly spread activation to pertinent knowledge in the knowledge base of the AI memory.

Name: /cudder/ 2016-06-20 0:09

/cudder/

Name: Anonymous 2016-06-20 0:37

>>6
We have created
Shut the fuck up, you don't have any people who care about you or would even remotely want to work with you. Fuck off, Mentishit, you're a waste of oxygen.

Name: Anonymous 2016-06-20 11:45

Check em

Name: Anonymous 2016-06-20 19:49

> void f() {
> cout << "VALID C++" << endl;
> }

Name: Anonymous 2016-06-20 19:53

You're declaring a function, my_c(), that returns a class of type c. What's the problem?

Furthermore, why would you use the class keyword at all? C++ is fine if you just use it like a better version of C and ignore the class-oriented programming paradigm.

Name: Anonymous 2016-06-20 20:28

What will this program output?
Good luck, you'll need it!

int main(void) {
"VALID C";
}

The answer is absolutely nothing because >>1 is a baka

Name: Cudder !cXCudderUE 2016-06-28 11:24

#include <stdio.h>
int foo() { return 0xe-2; }
int bar() { return 0xf-2; }
int main() {
printf("%u %u\n", foo(), bar());
return 0;
}

Name: Anonymous 2016-06-28 11:35

>>13
foo.c: In function ‘foo’:
foo.c:2:20: error: invalid suffix "-2" on integer constant
int foo() { return 0xe-2; }
^

Name: Anonymous 2016-06-28 11:47

>>12
>>13
>>14
What programming language is this?

Name: Anonymous 2016-06-28 13:35

>>15
One that can't even optimise!

Name: Cudder !cXCudderUE 2016-06-29 12:27

>>14
12 13
This is where MSVC wins for not following the retardedness of the standards committee.

Name: Cudder !cXCudderUE 2016-07-09 5:40

Everyone complaining about how C++ is so hard to parse is missing something so bloody simple it makes you feel stupid for not seeing it when you finally do.

The "if it can be parsed as a declaration, it is a declaration" rule is probably a direct consequence of the early C++ parsers simply trying to parse a declaration first, then an expression-statement if the declaration doesn't work.

Maybe years of academia has turned language researcher's brains into indoctrinated mush, as in fact C++ parsing is very straightforward with a variant of recursive-descent.

Here's a classic "C++ parsing is hard!" example:

int(x), y, *const z; // declaration
int(x), y, new int; // expression-statement

The academics claim you need "infinite" lookahead to parse those correctly, because there can be arbitrarily many tokens before it knows which path to take. Bullshit. All you need to do is "fork" the current thread whenever there are multiple matches and feed the incoming tokens to all the active "threads", and when one can't proceed any further, it terminates. If there are no more threads, that's an error. When you reach the ';', take the AST formed by the first (which if you arranged things correctly, will be the one that went down the declaration path) and/or only thread, and you're done. You don't even need to build the AST for both paths if you're really optimising for space - just record which path is the right one and go back to build the AST.

If you're somewhat knowledgeable of (but not indoctrinated by) the theory, that strategy should seem very familiar:

https://swtch.com/~rsc/regexp/regexp1.html

It's just like Thompson's NFA algorithm, except each state transition is the RD parser "swallowing" a token, and that can be done in constant time, so the parse is still linear in the length of the input.

Name: Anonymous 2016-07-09 6:05

>>18
So just a nigger-rigged version of breadth-first search? Lrn2code, fudder.

Name: Anonymous 2016-07-09 13:27

Check em

Name: Anonymous 2016-07-09 13:32

Cudder is a coalburner!

Name: Anonymous 2016-07-09 16:02

>>18
The academics claim you need "infinite" lookahead to parse those correctly, because there can be arbitrarily many tokens before it knows which path to take. Bullshit. All you need to do is "fork" the current thread whenever there are multiple matches and feed the incoming tokens to all the active "threads", and when one can't proceed any further, it terminates. If there are no more threads, that's an error.
So, infinite lookahead.

Name: Cudder !cXCudderUE 2016-07-09 16:47

>>22
Does matching regular expressions require "infinite lookahead"? No. Or maybe they'll claim it does, but ultimately it doesn't make a gnat's arse of difference. In the end, parsing C++ (and other ambiguous grammars) is not that hard. It's the other stuff like templates which is a little harder.

>>21
The term is "coal roller", dimwit.

Name: Anonymous 2016-07-09 16:48

>>18
What is int(x), y, *z;? Does it declare a pointer z? Or does it apply the * operator to z?

Name: Cudder !cXCudderUE 2016-07-09 17:33

>>24
"If it can be parsed as a declaration, it will be."

You tell me.

Name: Anonymous 2016-07-09 18:24

Check em

Name: Anonymous 2016-07-09 20:09

C-dder is all talk and no action.

Name: Anonymous 2016-07-10 3:52

>>23
It requires infinite lookahead to prove certain things. You haven't gotten around that. Your solution is just declaring a convention to be the correct one. You can't "solve" the halting problem by giving it a finite time to run and then just assuming that it doesn't halt.

Name: Anonymous 2016-07-10 3:54

Cuddork is a backpedalling idiot who won't admit to the stupidity he blatantly displays.

Name: Anonymous 2016-07-10 4:37

Cuckdurr will never do anything useful with his life

Name: Anonymous 2016-07-10 7:33

>>24
The comma notation means the int is 'distributed' to each item in the comma-delimited list. So the last item in the list is really int *z. Which means the * is interpreted as the pointer declaration operator, as the dereference operator is a unary operator and multiplying a typename by an undeclared identifier doesn't make sense.

>>28
An infinite lookahead algorithm should halt on all inputs. The number of threads (equal to the number of possible interpretations at the current stage of parsing) and the size of the input are both finite, so every thread will eventually halt either by its interpretation ceasing to be possible or by reaching the end of the input. Even if the ambiguity cannot be resolved (two or more threads survive to the end of input), it still halts.

Name: Cudder !cXCudderUE 2016-07-10 15:35

>>28
What the hell do you need to "prove" anyway. I claimed C++ parsing wasn't all that hard, and once you understand how it works, it really isn't. If you applied the same reasoning you'd probably claim the Thompson NFA algorithm needs "infinite lookahead" too, and yet AFAIK no one has ever said that.

>>31
as the dereference operator is a unary operator and multiplying a typename by an undeclared identifier doesn't make sense.

It could've been declared in an outer scope. If you want to really cast x to an int, read y and throw its value away (which is perfectly acceptable and the compiler would have to do it if it was declared volatile, and then apply unary operator*() to z, then you would need to do this:

(int(x), y, *z);

Type specifiers cannot start with a parenthesis, so the parser is immediately going to go down the expression path.

>>29,30
U MAD?

Name: Cudder !cXCudderUE 2016-07-10 15:38

>>31
And since there is a constant number of operations done on each token input, the overall running time is still linear in the length of the input.

That is probably not going to be the case if you introduce templates, however.

Name: Anonymous 2016-07-10 15:44

Check em

Name: Anonymous 2016-07-10 16:09

>>34
Check what?

Name: Anonymous 2016-07-10 22:16

>>32
You claim that nothing is hard, that you can implement everything in plain asm in just a few days, and actually deliver nothing. Just shut the fuck up already.

And since there is a constant number of operations done on each token input, the overall running time is still linear in the length of the input.

No it's not, you fucking ignoramus. See
>>18
All you need to do is "fork" the current thread whenever there are multiple matches and feed the incoming tokens to all the active "threads"

Name: Anonymous 2016-07-11 3:09

>>36
You shouldn't expect anything from one who only talks without backing it up with action.

Name: Anonymous 2016-07-11 3:25

>>36,37
Isn't "linear time" generally used to mean "every thread runs in linear time or better" in the context of multi-threading?

Name: Anonymous 2016-07-11 5:18

>>38
No it doesn't, you double-fucking double-ignoramus.

Name: Cudder !cXCudderUE 2016-07-11 10:10

>>36
The number of active threads cannot exceed a small constant.

Name: Anonymous 2016-07-11 15:46

>>38,39
Regardless, doesn't multithreading have no effect on efficiency class in most situations, since the number of threads is finite and thus increases speed by at most a constant multiple for a given input?

Name: Anonymous 2016-07-11 19:30

>>41
All computer resources are finite, dumbass.

Name: Anonymous 2016-07-11 20:29

>>42
So do you think C++ isn't Turing complete then? A real Turing machine has unbounded memory, since what distinguishes it from other models of computation is that it has an infinite number of possible states.

Name: Anonymous 2016-07-11 20:34

Distinguish these dubs

Name: Anonymous 2016-07-11 21:57

>>43
What a load of utter fuckheads. You in particular, shit-for-brains, don't know the different between Turing Complete and a Turing Machine.

Everybody who's posted in this thread, except me, must be killed.

Name: Anonymous 2016-07-11 22:11

Check em

Name: Anonymous 2016-07-11 22:14

Check em

Name: Anonymous 2016-07-11 22:59

>>45
Turing complete means able to simulate any single-taped Turing machine. And I was memeing, C++ actually IS Turing complete because the language itself places no limit on the available memory. But the language specification is just a theoretical ideal, any actual implementation of the language will not be truly Turing complete because the hardware limits available memory. You can write code in C++ to simulate a universal Turing machine, but there will always be some Turing machine that is impossible to simulate because there isn't enough memory. Some Turing machines actually do require infinite memory (though these are by definition non-halting, but not all non-halting TM's require infinite memory), and since the largest positive number less than infinity is unbounded, for any physical computer there will exist some halting Turing machine which it does not have sufficient memory to simulate.

Name: Anonymous 2016-07-11 23:00

>>46
>>47
Are you even trying?

Name: Anonymous 2016-07-12 2:43

>>48
Because I/O exists, the size limitations of memory have nothing to do with simulating a Turing machine. Do you faggots even fucking think?

Name: Anonymous 2016-07-12 3:04

>>50
What does I/O have to do with it? Are you talking about writing to removable disks and using that as your "infinite memory"? Even if you are, the total number of removable disks available to write to is still finite. Even if we could use the entire universe as our data storage medium at say 1 exabyte per atom, there are still some Turing machines that we'd be unable to simulate.

Name: Anonymous 2016-07-12 4:01

>>50,51
For all practical purposes, we don't need any system to implement the "infinite tape" part of the universal Turing machine. Such machines are still considered Turing complete.

Name: Anonymous 2016-07-12 4:23

>>52
No actual Turing complete computational device has ever been created. Turing completeness is really only meaningful to measure the expressiveness of languages. Saying a language is Turing complete means the set of algorithms it can describe is at least equal to the set of algorithms that can be executed by a Turing machine. But there are some such algorithms that cannot be executed on any real computer.

Name: Anonymous 2016-07-12 20:43

>>53
But there are some such algorithms that cannot be executed on any real computer.

Name one.

Name: Anonymous 2016-07-12 21:06

>>55
Travelling salesman.

Name: Anonymous 2016-07-13 0:30

>>54
Outputting an infinite list of 1's.

Name: Anonymous 2016-07-13 1:35

>>55

Some traveling salesman problems can be solved by a computer, but no physical computer is TS-complete (i.e. able to solve any arbitrary version of the traveling salesman problem). This is because, for any given algorithm, as the number of cities approaches infinity, so does the memory required. Of course, some algorithms are more memory-efficient than others, but even so, eventually the input alone will exceed available memory.

However, generally speaking the TSP is viewed as time-limited, not memory-limited. Pretty much ANY problem will require infinite memory as input size goes to infinity, so TSP doesn't really stand out in that regard. Where it does stand out is in having O(n!) time efficiency for the brute force case.

Name: Anonymous 2016-07-13 7:26

All threads will be replied to.

Name: Anonymous 2016-07-13 13:34

>>58

NO EXCEPTIONS

Name: Anonymous 2016-07-13 13:48

>>56
while(1){
output(1);
}

Name: Anonymous 2016-07-13 14:52

>>60
Any real computer will run out of memory to store all those 1's eventually. The LANGUAGE is Turing complete (since it can describe any algorithm that can run on a Turing machine), but no hardware truly is.

Name: Anonymous 2016-07-13 17:48

>>61
Pipe it to /dev/null. Infinite 1 generation achieved.

Name: Anonymous 2016-07-13 21:28

>>62
But that means you can't actually get the entire output. That's like saying
#include <string>
int main() {
string aString = "Hello World!";
return 0;
}
is a valid Hello World program.

Name: Anonymous 2016-07-13 22:32

>>63
You can't get the output of lambda terms either, but lambda calculus is respected among the LGBT community.

Name: Anonymous 2016-07-13 23:22

>>19
Note that 'thread' doesn't necessarily mean thread in the operating system sense.
This is the general idea of how a good regex engine works though.

Name: Anonymous 2016-07-13 23:31

>>65
Obviously. Well, to everybody but Cudder, I guess.

Name: Anonymous 2016-07-13 23:31

>>23
Is reading to the end of the subject string required for regular expressions?

Not all of them but obviously yes for some you fucking moron.

Name: Anonymous 2016-07-14 3:14

>>65
But true multithreading is needed if you want it to run in better than linear time.

Name: Anonymous 2016-07-14 7:12

>>68
I don't think threading on reasonable consumer hardware would bring it down to less than linear time anyway.

Name: Cudder !cXCudderUE 2016-07-14 10:49

>>67
Completely missed the point "you fucking moron". So what? I don't see anyone complaining that matching regular expressions is hard...!

>>65
That's why "thread" is in quotes. Coroutines would be far better for this than actual threads.

>>68
It's not possible to be better than linear since the whole program needs to be parsed. Actual multithreading will at best improve performance by a constant factor.

Name: Anonymous 2016-07-14 13:17

>>70
Cudder give me your Kik, I want a chat with you.

Name: Anonymous 2016-07-14 18:14

Cudder loves nigger dick!

Name: Anonymous 2016-07-14 21:51

>>72
[citation needed]

Name: Anonymous 2016-07-14 22:21

>>73
Every post on this board from Cudder is citation enough that he craves the negro penis.

Name: Anonymous 2016-09-08 19:37

>>36
Are you seriously claiming that using multithreading means the parser doesn't run in linear time? That's like saying Hello World runs in O(n!) since the number of computers it can run on at once is unbounded.

>>54
The following program will run indefinitely on a Turing machine, but will terminate due to OOM on any real computer
int main(void) {
unsigned char *ptr;
while(1) {
ptr = malloc(sizeof(char));
*ptr = 255;
}
return 0;
}

Name: Anonymous 2016-09-08 20:39

but will terminate due to OOM on any real computer
This is wrong, ptr may either be garbage collected at the end of each loop, malloc may return null and you cause UB or the compiler may as well optimise it and only keep the while(1).
On shitty systems the program may be killed by OOM.

Name: Anonymous 2016-09-08 20:58

>>76
I chose C because it's not a garbage collected language, and I assumed use of a non-optimizing compiler. And yes, I'm aware that malloc returns null when OOM, however wouldn't assigning a value to a null pointer cause the program to crash?

Name: Anonymous 2016-10-28 2:35

What will this program output?

#include <stdio.h>

int squareprompt(void);

int x = squareprompt();

int main(void) {
puts("GOODBYE, CRUEL WORLD!");
return 0;
}

int squareprompt(void) {
int n, r;
input:
printf("PLEASE ENTER A POSITIVE INTEGER: ");
scanf("%d", &n);
if (n < 0) goto input;
r = n * n;
printf("SQUARE OF THE NUMBER YOU ENTERED IS %d.\n", r);
return r;
}

Name: Anonymous 2016-10-28 9:01

>>78 Intuitively i think it would be rejected since statics cannot inited from functions. This is the actual result: http://codepad.org/2gpwf0SQ

Name: Anonymous 2016-10-28 11:36

>>77
it's not a garbage collected language
The standard allows it to be.

and I assumed use of a non-optimizing compiler
You assume many things.

however wouldn't assigning a value to a null pointer cause the program to crash?
Its UB

Name: Anonymous 2016-10-28 15:54

>>80
The standard allows it to be.
It doesn't require it to be. So any code which depends on GC cannot be said to be standard-conforming.

You assume many things.
It's a valid assumption because we're talking about algorithms, not implementations. So it's assumed the compiler generates the "most literal interpretation" of the source code.

Its UB
Again, according to "most literal interpretation", a null pointer would be interpreted as pointing to a non-valid memory address. Meaning that assignment would cause a segfault on a system with memory protection. Not all implementations may exhibit this behavior, but again we are talking about algorithms, not implementations. In any case, we could eliminate this issue by revising the program to

int main(void) {
unsigned char *ptr;
while(1) {
ptr = malloc(sizeof(char));
if(ptr) {
*ptr = 255;
} else return 1;
}
return 0;
}

Which means, assuming no optimization, and no GC, this program will exit with an exit code of 1 on any real computer, while on a Turing machine it should keep looping forever (since having unbounded memory means there is really no logical reason for a call to malloc() to fail).

Name: Anonymous 2016-10-29 17:27

Checking dubs

Name: Anonymous 2016-10-29 21:46

>>81
So any code which depends on GC cannot be said to be standard-conforming.
Programs don't need to depend on GC for an implementation to use GC.

It's a valid assumption because we're talking about algorithms, not implementations
We are not however.

Meaning that assignment would cause a segfault on a system with memory protection
The standard does not contain the world ``segfault''.

but again we are talking about algorithms, not implementations
And again, we are not. We are talking about the standard and what implementations are allowed to do.

} else return 1;
Are you aware that 1 might not stand for EXIT_FAILURE on some implementations?

Which means, assuming no optimization, and no GC
Again, many assumptions.

Name: Anonymous 2016-10-29 22:25

>>84
We are not however.
[citation needed]

The standard does not contain the world ``segfault''.
It doesn't have to. This is an OS issue, not a C Standard issue. Regardless of what language your program is written in, accessing illegal memory is a segmentation fault.

Are you aware that 1 might not stand for EXIT_FAILURE on some implementations?
And I'm not assuming that it is. Neither EXIT_SUCCESS == 0 nor EXIT_FAILURE == 1 is guaranteed by the standard; however anything that isn't either EXIT_SUCCESS or 0 should be interpreted as indicating failure.

Again, many assumptions.
Those assumptions were chosen to simplify the discussion of the algorithm.

Name: Anonymous 2016-10-30 1:45

>>84
Regardless of what language your program is written in, accessing illegal memory is a segmentation fault.
You're assuming the computer has memory protection.

Sometimes the computer will give you whatever is at that address. It might not even be attached to hardware at all. It could be random bits or whatever was on the bus last.

Also, it's not always a ``segmentation fault''. Good hardware would give you a more specific error.

Name: Anonymous 2016-10-30 3:12

>>82
What dubs?

Name: Anonymous 2016-10-30 3:38

these dubs

Name: Anonymous 2016-10-30 6:38

You're assuming the computer has memory protection.
I previously specified that that was one of the assumptions being made to demonstrate my point. But here's a program that does the same thing without depending on the assumption of memory protection:

#include <stdlib.h>
#include <stdint.h>

int main(void) {
uint8_t *ptr;
while(1) {
ptr = malloc(1);
if(ptr == NULL) {
puts("MEMORY ALLOCATION FAILURE");
return EXIT_FAILURE;
}
else *ptr = 111;
}
return EXIT_SUCCESS;
}

Now I'm sure someone will find some nitpick for why this wouldn't work, but this has the same expected behavior as the previous program: on a real computer, it would return with failure result, on a Turing machine it would never exit.

This version should work even without memory protection (as on a real machine, repeated calls to malloc() without calling free() should eventually use up all available memory and cause malloc() to return a null pointer). Again, we're to assume garbage collection (if available in the implementation) is disabled, and optimization is disabled, so the machine code generated is as close to possible to the source code.

Name: Anonymous 2016-10-30 10:19

>>84
[citation needed]
Check our discussion, there was no talk about algorithms.

This is an OS issue, not a C Standard issue
Actually it's an implementation issue.

Regardless of what language your program is written in, accessing illegal memory is a segmentation fault.
And this is wrong, the implementation is free to do whatever it wants as it is UB.

however anything that isn't either EXIT_SUCCESS or 0 should be interpreted as indicating failure.
I disagree, the standard disagrees as well.

Those assumptions were chosen to simplify the discussion of the algorithm.
We are not talking about any algorithm, in fact no algorithm was posted in this thread.

>>88
on a real computer, it would return with failure result
A real compiler on a real computer is free to optimise the loop by not including any of the code inside it or gc ptr.

on a Turing machine it would never exit
Except if the implementation of malloc for some reason returned NULL.

Why are you using uint8_t? Don't you know that it is considered optional and some implementations don't or can't include it? Your code doesn't even have a need for it, you could just use char instead.

as on a real machine, repeated calls to malloc() without calling free() should eventually use up all available memory and cause malloc() to return a null pointer
This is wrong, see above.

Again, we're to assume garbage collection (if available in the implementation) is disabled, and optimization is disabled, so the machine code generated is as close to possible to the source code.
Way too many assumptions. I thought that you wanted to talk about ``real machine''s.

Name: Anonymous 2016-10-30 13:24

>>88
Now I'm sure someone will find some nitpick for why this wouldn't work, but this has the same expected behavior as the previous program: on a real computer, it would return with failure result, on a Turing machine it would never exit.
Well, the OS might be retarded. Instead of printing MEMORY ALLOCATION FAILURE it might end up invoking an OOM killer.

Name: Anonymous 2016-10-30 17:52

>>90 Errors don't help anyone and require human intervention. OOM killer is the right design, since it allows to respond to memory hogging apps fast.

Name: Anonymous 2016-12-16 1:32

What does this output?

#include <stdio.h>

int main(void) {
int C;
if(C++ == C) puts("C++ is equal to C!");
else puts("C++ is not equal to C!");
return 0;
}

Name: Anonymous 2016-12-16 11:24

>>92
operations on declared but undefined variable are technically an undefined behavior so anything could happen but on real machines C will just be treated like a valid variable containing whatever was in that particular area of memory. for simplicity, let's assume that the memory was zeroed-out (although this doesn't change anything - only thing that matters is whether the implementation does anything retarded on undefined behavior) and write an equivalent:

int C = 0; //assume a normal implementation treats C like a valid variable
int x = C++; //we introduce an additional variable for clarity
if(x == C) puts("C++ is equal to C!"); // this won't happen: x was assigned 0 and C was incremented so it's 1 (post-incrementation)
else puts("C++ is not equal to C!"); // this will happen
return 0;

so basically, on actual hardware and with a non-meme compiler, you'll see C++ is not equal to C! on stdout and the program will exit. that's for STACKBOI RETOIDS though because it relies on undefined behavior, technically it could format your HDD, burn down your house and print HAX MY ANUS to stderr and go into an endless loop and it would still conform to the standard.
Don't change these.
Name: Email:
Entire Thread Thread List
All trademarks and copyrights on this site are owned by their respective parties. All comments and posts are the responsibility of their own posters.
- Tinychan + 2ch Mode + RSS -