www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - How about adding NEW Special Tokens?? For ease and Security

reply Matthew Ong <ongbp yahoo.com> writes:
Hi all,

These 2 tokens are very useful for debugging and also trouble shooting 
during exceptions time and even implementing logging api similar to log4j:
I do understand that this are compile time information and they are static.

__FILE__  // prints something like D:\User\Project\...\MyMod.d
              I do not like this full path format because it might give 
hacker some idea when of server directory layout structure for webbase 
cgi /  layout, accidentally by junior developer because of mis handled 
exceptions.
__LINE__  // some line number.

How about keeping those 2 and also adding some new compile time 
information's tokens:
1) __FILENAME__   // prints only MyMod.d
2) __MODULE__     // prints the full module name. eg: std.c.windows
3) __FUNCNAME__   // prints the function name.
4) __BLOCKNAME__  // perhaps another name, but prints 
class/struct/interface/template... name. If is global, print global.
5) __DEBUGLINE__  // prints __MODULE__ ~ __BLOCKNAME__ ~ __FUNCNAME__ ~ 
__LINE__

The reasons for those are:
1) to make the life of coder simple instead of having to every time call 
a template function/function to trim those information.
2) Some time the code does gets move around within a large project due 
to re-factoring and remodeling. Having only the file name & line number 
might loose the

I am rather sure that the compiler will have some Abstract Syntax Tree 
in memory to map value for such tokens.

It would be even more cool if there is some immutable runtime special 
tokens:
1) __LOGIN__  // Current user login id, eg: johnchia
2) __UID__    // User login number, eg: 0, 304,1234,...
3) __PID__    // Current program process id
4) __PPID__   // Parent process id
5) __STIME__  // Start time, date time,2011-02-23 14:45, to see if there 
is a long over due program.
6) __CMDLINE__ // prints full path name C:\Program 
Files\Notepad++\notepad.exe
7) __TOTMEM__  // Total amount of memory being used. Read Only, but dynamic.
8) __MAXMEM__  // Max amount of memory allocated for this process.Read 
Only, but dynamic. (perhaps a new setting may be done at the library or 
function somewhere to limit the total amount of memory being allocated 
by code.) I find that such setting are very useful to limit such within 
a multi-threaded and multi-tasking application such as a web server. I 
helps to reduce the amount of paging needed during runtime and stabilise
the system.

These runtime tokens will be very useful for developer to do secure 
coding to check for some runtime Access Control Information or 
preventing denial of service and maybe anti buffer over flowing attacks.

Perhaps the runtime special information are already available. If not, 
that might be in the future version.



-- 
Matthew Ong
email: ongbp yahoo.com
May 25 2011
next sibling parent reply Kagamin <spam here.lot> writes:
That's why Tortoise* are so evil, I shit bricks just by looking at them.
May 25 2011
parent Matthew Ong <ongbp yahoo.com> writes:
On 5/25/2011 6:57 PM, Kagamin wrote:
 That's why Tortoise* are so evil, I shit bricks just by looking at them.

-- Matthew Ong email: ongbp yahoo.com
May 25 2011
prev sibling next sibling parent reply KennyTM~ <kennytm gmail.com> writes:
On May 25, 11 16:29, Matthew Ong wrote:
 Hi all,

 These 2 tokens are very useful for debugging and also trouble shooting
 during exceptions time and even implementing logging api similar to log4j:
 I do understand that this are compile time information and they are static.

 __FILE__ // prints something like D:\User\Project\...\MyMod.d
 I do not like this full path format because it might give hacker some
 idea when of server directory layout structure for webbase cgi / layout,
 accidentally by junior developer because of mis handled exceptions.
 __LINE__ // some line number.

 How about keeping those 2 and also adding some new compile time
 information's tokens:
 1) __FILENAME__ // prints only MyMod.d

std.path.basename(__FILE__);
 2) __MODULE__ // prints the full module name. eg: std.c.windows

.stringof[7 .. $]
 3) __FUNCNAME__ // prints the function name.

