standard include files

[BGB]

so's most knowledge when viewed from a particular point of view.

yes, typically any point of view besides the one where the knowledge is
relevant.

the problem them comes in that many people seem prone to believe that
their particular POV is somehow "absolute", rather than itself relative
to the world around them and their particular setting and activities.

as a result, people will tend to judge things, and regard their
particular judgements as somehow being "universal truths" or whatever
(rather than, say, "I don't need this for what I am doing" or similar).


much like, what is the case at the current moment is not necessarily
what will be the case the next moment, but this doesn't invalidate what
is the case at the current moment, or mandate that an which is ideal now
is necessarily ideal at a different point in time.

so, decision making is essentially relative to the task at hand (and the
time and place in which it is done).

 

[BGB]

<offtopic>
That one strikes me as exceptional, though I could easily be mistaken.
I'd expect more along the lines of 'WsaGetLastError' to appear in
Windows, but maybe I'm thinking NT-only.
</offtopic>

I think it depends some, as MS tends to often vary its conventions from
one place to another:
sometimes the prefix is all caps, other times just the first letter, and
sometimes (rarely) it is all lower-case.

but, yes, maybe I was mistaken, first-letter-caps seems to be more
common, like in "CoCreateGuid()" and similar.


but, there are few things entirely consistent with MS naming conventions.

 

[BGB]

Le 24/02/12 11:03, Robert Wessel a écrit :

Exactly.

Lcc-win has the library in a static library (no dlls). I eliminated the
dll because of the endless problems in support...

In 16 bit windows, dlls were essential, in 32 bit windows they are less
essential and in 64 bits they are quite unnecessary.

MSVC often statically links the C runtime by default, with the result
that passing malloc'ed memory, or a FILE, across DLL boundaries, is
prone to cause the program to blow up (all file IO needs to take place
in the same DLL which opened the file, free/realloc/... needs to be
called from the same DLL as the malloc call, ...).

admittedly, it can be kind of annoying, but does have a side benefit:
heap-corruption bugs, ... will tend to cause crashes in the same DLL
which corrupted the memory.


however, I still figure DLLs are fairly useful:
they are useful for organizing code;
they remember their own library dependencies;
they result in smaller binaries (one ends up with 20MB of DLLs, rather
than a 20MB EXE, ...);
they help reduce build-times, since only the DLL in question needs to be
rebuilt, rather than the whole program;
they provide a macro-scale way of dealing with cross-library name
clashes (one only sees names exported by the particular DLLs one has
directly imported, rather than potentially every symbol in every library
on the system or in use by an application);
....


granted, this is assuming a strategy of "send the app binary with a
large pile of DLLs in its program directory". this can also be sort of
annoying.

one might desire a way, say, to bundle all of the DLLs into a larger
aggregate unit, but there is no ideal way to do this (there are ways,
but each has drawbacks).


or such...

 

[BGB]

[including all the header files]

But this is not necessarily a good idea, so there is a case to be made for
having this diagnosed as if the header were included.

ok might be sensible for a small library likes C's runtime but would
you want to do that C++? or Python? or Perl? I'm not even sure it's
clear what /is/ the standard library for some of those. I suppose
referencing a namespace could automatically import the correct
identifiers and do the moral equivalent of linking. presumably you'd
have to obey some sort of convention on where files were kept. or use
a database.

in my language, importing a "package" (essentially a namespace, using
the Java/ActionScript term) may trigger the VM to try to load a module
of the same name (the package name is treated as a path-name, and is
searched along the VM's known library paths, technically inside of a VFS).

once imported, a delegation link is made between the current lexical
scope and the packages' object (internally, imports' are actually
variable declarations, and the VM uses a delegation system similar to
the one in Self, likewise: packages are objects).

side note:
organizing things like in Java essentially requires creating another
module who's sole purpose is to (manually) import all of the per-class
modules (could be changed, but for now it works, note that nothing
prevents putting multiple classes in a given module, nor prevents
putting variable and function declarations directly into packages or at
the toplevel).

annoyingly, there are a bunch of modifiers which may be needed on import
and package declarations in my language to influence the semantics
("import" vs "extern import" vs "abstact import" vs "native import" vs
"static import" vs "delegate import" vs ...).


OTOH, the C FFI basically just loads in a bunch of databases (the DBs
have names matching the loaded DLLs, so seeing any loaded DLL will
trigger loading a DB of the same name). these DB's are built by
"compiling" the headers associated with the DLL (tool parses header,
spits out a DB of everything it saw along the way).

