View mode: basic / threaded / horizontal-split · Log in · Help
February 10, 2007
Re: DMD 1.005 release
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
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]
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]
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]
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
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
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
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
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
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
12 13 14 15 16 17 18 19
Top | Discussion index | About this forum | D home