If we had __function (see http://d.puremagic.com/issues/show_bug.cgi?id=5140), then it would be __traits(identifier, __function) Also check http://www.digitalmars.com/d/archives/digitalmars/D/FUNCTION_implemented_with_mixins_and_mangles_92055.html
 4) __BLOCKNAME__ // perhaps another name, but prints
 class/struct/interface/template... name. If is global, print global.
 5) __DEBUGLINE__ // prints __MODULE__ ~ __BLOCKNAME__ ~ __FUNCNAME__ ~
 __LINE__

Just define that function if you need it. string __DEBUGLINE__() { return __MODULE__ ~ ":" ~ ...; }
 The reasons for those are:
 1) to make the life of coder simple instead of having to every time call
 a template function/function to trim those information.
 2) Some time the code does gets move around within a large project due
 to re-factoring and remodeling. Having only the file name & line number
 might loose the

 I am rather sure that the compiler will have some Abstract Syntax Tree
 in memory to map value for such tokens.

 It would be even more cool if there is some immutable runtime special
 tokens:
 1) __LOGIN__ // Current user login id, eg: johnchia
 2) __UID__ // User login number, eg: 0, 304,1234,...
 3) __PID__ // Current program process id
 4) __PPID__ // Parent process id
 5) __STIME__ // Start time, date time,2011-02-23 14:45, to see if there
 is a long over due program.
 6) __CMDLINE__ // prints full path name C:\Program
 Files\Notepad++\notepad.exe
 7) __TOTMEM__ // Total amount of memory being used. Read Only, but dynamic.
 8) __MAXMEM__ // Max amount of memory allocated for this process.Read
 Only, but dynamic. (perhaps a new setting may be done at the library or
 function somewhere to limit the total amount of memory being allocated
 by code.) I find that such setting are very useful to limit such within
 a multi-threaded and multi-tasking application such as a web server. I
 helps to reduce the amount of paging needed during runtime and stabilise
 the system.

-8. Use those functions (getuid(), getpid(), etc.) if you need those values. Why make them look like compile-time special tokens?
 These runtime tokens will be very useful for developer to do secure
 coding to check for some runtime Access Control Information or
 preventing denial of service and maybe anti buffer over flowing attacks.

 Perhaps the runtime special information are already available. If not,
 that might be in the future version.

May 25 2011
next sibling parent reply Daniel Gibson <metalcaedes gmail.com> writes:
Am 25.05.2011 15:43, schrieb KennyTM~:
 On May 25, 11 16:29, Matthew Ong wrote:
 Hi all,

 These 2 tokens are very useful for debugging and also trouble shooting
 during exceptions time and even implementing logging api similar to
 log4j:
 I do understand that this are compile time information and they are
 static.

 __FILE__ // prints something like D:\User\Project\...\MyMod.d
 I do not like this full path format because it might give hacker some
 idea when of server directory layout structure for webbase cgi / layout,
 accidentally by junior developer because of mis handled exceptions.
 __LINE__ // some line number.

 How about keeping those 2 and also adding some new compile time
 information's tokens:
 1) __FILENAME__ // prints only MyMod.d

std.path.basename(__FILE__);
 2) __MODULE__ // prints the full module name. eg: std.c.windows

.stringof[7 .. $]
 3) __FUNCNAME__ // prints the function name.

If we had __function (see http://d.puremagic.com/issues/show_bug.cgi?id=5140), then it would be __traits(identifier, __function) Also check http://www.digitalmars.com/d/archives/digitalmars/D/FUNCTION_implemented_with_mixins_and_mangles_92055.html
 4) __BLOCKNAME__ // perhaps another name, but prints
 class/struct/interface/template... name. If is global, print global.
 5) __DEBUGLINE__ // prints __MODULE__ ~ __BLOCKNAME__ ~ __FUNCNAME__ ~
 __LINE__

Just define that function if you need it. string __DEBUGLINE__() { return __MODULE__ ~ ":" ~ ...; }

