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.


Huh??

-- 
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
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__ ~ ":" ~ ...;
  }




 are you sure this works? this probably returns the module etc where
 __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 .. $]


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?




It would be even more cool if there is some immutable >RUNTIME< special 
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?




 It would be even more cool if there is some immutable >RUNTIME< special
 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?




 It would be even more cool if there is some immutable >RUNTIME< special
 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 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=


red

 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=




l.

 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?




 It would be even more cool if there is some immutable >RUNTIME< special
 tokens:


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


e

 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=


y has

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


 Thanks very much for the URL.
May 25 2011
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 reply 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=


ss

 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
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.


https://www.owasp.org/index.php/Fuzzing#File_format_fuzzing
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


Yes, I would have to agree as not really useful. Most of us will be 
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(){

  	  writeln("This is run within: ",__FUNCTION__); 		
	}
}


  void main(string[] args){
  	funcMyFuncA();
  	writeln("Creating MyClassA()..."); 		
	MyClassA objA=new MyClassA();
  	objA.showInfo();

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 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).


https://www.owasp.org/index.php/Fuzzing#File_format_fuzzing
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


I believe that would be the __UUID__/__GUID__ used within Object type
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__.


Try: __UUID__ = sha512_hash(__FILE__ ~ __LINE__ ~ __FUNCTION__)
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.


What is that? Some URL please.


-- 
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.


 What is that? Some URL please.
 
 


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