In article <3hhva1$bv@hustle.rahul.net>, "Ronald F. Guilmette"
<rfg@rahul.net> writes:
|>
||>
|>OK.  But what are the semantics of (for example):
|>
|> #include "\n\n\n\xyz.h"
|>
|>Unless I'm mistaken, the C standard (and, I hope, also the
|>forthcoming
|>C++ standard) require that the \n's in the string literal be
|>interpreted
|>as newline characters.
|>
|>Given that interpretation, the above #include directive would, if it
|>worked, include a file with a very odd filename indeed.
|>

The '#include' is a preprocessor directive, and should be processed by
the preprocessor & expanded to the file before the conversion of '\n's
to newlines, so avoiding strange filenames.

--
--  <><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><>
Neil M. Hubbard <u9429751@sys.uea.ac.uk> (finger for PGP public key).
Opinions expressed are mine only. WWW:http://www.sys.uea.ac.uk/~u9429751
"To be or not to be, that is a tautology."

Ronald F. Guilmette (rfg@rahul.net) wrote:
> OK.  But what are the semantics of (for example):

>  #include "\n\n\n\xyz.h"

> Unless I'm mistaken, the C standard (and, I hope, also the forthcoming
> C++ standard) require that the \n's in the string literal be interpreted
> as newline characters.

> Given that interpretation, the above #include directive would, if it
> worked, include a file with a very odd filename indeed.

You are mistaken.  The C standard does not require the \n's to be interpretted
as newline characters.  This is not a string literal.  The syntax is
(ISO 6.8.2)

 #include "q-char-sequence" new-line

and (ISO 6.1.7)

 q-char-sequence:
  q-char
  q-char-sequence q-char

 q-char:
  any member of the source character set except the new-line
  character and "




--
Mike Rubenstein

In article <3hhva1$bv@hustle.rahul.net> "Ronald F. Guilmette" <rfg@rahul.net> writes:
|OK.  But what are the semantics of (for example):
|
| #include "\n\n\n\xyz.h"
|
|Unless I'm mistaken, the C standard (and, I hope, also the forthcoming
|C++ standard) require that the \n's in the string literal be interpreted
|as newline characters.

You are mistaken -- at least regards the ANSI C standard.  That standard
makes it very clear that that which follows the #include is not a "normal"
string literal.  It is given a special name "q-char-sequence", and
special, different rules are applied to what follows #include regards
preprocessing.  For example, if two or more preprocessing tokens
following the #include evaluate to string literals, then these two
string literals are NOT concatenated as in the normal case.  The ANSI C
standard then points out a wide variety of ways that the #include specification
might be interpreted differently on different systems, such as differing
number of significant characters, whether or not capitalization matters,
etc.

For example:

#include <StRiNgXYZZY.H>

can legally result in the standard "string.h" inclusion on some hypothetical
operating system.

In short, at least the ANSI C standardization effort recognized that
language standardization efforts should not attempt to specify operating
systems.  Operating system specs specify operating systems, and language
specs specify languages.  Maybe someday some OS will want something like:

#include "http:\\www.wacko.com/system/includes/example.h"

Why should the language care what the OS wants?  Why shouldn't
OS's develop somewhat independently of languages?

In article <3hhva1$bv@hustle.rahul.net>,
Ronald F. Guilmette <rfg@rahul.net> wrote:
>>reycri@atlantis.actrix.gen.nz (Reynaldo Crisostomo) writes:
>>>Is this also true for standard headers that are in a standard subdirectory?
>>>For example, #include <sys\stat.h>. A potential problem here is the "\"
>>>for DOS. Unix uses "/".

I don't know about the proposed C++ standard, but the C standard
doesn't have any such header files.  I suppose you could mean XPG,
Posix or the like, but then the \-as-dir-delimiter problem is hardly a
problem.

>OK.  But what are the semantics of (for example):
>
> #include "\n\n\n\xyz.h"
>
>Unless I'm mistaken, the C standard (and, I hope, also the forthcoming
>C++ standard) require that the \n's in the string literal be interpreted
>as newline characters.