are you sure this works? this probably returns the module etc where __DEBUGLINE__ resides and not the module etc from where it's called.
 The reasons for those are:
 1) to make the life of coder simple instead of having to every time call
 a template function/function to trim those information.
 2) Some time the code does gets move around within a large project due
 to re-factoring and remodeling. Having only the file name & line number
 might loose the

 I am rather sure that the compiler will have some Abstract Syntax Tree
 in memory to map value for such tokens.

 It would be even more cool if there is some immutable runtime special
 tokens:
 1) __LOGIN__ // Current user login id, eg: johnchia
 2) __UID__ // User login number, eg: 0, 304,1234,...
 3) __PID__ // Current program process id
 4) __PPID__ // Parent process id
 5) __STIME__ // Start time, date time,2011-02-23 14:45, to see if there
 is a long over due program.
 6) __CMDLINE__ // prints full path name C:\Program
 Files\Notepad++\notepad.exe
 7) __TOTMEM__ // Total amount of memory being used. Read Only, but
 dynamic.
 8) __MAXMEM__ // Max amount of memory allocated for this process.Read
 Only, but dynamic. (perhaps a new setting may be done at the library or
 function somewhere to limit the total amount of memory being allocated
 by code.) I find that such setting are very useful to limit such within
 a multi-threaded and multi-tasking application such as a web server. I
 helps to reduce the amount of paging needed during runtime and stabilise
 the system.

-8. Use those functions (getuid(), getpid(), etc.) if you need those values. Why make them look like compile-time special tokens?
 These runtime tokens will be very useful for developer to do secure
 coding to check for some runtime Access Control Information or
 preventing denial of service and maybe anti buffer over flowing attacks.

 Perhaps the runtime special information are already available. If not,
 that might be in the future version.


May 25 2011
next sibling parent KennyTM~ <kennytm gmail.com> writes:
On May 25, 11 21:45, Daniel Gibson wrote:
 5) __DEBUGLINE__ // prints __MODULE__ ~ __BLOCKNAME__ ~ __FUNCNAME__ ~
  __LINE__


Just define that function if you need it. string __DEBUGLINE__() { return __MODULE__ ~ ":" ~ ...; }


__DEBUGLINE__ resides and not the module etc from where it's called.

You're right. It won't work in this form, but it will work if they're present as default parameters. string __DEBUGLINE__(string fn=__FILE__, string ln=__LINE__, etc) { return fn ~ ":" ~ to!string(ln); }
May 25 2011
prev sibling parent reply Matthew Ong <ongbp yahoo.com> writes:
On 5/25/2011 9:45 PM, Daniel Gibson wrote:


.stringof[7 .. $]

4) __BLOCKNAME__ // perhaps another name, but prints
 class/struct/interface/template... name. If is global, print global.


http://www.digitalmars.com/d/archives/digitalmars/D/FUNCTION_implemented_with_mixins_and_mangles_92055.html ---------------------------------------------------------------------------
 Use those functions (getuid(), getpid(), etc.) if you need those values.
  Why make them look like compile-time special tokens?


tokens: Defining them as variable makes the code independent from OS(win32/lin/OSX) API. 1) __LOGIN__ // Current user login id, eg: johnchia 2) __UID__ // User login number, eg: 0, 304,1234,... 3) __PID__ // Current program process id 4) __PPID__ // Parent process id 5) __STIME__ // Start time, date time,2011-02-23 14:45, to see if there is a long over due program. 6) __CMDLINE__ // prints full path name C:\Program Files\Notepad++\notepad.exe 7) __TOTMEM__ // Total amount of memory being used. Read Only, but dynamic. 8) __MAXMEM__ // These runtime tokens will be very useful for developer to do secure coding to check for some runtime Access Control Information or preventing denial of service and maybe anti buffer over flowing attacks. Perhaps the runtime special information are already available. If not, that might be in the future version. Thanks very much for the URL. -- Matthew Ong email: ongbp yahoo.com
May 25 2011
next sibling parent Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 5/25/11 9:23 AM, Matthew Ong wrote:
 On 5/25/2011 9:45 PM, Daniel Gibson wrote:


  >.stringof[7 .. $]
 Belonging to which object or variable?

 4) __BLOCKNAME__ // perhaps another name, but prints
  >> class/struct/interface/template... name. If is global, print global.
 How about this one? The class which the fuction belows

 http://www.digitalmars.com/d/archives/digitalmars/D/FUNCTION_implemented_with_mixins_and_mangles_92055.html



 ---------------------------------------------------------------------------

 Use those functions (getuid(), getpid(), etc.) if you need those values.
 Why make them look like compile-time special tokens?


tokens: Defining them as variable makes the code independent from OS(win32/lin/OSX) API.