the result is that presently the C FFI has visibility of nearly all of C
land at once. this is in-fact kind of annoying, as one sort of expects
the ability to import *particular* C headers or libraries, rather than
trying to import anything from C land, and having the entire rest of the
C toplevel coming with it (but, this is not really a sufficient issue to
bother trying to fix it).

note that the command for importing C modules, as-is, may trigger
loading DLLs (in the current incarnation, the native package names are
inferred to be potential DLL or SO names).

there is a system for aliases though, so trying to import "C.stdio" may
redirect to internally importing "C.msvcrt" or similar instead (mostly
so that ideally code doesn't need to depend on OS-specific DLL/SO
names). side note: the "C." prefix is mandatory, and magic...


as-is, the language doesn't really have much of a "standard library"
though, since most stuff thus far has either been via built-in
functionality, or via calling C code via the FFI.


yes, probably all a bit crufty and nasty seeming...

 

[BGB]

Most of what you describe would apply only to freestanding
implementations. A conforming freestanding implementation is not
required to provide any standard headers other than:

<float.h>
<iso646.h>
<limits.h>
<stdalign.h>
<stdarg.h>
<stdbool.h>
<stddef.h>
<stdint.h>
<stdnoreturn.h>

(Several of these headers are new in C11.)

and one of them has a name which would be invalid under MS-DOS / Win 3.x
file-name rules...

one could argue, "but shouldn't C stay with everything being friendly to
the limits of older systems?", as in, keeping all header names in a
format usable to MS-DOS (so, say, using "stdnortn.h" or similar instead...).


well, nevermind if probably hardly anyone anymore is compiling their
code on MS-DOS systems.

 

[Jeroen Mostert]

and one of them has a name which would be invalid under MS-DOS / Win 3.x
file-name rules...

There is no requirement that the standard headers reside in files, nor that
the standard header names are valid source file names. As long as "#include
<stdnoreturn.h>" behaves as required, all is well. In fact, section 6.10.2p5
of the standard says "the implementation may ignore the distinctions of
alphabetical case and restrict the mapping to eight significant characters
before the period", so an implementation is not even required to be able to
distinguish between <stdnoreturn.h> and <stdnoretirement.h>.

A compiler supporting 8.3 filenames will simply truncate the name, so when
stored on disk, the header would reside in stdnoret.h (again, the standard
doesn't mandate this). Handling long names is nothing new, various Unix
headers defied the convention long ago.

 

[BGB]

There is no requirement that the standard headers reside in files, nor
that the standard header names are valid source file names. As long as
"#include <stdnoreturn.h>" behaves as required, all is well. In fact,
section 6.10.2p5 of the standard says "the implementation may ignore the
distinctions of alphabetical case and restrict the mapping to eight
significant characters before the period", so an implementation is not
even required to be able to distinguish between <stdnoreturn.h> and
<stdnoretirement.h>.

A compiler supporting 8.3 filenames will simply truncate the name, so
when stored on disk, the header would reside in stdnoret.h (again, the
standard doesn't mandate this). Handling long names is nothing new,
various Unix headers defied the convention long ago.

fair enough.

I wasn't seriously expecting much modern development to be being done on
DOS systems, and other (more modern) DOS variants, such as FreeDOS, have
LFN support, so it is likely a moot point anyways.

 

[Eric Sosman]

and one of them has a name which would be invalid under MS-DOS / Win 3.x
file-name rules...

For one thing, the standard headers need not be files at
all. They might be built into the compiler, or they might be
"records" of a combined file. (I have not personally run into
the former, but I have seen the latter.)

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.)

 

[Ian Collins]

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?

 

[BGB]

Eh? I though most were, or are you including the full path in the names?

on Linux, they generally are exact matches.

on Windows, the only obvious difference is that the OS is not case
sensitive, so one may potentially have the source files have names
differing in case from the OS files (at the cost that it will blow up if
one tries to compile the program on Linux or similar).

never-mind matters of include paths, but the include paths are a side
issue IMO.

 

[BGB]

For one thing, the standard headers need not be files at
all. They might be built into the compiler, or they might be
"records" of a combined file. (I have not personally run into
the former, but I have seen the latter.)

on all the systems I have dealt with, they have been plain files.

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.)

I will disagree.

on Linux, they are exact matches, otherwise the compiler will fail to
find them (given they are case sensitive, ...).

on Windows, one can potentially have a difference in case, but this is
likely the exception rather than the rule.

but, either way, the basic file names need to match, as otherwise the
compiler wont find them.

 

