Path: csiph.com!v102.xanadu-bbs.net!xanadu-bbs.net!feeder.erje.net!1.eu.feeder.erje.net!eternal-september.org!feeder.eternal-september.org!mx02.eternal-september.org!.POSTED!not-for-mail
From: Keith Thompson <kst-u@mib.org>
Newsgroups: comp.lang.c
Subject: Re: SAFEcode
Date: Wed, 22 Apr 2015 08:38:21 -0700
Organization: None to speak of
Lines: 46
Message-ID: <87pp6wkwb6.fsf@kst-u.example.com>
References: <e8a2658f-49d8-4af1-a6ca-6ec7f686f0b7@googlegroups.com> <mh1697$49g$1@dont-email.me> <0734af4b-4b6e-44b5-9f8f-9fba8315e833@googlegroups.com> <mh291a$b2$1@dont-email.me> <bb060ce1-d2c3-4479-9297-78234efe5489@googlegroups.com> <871tjf6ovf.fsf@bsb.me.uk> <72593655-4999-4703-9bc9-ef7f0c0f9e78@googlegroups.com> <87lhhm5v88.fsf@bsb.me.uk> <e168f3b1-e08e-45fb-b5df-d06fef91c9e8@googlegroups.com> <87k2x54lkl.fsf@bsb.me.uk> <2ad7ea64-09e4-4a2c-ba89-6ab04777e7b3@googlegroups.com> <mh5sl3$ptj$1@dont-email.me> <82447b8d-608e-4dea-b6bb-c07b8b503f75@googlegroups.com> <mh698l$k5f$1@dont-email.me> <76a6250e-ebbf-4597-94ee-3c926b74a059@googlegroups.com> <mh6otk$gh4$1@dont-email.me> <6f9d9a9e-e950-47e5-bf88-c91d03ae73df@googlegroups.com> <mh7kuc$t5o$1@dont-email.me> <87bnigbif2.fsf@bsb.me.uk> <mh7tjl$sci$1@dont-email.me> <mh87op$44s$1@dont-email.me>
Mime-Version: 1.0
Content-Type: text/plain
Injection-Info: mx02.eternal-september.org; posting-host="9be37d943435275679235b07c7947eef"; logging-data="4004"; mail-complaints-to="abuse@eternal-september.org";	posting-account="U2FsdGVkX19cOagtKkpAvfqvtJ4iSA+m"
User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3 (gnu/linux)
Cancel-Lock: sha1:WbPdfv4+/x6YwGz8CvFMq+MmJWY= sha1:pNONIpM/3483l4hHSjyuiVYVvrE=
Xref: csiph.com comp.lang.c:60743

David Brown <david.brown@hesbynett.no> writes:
[...]
> But that's a rather boring problem, if we only represent numbers
> directly like that.  Lets allow our 65KB "object" to include C source
> code as well (relying only on features of ISO C, of course).  Perhaps we
> should say that it must be only C source code.  The problem now is not
> to find the biggest number that can be represented (since it's easy to
> spit out ridiculously large numbers of digits), but to find the smallest
> number that /cannot/ be represented.
>
> To get started, we should have a limit rather smaller than 65KB.  With a
> limit of 46 characters, I think 10 is the limit:
>
> #include <stdio.h>
> int main(void){puts("9");}
>
> Obviously that can be extended with a 10^n - 1 being representable using
> 45+n characters.  But when do we beat that?

Sticking to 46 characters, the space between #include and <stdio.h> is
optional:

#include<stdio.h>
int main(void){puts("99");}

And arguably we can do this:

#include<stdio.h>
int main(){puts("999999");}

A very strict reading of the standard implies (to me at least) that
`int main()` has undefined behavior, but it's very likely that it's
intended to be permitted and well defined.  With that assumption,
this is the best I can do in C99 and C11:

int puts();int main(){puts("9999999999999");}

If we allow C90:

main(){puts("9999999999999999999999999999");}

-- 
Keith Thompson (The_Other_Keith) kst-u@mib.org  <http://www.ghoti.net/~kst>
Working, but not speaking, for JetHead Development, Inc.
"We must do something.  This is something.  Therefore, we must do this."
    -- Antony Jay and Jonathan Lynn, "Yes Minister"