Good standard library artifacts make the code independent from OS. Andrei
May 25 2011
prev sibling parent reply KennyTM~ <kennytm gmail.com> writes:
On May 25, 11 22:23, Matthew Ong wrote:
 On 5/25/2011 9:45 PM, Daniel Gibson wrote:


  >.stringof[7 .. $]
 Belonging to which object or variable?

Belongs to the module. '.xxx' is D's syntax for access a global object (derived from C++'s '::xxx' syntax). Please read through the whole D specification. (Frankly speaking this is a DMD-specific hack as the spec has never required that the .stringof of a module must return "module foo.bar.baz".)
 4) __BLOCKNAME__ // perhaps another name, but prints
  >> class/struct/interface/template... name. If is global, print global.
 How about this one? The class which the fuction belows

 http://www.digitalmars.com/d/archives/digitalmars/D/FUNCTION_implemented_with_mixins_and_mangles_92055.html



 ---------------------------------------------------------------------------

 Use those functions (getuid(), getpid(), etc.) if you need those values.
 Why make them look like compile-time special tokens?


tokens:

It is easy to tell if a runtime function returns "immutable" value: a pure function that takes no arguments. pure int f(); //^^^^
 Defining them as variable makes the code independent from
 OS(win32/lin/OSX) API.

 1) __LOGIN__ // Current user login id, eg: johnchia
 2) __UID__ // User login number, eg: 0, 304,1234,...
 3) __PID__ // Current program process id
 4) __PPID__ // Parent process id
 5) __STIME__ // Start time, date time,2011-02-23 14:45, to see if there
 is a long over due program.
 6) __CMDLINE__ // prints full path name C:\Program
 Files\Notepad++\notepad.exe
 7) __TOTMEM__ // Total amount of memory being used. Read Only, but dynamic.
 8) __MAXMEM__ //

 These runtime tokens will be very useful for developer to do secure
 coding to check for some runtime Access Control Information or
 preventing denial of service and maybe anti buffer over flowing attacks.
 Perhaps the runtime special information are already available. If not,
 that might be in the future version.

I don't see how these 8 information _prevent_ DoS attack. And D already has anti-buffer-overflow protection: range checking (in SafeD, at least).
 Thanks very much for the URL.

May 25 2011
next sibling parent Matthew Ong <ongbp yahoo.com> writes:
On 5/25/2011 10:46 PM, KennyTM~ wrote:
 I don't see how these 8 information _prevent_ DoS attack.  And D already
 has anti-buffer-overflow protection: range checking (in SafeD, at least).

Actually these allow the application developer to write some self regulating routine threads to check for such thing and see how many pid file is created within the /var/myprogram/pids directory. For denial of service. STIME to see how long this instance is already running if it is a CGI. CMDLINE to see if there is shift to the file layout. TOTMEM MAXMEM // Max amount of memory allocated for this process.Read Only, but dynamic. (perhaps a new setting may be done at the library or function somewhere to limit the total amount of memory being allocated by code.) I find that such setting are very useful to limit such within a multi-threaded and multi-tasking application such as a web server. I helps to reduce the amount of paging needed during runtime and stabilise the system. In Java JVM: -X options -Xms<size> set initial Java heap size -Xmx<size> set maximum Java heap size -Xss<size> set java thread stack size has more as JVM start up options... but they are NOT available with the JDK API as info also... :( actually there is a lot more things you can counter check with ps -ef or so on... Perhaps, I should have use the word checking for DoS instead of prevention. But if the CGI redirect the page to a busy static page, that should know. Hope that this make some sense. The same logic with variable can also be used to develop a robust server or middle tier. -- Matthew Ong email: ongbp yahoo.com
May 25 2011
prev sibling parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 5/25/11 10:50 AM, Jose Armando Garcia wrote:
 On Wed, May 25, 2011 at 11:46 AM, KennyTM~<kennytm gmail.com>  wrote:
 On May 25, 11 22:23, Matthew Ong wrote:
 On 5/25/2011 9:45 PM, Daniel Gibson wrote:


   >.stringof[7 .. $]
 Belonging to which object or variable?

Belongs to the module. '.xxx' is D's syntax for access a global object (derived from C++'s '::xxx' syntax). Please read through the whole D specification. (Frankly speaking this is a DMD-specific hack as the spec has never required that the .stringof of a module must return "module foo.bar.baz".)

