Re: Writing own source disk

bart <bc@freeuk.com> writes:

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.

Ah, OK.

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.

In fact, I didn't say it wasn't interesting, only that it's not an
interesting quine.  Saying more about what you see as those intriguing
possibilities would be topical here.

   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.

So this is not C.  In comp.lang.c, when a line is very C-like, the fact
that it's not C should be flagged.

--
Ben.