Re: Writing own source disk

On 03/06/2024 12:58, Ben Bacarisse wrote:

bart <bc@freeuk.com> writes:
 

On 03/06/2024 10:31, Ben Bacarisse wrote:

There's nothing wrong with using either, but a C quine that uses #embed
relies on knowing the name of the file in which it is stored.

>
I assume you can use __FILE__ with #embed? (I can do that with my version
of it).
>
Then it doesn't need to know the actual name of the file.

 I don't know if that is guaranteed by the standard as I've not really
looked at C23, but if is it, that would be a way to write a (rather
boring) quine in C23.

  It is a
"fixed point of the execution environment", but it's probably the least
interesting C quine possible -- much like
    1
is a quine in languages that evaluate and print an expression.

>
Not really.

 What part are you objecting to?

That it is not very interesting. Using #embed applied to a program's only source code I think opens up some intriguing possibilities.
Whereas a pure quine, which can require ingenuity, to me is just a puzzle.

 That the above (a C quine using #embed)
in not a fixed point of the execution environment?  That it's not an
uninteresting quine?  Or that it's not "much like" self-evaluating
expression quines?
 You said "not really" in reply to a moderately complex paragraph.
 

I've just added this line:
>
   puts(strinclude(__FILE__));

 I think I'm missing your point.  That does input at run-time (if my
guess about strinclude is correct).

'strinclude' is the equivalent of #embed. It does textual inclusion at compile-time.
Without that line, the sql.exe executable is about 1MB. With that line added, it's just over 9MB because that source file is just over 8MB.