Is this evaluated at compile time? I prefer to use this for std.log over __FILE__ when filtering verbose log messages. The user is more likely to remember the module name and not the file name.

It is. Probably it's a good idea to use module name, which is unique across an application, unlike the (directory-less) file name. Andrei
May 25 2011
parent Matthew Ong <ongbp yahoo.com> writes:
On 5/26/2011 6:05 AM, Jose Armando Garcia wrote:

 It is. Probably it's a good idea to use module name, which is unique across
 an application, unlike the (directory-less) file name.

Yes. It should be, there is a defense contractor that I used to work with as a client ask if there is anyway to check for such code. That is from another language but the principles are the same.
 Actually, '.stringof' is not good enough for my use case. I would
 really like __MODULE__! The nice thing about the __FILE__ and __LINE__
 is that they are evaluated at the call site. It doesn't matter if you
 use them in the value of template parameter or in the value of
 function parameter. '.stringof' is getting evaluated in the module
 where the function is declared so it is not really useful as a default
 value. In other words I can't use it for std.log without polluting the
 API.

 void func() { grabModuleName(); }
 void main() { func(); }
 $ ./test_module
 module test_module2
not really useful

writing a log library and to record the calling module info. May I also add this. __BLOCKNAME__ // Since in D, as I have seen within the phobos, the source file are huge. class/struct/interface/template... name. and if there is any refactoring donem,within the webproject, on the existing source in the future, how do we track by just __FILE__ __LINE__ when it might have changed without changing the class/struct/interface name to else where? Reading this and trying out the sample. http://www.digitalmars.com/d/archives/digitalmars/D/FUNCTION_implemented_with_mixins_and_mangles_92055.html // Parsing mangles for fun and profit. string _getJustName(string mangle){ size_t idx = 1; size_t start = idx; size_t len = 0; while(idx < mangle.length && mangle[idx] >= '0' && mangle[idx] <= '9'){ int size = mangle[idx++] - '0'; while(mangle[idx] >= '0' && mangle[idx] <= '9') size = (size * 10) + (mangle[idx++] - '0'); start = idx; len = size; idx += size; } if(start < mangle.length) return mangle[start .. start + len]; else return ""; } // Eheheh, I has a __FUNCTION__. const string FuncNameMix = "static if(!is(typeof(__FUNCTION__)))" "{ struct __FUNCTION {} const char[] __FUNCTION__ =" "_getJustName(__FUNCTION.mangleof); }"; static this(){ mixin(FuncNameMix); writeln("This is run within: ",__FUNCTION__); } class MyClassB { this(){ mixin(FuncNameMix); writeln("This is run within: ",__FUNCTION__); } ~this(){ mixin(FuncNameMix); writeln("This is run within: ",__FUNCTION__); } } class MyClassA { this() { mixin(FuncNameMix); writeln("This is run within: ",__FUNCTION__); } ~this(){ mixin(FuncNameMix); writeln("This is run within: ",__FUNCTION__); } void showInfo(){ mixin(FuncNameMix); // ### each mixin insert binary writeln("This is run within: ",__FUNCTION__); } } void main(string[] args){ funcMyFuncA(); writeln("Creating MyClassA()..."); MyClassA objA=new MyClassA(); objA.showInfo(); MyClassB objB=new MyClassB(); // ### How to tell the output of this from A __ctor?? writeln("Done running MyClassA()..."); } __FUNCTION__ seems to only work for a functions and not: 1) Class/struct/interface where there are perhaps over 20 methods each. Mixin 20 times?? that will take up lots of binary code size with the dll/exe. 2) How to tell which block of code that __FUNCTION__ message belongs to? Thanks for the source code and URL from these places. It does open up eye for me about code interacting with D compiler directly. However, I and think many others would sure like if there is more build in compiler generated information like __FILE__ automatically WITHOUT using mixin all over the places as overhead to the runtime instead of compile time. -- Matthew Ong email: ongbp yahoo.com
May 26 2011
prev sibling next sibling parent Jose Armando Garcia <jsancio gmail.com> writes:
On Wed, May 25, 2011 at 11:46 AM, KennyTM~ <kennytm gmail.com> wrote:
 On May 25, 11 22:23, Matthew Ong wrote:
 On 5/25/2011 9:45 PM, Daniel Gibson wrote:


 =A0>.stringof[7 .. $]
 Belonging to which object or variable?

