Leak Memory in as few bytes as possible

Question 1

Your task is to write code that will leak at least one byte of memory in as few bytes as possible. The memory must be leaked not just allocated.

Leaked memory is memory that the program allocates but loses the ability to access before it can deallocate the memory properly. For most high level languages this memory has to be allocated on the heap.

An example in C++ would be the following program:

int main(){new int;}

This makes a new int on the heap without a pointer to it. This memory is instantly leaked because we have no way of accessing it.

Here is what a leak summary from Valgrind might look like:

LEAK SUMMARY:
 definitely lost: 4 bytes in 1 blocks
 indirectly lost: 0 bytes in 0 blocks
 possibly lost: 0 bytes in 0 blocks
 still reachable: 0 bytes in 0 blocks
 suppressed: 0 bytes in 0 blocks

Many languages have a memory debugger (such as Valgrind) if you can you should include output from such a debugger to confirm that you have leaked memory.

The goal is to minimize the number of bytes in your source.

Question 2

Perhaps you could have different ranges of amount leaked and depending on how much you leak you lose x% of your byte count

Question 3

@ChristopherPeart For one I am not a fan of bonuses on challenges and for two as you have already shown it is very easy to leak unbounded memory.

Question 4

Related. Not a duplicate, though, because most answers to that question form an infinite reachable structure in memory rather than actually leaking memory.

Question 5

what is the idea? That the mem cannot be freed? I guess this would require native execution for garbage collected languages or exploiting bugs.

Question 6

I see how languages designed for golfing fail miserably on this one ...

Question 7

Perl (5.22.2), 0 bytes

Try it online!

I knew there'd be some language out there that leaked memory on an empty program. I was expecting it to be an esolang, but turns out that perl leaks memory on any program. (I'm assuming that this is intentional, because freeing memory if you know you're going to exit anyway just wastes time; as such, the common recommendation nowadays is to just leak any remaining memory once you're in your program's exit routines.)

Verification

$ echo -n | valgrind perl
...snip...
==18517== 
==18517== LEAK SUMMARY:
==18517== definitely lost: 8,134 bytes in 15 blocks
==18517== indirectly lost: 154,523 bytes in 713 blocks
==18517== possibly lost: 0 bytes in 0 blocks
==18517== still reachable: 0 bytes in 0 blocks
==18517== suppressed: 0 bytes in 0 blocks
==18517== 
==18517== For counts of detected and suppressed errors, rerun with: -v
==18517== ERROR SUMMARY: 15 errors from 15 contexts (suppressed: 0 from 0)

Question 8

I liked the Unlambda answer, but this one is (IMHO) too much of a stretch, as it is obviously the interpreter itself which leaks the memory, i.e. I get ` definitely lost: 7,742 bytes in 14 blocks` when I run perl --version on my machine, despite it never gets to running any program, at all.

Question 9

@zeppelin: Agreed, but according to our rules, it's the implementation that defines the language, thus if the implementation leaks memory, all programs in the language leak memory. I'm not necessarily sure I agree with that rule, but at this point it's too entrenched to really be able to change.

Question 10

This also works in Node JS.

Question 11

This feels like a new standard loophole in the making...

Question 12

Finally a Perl script that I can understand.

Question 13

C, (削除) 48 31 (削除ここまで) 22 bytes

Warning: Don't run this too many times.

Thanks to Dennis for lots of help/ideas!

f(k){shmget(k,1,512);}

This goes one step further. shmget allocates shared memory that isn't deallocated when the program ends. It uses a key to identify the memory, so we use an uninitialized int. This is technically undefined behaviour, but practically it means that we use the value that is just above the top of the stack when this is called. This will get written over the next time that anything is added to the stack, so we will lose the key.

The only case that this doesn't work is if you can figure out what was on the stack before. For an extra 19 bytes you can avoid this problem:

f(){srand(time(0));shmget(rand(),1,512);}

