On 2/26/2012 6:30 AM, Eric Sosman wrote:
> On 2/25/2012 5:03 PM, Ian Collins wrote:
>> On 02/26/12 10:59 AM, Eric Sosman wrote:
>>>
>>> For another thing, even if the implementation provides the
>>> standard headers as files it is not obliged to name them with
>>> the same strings used in the source. (Come to think of it, I
>>> have never encountered an implementation whose header file names
>>> were exact matches for what's seen in the source.)
>>
>> Eh? I though most were, or are you including the full path in the names?
>
> Most compilers I've used have formed the header's file name
> by adding characters to those from the source: /usr/include/stdio.h
> or C:\DJGPP\include\stdio.h or things of that kind. A few have
> actually changed the source's characters: STDIO.H, for example
> (note that six of the file name's seven characters do not appear
> in the C source).
>
> I have never seen a compiler satisfy `#include <stdio.h>" by
> reading the file stdio.h, with no decorations or translation.
>

this is because it is part of the include path, and how the OS deals
with case. "case" doesn't really exist on an OS which doesn't check or
preserve case.

the include path issue doesn't make much of a difference, since the vast
majority of file access is relative to some or another path, and the
existence of a path is generally ignored when considering a files' name.

more so, say, one can make use of a VFS, say where the include file
isn't necessarily stored in a disk file, but maybe inside of an archive
of some sort or similar, but this doesn't make much difference, if the
file has the same file-name within the archive as it would have as a
file (or is subject to similar naming restrictions).


however, the claim was that there were not many OS's where they actually
matched, as in, including "stdio.h" actually fetched an "stdio.h" from
disk (from wherever, this doesn't matter), rather than wandering off and
fetching, vs say, "stdio_h.pcn" or something.