Belongs to the module. '.xxx' is D's syntax for access a global object (derived from C++'s '::xxx' syntax). Please read through the whole D specification. (Frankly speaking this is a DMD-specific hack as the spec has never requi=

 that the .stringof of a module must return "module foo.bar.baz".)

Is this evaluated at compile time? I prefer to use this for std.log over __FILE__ when filtering verbose log messages. The user is more likely to remember the module name and not the file name.
 4) __BLOCKNAME__ // perhaps another name, but prints
 =A0>> class/struct/interface/template... name. If is global, print globa=


 How about this one? The class which the fuction belows


 http://www.digitalmars.com/d/archives/digitalmars/D/FUNCTION_implemented=


 ------------------------------------------------------------------------=


 Use those functions (getuid(), getpid(), etc.) if you need those values=



 Why make them look like compile-time special tokens?


tokens:

It is easy to tell if a runtime function returns "immutable" value: a pur=

 function that takes no arguments.

 =A0 =A0pure int f();
 =A0//^^^^

 Defining them as variable makes the code independent from
 OS(win32/lin/OSX) API.

 1) __LOGIN__ // Current user login id, eg: johnchia
 2) __UID__ // User login number, eg: 0, 304,1234,...
 3) __PID__ // Current program process id
 4) __PPID__ // Parent process id
 5) __STIME__ // Start time, date time,2011-02-23 14:45, to see if there
 is a long over due program.
 6) __CMDLINE__ // prints full path name C:\Program
 Files\Notepad++\notepad.exe
 7) __TOTMEM__ // Total amount of memory being used. Read Only, but
 dynamic.
 8) __MAXMEM__ //

 These runtime tokens will be very useful for developer to do secure
 coding to check for some runtime Access Control Information or
 preventing denial of service and maybe anti buffer over flowing attacks.
 Perhaps the runtime special information are already available. If not,
 that might be in the future version.

I don't see how these 8 information _prevent_ DoS attack. =A0And D alread=

 anti-buffer-overflow protection: range checking (in SafeD, at least).

 Thanks very much for the URL.


May 25 2011
prev sibling parent Jose Armando Garcia <jsancio gmail.com> writes:
On Wed, May 25, 2011 at 1:20 PM, Andrei Alexandrescu
<SeeWebsiteForEmail erdani.org> wrote:
 On 5/25/11 10:50 AM, Jose Armando Garcia wrote:
 On Wed, May 25, 2011 at 11:46 AM, KennyTM~<kennytm gmail.com> =A0wrote:
 On May 25, 11 22:23, Matthew Ong wrote:
 On 5/25/2011 9:45 PM, Daniel Gibson wrote:


 =A0>.stringof[7 .. $]
 Belonging to which object or variable?

Belongs to the module. '.xxx' is D's syntax for access a global object (derived from C++'s '::xxx' syntax). Please read through the whole D specification. (Frankly speaking this is a DMD-specific hack as the spec has never required that the .stringof of a module must return "module foo.bar.baz".)

Is this evaluated at compile time? I prefer to use this for std.log over __FILE__ when filtering verbose log messages. The user is more likely to remember the module name and not the file name.

It is. Probably it's a good idea to use module name, which is unique acro=

 an application, unlike the (directory-less) file name.

Actually, '.stringof' is not good enough for my use case. I would really like __MODULE__! The nice thing about the __FILE__ and __LINE__ is that they are evaluated at the call site. It doesn't matter if you use them in the value of template parameter or in the value of function parameter. '.stringof' is getting evaluated in the module where the function is declared so it is not really useful as a default value. In other words I can't use it for std.log without polluting the API. Example: --- $ cat test_module.d module test_module; import test_module2; void func() { grabModuleName(); } void main() { func(); } $ cat test_module2.d module test_module2; import std.stdio; void grabModuleName(string moduleName =3D .stringof)() { writeln(moduleName); } $ dmd test_module test_module2 $ ./test_module module test_module2 --- -Jose
 Andrei