Or, for 26 bytes:

main(k){shmget(&k,1,512);}

But with this one, the memory is leaked after the program exits. While running the program has access to the memory which is against the rules, but after the program terminates we lose access to the key and the memory is still allocated. This requires address space layout randomisation (ASLR), otherwise &k will always be the same. Nowadays ASLR is typically on by default.

Verification:

You can use ipcs -m to see what shared memory exists on your system. I removed pre-existing entries for clarity:

$ cat leakMem.c 
f(k){shmget(k,1,512);}
int main(){f();} 
$ gcc leakMem.c -o leakMem
leakMem.c:1:1: warning: return type defaults to ‘int’ [-Wimplicit-int]
 f(k){shmget(k,1,512);}
 ^
leakMem.c: In function ‘f’:
leakMem.c:1:1: warning: type of ‘k’ defaults to ‘int’ [-Wimplicit-int]
leakMem.c:1:6: warning: implicit declaration of function ‘shmget’ [-Wimplicit-function-declaration]
 f(k){shmget(k,1,512);}
ppcg:ipcs -m
------ Shared Memory Segments --------
key shmid owner perms bytes nattch status 
$ ./leakMem 
$ ipcs -m
------ Shared Memory Segments --------
key shmid owner perms bytes nattch status 
0x0000007b 3375157 Riley 0 1 0

Question 14

@AndrewSavinykh Theoretically, the shmid could have been stored in a file and a program could attach to it in the future. This is how unix shared memory works...

Question 15

@AndrewSavinykh Shared memory basically becomes a resource that the OS can give to other processes. It is similar to a file that lives in RAM and any process that knows the name (key) has access to it until it is deleted. Imagine a process that calculates a number and stores it in memory and exits before the process that reads the data connects to the shared memory. In this case, if the OS frees the memory then the second process can't get it.

Question 16

Thank you for posting this. I just protected TIO against shared memory leaks.

Question 17

@Dennis That's why I didn't post a TIO link. I didn't know if it was protected or not.

Question 18

I like how you use the word problem to describe the scenario where the program leaks less memory than intended.

Question 19

Unlambda (`c-refcnt/unlambda`), 1 byte

Try it online!

This is really a challenge about finding a pre-existing interpreter which leaks memory on very simple programs. In this case, I used Unlambda. There's more than one official Unlambda interpreter, but c-refcnt is one of the easiest to build, and it has the useful property here that it leaks memory when a program runs successfully. So all I needed to give here was the simplest possible legal Unlambda program, a no-op. (Note that the empty program doesn't work here; the memory is still reachable at the time the interpreter crashes.)

Verification

$ wget ftp://ftp.madore.org/pub/madore/unlambda/unlambda-2.0.0.tar.gz
...snip...
2017年02月18日 18:11:08 (975 KB/s) - ‘unlambda-2.0.0.tar.gz’ saved [492894]
$ tar xf unlambda-2.0.0.tar.gz 
$ cd unlambda-2.0.0/c-refcnt/
$ gcc unlambda.c
$ echo -n i | valgrind ./a.out /dev/stdin
...snip...
==3417== LEAK SUMMARY:
==3417== definitely lost: 40 bytes in 1 blocks
==3417== indirectly lost: 0 bytes in 0 blocks
==3417== possibly lost: 0 bytes in 0 blocks
==3417== still reachable: 0 bytes in 0 blocks
==3417== suppressed: 0 bytes in 0 blocks
==3417== 
==3417== For counts of detected and suppressed errors, rerun with: -v
==3417== ERROR SUMMARY: 1 errors from 1 contexts (suppressed: 0 from 0)

Question 20

TI-Basic, 12 bytes

While 1
Goto A
End
Lbl A
Pause

"... a memory leak is where you use a Goto/Lbl within a loop or If conditional (anything that has an End command) to jump out of that control structure before the End command is reached... " (more)

Question 21