Section 6.8.2 says include directives are of the form:
# include < h-char-sequence > new-line
# include " q-char-sequence " new-line
or
# include pp-tokens new-line

In the last case, the pp-tokens need to expand to one of the preceding
cases.

6.1.7:  (some of the commas below look like periods in my copy, but...)

   If the characters ', \, ", or /* occur in the sequence between the
   > and < delimiters, the behavior is undefined.  Similarly, if the
   characters ', \, or /* occur in the sequence between the " delimiters,
   the behavior is undefined. ^25

Footnote 25: "Thus, sequences of characters that resemble escape
sequences cause undefined behavior."

Todd Larason

In article <pstemari.165.002944B1@erinet.com>,
Paul J. Ste. Marie <pstemari@erinet.com> wrote:
>In article <3hhva1$bv@hustle.rahul.net> "Ronald F. Guilmette" <rfg@rahul.net> writes:
>
>>OK.  But what are the semantics of (for example):
>
>>        #include "\n\n\n\xyz.h"
>
>>Unless I'm mistaken, the C standard (and, I hope, also the forthcoming
>>C++ standard) require that the \n's in the string literal be interpreted
>>as newline characters.
>
>The ARM, and presumably the standards, don't define the "filename.h" as a
>string literal.  The ARM specifically says that \, ', /*, and // within the
>filename result in undefined behavior.

You're right, and I stand corrected.  Thank you.

P.S.  Such usage also results in undefined behavior in an ANSI/ISO C program.

--

-- Ron Guilmette, Sunnyvale, CA ---------- RG Consulting -------------------
---- E-mail: rfg@segfault.us.com ----------- Purveyors of Compiler Test ----
-------------------------------------------- Suites and Bullet-Proof Shoes -

Ronald F. Guilmette (rfg@rahul.net) wrote:
: >>Is this also true for standard headers that are in a standard subdirectory?
: >>For example, #include <sys\stat.h>. A potential problem here is the "\"
: >>for DOS. Unix uses "/".

: OK.  But what are the semantics of (for example):

:  #include "\n\n\n\xyz.h"

: Unless I'm mistaken, the C standard (and, I hope, also the forthcoming
: C++ standard) require that the \n's in the string literal be interpreted
: as newline characters.

You are mistaken.

The ANSI C standard says:
 There shall be an implementation defined mapping between the
 delimited sequence and the external source file name.

It doesn't say that escape substitution is done.  It doesn't call it a
string literal, so it doesn't imply it.

It doesn't require it, but it also doesn't forbid it.  I doubt any MS-DOS
implementations would use escape substitution though.

--
        Tony Cook - tony@online.tmx.com.au
                    100237.3425@compuserve.com

In article <3hhva1$bv@hustle.rahul.net> rfg@rahul.net writes:

>OK.  But what are the semantics of (for example):
>
>        #include "\n\n\n\xyz.h"
>
>Unless I'm mistaken, the C standard (and, I hope, also the forthcoming
>C++ standard) require that the \n's in the string literal be interpreted
>as newline characters.
>
>Given that interpretation, the above #include directive would, if it
>worked, include a file with a very odd filename indeed.
>

I don't think there is a problem. (At least, in C)  The token between
the quotes is defined as a q-char sequence, not a string literal.
A q-char sequence can contain any member of the source character set
except " and new-line.  Note that is new-line, a 'physicl' end of a
line of source, not the \n simple-escape-sequence.  That basically
means you can't split the header name across two lines.

The above include is legal C.  How it is interpreted is
implementation defined.

--
===================================================================
 Ian Cargill   CEng MIEE                 Soliton Software Ltd.
 email: ian@soliton.demon.co.uk          54 Windfield, Leatherhead,
 tel:  +44 (0)1372  37 5529              Surrey, UK    KT22 8UQ
===================================================================
 Find out about the Association of C and C++ Users:  info@accu.org

"Ronald F. Guilmette" <rfg@rahul.net> writes:

>OK.  But what are the semantics of (for example):

> #include "\n\n\n\xyz.h"