May 25 2011
prev sibling parent reply pillsy <pillsbury gmail.com> writes:
== Quote from Matthew Ong (ongbp yahoo.com)'s article

 These 2 tokens are very useful for debugging and also trouble
 shooting during exceptions time and even implementing logging
 api similar to log4j:

 I do understand that this are compile time information and they
 are static.
 __FILE__  // prints something like D:\User\Project\...\MyMod.d
               I do not like this full path format because it
 might give hacker some idea when of server directory layout
 structure for webbase cgi /  layout, accidentally by junior
 developer because of mis handled exceptions.

This seems like a pretty weak reason (especially since it gives you the path of the *source file* in a compilation environment).
 __LINE__  // some line number.

 How about keeping those 2 and also adding some new compile time
 information's tokens:
 1) __FILENAME__   // prints only MyMod.d

Use CTFE. I don't disagree in principle with the idea of additional tokens, but I'm not sure the ones you're talking about make a lot of sense. I would like to see __COLUMN__, and I know adding it has been discussed, because it's the sort of thing one ought to be able to get from the compiler and it might be useful. One addition that I would advocate for whic isn't on your list is a token called __GENSYM__ (or perhaps __UNIQUE__ would be a better name), which returns a string that's guaranteed to be unique and usable as an identifier; this could provide additional safety when metaprogramming with mixin templates and string mixins. Right now you have to do hacky and not-terribly-robust things to synthesize unique IDs out of __FILE__ and __LINE__. Cheers, Pillsy
May 25 2011
next sibling parent Matthew Ong <ongbp yahoo.com> writes:
On 5/25/2011 10:37 PM, pillsy wrote:
 == Quote from Matthew Ong (ongbp yahoo.com)'s article
 I do understand that this are compile time information and they
 are static.
 __FILE__  // prints something like D:\User\Project\...\MyMod.d
                I do not like this full path format because it
 might give hacker some idea when of server directory layout
 structure for webbase cgi /  layout, accidentally by junior
 developer because of mis handled exceptions.


 This seems like a pretty weak reason (especially since it gives
 you the path of the *source file* in a compilation environment).

Hmm... Somehow they do not think so. And I do know a Defense Ministry core vendor looks for this.
 __LINE__  // some line number.

 How about keeping those 2 and also adding some new compile time
 information's tokens:
 1) __FILENAME__   // prints only MyMod.d

Use CTFE. I don't disagree in principle with the idea of additional tokens, but I'm not sure the ones you're talking about make a lot of sense. I would like to see __COLUMN__, and I know adding it has been discussed, because it's the sort of thing one ought to be able to get from the compiler and it might be useful.

 One addition that I would advocate for whic isn't on your list is
 a token called __GENSYM__ (or perhaps __UNIQUE__ would be a better
 name), which returns a string that's guaranteed to be unique and
 usable as an identifier; this could provide additional safety when
 metaprogramming with mixin templates and string mixins. Right now

serialization. Yeah. I agree I missed that out.
 you have to do hacky and not-terribly-robust things to synthesize
 unique IDs out of __FILE__ and __LINE__.

Not too sure about the routine to call in D.
 Cheers,
 Pillsy

-- Matthew Ong email: ongbp yahoo.com
May 25 2011
prev sibling next sibling parent reply Matthew Ong <ongbp yahoo.com> writes:
On 5/25/2011 10:37 PM, pillsy wrote:
 Use CTFE.

-- Matthew Ong email: ongbp yahoo.com
May 25 2011
parent Daniel Gibson <metalcaedes gmail.com> writes:
Am 25.05.2011 17:56, schrieb Matthew Ong:
 On 5/25/2011 10:37 PM, pillsy wrote:
 Use CTFE.


http://www.digitalmars.com/d/2.0/function.html#interpretation
May 25 2011
prev sibling parent bearophile <bearophileHUGS lycos.com> writes:
pillsy:

 One addition that I would advocate for whic isn't on your list is
 a token called __GENSYM__ (or perhaps __UNIQUE__ would be a better
 name), which returns a string that's guaranteed to be unique and
 usable as an identifier; this could provide additional safety when
 metaprogramming with mixin templates and string mixins.

"__GENSYM__" name is too much ugly, and it's essentially a compile time function that keeps a size_t state across calls, so "gensym()" name seems better to me. Bye, bearophile
May 25 2011