February 07, 2007 Re: DMD 1.005 release | ||||
---|---|---|---|---|
| ||||
Posted in reply to BCS | 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 Re: DMD 1.005 release | ||||
---|---|---|---|---|
| ||||
Posted in reply to Walter Bright | 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 Re: DMD 1.005 release | ||||
---|---|---|---|---|
| ||||
Posted in reply to janderson | 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 Re: DMD 1.005 release | ||||
---|---|---|---|---|
| ||||
Posted in reply to Jari-Matti Mäkelä | "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 Re: DMD 1.005 release | ||||
---|---|---|---|---|
| ||||
Posted in reply to Jarrett Billingsley | 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 Re: DMD 1.005 release | ||||
---|---|---|---|---|
| ||||
Posted in reply to Ary Manzana | 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 Re: DMD 1.005 release | ||||
---|---|---|---|---|
| ||||
Posted in reply to Walter Bright | 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 Re: DMD 1.005 release | ||||
---|---|---|---|---|
| ||||
Posted in reply to Derek Parnell |
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 Re: DMD 1.005 release [security concerns about ImportExpressions] | ||||
---|---|---|---|---|
| ||||
Posted in reply to Walter Bright | 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 Re: DMD 1.005 release [security concerns about ImportExpressions] | ||||
---|---|---|---|---|
| ||||
Posted in reply to Vladimir Panteleev |
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.
|
Copyright © 1999-2021 by the D Language Foundation