>Unless I'm mistaken, the C standard (and, I hope, also the forthcoming
>C++ standard) require that the \n's in the string literal be interpreted
>as newline characters.

First, C:

You are mistaken.  That's not a string literal at all -- it's a
`"' character, a `q-char-sequence' and a `"' character.  Section
6.1.7 explicitly makes the use of `'', `\', and `/*' undefined
inside the `"..."' pair (and the `"' is also prohibited inside
the `<...>' pair.

Next, C++:

The ARM makes the same restrictions and adds the `//' sequence
to the prohibited stuff (Section 16.4).

>Given that interpretation, the above #include directive would, if it
>worked, include a file with a very odd filename indeed.

Well, I would like such filenames to be allowed here just as
they are allowed (and used) on my systems -- but I suspect the
Standard(s) won't accommodate me.

--
Greg Black -- gjb@gba.oz.au

In article <792599041snz@soliton.demon.co.uk> I wrote:

>I don't think there is a problem. (At least, in C)  The token between
>the quotes is defined as a q-char sequence, not a string literal.
>A q-char sequence can contain any member of the source character set
>except " and new-line.  Note that is new-line, a 'physical' end of a
>line of source, not the \n simple-escape-sequence.  That basically
>means you can't split the header name across two lines.
>
>The above include is legal C.  How it is interpreted is
>implementation defined.