Yep, most of us know the feeling ;) @RayKoopa

Question 22

+1 for Ti Basic. I spent most of my 9th grade year programming those things.

Question 23

Do you need Pause at the end? You could save 2 bytes.

Question 24

@kamoroso94 I think so, because "If a program is ended the leak is cleared and will cause no further issues", so it is to stop the program from ending.

Question 25

A simpler "leak" under these rules would be to create a program named prgmA consisting of the single command prgmA (2 bytes). This creates the same kind of "leak" (technically blowing an internal stack). Neither one is leaking "memory" in the OP's sense, and neither one is "unrecoverable" in OP's sense either (since the While "leak" can be reclaimed by hitting an End, and the infinite recursion can be stopped by... making it not-infinite) — but I don't think the OP's definitions make a whole lot of sense in non-C languages anyway. :)

Question 26

Python <3.6.5, 23 bytes

property([]).__init__()

property.__init__ leaks references to the property's old fget, fset, fdel, and __doc__ if you call it on an already-initialized property instance. This is a bug, eventually reported as part of CPython issue 31787 and fixed in Python 3.6.5 and Python 3.7.0. (Also, yes, property([]) is a thing you can do.)

Question 27

Has a bug report been sent?

Question 28

@mbomb007: CPython issue 31787.

Question 29

C#, 34 bytes

class L{~L(){for(;;)new L();}}

This solution does not require the Heap. It just needs a real hard working GC (Garbage Collector).

Essentially it turns the GC into its own enemy.

Explanation

Whenever the destructor is called, It creates new instances of this evil class as long as the timeout runs out and tells the GC to just ditch that object without waiting for the destructor to finish. By then thousands of new instances have been created.

The "evilness" of this is, the harder the GC is working, the more this will blow up in your face.

Disclaimer: Your GC may be smarter than mine. Other circumstances in the program may cause the GC to ignore the first object or its destructor. In these cases this will not blow up. But in many variations it will. Adding a few bytes here and there might ensure a leak for every possible circumstances. Well except for the power switch maybe.

Test

Here is a test suite:

using System;
using System.Threading;
using System.Diagnostics;
class LeakTest {
 public static void Main() {
 SpawnLeakage();
 Console.WriteLine("{0}-: Objects may be freed now", DateTime.Now);
 // any managed object created in SpawbLeakage 
 // is no longer accessible
 // The GC should take care of them
 
 // Now let's see
 MonitorGC();
 }
 public static void SpawnLeakage() {
 Console.WriteLine("{0}-: Creating 'leakage' object", DateTime.Now);
 L l = new L();
 }
 public static void MonitorGC() {
 while(true) {
 int top = Console.CursorTop;
 int left = Console.CursorLeft;
 Console.WriteLine(
 "{0}-: Total managed memory: {1} bytes",
 DateTime.Now,
 GC.GetTotalMemory(false)
 );
 Console.SetCursorPosition(left, top);
 }
 }
}

Output after 10 minutes:

2/19/2017 2:12:18 PM-: Creating 'leakage' object
2/19/2017 2:12:18 PM-: Objects may be freed now
2/19/2017 2:22:36 PM-: Total managed memory: 2684476624 bytes

That's 2 684 476 624 bytes. The Total WorkingSet of the process was about 4.8 GB

This answer has been inspired by Eric Lippert's wonderful article: When everything you know is wrong.

Question 30

This is fascinating. Does the garbage collector "Forget" that some things exist and lose track of them because of this? I dont know much about c#. Also now I am wondering, what is the difference between a bomb and a leak? I imagine a similar fiasco could be created by calling a constructor from inside of a constructor, or having an infinite recursing function that never stops, although technically the system never loses track of those references, it just runs out of space...

Question 31

A constructor within a constructor would cause a stack overflow. But the destructor of an instance gets called in a flat hierarchy. The GC actually never loses track of the objects. Just whenever it tries to destroy them it unwittingly create new objects. User code on the other hand has no access to said objects. Also the mentioned inconsistencies may arise since the GC may decide to destroy an object without calling its destructor.