[Jeroen Mostert]

on Linux, they generally are exact matches.

on Windows, the only obvious difference is that the OS is not case
sensitive

The Win32 file APIs are not case sensitive. NTFS retains case, and
subsystems can choose whether or not to be case sensitive (the POSIX/Interix
subsystem is case sensitive). So you might call case sensitivity an option
on Windows (albeit one that's not often exercised).

 

[Eric Sosman]

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.

 

[Eric Sosman]

[... concerning names of Standard headers ...]
and one of them has a name which would be invalid under MS-DOS / Win 3.x
file-name rules...

For one thing, the standard headers need not be files at
all. They might be built into the compiler, or they might be
"records" of a combined file. (I have not personally run into
the former, but I have seen the latter.)

on all the systems I have dealt with, they have been plain files.

Ah. That's settled, then.

I will disagree.

Please cite the part of the Standard that states the obligation,
or perhaps the several parts from which one can deduce the existence
thereof. (Hint: You may save yourself a certain amount of effort by
starting at 6.10.2p2, which says in part "How the places are specified
or the header identified is implementation-defined.")

 

[BGB]

The Win32 file APIs are not case sensitive. NTFS retains case, and
subsystems can choose whether or not to be case sensitive (the
POSIX/Interix subsystem is case sensitive). So you might call case
sensitivity an option on Windows (albeit one that's not often exercised).

this doesn't make much difference though, the normal result is that
header names on Linux need to match exactly, and on Windows may differ
in case, but otherwise need to have the same characters.

 

[BGB]

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.

 

[BGB]

zOS (IBM mainframe) C/C++ developers often use PDSs to store header
files - these make names longer than eight characters problematic, at
best. In fact C header files are often stored in a PDS dedicated to
headers, and the header name does not include the ".h".

hmm... I had overlooked / was not aware of this.

but, yes, IBM and their sometimes strangely arcane systems.

 

[Ian Collins]

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.

Well the files name does match, the compiler just happens to know where
to find it.

 

[James Kuyper]

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.

The standard covers that by specifying that the implementation will
search through "a sequence of implementation-defined places" (6.10.2p2)
for the specified file. For the two compilers you've described, that
sequence apparently includes /usr/include/ and C:\DJBPP\include\,
respectively, Keeping the distinction between "place searched" and
"name of file searched for" in mind, do you know of any implementation
which changes the provided file name, rather than having specific list
of search places?

 

[Eric Sosman]

[...]
I have never seen a compiler satisfy `#include<stdio.h>" by
reading the file stdio.h, with no decorations or translation.

The standard covers that by specifying that the implementation will
search through "a sequence of implementation-defined places" (6.10.2p2)
for the specified file. For the two compilers you've described, that
sequence apparently includes /usr/include/ and C:\DJBPP\include\,
respectively, Keeping the distinction between "place searched" and
"name of file searched for" in mind, do you know of any implementation
which changes the provided file name, rather than having specific list
of search places?

In the snippage, I mentioned a compiler that found <stdio.h>
in the file STDIO.H (no decorations of any kind: the file system
had only one level, no "directories" or "paths"). The file system
was actually case-sensitive but the "shell" turned everything to
upper case, so the compiler also did case translation to make things
easier for the command-line user.

Another compiler found <stdio.h> by reading a file named
something like (this was long ago and some details have faded
from my fading memory)

STDIO H SYS

That's eighteen characters in all, with nine embedded spaces.
Again, the file system had no "directories," but it had "groups"
(which were a bit like directories, but only one level deep).
Six of the embedded spaces could have named a "queue" (a file
in a group could exist in zero or more queues, usually one), but
queue wasn't needed if you knew all of name, extension, and group.
Case translation occurred because names, queues, and groups were
all stored on disk in "RAD50" encoding, which could only handle
one letter case.

Another looked in a "text library" with a name something like
VAXC$INCLUDE.TLB (again, details have been subjected to fadeage),
and found the "member" named STDIO (upper case, no dot-aitch).
This was very much like the "partitioned data set" mentioned
elsethread by Robert Wessel.

I'll admit that all these mappings are "name-preserving" in
some sense specific to the systems involved. However, 6.10.2p2
does not require that the Standard headers be files, nor that their
file names (if any) have any obvious relation to the header names.
A compiler faced with a header name that's unsuitable as a file name
for the local system is in no difficulty: all it needs to do is map
the name to something else. The "something else" is entirely at the
whim of the implementor (although it must be documented).