Except I missed the Semantics. :-(  So it's undefined behavior.

--
===================================================================
 Ian Cargill   CEng MIEE                 Soliton Software Ltd.
 email: ian@soliton.demon.co.uk          54 Windfield, Leatherhead,
 tel:  +44 (0)1372  37 5529              Surrey, UK    KT22 8UQ

In article <D3Kz24.Jxy@ucc.su.OZ.AU> maxtal@physics.su.OZ.AU (John Max
Skaller) writes:

|> In the case of Unix there is a Standard under development by an
|> ISO body, namely POSIX. Where possible, most DOS/Windows/NT vendors
|> attempt to conform to the POSIX document.

It would be more correct to say that they attempt to conform to a
small (but frequently used) subset of the POSIX document.

The POSIX standard is quite large.  In particular, it also defines a
large number of programs which are present; the call ``system( "ls -l" )''
is well defined in POSIX, as is its output.  I have seen no
DOS/Windows vendor even make a stab at emulating this.  (Nor should
they, IMHO.)
--
James Kanze         Tel.: (+33) 88 14 49 00        email: kanze@gabi-soft.fr
GABI Software, Sarl., 8 rue des Francs-Bourgeois, F-67000 Strasbourg, France
Conseils en informatique industrielle --
                              -- Beratung in industrieller Datenverarbeitung

In article <craigaD3KxIu.ABC@netcom.com> craiga@netcom.com (Craig
Arnush) writes:

|> reycri@atlantis.actrix.gen.nz (Reynaldo Crisostomo) writes:
|> >
|> >Is this also true for standard headers that are in a standard subdirectory?
|> >For example, #include <sys\stat.h>. A potential problem here is the "\"
|> >for DOS. Unix uses "/".

|> I can't say for other compilers, but Borland's latest releases allow you
|> to use both the backward (in every sense of the word) slash and the
|> forward slash interchangeably when including standard headers.  If you
|> find a compiler that doesn't allow forward slashes, call them up and
|> complain bitterly that they're not adhering to the standards.

Which standard?  None of the *standard* header filenames include a '/'
anyway?  (Nor do they include a ".h"/".hpp".)
--
James Kanze         Tel.: (+33) 88 14 49 00        email: kanze@gabi-soft.fr
GABI Software, Sarl., 8 rue des Francs-Bourgeois, F-67000 Strasbourg, France
Conseils en informatique industrielle --
                              -- Beratung in industrieller Datenverarbeitung

In article <D3KL5r.7pL@actrix.gen.nz> reycri@atlantis.actrix.gen.nz (Reynaldo Crisostomo) writes:

> Is this also true for standard headers that are in a standard subdirectory?
> For example, #include <sys\stat.h>. A potential problem here is the "\"
> for DOS. Unix uses "/".

There are no standard subdirectories: the names of the standard
headers contain neither / or \ characters.  This is certainly
true in C and is also true in the present C++ working paper;
I would be very surprised if it were to change in the Standard.
--
    --Andrew Koenig
      ark@research.att.com

kevinl@fangorn.cs.monash.edu.au (Kevin Lentin) writes:

>I think you'll find that most (if not all) DOS compilers will work just
>fine with sys/stat.h
>I've compiled a lot of unix code under DOS and it worked fine.

>--
>[==================================================================]
>[ Kevin Lentin                   |___/~\__/~\___/~~~~\__/~\__/~\_| ]
>[ kevinl@bruce.cs.monash.edu.au  |___/~\/~\_____/~\______/~\/~\__| ]
>[ Macintrash: 'Just say NO!'     |___/~\__/~\___/~~~~\____/~~\___| ]
>[==================================================================]

This is not so hard to explain!
MS-DOS accepts both \ and / as pathname separators.
It is only the parsing phase of COMMAND.COM (the
shell command interpreter) that insists on having
/ as command switch leading char and \ as the path
separator.

Federico

Fergus Henderson <fjh@munta.cs.mu.OZ.AU> wrote:
>reycri@atlantis.actrix.gen.nz (Reynaldo Crisostomo) writes:
>
>>For example, #include <sys\stat.h>.
>>A potential problem here is the "\" for DOS. Unix uses "/".
>
>The header name is <sys/stat.h>.
>If you use the right header name, it will work correctly on
>both systems.  That is because DOS compilers allow "/" as an
>alternative pathname separator.

Similarly, this will also work correctly on VMS, even though it gets
translated into something like SYS$INCLUDE:[SYS]STAT.H;1

In every DOS compiler I've used, this same translation gets done
on all filenames, allowing, e.g., fopen("/foo/bar/zot.dat", ...)
to be used instead of requiring   fopen("\\foo\\bar\\zot.dat", ...).

-- John.

In article <D3Gxyt.M7E@actrix.gen.nz>, reycri@atlantis.actrix.gen.nz (Reynaldo Crisostomo) writes:
>I am browsing through the working paper and I noticed that the name of
>some of the standard headers are more than 8 characters.
>
>How can a DOS/Windows 3.x C++ compiler expected to comply?

I beleive the mapping of the header names used in C++ to real file names is
implementation defined.  Therefor, a compiler is free to adjust the names as
needed to get usable file names.

----------------------------------------------------------------------------
 Richard Deken                   Graduate student in electrical engineering
 PGP public key available      Tennessee Technological University
 Internet: rad6938@gemini.tntech.edu        Cookeville, TN, USA

maxtal@physics.su.OZ.AU (John Max Skaller) writes:
>In the case of Unix there is a Standard under development by an
>ISO body, namely POSIX. Where possible, most DOS/Windows/NT vendors
>attempt to conform to the POSIX document.

James Kanze US/ESC 60/3/141 #40763 <kanze@us-es.sel.de> wrote:
>It would be more correct to say that they attempt to conform to a
>small (but frequently used) subset of the POSIX document.

There isn't one POSIX document.  There are several POSIX standards
that vendor could claim compliance with.

>The POSIX standard is quite large.  In particular, it also defines a
>large number of programs which are present; the call ``system( "ls -l" )''
>is well defined in POSIX, as is its output.

It's defined in POSIX .2 but not in POSIX .1.

>I have seen no DOS/Windows vendor even make a stab at emulating this.

The MKS Toolkit for DOS or NT makes quite a stab at it.

>(Nor should they, IMHO.)

*shrug*  There's a market for it.  There are much more bizarre sytems,
(eg. VMS, MVS, or MPE) where system("ls -l") works...

       Ross Ridge

Disclaimer:  I work for MKS.

--
 l/  //   Ross Ridge -- The Great HTMU, Ook                    +1 519 883 4329
[oo][oo]  rridge@csclub.uwaterloo.ca      http://csclub.uwaterloo.ca/u/rridge/
-()-/()/
 db  //

[I am following-up on an article which was originally posted only to the
 comp.std.c++ newsgroup.  Note that my follow-up is directed to BOTH
 the comp.std.c++ group and also to comp.std.c.]

In article <craigaD3KxIu.ABC@netcom.com>,
Craig Arnush <craiga@netcom.com> wrote:
>reycri@atlantis.actrix.gen.nz (Reynaldo Crisostomo) writes:
>>
>>Is this also true for standard headers that are in a standard subdirectory?
>>For example, #include <sys\stat.h>. A potential problem here is the "\"
>>for DOS. Unix uses "/".
>
>I can't say for other compilers, but Borland's latest releases allow you
>to use both the backward (in every sense of the word) slash and the
>forward slash interchangeably when including standard headers...

OK.  But what are the semantics of (for example):

 #include "\n\n\n\xyz.h"

Unless I'm mistaken, the C standard (and, I hope, also the forthcoming
C++ standard) require that the \n's in the string literal be interpreted
as newline characters.

