February 07, 2007
BCS wrote:
> janderson wrote:
>> Walter Bright wrote:
>>
>>> Fixes many bugs, some serious.
>>>
>>> Some new goodies.
>>>
>>> http://www.digitalmars.com/d/changelog.html
>>>
>>> http://ftp.digitalmars.com/dmd.1.005.zip
>>
>>
>> The import stuff has been part of C for a long time (in the form of #include), however I've never seen it used.  Maybe with string operations it will be useful, but otherwise I don't see the point.
>>
>> =Joel
> 
> not quite, I don't think this works in c
> 
> char string[] = "#import<bigstring.txt>"
> 
> sting gets the value of "#import<bigstring.txt>", not the contents of "bigstring.txt"

No but you could do:

char* string =
#import "bigstring.txt"

and have quotes in the bigstring.txt

D's look nicer but its been around for ages.  I'm sure combining it with the mixins will make all the difference.

-Joel
February 07, 2007
Walter Bright wrote:
> janderson wrote:
>> The import stuff has been part of C for a long time (in the form of #include), however I've never seen it used.  Maybe with string operations it will be useful, but otherwise I don't see the point.
> 
> The fundamental difference is that #include inserts *program text*, while import inserts the contents as a *string literal*.
> 
> Some things that you can do with import that you cannot do with #include:
> 
> 1) You can have tech writers write "help text" files, which can then be imported by the programmers as string literals. This means the tech writers do not have to be concerned in the slightest with string syntax.

They could just add quotes around them in C.  Slightly less convenient, never seen anyone use that feature.

> 
> 2) It's an easy way to bind binary data into a program. For example, let's say one wants to embed an icon (.ico) file into your program binary. In C, one would have to write:
> 
>     static unsigned char icon[] = { 0x00, 0x10, 0x53, 0x29, ... };
> 
> meaning one must translate the binary data in foo.ico to the hex notation.
> 
> In D, one can write:
> 
>     static ubyte[] icon = cast(ubyte[])import("foo.ico");

This is a good point.  Maybe it should be on the webpage.

-Joel
February 07, 2007
janderson wrote:
> Walter Bright wrote:
>> Some things that you can do with import that you cannot do with #include:
>>
>> 1) You can have tech writers write "help text" files, which can then be imported by the programmers as string literals. This means the tech writers do not have to be concerned in the slightest with string syntax.
> 
> They could just add quotes around them in C.

Not exactly. You cannot have multiline string literals in C. You'd have to use \n\ line splicing, and escape any " and \ embedded in the text:

"Your text\n\
would have to\n\
look like this\n\
and be careful to\n\
escape any \"s in\n\
the text, as well as\n\
any \\s."

Furthermore, string literals are limited to 4095 characters (if one cares about portability). C99 5.2.4.1

These restrictions are annoying enough that I've preferred using runtime reading and loading of the message file instead.
February 07, 2007
"Jari-Matti Mäkelä" <jmjmak@utu.fi.invalid> wrote in message news:eqaban$2l90$1@digitaldaemon.com...
> BCS kirjoitti:
>> Without the gratuitous stuff that has to be the cleanest quine outside of bash (in bash an empty file prints nothing)
>>
>> import std.stdio;
>> void main(){writef(import(__FILE__));}
>
> And if the strings don't mess up with printf, it can be made even shorter:
>
> void main(){printf(import(__FILE__));}

"writef".length == "printf".length


February 07, 2007
Jarrett Billingsley wrote:
> "Jari-Matti Mäkelä" <jmjmak@utu.fi.invalid> wrote in message news:eqaban$2l90$1@digitaldaemon.com...
>> BCS kirjoitti:
>>> Without the gratuitous stuff that has to be the cleanest quine outside
>>> of bash (in bash an empty file prints nothing)
>>>
>>> import std.stdio;
>>> void main(){writef(import(__FILE__));}
>> And if the strings don't mess up with printf, it can be made even shorter:
>>
>> void main(){printf(import(__FILE__));}
> 
> "writef".length == "printf".length 
> 
> 

But the "printf" version is -= "import std.stdio;".length + 1;