Question 32

Wouldn't the challenge be complete by just using class L{~L(){new L();}}? AFAIK the for(;;) only makes it leak memory faster, right?

Question 33

Sadly, no. Since for each destroyed object only one new instance is going to be created, which then again is inaccessible and marked for destruction. Repeat. Only ever one object will be pending for destruction. No increasing population.

Question 34

Not really. Eventually one finalized will be ignored. The corresponding object will be eaten regardless.

Question 35

Javascript, 14 bytes

Golfed

setInterval(0)

Registers an empty interval handler with a default delay, discarding the resulting timer id (making it impossible to cancel).

enter image description here

I've used a non-default interval, to create several million timers, to illustrate the leak, as using a default interval eats CPU like mad.

Question 36

Haha I love that you've typed 'Golfed', makes me curious about the ungolfed version

Question 37

it might look like this if(window && window.setInterval && typeof window.setInterval === 'function') { window.setInterval(0); }

Question 38

Actually, this is not impossible to cancel: interval (and timeout) ID's are numbered sequentially, so it's fairly easy to cancel the thing just by calling clearInterval with an incrementing ID until your interval is gone. For example: for(let i=0;i<1e5;i++){try{clearInterval(i);}catch(ex){}}

Question 39

@user2428118 As zeppelin says, this is no more "legitmate" than saying the C/C++ leaks aren't "real" because you could brute force calls to free()

Question 40

Wow, not many challenges where JavaScript is an actual contender...

Question 41

C (gcc), 15 bytes

f(){malloc(1);}

Verification

$ cat leak.c
f(){malloc(1);}
main(){f();}
$ gcc -g -o leak leak.c
leak.c: In function ‘f’:
leak.c:1:5: warning: incompatible implicit declaration of built-in function ‘malloc’ [enabled by default]
 f(){malloc(1);}
 ^
$ valgrind --leak-check=full ./leak
==32091== Memcheck, a memory error detector
==32091== Copyright (C) 2002-2013, and GNU GPL'd, by Julian Seward et al.
==32091== Using Valgrind-3.10.0 and LibVEX; rerun with -h for copyright info
==32091== Command: ./leak
==32091=わ=わ
=わ=わ32091=わ=わ
=わ=わ32091== HEAP SUMMARY:
==32091== in use at exit: 1 bytes in 1 blocks
==32091== total heap usage: 1 allocs, 0 frees, 1 bytes allocated
==32091=わ=わ
=わ=わ32091=わ=わ 1 bytes in 1 blocks are definitely lost in loss record 1 of 1
==32091== at 0x4C29110: malloc (in /usr/lib64/valgrind/vgpreload_memcheck-amd64-linux.so)
==32091== by 0x40056A: f (leak.c:1)
==32091== by 0x40057A: main (leak.c:2)
==32091==
==32091== LEAK SUMMARY:
==32091== definitely lost: 1 bytes in 1 blocks
==32091== indirectly lost: 0 bytes in 0 blocks
==32091== possibly lost: 0 bytes in 0 blocks
==32091== still reachable: 0 bytes in 0 blocks
==32091== suppressed: 0 bytes in 0 blocks
==32091==
==32091== For counts of detected and suppressed errors, rerun with: -v
==32091== ERROR SUMMARY: 1 errors from 1 contexts (suppressed: 0 from 0)

Question 42

Rust, 52 bytes

extern{fn malloc(_:u8);}fn main(){unsafe{malloc(9)}}

Allocates some bytes with the system malloc. This assumes the wrong ABI is acceptable.

(削除) Rust (in theory), 38 bytes (削除ここまで)

fn main(){Box::into_raw(Box::new(1));}

We allocate memory on the heap, extract a raw pointer, and then just ignore it, effectively leaking it. (Box::into_raw is shorter then std::mem::forget).

