February 10, 2007 Re: DMD 1.005 release | ||||
---|---|---|---|---|
| ||||
Posted in reply to janderson | janderson wrote:
> Andrei Alexandrescu (See Website For Email) wrote:
>> janderson wrote:
>>> Yauheni Akhotnikau wrote:
>>>> On Thu, 08 Feb 2007 10:08:29 +0300, Walter Bright <newshound@digitalmars.com> wrote:
>>>>
>>
>> Probably an easier way to go would be:
>>
>> class A
>> {
>> ...
>> int x;
>> B y;
>> int z;
>> }
>>
>> mixin(serialize!(A, "x=10, y"));
>
> I'm not sure I'd need a mixin for this.
Oh, indeed. A template instantiation is all that's needed. (It would use mixins inside for parsing the spec string.)
Andrei
|
February 10, 2007 Re: DMD 1.005 release | ||||
---|---|---|---|---|
| ||||
Posted in reply to Andrei Alexandrescu (See Website For Email) | On Sat, 10 Feb 2007 03:14:48 +0300, Andrei Alexandrescu (See Website For Email) <SeeWebsiteForEmail@erdani.org> wrote: > Probably an easier way to go would be: > > class A > { > ... > int x; > B y; > int z; > } > > mixin(serialize!(A, "x=10, y")); > > This way you leave to the compiler the task of parsing the class, and you only deal with the annotations. Yes. And this has yet another advantage -- it may be necessary to support several servialization methods at one time. For example, home-made serialization method and ASN.1 BER serialization: // home-made serialization. mixin( serialize!(A, "x=10, y")); // ASN.1 BER. mixin( asn1ber_serialize!(A, "x,tag=0x1020,optional=10", "y,tag=0x1139")); -- Regards, Yauheni Akhotnikau |
February 10, 2007 Re: DMD 1.005 release [security concerns about ImportExpressions] | ||||
---|---|---|---|---|
| ||||
Posted in reply to Andrei Alexandrescu (See Website For Email) | On 2007-02-06 23:51:17 -0800, "Andrei Alexandrescu (See Website For Email)" <SeeWebsiteForEmail@erdani.org> said: > 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. > > How would the bad person see the output of the compilation? > > Andrei By asking someone else to compile code for you and send back the executable. Some services exist for compiling C/C++ on the web and this concern would prevent people from doing the same with D. -- Jeff McGlynn |
February 10, 2007 Re: DMD 1.005 release [security concerns about ImportExpressions] | ||||
---|---|---|---|---|
| ||||
Posted in reply to Jeff McGlynn | Jeff McGlynn wrote:
> On 2007-02-06 23:51:17 -0800, "Andrei Alexandrescu (See Website For Email)" <SeeWebsiteForEmail@erdani.org> said:
>
>> 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.
>>
>> How would the bad person see the output of the compilation?
>>
>> Andrei
>
>
> By asking someone else to compile code for you and send back the executable. Some services exist for compiling C/C++ on the web and this concern would prevent people from doing the same with D.
I see. This is a new scenario indeed. Given previous experience with TeX, it looks like the compiler switch approach could take care of it.
Andrei
|
February 11, 2007 Re: DMD 1.005 release [security concerns about ImportExpressions] | ||||
---|---|---|---|---|
| ||||
Posted in reply to Andrei Alexandrescu (See Website For Email) | Andrei Alexandrescu (See Website For Email) wrote: > Jeff McGlynn wrote: >> By asking someone else to compile code for you and send back the executable. Some services exist for compiling C/C++ on the web and this concern would prevent people from doing the same with D. > > I see. This is a new scenario indeed. Given previous experience with TeX, it looks like the compiler switch approach could take care of it. The switch will be in the next update. C/C++ doesn't really have this problem with #include, since that will only read files that consist of preprocessor tokens. Arbitrary files will not work. |
February 11, 2007 Re: DMD 1.005 release | ||||
---|---|---|---|---|
| ||||
Posted in reply to Charles D Hixson | Charles D Hixson wrote: > Were I to select a Forth to use I'm probably pick gforth or bigforth (+ Minos?). IMHO the tool (=programming language) should be chosen according to the work at hand, and to the mastership one can achieve as an individual with a certain tool. For some people FICL is a good tool http://ficl.sourceforge.net/ It should not be too difficult to incorporate it into D applications as _resident_ interactive debugging aid _during_runtime_. > Neon, though, was impressive. I think there's a version calls MOPS or mops or some such still extant, but I don't know how complete it is, and last I checked it only ran on Mac pre-OSX. (I trust that's no longer true...if not, it's history.) See http://powermops.sourceforge.net/index.php/Main_Page |
February 11, 2007 Re: DMD 1.005 release | ||||
---|---|---|---|---|
| ||||
Posted in reply to Andreas Kochenburger | Andreas Kochenburger wrote:
> Charles D Hixson wrote:
>> Were I to select a Forth to use I'm probably pick gforth or bigforth (+ Minos?).
>
> IMHO the tool (=programming language) should be chosen according to the work at hand, and to the mastership one can achieve as an individual with a certain tool. For some people FICL is a good tool
> http://ficl.sourceforge.net/
>
> It should not be too difficult to incorporate it into D applications as _resident_ interactive debugging aid _during_runtime_.
>
>> Neon, though, was impressive. I think there's a version calls MOPS or mops or some such still extant, but I don't know how complete it is, and last I checked it only ran on Mac pre-OSX. (I trust that's no longer true...if not, it's history.)
>
> See
> http://powermops.sourceforge.net/index.php/Main_Page
Glad to hear it's still going... sorry to hear it's soon to be gone. (The author announces no plans to port to the Intel Macs...well, he's a bit stronger about it than that.)
|
February 11, 2007 Re: DMD 1.005 release | ||||
---|---|---|---|---|
| ||||
Posted in reply to Jarrett Billingsley | Jarrett Billingsley wrote: > "Jarrett Billingsley" <kb3ctd2@yahoo.com> wrote in message news:eqcmo3$2u17$1@digitaldaemon.com... > > Just wanted to add that something I find severely lacking is that there's no way to get a pretty (usable, non-mangled) string representation of a type. Instead we have to write large template libraries to accomplish something that the compiler does _all the time_. This means it's currently not possible to do something like > > template MakeVariable(Type, char[] name) > { > const char[] MakeVariable = Type.nameof ~ " " ~ name ~ ";"; > } > > mixin(MakeVariable!(int, "x")); > > Instead we have to use a template library to demangle the name: > > import ddl.meta.nameof; > > template MakeVariable(Type, char[] name) > { > const char[] MakeVariable = prettytypeof!(Type) ~ " " ~ name ~ ";"; > } > > mixin(MakeVariable!(int, "x")); > > > :\ > > Well, actually you can do that, with the unannounced (in the changelog) .stringof property ( http://www.digitalmars.com/d/property.html ) : ---- template MakeVariable(Type, char[] name) { const char[] MakeVariable = Type.stringof ~ " " ~ name ~ ";"; } -- Bruno Medeiros - MSc in CS/E student http://www.prowiki.org/wiki4d/wiki.cgi?BrunoMedeiros#D |
February 11, 2007 Re: DMD 1.005 release | ||||
---|---|---|---|---|
| ||||
Posted in reply to Bruno Medeiros | Bruno Medeiros wrote:
> Well, actually you can do that, with the unannounced (in the changelog) .stringof property ( http://www.digitalmars.com/d/property.html ) :
>
> ----
>
> template MakeVariable(Type, char[] name)
> {
> const char[] MakeVariable = Type.stringof ~ " " ~ name ~ ";";
> }
It's unannounced because it doesn't work right yet.
|
February 12, 2007 Re: DMD 1.005 release | ||||
---|---|---|---|---|
| ||||
Posted in reply to Walter Bright | Walter Bright wrote: > Bruno Medeiros wrote: >> Well, actually you can do that, with the unannounced (in the changelog) .stringof property ( http://www.digitalmars.com/d/property.html ) : >> >> ---- >> >> template MakeVariable(Type, char[] name) >> { >> const char[] MakeVariable = Type.stringof ~ " " ~ name ~ ";"; >> } > > It's unannounced because it doesn't work right yet. What do you mean? If it's doesn't work right yet, why was it released already? (basic cases seem to be working) -- Bruno Medeiros - MSc in CS/E student http://www.prowiki.org/wiki4d/wiki.cgi?BrunoMedeiros#D |
Copyright © 1999-2021 by the D Language Foundation