That said, for examplar|demonstrative D code I'd just assume avoid printf regardless.  It just isn't "the D way."  Personal preferance, though, would be:

import tango.io.Stdout;
void main(){Stdout(import(__FILE__));}

-- Chris Nicholson-Sauls
February 07, 2007
Ary Manzana wrote:
> But... I'm wondering which are the evil uses of it. For me it's now almost impossible not to program with an IDE (big projects, I mean). At least in Java. Maybe compile time stuff will make it such that an IDE won't be needed anymore. But it's very hard for me to see that happening.

I believe by 'evil use', Walter meant evil use of mixins, not IDE's. Isn't he?

-- 
serg.
February 07, 2007

Walter Bright wrote:
> Ary Manzana wrote:
>> Walter Bright escribió:
>>> True, but on the other hand, specifically not supporting it in the IDE may act as a needed brake on evil uses of it.
>> But... I'm wondering which are the evil uses of it.
> 
>  From my point of view, evil uses of it are things like version control:
> 
>     mixin(import("versions.txt"));
> 
> where versions.txt contains:
> 
>     version = FOO;
>     version = BAR;
> 
> etc., or other uses that subvert the right way to do things. One should think long and hard about using textual import to import D code.

Why is that evil? I think it's actually a great idea. "versions" are a sort of configuration that determines which code should be compiled and which code shouldn't. Storing this configuration in a separate file makes sense to me.

> 
> What it's for is to:
> 
> 1) import data for a string constant
> 2) import code that's in DSL (Domain Specific Language), not D, form.
February 07, 2007

Derek Parnell wrote:
> On Tue, 06 Feb 2007 11:55:18 -0800, Walter Bright wrote:
> 
>> Hasan Aljudy wrote:
>>> I don't see how it's possible to interpret that without implementing a full compiler.
>> You're right, it isn't possible.
>>
>>> P.S. I know that for "build" all we need is a list of import files, and dmd already has a switch to do that.
>> DMD will also output a list of files that are textually imported, so bud can pick them up at least the second time around.
> 
> Thanks Walter! :-(
> 
> Bud is no longer a useful tool because it can no longer do what it was
> trying to do - namely find out which files needed recompiling and get only
> that done. 

Really? I always use -full -clean switches. I use build/bud because dmd is not smart enough to compile all the files needed to make the program. dmd is fast enough to not require one to bother do "selective" compliation. (if one can say so ..)

February 07, 2007
On Tue, 06 Feb 2007 06:54:18 +0200, Walter Bright <newshound@digitalmars.com> wrote:

> http://www.digitalmars.com/d/changelog.html

Hmm. What would prevent someone from writing programs like:
   writef(import("/etc/passwd"));
and trick someone to compile this program for them (under the pretext that they don't have a D compiler, for example) to steal the user list (or the contents of any other file with a known absolute or relative path on the victim's system)?

IMO, the compiler should at least issue a warning when importing a file not located in/under the source file's directory. Although, if the source emits a lot of pragma(msg) messages, the warning might get cluttered by those - or this might be concealed in a large program with a lot of files. A better security-wise solution is to disallow importing files outside the source file's directory, unless specified by the user on the command-line.

-- 
Best regards,
  Vladimir                          mailto:thecybershadow@gmail.com
February 07, 2007

Vladimir Panteleev wrote:
> On Tue, 06 Feb 2007 06:54:18 +0200, Walter Bright <newshound@digitalmars.com> wrote:
> 
>> http://www.digitalmars.com/d/changelog.html
> 
> Hmm. What would prevent someone from writing programs like:
>    writef(import("/etc/passwd"));
> and trick someone to compile this program for them (under the pretext that they don't have a D compiler, for example) to steal the user list (or the contents of any other file with a known absolute or relative path on the victim's system)?
> 
> IMO, the compiler should at least issue a warning when importing a file not located in/under the source file's directory. Although, if the source emits a lot of pragma(msg) messages, the warning might get cluttered by those - or this might be concealed in a large program with a lot of files. A better security-wise solution is to disallow importing files outside the source file's directory, unless specified by the user on the command-line.
> 

Well, theoretically nothing prevents someone from writing a virus in C++ and trick someone to compile and run it.