Given that interpretation, the above #include directive would, if it
worked, include a file with a very odd filename indeed.

--

-- Ron Guilmette, Sunnyvale, CA ---------- RG Consulting -------------------
---- E-mail: rfg@segfault.us.com ----------- Purveyors of Compiler Test ----
-------------------------------------------- Suites and Bullet-Proof Shoes -

In article <3hhva1$bv@hustle.rahul.net> "Ronald F. Guilmette" <rfg@rahul.net> writes:

>OK.  But what are the semantics of (for example):

>        #include "\n\n\n\xyz.h"

>Unless I'm mistaken, the C standard (and, I hope, also the forthcoming
>C++ standard) require that the \n's in the string literal be interpreted
>as newline characters.

The ARM, and presumably the standards, don't define the "filename.h" as a
string literal.  The ARM specifically says that \, ', /*, and // within the
filename result in undefined behavior.

 Paul J. Ste. Marie,
 pstemari@well.sf.ca.us, pstemari@erinet.com

>Is this also true for standard headers that are in a standard subdirectory?
>For example, #include <sys\stat.h>. A potential problem here is the "\"
>for DOS. Unix uses "/".

(slightly off-topic)
Not really.  The DOS kernel, from v2.0 to latest, accepts either `\' or
`/' as the path separator.  So, _any_ pathname you use inside programs
can have `/' instead of `\'.  The only place you _have_ to use `\' is
on the command line, that too, only in a COMMAND.COM session or in a
batch file.

An interesting, and happy, result of this is that for hard-coded
pathnames inside programs, you can use:
 "d:/borlandc/bgi/trip.chr"

instead of the decidedly ugly, and inconvenient:
 "d:\\borlandc\\bgi\\trip.chr",

