Path: ...!npeer.as286.net!npeer-ng0.as286.net!weretis.net!feeder8.news.weretis.net!eternal-september.org!feeder3.eternal-september.org!news.eternal-september.org!.POSTED!not-for-mail
From: David Brown <david.brown@hesbynett.no>
Newsgroups: comp.lang.c
Subject: Re: Writing own source disk
Date: Wed, 5 Jun 2024 21:27:19 +0200
Organization: A noiseless patient Spider
Lines: 38
Message-ID: <v3qe6n$13d67$1@dont-email.me>
References: <v3hmha$3banl$1@dont-email.me> <87sexvm1lr.fsf@bsb.me.uk>
 <v3iu4n$3i607$1@dont-email.me> <87mso2mky5.fsf@bsb.me.uk>
 <v3k49t$3rdhi$1@dont-email.me> <87h6e91r91.fsf@nosuchdomain.example.com>
 <87cyox1r5e.fsf@nosuchdomain.example.com> <v3p72o$t16n$1@dont-email.me>
 <87wmn3z2dp.fsf@nosuchdomain.example.com> <s228O.47424$Dsz1.38632@fx14.iad>
 <87sexrz1nj.fsf@nosuchdomain.example.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Injection-Date: Wed, 05 Jun 2024 21:27:19 +0200 (CEST)
Injection-Info: dont-email.me; posting-host="56141dcf3b691042dab403761b77ec57";
	logging-data="1160391"; mail-complaints-to="abuse@eternal-september.org";	posting-account="U2FsdGVkX18uDYGCZTbLvZV6QBpLncNgbHo1vv/jE4k="
User-Agent: Mozilla Thunderbird
Cancel-Lock: sha1:aMjdVl0aJ2xi5Rq8g9c7uXdsdzw=
Content-Language: en-GB
In-Reply-To: <87sexrz1nj.fsf@nosuchdomain.example.com>
Bytes: 3045

On 05/06/2024 20:26, Keith Thompson wrote:
> scott@slp53.sl.home (Scott Lurndal) writes:
>> Keith Thompson <Keith.S.Thompson+u@gmail.com> writes:
>>> Mikko <mikko.levanto@iki.fi> writes:
>>>> On 2024-06-04 00:35:25 +0000, Keith Thompson said:
>>> [...]
>>>>> #embed is of course handled at compile time.  It's very likely, but
>>>>> still not quite guaranteed, that `#embed __FILE__` will be able to
>>>>> access the source file.
>>>>
>>>> An operating system might refuse to open an already opened file.
>>>> There is no good reason to refuse when all accesses are for read-only
>>>> but a supid operating system might think otherwise.
>>>
>>> That seems unlikely, and would be a concern only if some real-world OS
>>> actually behaved that way.
>>
>> IIRC windows has some restrictions on when a file can be opened vis
>> a vis other processes also having it open.
>>
>> But I don't do windows and my recollection could be faulty.
> 
> My understanding is that there can be one writer or multiple readers.

Yes.  It's more restrictive than on *nix systems (also on directory 
deletion or renaming), but it's not unreasonable.

> That wouldn't affect `#embed __FILE__`.  Allowing only one reader would
> break a *lot* of functionality.
> 

The only realistic issues I could imagine with "#embed __FILE__" is the 
possibility of directory handling (i.e., if you compiled it as "cc 
xxx/yyy.c", would __FILE__ expand to "yyy.c" or "xxx/yyy.c", and would 
the correct file then be found?) or if your source was from a pipe or 
shell redirection.  "cat xxx.c > gcc -x c -", for example.