However, Rust by default uses jemalloc, which valgrind can't detect any leakage. We could switch to the system allocator but that adds 50 bytes and requires nightly. Thanks so much for memory safety.

Output of the first program:

==10228== Memcheck, a memory error detector
==10228== Copyright (C) 2002-2015, and GNU GPL'd, by Julian Seward et al.
==10228== Using Valgrind-3.12.0.SVN and LibVEX; rerun with -h for copyright info
==10228== Command: ./1
=わ=わ10228=わ=わ 
=わ=わ10228=わ=わ 
=わ=わ10228== HEAP SUMMARY:
==10228== in use at exit: 9 bytes in 1 blocks
==10228== total heap usage: 7 allocs, 6 frees, 2,009 bytes allocated
==10228== 
==10228== LEAK SUMMARY:
==10228== definitely lost: 9 bytes in 1 blocks
==10228== indirectly lost: 0 bytes in 0 blocks
==10228== possibly lost: 0 bytes in 0 blocks
==10228== still reachable: 0 bytes in 0 blocks
==10228== suppressed: 0 bytes in 0 blocks
==10228== Rerun with --leak-check=full to see details of leaked memory
==10228== 
==10228== For counts of detected and suppressed errors, rerun with: -v
==10228== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 0 from 0)

Question 43

awesome. posts like this led me to explore Rust over the past year, definitely one of the most fun languages i have tried to learn.

Question 44

I am not aware of any operating systems that have a usize defined as u8. It should be fn malloc(_:usize);.

Question 45

@Sapphire_Brick using the correct function prototype would waste 3 bytes. thus the comment "This assumes the wrong ABI is acceptable".

Question 46

Java, 10 bytes

Finally, a competitive answer in Java !

Golfed

". "::trim

This is a method reference (against a string constant), which can be used like that:

Supplier<String> r = ". "::trim

A literal string ". " will be automatically added to the global interned strings pool, as maintained by the java.lang.String class, and as we immediatelly trim it, the reference to it can not be reused further in the code (unless you declare exactly the same string again).

...

A pool of strings, initially empty, is maintained privately by the class String.

All literal strings and string-valued constant expressions are interned. String literals are defined in section 3.10.5 of the The JavaTM Language Specification.

...

https://docs.oracle.com/javase/8/docs/api/java/lang/String.html#intern--

You can turn this in a "production grade" memory leak, by adding the string to itself and then invoking the intern() method explicitly, in a loop.

Question 47

I considered this for C#... but I don't think it counts, because as you say you can access that memory by including another string literal. I'd also be interested to know what ("." + " ").intern() would do (if they were user input or w/e, so we discount compiler optimisations).

Question 48

Indeed, the only consensus is slim at best, I'm just firmly on the "the code should compile" side. I'm still not sure I buy this solution given the wording on the question (these strings can't be freed, and they can be found in normal operating code even though it's unlikely), but I invite others to make their own judgement

Question 49

That string isn't even inaccessible, let alone leaked. We can retrieve it at any time by interning an equal string. If this were to count, any unused global variable (private static in Java) would be a leak. That's not how memory leaks are defined.

Question 50

@user2357112 "...That string isn't even inaccessible..." That only looks obvious because you see the code. Now consider you got this method reference X() as an argument to your code, you know that it allocates (and interns) a string literal inside, but you do not know which one exactly, it might be ". " or "123" or any other string of a (generally) unknown length. Would you please demonstrate how you can still access it, or deallocate the entry in the "intern" pool it occupies?

Question 51

@user2357112 On a machine with a finite memory, you can access a value stored in any piece of memory simply by guessing it correctly, but that does not mean that such a thing as memory leaks do not exist. there's probably some way to use reflection to determine the string's contents too could you demonstrate this ? (hint, String.intern() is implemented in the native code).

Question 52

8086 ASM, 3 bytes