or the completely wrong (but silently accepted :-():
 "d:\borlandc\bgi\trip.chr".

And yes, you can use
 #include <sys/stat.h>

on _any_ DOS compiler.

(Follow-ups to `comp.os.msdos.programmer').

(On-topic)
I am not very sure if ISO C/C++ requires the `sys' sub-directory, or
any sub-directory at all.  I don't think that the standard presumes a
hierarchical file directory structure.

Another observation is that the standard does _not_ require the part
enclosed by <> in the #include to be a filename.  The compiler can do
anything with that string, as long as it provides the namespace with
the prototypes/vble defns that are supposed to be in that header.
--
--Raja R Harinath-----------`finger harinath@cs.umn.edu' for more info
   "Come to think of it, there already _are_ a million monkeys on a
     million typewriters, but Usenet is _nothing_ like Shakespeare."
                                                  -- Blaire Houghton

In article <D3JLxv.4n2@ucc.su.oz.au>,
John Max Skaller <maxtal@physics.su.OZ.AU> wrote:
> In article <D3Gxyt.M7E@actrix.gen.nz> reycri@atlantis.actrix.gen.nz (Reynaldo Crisostomo) writes:
> >I am browsing through the working paper and I noticed that the name of
> >some of the standard headers are more than 8 characters.
> >
> >How can a DOS/Windows 3.x C++ compiler expected to comply?
> >
> >Am I missing something?
>
>  Yes. _Technically_ a "header" is _not_ a file name.
> So when you see
>
>  #include <stdname>
>
> where "stdname" is on of the predefined header names, what
> you are seeing is not a normal source file #include.
> There does not have to be any file to include. The compiler
> could just "unlock" an already built symbol table, for example.
>
>  In practice, it is usually a file name. DOS actually
> allows up to 63 characters I think-- it just ignores most of them :-)
> So the long names would only be a problem if they agreed on the
> first 8 characters.
>
> --
>         JOHN (MAX) SKALLER,         INTERNET:maxtal@suphys.physics.su.oz.au
>  Maxtal Pty Ltd,
>         81A Glebe Point Rd, GLEBE   Mem: SA IT/9/22,SC22/WG21
>         NSW 2037, AUSTRALIA     Phone: 61-2-566-2189

Is this also true for standard headers that are in a standard subdirectory?
For example, #include <sys\stat.h>. A potential problem here is the "\"
for DOS. Unix uses "/".

Rey Crisostomo
Wellington, New Zealand

reycri@atlantis.actrix.gen.nz (Reynaldo Crisostomo) writes:
>
>Is this also true for standard headers that are in a standard subdirectory?
>For example, #include <sys\stat.h>. A potential problem here is the "\"
>for DOS. Unix uses "/".

I can't say for other compilers, but Borland's latest releases allow you
to use both the backward (in every sense of the word) slash and the
forward slash interchangeably when including standard headers.  If you
find a compiler that doesn't allow forward slashes, call them up and
complain bitterly that they're not adhering to the standards.

Me

In article <D3KL5r.7pL@actrix.gen.nz> reycri@atlantis.actrix.gen.nz (Reynaldo Crisostomo) writes:
>>
>>  Yes. _Technically_ a "header" is _not_ a file name.
>> So when you see
>>
>>  #include <stdname>
>>
>> where "stdname" is on of the predefined header names, what
>> you are seeing is not a normal source file #include.
>
>Is this also true for standard headers that are in a standard subdirectory?

>For example, #include <sys\stat.h>. A potential problem here is the "\"
>for DOS. Unix uses "/".

 The ISO C Standard headers (prior to the Amendment) are

 <assert.h> <locale.h> <stddef.h>
 <ctype.h> <math.h> <stdio.h>
 <errno.h> <setjmp.h> <stdlib.h>
 <float.h> <signal.h> <string.h>
 <limits.h> <stdarg.h> <time.h>

See ISO C, 7.1.2. You don't see and "stat" or "sys/stat" in the list,
so it isn't Standard. Both DOS and Unix have some conventions.
In the case of Unix there is a Standard under development by an
ISO body, namely POSIX. Where possible, most DOS/Windows/NT vendors
attempt to conform to the POSIX document.
--
        JOHN (MAX) SKALLER,         INTERNET:maxtal@suphys.physics.su.oz.au
 Maxtal Pty Ltd,
        81A Glebe Point Rd, GLEBE   Mem: SA IT/9/22,SC22/WG21
        NSW 2037, AUSTRALIA     Phone: 61-2-566-2189

In article <D3KL5r.7pL@actrix.gen.nz>
           reycri@atlantis.actrix.gen.nz "Reynaldo Crisostomo" writes:

>
> Is this also true for standard headers that are in a standard subdirectory?
> For example, #include <sys\stat.h>. A potential problem here is the "\"
> for DOS. Unix uses "/".
>

 I've yet to see a DOS/Winders compiler that won't accept either \ or / in
this context (indeed, I always tend to use "/" - makes me feel more like I'm
writing code for a real 'puter:-)

Regards,
 Andy
--
* Andy Sawyer ** e-mail:andys@thone.demon.co.uk ** Compu$erve:100432,1713 **
 The opinions expressed above are my own, but you are granted the right to
 use and freely distribute them. I accept no responsibility for any injury,
 harm or damage arising from their use.                --   The Management.

reycri@atlantis.actrix.gen.nz (Reynaldo Crisostomo) writes:

>For example, #include <sys\stat.h>.
>A potential problem here is the "\" for DOS. Unix uses "/".

The header name is <sys/stat.h>.
If you use the right header name, it will work correctly on
both systems.  That is because DOS compilers allow "/" as an
alternative pathname separator.

--
Fergus Henderson - fjh@munta.cs.mu.oz.au
all [L] (programming_language(L), L \= "Mercury") => better("Mercury", L) ;-)

Reynaldo Crisostomo (reycri@atlantis.actrix.gen.nz) wrote:

> Is this also true for standard headers that are in a standard subdirectory?
> For example, #include <sys\stat.h>. A potential problem here is the "\"
> for DOS. Unix uses "/".

I think you'll find that most (if not all) DOS compilers will work just
fine with sys/stat.h
I've compiled a lot of unix code under DOS and it worked fine.

--
[==================================================================]
[ Kevin Lentin                   |___/~\__/~\___/~~~~\__/~\__/~\_| ]
[ kevinl@bruce.cs.monash.edu.au  |___/~\/~\_____/~\______/~\/~\__| ]
[ Macintrash: 'Just say NO!'     |___/~\__/~\___/~~~~\____/~~\___| ]
[==================================================================]

I am browsing through the working paper and I noticed that the name of
some of the standard headers are more than 8 characters.

How can a DOS/Windows 3.x C++ compiler expected to comply?

Am I missing something?

Rey Crisostomo
Wellington, New Zealand

reycri@atlantis.actrix.gen.nz (Reynaldo Crisostomo) writes:

>I am browsing through the working paper and I noticed that the name of
>some of the standard headers are more than 8 characters.
>
>How can a DOS/Windows 3.x C++ compiler expected to comply?

Easy.  The mapping from header-name to file-name is determined by the
implementation.  (In fact, headers don't even have to be implemented
using files at all!)

When a DOS compiler sees

 #include "header_with_very_long_name.h"

it justs truncates the name to 8 characters, and searches for "header_w.h".
That scheme only works if the header-names are all distinct in the first 8
characters, but it is enough to handle the ones in the working paper.
(There are also more complicated schemes that could handle the general case.)

--
Fergus Henderson - fjh@munta.cs.mu.oz.au
all [L] (programming_language(L), L \= "Mercury") => better("Mercury", L) ;-)

>>>>> Reynaldo Crisostomo <reycri@atlantis.actrix.gen.nz> writes:

> I am browsing through the working paper and I noticed that the name of
> some of the standard headers are more than 8 characters.

> How can a DOS/Windows 3.x C++ compiler expected to comply?

<arbitrarily_long_standard_header_name.h> does not have to correspond to a
file "arbitrarily_long_standard_header_name.h"; a compiler is allowed to
recognize the standard headers and do special magic to include them
properly.

What Borland C++ has always done is to ignore the extra characters; this
works tolerably well.

Jason

In article <D3Gxyt.M7E@actrix.gen.nz> reycri@atlantis.actrix.gen.nz (Reynaldo Crisostomo) writes:
>I am browsing through the working paper and I noticed that the name of
>some of the standard headers are more than 8 characters.
>
>How can a DOS/Windows 3.x C++ compiler expected to comply?
>
>Am I missing something?

 Yes. _Technically_ a "header" is _not_ a file name.
So when you see

 #include <stdname>

where "stdname" is on of the predefined header names, what
you are seeing is not a normal source file #include.
There does not have to be any file to include. The compiler
could just "unlock" an already built symbol table, for example.

 In practice, it is usually a file name. DOS actually
allows up to 63 characters I think-- it just ignores most of them :-)
So the long names would only be a problem if they agreed on the
first 8 characters.

--
        JOHN (MAX) SKALLER,         INTERNET:maxtal@suphys.physics.su.oz.au
 Maxtal Pty Ltd,
        81A Glebe Point Rd, GLEBE   Mem: SA IT/9/22,SC22/WG21
        NSW 2037, AUSTRALIA     Phone: 61-2-566-2189