[Search for users] [Overall Top Noters] [List of all Conferences] [Download this site]

Conference turris::decc

Title:	DECC
Notice:	General DEC C discussions
Moderator:	TLE::D_SMITHNTE

Created:	Fri Nov 13 1992
Last Modified:	Fri Jun 06 1997
Last Successful Update:	Fri Jun 06 1997
Number of topics:	2212
Total number of notes:	11045

2092.0. "Problem with include files and search lists" by PRSSOS::VOUTERS (Philippe VOUTERS, Evry (France)) Thu Feb 13 1997 10:11

    Hello,
    
    A customer has a problem with include files specified in a search
    list of directories (cc/include=myincl). If one of the include file
    exists in two directories, then, DEC C V5.5-002, DEC C V5.3-006 and
    DEC C V5.2-003 on AXP V6.2 and V7.1 do not fetch the first file in
    the search list, like the TYPE at the end of the command procedure
    below. The customer said this did not exist in previous versions of
    DEC C. Is it true ? The "DEC C User's Guide for OpenVMS Systems"
    page 1-26 does not speak much about the case of the search list.
    What does the ANSI standard says about diectories search list order ?
    Should I open an IPMT ? Or is it expected behaviour ?
    Thank you in advance for any replies.
    Best regards,
    Philippe Vouters (MCS France)
    
$ username = f$getjpi("","USERNAME")
$ username = f$extract (0,f$locate (" ",username),-
				username)
$ create/dire ['username'.decc.include1] 
$! Please note that definition1.h also exists
$! in ['username'.decc.include2]
$ create ['username'.decc.include1]definition1.h
#define CONST1 11
$ create/dire ['username'.decc.include2]
$ create ['username'.decc.include2]definition.h
#include "definition1.h"
#include "definition2.h"
$ create ['username'.decc.include2]definition1.h
#define CONST1 1
$ create ['username'.decc.include2]definition2.h
#define CONST2 2
$ create ['username'.decc]test.c
#include <stdio.h>
#include "definition.h"

main(){
int a,b;
a = CONST1;
printf ("a = CONST1 = %d\n",a);
b = CONST2;
printf ("b = CONST2 = %d\n",b);
}
$ define myincl ['username'.decc.include1],-
		['username'.decc.include2] 
$ cc/version/noobject nl:
$ cc/include=myincl/object=['username'.decc]test.obj -
				['username'.decc]test.c 
$ link/exe=['username'.decc]test.exe -
				['username'.decc]test.obj
$ run ['username'.decc]test.exe
$ write sys$output "Expected : a = CONST1 = 11
$ write sys$output "           b = CONST2 = 2"
$ write sys$output "as in pre V5.3-006 DEC C versions"
$ type myincl:definition1.h
$ exit

T.R	Title	User	Personal Name	Date	Lines
2092.1		DECC::VMCCUTCHEON		`Thu Feb 13 1997 15:31`	38
	Yes, this is correct behavior. And yes, the behavior has changed, there are some other notes in this notes file which explain some of the history if you are interested. 5.2.2 Inclusion Using Quotation Marks The second form of the #includepreprocessor directive uses quotation marks to delimit the file specification: #include " file-spec " The file-spec is a valid OpenVMS or UNIX style file specifi- cation. For this form of file inclusion, the compiler searches directo- ries in the following order for the file to be included: 1. One of the following directories: � If /NESTED_INCLUDE_DIRECTORY=INCLUDE_ FILE (the default) is specified, the directory where the immediately containing include file is located (that is, the directory containing the file in which the #include directive occurred). � If /NESTED_INCLUDE_DIRECTORY=PRIMARY_ FILE is specified, the directory containing the top- level source file (that is, the directory containing the .C file being compiled, which is not necessarily the current default directory). This is most similar to the behavior of the VAX C compiler. � If /NESTED_INCLUDE_DIRECTORY=NONE is specified, then skip this step and begin at step 2. --val
2092.2	Wrong file included; Why does /nest affect this behavior?	CADSYS::LEVITIN	Sam Levitin	`Thu Feb 13 1997 16:06`	48
	I've read .0 a bit and also 1657, but even 1657 omits details I think affect the problem I'm seeing that is related to .0. Briefly, CC includes the wrong header file; I can't understand why. This behavior is the same, whether the compiler is DEC C V5.2-003 on OpenVMS Alpha V6.2-1H2 or DEC C V5.5-002 on OpenVMS Alpha E7.1. MMSRC$ is defined to be SRC$,REF$ REQ$ is defined to be SRC$,REF$ A header file I have just modified lives in SRC$, with an earlier version in REF$. One of the includers of this file (most, in fact) lives in REF$. The CC command line is CC /NOLIST/DEBUG/noopt/inc=(req$,cad$root:[cadrtl])/PREFIX=ALL/DEFINE= (__VMS_VER=60100000)/WARN=DISABLE=MACROREDEF /OBJ=OBJ$:CLEO_UTILITIES.OBJ MMSRC$:CLEO_UTILITIES.C The file in question includes the header file as follows. #include "cleodef.h" I do not consider this to be a nested include, yet adding the qualifier /NEST=NONE affects which version of CLEODEF.H is included. If I read the docs carefully, /NEST appears to be speaking about what happens when a header file includes another header file, and should presumably not apply to the mechanism of how the top-level header files are located. I guess I'm getting confused by part of the behavior that Maurizio Sichera in 1657.0 described as else if (file_exists_in_the_directory_of_the_source) /* [1] */ The directory of the source, to me, is MMSRC$ (the search list logical name), not REF$ (the actual directory containing the file). Yes, there's a header file MMSRC$:CLEODEF.H, and it's in SRC$, not REF$. So, some questions are: 1. Why with both 5.2 and 5.5 compilers is the REF$:CLEODEF.H file included instead of SRC$: ? Does the compiler consider the directory_containing_the_source to be REF$ instead of MMSRC$ ? 2. Why does /NEST=NONE affect this behavior, when there's only one level of inclusion going on here? Sam
2092.3	I think you expected this answer...	WIBBIN::NOYCE	Pulling weeds, pickin' stones	`Thu Feb 13 1997 16:50`	15
	> 1. Why with both 5.2 and 5.5 compilers is the REF$:CLEODEF.H > file included instead of SRC$: ? Does the compiler consider > the directory_containing_the_source to be REF$ instead of MMSRC$ ? Yes, exactly. The compiler looks in the actual directory (whatever REF$ translates to), regardless of the search list that was used to find it. > 2. Why does /NEST=NONE affect this behavior, when there's only > one level of inclusion going on here? Perhaps the qualifier has a confusing name. It affects where the compiler finds include files, based on the location of the file that contains the "#include" directive. It applies even to #include's in the main source file.
2092.4	Does anybody find the documentation offering a different answer?	CXXC::REPETE	Rich Peterson 381-1802 ZKO2-3/N30	`Mon Feb 17 1997 10:06`	9
	The help file for the /include qualifier for V5.5 has a detailed description of exactly how #include files are found, and how the /nested qualifier affects the processing. The intent is that it should allow these questions to be answered unambiguously. To me, (re-)reading it answered all the questions asked here. If people who read it couldn't answer the questions, and/or have constructive suggestions on how to simplify or further clarify the documentation, that would be appreciated. However, changing the name of the /nested qualifier isn't really practical.