This examples assumes that a C runtime is linked in.

jmp _malloc

this assembles to e9 XX XX where XX XX is the relative address of _malloc

This invokes malloc to allocate an unpredictable amount of memory and then immediately returns, terminating the processes. On some operating systems like DOS, the memory might not be reclaimable at all until the system is rebooted!

Question 53

The normal implementation of malloc will result in memory being freed on process exit.

Question 54

@Joshua Yeah, but that's implementation defined behaviour.

Question 55

Forth, 6 bytes

Golfed

s" " *

Allocates an empty string with s" ", leaving it's address and length (0) on the stack, then multiplies them (resulting in a memory address being lost).

Valgrind

%valgrind --leak-check=full gforth -e 's" " * bye'
...
==12788== HEAP SUMMARY:
==12788== in use at exit: 223,855 bytes in 3,129 blocks
==12788== total heap usage: 7,289 allocs, 4,160 frees, 552,500 bytes allocated
==12788=わ=わ 
=わ=わ12788=わ=わ 1 bytes in 1 blocks are definitely lost in loss record 1 of 22
==12788== at 0x4C2AB80: malloc (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==12788== by 0x406E39: gforth_engine (in /usr/bin/gforth-0.7.0)
==12788== by 0x41156A: gforth_go (in /usr/bin/gforth-0.7.0)
==12788== by 0x403F9A: main (in /usr/bin/gforth-0.7.0)
==12788== 
...
==12818== LEAK SUMMARY:
==12818== definitely lost: 1 bytes in 1 blocks
==12818== indirectly lost: 0 bytes in 0 blocks

Question 56

Befunge (fungi), 1 byte

This may be platform dependent and version dependent (I've only tested with version 1.0.4 on Windows), but fungi has historically been a very leaky interpreter. The $ (drop) command shouldn't do anything on an empty stack, but looping over this code somehow manages to leak a lot of memory very quickly. Within a matter of seconds it will have used up a couple of gigs and will crash with an "out of memory" error.

Note that it doesn't necessarily have to be a $ command - just about anything would do. It won't work with a blank source file though. There's got to be at least one operation.

Question 57

go 45 bytes

package main
func main(){go func(){for{}}()}

this creates an anonymous goroutine with an infinite loop inside of it. the program can continue to run as normal, as starting the goroutine is kind of like spawning a concurrently running small thread, but the program has no way to reclaim the memory that was allocated for the goroutine. the garbage collector will never collect it either since it is still running. some people call this 'leaking a goroutine'

Question 58

golf check: this is 2 bytes shorter than calling C.malloc(8), since you need to import"C"

Question 59

There are three kinds of answers. The low-level languages where you just malloc then discard it, the garbage collected languages where you create an infinite loop that doesn't give the garbage collector time to deallocate memory, and the garbage collected languages that leak memory due to a bug in the interpreter.

Question 60

Java 1.3, 23 bytes

void l(){new Thread();}

Creating a thread but not starting it. The thread is registered in the internal thread pool, but will never be started, so never ended and therefore never be a candidate for the GC. It is an unretrievable object, stuck in Java limbos.

It's a bug in Java until 1.3 included as it was fixed afterwards.

Testing

The following program makes sure to pollute the memory with new thread objects and show a decreasing free memory space. For the sake of leaks testing, I intensively makes the GC run.

public class Pcg110485 {
 static
 void l(){new Thread();}
 public static void main(String[] args) {
 while(true){
 l();
 System.gc();
 System.out.println(Runtime.getRuntime().freeMemory());
 }
 }
}

Question 61

Since this works only on specific Java versions, you should say "Java 3" in your header instead.

Question 62

There's no such thing as Java 3. It's Java 1.3. There was Java 1.0, 1.1, 2, 1.3, 1.4, 5, 6, 7, 8, 9. Weird numbering, but that's how it is.

Question 63

This was my idea too. Damn.

Question 64

Swift 3, 38 bytes

New version:

class X{var x: X!};do{let x=X();x.x=x}

x has a strong reference to itself, so it will not be deallocated, leading to a memory leak.

Old version:

class X{var y:Y!}
class Y{var x:X!}
do{let x=X();let y=Y();x.y=y;y.x=x}

x contains a strong reference to y, and vice versa. Thus, neither will be deallocated, leading to a memory leak.

user62131 · Accepted Answer · 2017-02-19 01:00:20Z

Perl (5.22.2), 0 bytes

Try it online!

I knew there'd be some language out there that leaked memory on an empty program. I was expecting it to be an esolang, but turns out that perl leaks memory on any program. (I'm assuming that this is intentional, because freeing memory if you know you're going to exit anyway just wastes time; as such, the common recommendation nowadays is to just leak any remaining memory once you're in your program's exit routines.)

Verification

$ echo -n | valgrind perl
...snip...
==18517== 
==18517== LEAK SUMMARY:
==18517== definitely lost: 8,134 bytes in 15 blocks
==18517== indirectly lost: 154,523 bytes in 713 blocks
==18517== possibly lost: 0 bytes in 0 blocks
==18517== still reachable: 0 bytes in 0 blocks
==18517== suppressed: 0 bytes in 0 blocks
==18517== 
==18517== For counts of detected and suppressed errors, rerun with: -v
==18517== ERROR SUMMARY: 15 errors from 15 contexts (suppressed: 0 from 0)

I liked the Unlambda answer, but this one is (IMHO) too much of a stretch, as it is obviously the interpreter itself which leaks the memory, i.e. I get ` definitely lost: 7,742 bytes in 14 blocks` when I run perl --version on my machine, despite it never gets to running any program, at all.
@zeppelin: Agreed, but according to our rules, it's the implementation that defines the language, thus if the implementation leaks memory, all programs in the language leak memory. I'm not necessarily sure I agree with that rule, but at this point it's too entrenched to really be able to change.

Leak Memory in as few bytes as possible

42 Answers 42

Perl (5.22.2), 0 bytes

Verification

C, (削除) 48 31 (削除ここまで) 22 bytes

Unlambda (c-refcnt/unlambda), 1 byte

Verification

TI-Basic, 12 bytes

Python <3.6.5, 23 bytes

C#, 34 bytes

Explanation

Test

Javascript, 14 bytes

C (gcc), 15 bytes

Verification

Rust, 52 bytes

(削除) Rust (in theory), 38 bytes (削除ここまで)

Java, 10 bytes

8086 ASM, 3 bytes

Forth, 6 bytes

Befunge (fungi), 1 byte

go 45 bytes

Java 1.3, 23 bytes

Testing

Swift 3, 38 bytes

Delphi (Object Pascal) - 33 bytes

C# - 84bytes

Factor, 13 bytes

AutoIt, 39 bytes

Common Lisp (SBCL only), (削除) 28 (削除ここまで) 26 bytes

C++, 16 bytes

Valgrind result

Solution 1: C (Mac OS X x86_64), 109 bytes

Results:

Explanation

Solution 2: C (Mac OS X x86_64), 44 bytes

Explanation

Possible Solution 1: C (Mac OS X x86_64), 11 bytes

Possible Solution 2: C (Mac OS X x86_64), 8 bytes

Java (OpenJDK 9), (削除) 322 (削除ここまで) 220 bytes

C#, 109 bytes

C 30 bytes

Valgrind Results:

Dart, 76 bytes

Swift, 12 bytes

Explanation:

c, 9 bytes

Plain English, (削除) 71 (削除ここまで) (削除) 70 (削除ここまで) (削除) 58 (削除ここまで) 35 bytes

Your Answer

Sign up or log in

Post as a guest

Post as a guest

Linked

Related

Hot Network Questions

Unlambda (`c-refcnt/unlambda`), 1 byte