Hi,
It might be possible to do (1) or (2) under the hood, without requiring the
corresponding
command line option. However, making either of these the default behavior
might have
unforeseen consequences - I can't see that far ahead without some serious
study, and
my first question would be: why wasn't it done this way to begin with?
If a consensus could be reached on the best approach, I'd be willing to try
to implement
it in the IDL compiler (with the caveat that #3 would be much harder to
implement than
either of the other two - there are reasons for copying the file before
preprocessing, and
they would all have to be worked around in order to skip that step).
thanks,
Jeff Parsons
_____
From: owner-tao-b...@cse.wustl.edu [mailto:owner-tao-b...@cse.wustl.edu] On
Behalf Of Vladimir Panov
Sent: Sunday, January 01, 2006 8:34 AM
To: tao-b...@cs.wustl.edu
Subject: [tao-bugs] tao_idl: #include "..." is not handled correctly
TAO VERSION: 1.4.8
ACE VERSION: 5.4.8
HOST MACHINE and OPERATING SYSTEM:
Any.
TARGET MACHINE and OPERATING SYSTEM, if different from HOST:
Not different.
COMPILER NAME AND VERSION (AND PATCHLEVEL):
Any.
THE $ACE_ROOT/ace/config.h FILE [if you use a link to a platform-
specific file, simply state which one]:
Any.
THE $ACE_ROOT/include/makeinclude/platform_macros.GNU FILE [if you
use a link to a platform-specific file, simply state which one
(unless this isn't used in this case, e.g., with Microsoft Visual
C++)]:
Any.
CONTENTS OF $ACE_ROOT/bin/MakeProjectCreator/config/default.features
(used by MPC when you generate your own makefiles):
// $Id$
// This is an automatically generated file.
ssl=0
qos=1
cidl=0
rwho=0
sctp=0
AREA/CLASS/EXAMPLE AFFECTED:
tao_idl doesn't support the special semantics of #include "...".
DOES THE PROBLEM AFFECT:
COMPILATION?
No.
LINKING?
No.
EXECUTION?
No.
OTHER (please specify)?
IDL compilation is affected.
SYNOPSIS:
tao_idl does not support the "search included file relative to the
preprocessed file's directory" semantics of #include "...".
DESCRIPTION:
tao_idl copies the preprocessed IDL file to /tmp and calls the C
preprocessor on the copied file. Thus, the preprocessor doesn't know where
is the
original location of the IDL file and cannot apply the aforementioned
semantics.
Even worse: it actually applies the semantics, but relative to /tmp. And
/tmp is usually world-writable, i.e. an ill-wisher might put a different
version of the included file there. The IDL compilation will succeed but not
with the intended results. Depending on the skills of the ill-wisher this
behaviour might even be classified as a security hole.
REPEAT BY:
$ ls
ala.idl bala.idl t/
$ cat ala.idl
#include "bala.idl"
interface ala : bala
{
};
$ cat bala.idl
interface bala
{
};
$ tao_idl ala.idl
$ cd t
$ tao_idl ../ala.idl
../ala.idl:1:20: bala.idl: No such file or directory
tao_idl: preprocessor "cc" returned with an error
$ touch /tmp/bala.idl
$ tao_idl ../ala.idl
tao_idl: "../ala.idl", line 4: error in lookup of symbol: bala
SAMPLE FIX/WORKAROUND:
Workarounds:
1. Add the directory of the compiled IDL file (if different from .) to the
-I flags. But:
a) This might be needed to be done on a per IDL file basis, i.e. very hard.
b) This workaround still doesn't remove the potential security hole because
the directory of the preprocessed file has a precendence over the -I flags.
2. Set the temp directory (with tao_idl's -t flag) to be the directory of
the compiled IDL file. But:
a) This might be needed to be done on a per IDL file basis, i.e. very hard.
b) The source directory might be read-only.
3. Don't rely on this semantics at all or always change to the directory of
the IDL file before calling tao_idl.
a) Again, this might be very hard or even impossible in certain cases.
Fix:
Preprocess the IDL file itself, not a copy.
|
