Re: [fpc-devel] Stack dump with possible segfault
Hi again! Am Montag, den 12.05.2014, 23:33 +0200 schrieb Johann Glaser: Hi! I'm working on a project with an external library (libtcl, it is written in C) which creates some problems with back traces for exceptions. If a custom TCL command raises an exception, I catch it and use the function DumpExceptionBackTrace to print the back trace. This function uses RaiseList which returns the ExceptObjectStack pointer. The stack frame information is filled by fpc_PushExceptObj in except.inc using the functions get_frame, get_caller_addr and get_caller_frame. These three functions are also used by dump_stack which can be used at any point in the code (outside of exceptions). These three functions assume, that the stack frame is stored in the RBP register (x86_64 architecture) and that every function call starts with these two assembler instructions push %rbp mov%rsp,%rbp which leads to the stack layout of the return address (pushed by the call instruction) followed by the RBP value. As this is true for FreePascal code (I guess), this doesn't necessarily hold for external libraries as the TCL library mentioned above. News on that front: Today I investigated a duplicate key exception in FGL.TFPSMaps.Add(AKey: Pointer): Integer. In the current Debian package fp-units-rtl-2.6.4 2.6.4+dfsg-2 this seems to be compiled with looots of optimization and without stack frame: 1918 FGL_TFPSMAP_$__ADD$POINTER$$LONGINT: 1918: 48 81 ec 18 01 00 00sub$0x118,%rsp 191f: 48 89 9c 24 08 01 00mov%rbx,0x108(%rsp) 1926: 00 1927: 4c 89 a4 24 10 01 00mov%r12,0x110(%rsp) 192e: 00 192f: 48 89 fbmov%rdi,%rbx 1932: 49 89 f4mov%rsi,%r12 Even GDB couldn't trace back the stack there. :-O Bye Hansi ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] TCL
Hi! Am Dienstag, den 13.05.2014, 11:46 +0200 schrieb Tomas Hajny: On Tue, May 13, 2014 10:54, Johann Glaser wrote: Hi! Hi, I'm working on a project with an external library (libtcl, it is written in C) which creates some problems with back traces for exceptions. . . While not completely related to your original topic, I'd like to ask you if you decided knowingly not to use the package tcl provided with FPC (and possibly improve / extend it for your target platform) and if so, what were your reasons. I ask because I'm not sure to which extent it's used and/or maintained, especially considering that it supports a fairly limited set of platforms measured by current FPC span and that the included name of the TCL DLL for Win32 does not seem to match currently available TCL version. Should the package not to be useful any longer, we should probably either update it (if anyone volunteers to maintain it, because I suspect that the original maintainer is not involved actively any longer), or consider deprecating it. I have to admit that I didn't consider that there could already be a TCL unit available. Therefore I did a full header translation for TCL 8.4 (which was the current version at that time). Additionally I added an object oriented wrapper to ease the programming. Please see at https://github.com/hansiglaser/pas-tcl for the sources. I use this library (together with pas-readline) in several projects (e.g. eztool on Github), some of which are actively in development but not yet published. It currently works perfectly with TCL 8.5, but I didn't (yet) update the header translations. I'd be happy for any help improving the library or even inclusion in FPC! Since you already use TCL, could you please check if the version included with FPC is still useable at all with the currently available TCL version? I guess that you'd be probably able to modify one of your test programs to only use functions available in the older TCL version (or create another simple test for that purpose if that would be easier)? I used the files in /usr/share/fpcsrc/2.6.4/packages/tcl/ which also include a demo program. I had to do the following changes: - tcl80.pp: remove the $define USE_C - tcl80.pp: change TCL_LIBRARY = 'tcl8.5'; - tcl80.pp: in function ArgvItem I removed the ridiculous assembler stuff by the simple line Result := argv[Idx];. This expression should also be used in tcl_demo.pp, btw. - copied over test.tcl from a quite old SVN checkout of http://svn.freepascal.org/svn/fpc/trunk (2011-03-05) I had somewhere on my disk Then compilation worked properly and the demo works too. Using tcl8.6 also works. Depending on the result (and compatibility of the relevant licences), we have to agree with other members of the FPC core team on the most sensible approach. I noticed that there are some obvious differences in used types (pointer versus PChar, minor differences in parameter or record member names, etc.) between the two translations, but these might not impose a major issue. Ok. PS: I've mentioned the TCL library in the fpc-pascal list some time ago: http://lists.freepascal.org/fpc-pascal/2012-September/035177.html I see; I probably missed it then. BTW, I noticed that you refer to file license.terms in multiple places of your repository, but I couldn't find that file there. That is a verbatim cite of the original TCL header files. Is it necessary to include their file with my Pascal translations? Thanks Hansi ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
[fpc-devel] Stack dump with possible segfault
Hi! I'm working on a project with an external library (libtcl, it is written in C) which creates some problems with back traces for exceptions. If a custom TCL command raises an exception, I catch it and use the function DumpExceptionBackTrace to print the back trace. This function uses RaiseList which returns the ExceptObjectStack pointer. The stack frame information is filled by fpc_PushExceptObj in except.inc using the functions get_frame, get_caller_addr and get_caller_frame. These three functions are also used by dump_stack which can be used at any point in the code (outside of exceptions). These three functions assume, that the stack frame is stored in the RBP register (x86_64 architecture) and that every function call starts with these two assembler instructions push %rbp mov%rsp,%rbp which leads to the stack layout of the return address (pushed by the call instruction) followed by the RBP value. As this is true for FreePascal code (I guess), this doesn't necessarily hold for external libraries as the TCL library mentioned above. In my particular case, GDB shows the following back trace after hitting a breakpoint in my custom TCL function implemented in INSERTTRFSMWRAPPER: #1 0x0040eb3c in INSERTTRFSMWRAPPER (this=0x77fe8340, OBJC=1, OBJV=0x79d080) at trfsmgen.lpr:2552 #2 0x0048f86f in CMDCALLER (CLIENTDATA=0x77fe8cc0, INTERP=0x78f700, OBJC=1, OBJV=0x79d080) at ../pas-tcl/src/tcloop.pas:317 #3 0x77aea8f8 in TclEvalObjvInternal (interp=interp@entry=0x78f700, objc=objc@entry=1, objv=objv@entry=0x79d080, command=0x77fe9890 'insert_trfsm_wrapper', length=20, flags=flags@entry=0) at /tmp/buildd/tcl8.5-8.5.15/unix/../generic/tclBasic.c:3708 #4 0x77aeb85b in TclEvalEx (interp=0x78f700, script=0x77fe9890 'insert_trfsm_wrapper', numBytes=optimized out, flags=optimized out, line=line@entry=1, clNextOuter=clNextOuter@entry=0x0, outerScript=0x77fe9890 'insert_trfsm_wrapper') at /tmp/buildd/tcl8.5-8.5.15/unix/../generic/tclBasic.c:4407 #5 0x77aeb096 in Tcl_EvalEx (interp=optimized out, script=optimized out, numBytes=optimized out, flags=optimized out) at /tmp/buildd/tcl8.5-8.5.15/unix/../generic/tclBasic.c:4064 #6 0x0048fe65 in EVAL (this=0x77fe8380, SCRIPT=0x77fe9890 'insert_trfsm_wrapper') at ../pas-tcl/src/tcloop.pas:385 #7 0x004db8a2 in EXECUTE (this=0x77fde1c0, COMMAND=0x77fe9890 'insert_trfsm_wrapper') at ../pas-tcl/src/tclcmdline.pas:230 #8 0x004da790 in EXECUTE (this=0x77fde1c0, COMMAND=0x77fe9890 'insert_trfsm_wrapper') at ../pas-tcl/src/tclcmdlinepredef.pas:184 #9 0x004dbe49 in COMMANDLOOP (this=0x77fde1c0) at ../pas-readline/src/cmdline.pas:81 #10 0x004daf89 in COMMANDLOOP (this=0x77fde1c0) at ../pas-tcl/src/tclcmdline.pas:76 #11 0x004923ad in RUN (this=0x77fe8340) at ../pas-tcl/src/tclapp.pas:63 #12 0x004133ed in main () at trfsmgen.lpr:3319 This list is very reasonable. TclEvalObjvInternal() is disassembled as follows: Dump of assembler code for function TclEvalObjvInternal: 0x77aea6c0 +0: push %r15 0x77aea6c2 +2: mov%rcx,%r15 0x77aea6c5 +5: push %r14 0x77aea6c7 +7: push %r13 0x77aea6c9 +9: push %r12 0x77aea6cb +11:mov%esi,%r12d 0x77aea6ce +14:push %rbp 0x77aea6cf +15:mov%rdi,%rbp 0x77aea6d2 +18:push %rbx 0x77aea6d3 +19:mov%r9d,%ebx ... RBP is the 5th register pushed to the stack instead of the first one. The function TclEvalEx() looks similar but pushes different registers before RBP. Now there are two problems: 1) DumpExceptionBackTrace and dump_stack don't show the full stack trace. 2) Both functions dereference values which were taken from the stack and go through a linked list (which is not guaranteed to be working), therefore dereferencing values which might not even be pointers. Problem 1) is inconvenient but just a cosmetic thing. I had a look at the GDB sources (backtrace_command() in gdb/stack.c and get_current_frame() and get_prev_frame_1() in gdb/frame.c), but especially the latter function is extremely complicated and trying multiple approaches to unwind the stack. I gave up on this. :-( The more important thing is problem 2) since it potentially creates a segfault. Two counter-measures are already met in dump_stack: the previous frame must be at a lower memory address as the current frame (because push decreases RSP), and zero-pointers are used as stop conditions. I suggest that additionally the RBP values are checked that they are within the program stack address range and divisible by SizeOf(PtrUInt). Further, the caller address (=return address) should be checked that it is within the program code address range. This might get a bit tricky for shared libraries. For this debugging
[fpc-devel] Script Language, TCL Update
Hi! I want to equip a program with a command line and plan to use a real scripting language to interpret the user input. I've looked around a bit (e.g. in the mailing list archives) and found some languages: - PascalScript - JavaScript - Lua - TCL Only the latter has a command line friendly syntax, i.e. the parameters are entered separated by spaces, like for the shell. So far, could you recommend me any other command line friendly language? After that, my second point. Happily, FreePascal comes with a TCL package, but this is linked to TCL 8.0, while 8.5 is the current version. Did anybody update the unit? Is anybody interested in an updated unit? Would you include it to the official FreePascal distribution if I send an updated unit? Thanks Hansi ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Dynamic Arrays as Static class variables
Hi! Am Dienstag, den 05.10.2010, 10:50 +0300 schrieb Juha Manninen (gmail): On Tuesday 05 October 2010 01:00:19 Willibald Krenn wrote: Hi, I just tried and can reproduce this with fpc rev. 16078 on win64. Same thing here on Linux , AMD64, few days old FPC trunk version. Thank you for trying and confirming. Should I submit a bug report? Bye Hansi ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
[fpc-devel] Dynamic Arrays as Static class variables
Hi! It seems there is a problem with dynamic arrays which are defined as static variables in classes. Type TTest = class FDynArr : Array of Integer; static; End; When the class is Destroy()ed, the call to CleanupInstance, which calls fpc_finalize, does a fpc_dynarray_decr_ref which generates a SEGV. Did anybody else experience this problem (using FPC2.4.0-2 on a AMD64 machine). If not, I'll put a test case together. Bye Hansi ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] High performance Linux timer
Hi! Does anybody know if there is a Linux (or generic Unix) high performance timer API available. Something like the Win32 API QueryPerformanceCounter()? Probably the Time-Stamp-Counter for your CPU is of interest for you. See http://en.wikipedia.org/wiki/Rdtsc for example code. Bye Hansi ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] In FPC written FPC Debugger
Hi! - Display STL types (e.g. std::string, std::vector, std::map). These are the usual way of making strings and containers in C++ and are quite complex internally. GDB displays this internal structure of these types instead of beautifying it according to its semantics. For the containers it's even impossible to view its elements. This is a limitation of the user interface you are using on top of the gdb infrastructure, as e.g. Xcode (which uses the gdb mi) does display such types. Yea, I already thought that Eclipse, DDD, Anjuta, ... could also wrap that functionality. But with your statement nearly every missing feature in GDB can be dropped by referring to the UI. - Set breakpoints within template functions. A template function might be instantiated multiple times, i.e. for every type it is used for. If you set a breakpoint at the source line within a template function, only one instantiation is (randomly?) chosen. Use the rbreak command instead of break (and you may also have to use dwarf instead of stabs). (gdb) help rbreak Set a breakpoint for all functions matching REGEXP. Hmm, so, this is just a workaround and only works for the start of a function, as far as I understand the help message. But nevertheless, thanks for the hint. Bye Hansi ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] In FPC written FPC Debugger
Hi! On Fre, 2008-02-22 at 09:20 +0100, Michael Schnell wrote: Lack of Pascal support like with, local procedures, widestrings, dynamic arrays, properties is platform independend. Therefore all platforms would benefit. Are these things depending on the internal structures of GDB part and informations for the executables that is needed to be used under a GIU like Lazarus or Eclipse ) or is it just a shortcoming of the command line user interface of GDB ? Would it not be more appropriate to enhance GDB itself instead of setting up a completely new project. This seems to be a lot less work that reinventing the wheel. I feel that Delphi language is not the only language that offers features like or similar to local procedures, widestrings, dynamic arrays, properties. So this effort should be supported by the powers of GDB. I want to second that. GDB also lacks some features very useful for C++ programmers (yes, I have to use it): - Display STL types (e.g. std::string, std::vector, std::map). These are the usual way of making strings and containers in C++ and are quite complex internally. GDB displays this internal structure of these types instead of beautifying it according to its semantics. For the containers it's even impossible to view its elements. - Set breakpoints within template functions. A template function might be instantiated multiple times, i.e. for every type it is used for. If you set a breakpoint at the source line within a template function, only one instantiation is (randomly?) chosen. Hmm, these rather like a GDB wish list bug report looking items point out that GDB doesn't even intensively care about C++ (despite it supports name (de-)mangling). Besides the mentioned points, I really dissuade from starting with a completely new debugger project, since there is so many basic work to implement and to care for and then to support. The FPC community is IMHO still too small for such a project. And GDB still lacks a lot of improvements. Bye Hansi ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
RE: [fpc-devel] BlackFin
Hi! Sorry, i forgot to mention a valuable source of information: http://www.bluetechnix.at/ Coincidental I'm (partly) working for this company and know their staff quite well. If you need any assistance or similar I'd be happy to help out. Bye Hansi ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] BlackFin
Hi! Am Montag, den 16.04.2007, 11:57 +0200 schrieb Michael Schnell: r2 = r1 + r3, r4 = dm(i0,m1); /* addition and memory access */ Yep. In my answer to Florian I forgot that (other than ARM) the Blackfin can do a calculation and a memory access in a single instruction cycle. That explains the much better performance even with standard (non-DSP-alike) tasks. r3 = r2 * r4, r1 = r2 + r4;/* multiplication and addition */ I did not know yet that it can do two independent 32 bit calculations and that it can do 32 bit multiplications. Anyway, even if only two 32 additions can be done in one instruction cycle this is a big chance for optimization. The above code is based on an example program for some Shark or TigerShark DSP, so its likely that the BlackFin has other processing units. I've written the code just as an example for the algebraic style. You have to carefully study the structure of the CPU (i.e. processing units, busses, registers, address calculation, ...) to know what can be done in parallel. In the example I've looked at there was a line with 4-instructions-in-1-cycle: f10 = f2 * f4, f12 = f10 + f12, f2 = dm(i1,m2), f4 = pm(i8,m8); (ADSP-2106x). In modern CPUs the parallel utilization of busses and processing units is state of the art. The ressource allocation and parallelization is done on the fly during program execution by some smart logic inside the CPU. When a compiler does optimization for a certain CPU it anticipates this and sorts the instructions and registers approprately to gain a few percent more speed. The beauty of DSPs is that its in the hand of the compiler (or assembler coder) to do the full optimization. Bye Hansi ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] BlackFin
Hi! regarding the ASM code is very strange if you compare it to the code of 80x86, PPC or ARM. As far as I have seen the BlackFin has two cores: an arm like risc core and a dsp. The BlackFin and other Analog Devices DSPs have an uncommon assembler syntax. Contrary to well-known mnemonic style like add eax,ecx they use an algebraic syntax like r2 = r1 + r3, r4 = dm(i0,m1); /* addition and memory access */ r3 = r2 * r4, r1 = r2 + r4;/* multiplication and addition */ Regarding the implementation for a compiler this is no principal problem, because the compiler has an internal representation of what it wants to do, and this can be equally expressed in (=transformed to) mnemonic and algebraic syntax. A totally different topic is the inherent parallel processing of a DSP. Usually they can utilize several processing units (+, *) and memories within a single cycle (e.g. see above). Instruction ordering and interleaving to utilize parallelism is tedious to do by hand and I think also challenging for a compiler. Bye Hansi ___ fpc-devel maillist - [EMAIL PROTECTED] http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] space char inside identifier's name
Hi! Am Samstag, den 25.03.2006, 17:19 +0700 schrieb Bisma Jayadi: Foo a.bar a := baz b[4].foo q You made a very excessive example. Of course we don't HAVE TO use space char all the times. I won't use it that way either. But it's there when we really want/need it. is harder to read! It's not the char itself, it's that it's used all over the place whenever this is used. I don't like it. Maybe you don't like it and that's alright. This feature won't harm you in any ways. But some other people could demand it in some circumstances. That is wrong. If the possibility exists, it will be used (at least in some cases by some people). In many cases this code will have to be maintained by different people too. There will be guys which can't stand this kind of identifiers but they are forced to use it. So this feature renders to a limitation of freedom and productivity of programmers. The proposed idea has big drawbacks: - code gets unreadable and unmaintainable (eye-ball search for mating '' chars, finding seperations between identifiers) - the linker doesn't support special chars inside variable names so automatic name manging would be necessary - people are stimulated to use identifiers in their natural language instead of short and pregnant keywords - somebody could have the idea to demand Unicode characters inside identifiers, cooperative software development (as widely exercised in Open Source and Free Software development) across different countries and languages comes to a stagnation due to lack of available characters on the programmer's keyboards (or could you write German äöüÄÖÜß, or even Russian cyrillic letters without painful tricks?) - create heavy incompatibilities with Delphi, Turbo Pascal, ... - and finally, a personal argument: The professional programming language Pascal is shifted towards kiddies and wannabe programmers and I personally want to prevent that FreePascal resembles Visual Basic or other language for blowhards. For your game maker application (which is intended for kiddies and wannabies, I guess), do the name mangling in your application and let the compiler and underlying language be a tool for professionals. Bye Hansi ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] PR: What sites to spam for 2.0.2 release?
Hi! Speaking of PR, we have a 2.0.2 to announce within a very short time and we better do it well. We won't be able to do a Slashdot or OSnews announcement, nevertheless we should take these opportunities to promote FPC. So, any ideas what sites we should spam? I'm looking for developer focused sites. Pascal/Delphi related sites are welcome, but remember we are already quite famous in that world. We need generic open source related sites. I recommend the German http://www.pro-linux.de/ Linux/FOSS news site. If you need help (translation, posting the announcement) I can help. Please write the text in news style because they don't like advertisements. Bye Hansi ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
[fpc-devel] Homepage SVN Conflict
Hi! Hint: At the homepage the latest news section shows an SVN conflict inline. Bye Hansi ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] PR advancement
Hi! This selection is done already. See news on main fpc page. Hm, after giving it some thought, and after seeing [http://www.freepascal.org/gallery.html] link, I have to agree: such selection looks nice. Indeed, nice page and truly impressive for people searching for a proof that FPC is ready for real-world applications. I didn't even know of this Gallery page and I couldn't find any link to it from the www.freepascal.org page. Probably looking around very carefully and reading lots of pages would unveil a link, but this is not what PR means. So I fully agree to Ales that the FPC homepage needs a wow style. Despite I do like clear, simple homepages I don't think that this gives us good PR. Without offending Michael and others for their effort creating and maintaining the website, I think these pages induce the impression that FPC is a tiny project, has unreliable release cycles and progress, it is just from hobbyists for their own pleasure and FPC is only used by some frugal enthusiasts. Propagating this impression is _not_ what good PR is about. :-) On the other hand, Lazarus' home page looks loaded and complex. In the ongoing discussion I read some funny statements (ranting about managers, ...) and some kind of ignorant statements (this and that is already ..., just look there and there, just read the mailing list, just type ... into Google, ...). I'm sure most of the necessary information is already available, probably some more easy to read things (like Ales' FAQ proposal) should be added. But: This information is hidden like in a maze! FPC should _not_ require potential interrests to invest lots of energy and time to get valuable information. FPC should provide this easily and directly accessable. It is not the interrested's job to search for information but it is our's to present it! The main disadvantage of the current website are the bad navigation scheme and the simplistic layout. I'd therefore propose to take the following steps: 1. Collect what information should be on the main page: focus on managers and busy visitors, but do not forget on technicians, enthusiasts, purists. Do not classify this list, don't concentrate on structure, hierarchy, ..., just collect. 2. sort this list, give it a structure 3. work out a navigation scheme of the new website (from the structured list) 4. work out a design and look-and-feel for the new website which is clear, stylish, wow, but not loaded. 5. bring structure, content and design togehter 6. enjoy and watch interrests Ok, this is a very simple path, I'm not sure it if works and if enough man power can be raised. OTOH I'm sure most ideas for the hard part (1) have already been said and/or can be found on the current web site. Any suggestions, comments, ideas? Bye Hansi ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
[fpc-devel] StrToNetAddr6
Hi!
It seems that the StrToNetAddr6 function is not implemented yet
(http://svn.freepascal.org/svn/fpc/trunk/rtl/inc/sockets.inc). I wrote
an implementation (attached as file including some testcases). I hope
you can use it for the Sockets unit.
Bye
Hansi
Program IP6;
Function StrToNetAddr6(IP : String) : TIn6_addr;
Var Part : String;
IPv6 : TIn6_addr;
P,J: Integer;
W : Word;
Index : Integer;
ZeroAt : Integer;
Begin
FillChar(IPv6,SizeOf(IPv6),0);
{ Every 16-bit block is converted at its own and stored into Result. When }
{ the '::' zero-spacer is found, its location is stored. Afterwards the }
{ address is shifted and zero-filled. }
Index := 0; ZeroAt := -1;
J := 0;
P := Pos(':',IP);
While (P 0) and (Length(IP) 0) and (Index 8) do
Begin
Part := '$'+Copy(IP,1,P-1);
Delete(IP,1,P);
if Length(Part) 1 then { is there a digit after the '$'? }
Val(Part,W,J)
else W := 0;
IPv6.u6_addr16[Index] := HtoNS(W);
if J 0 then
Begin
FillChar(IPv6,SizeOf(IPv6),0);
Exit;
End;
if IP[1] = ':' then
Begin
ZeroAt := Index;
Delete(IP,1,1);
End;
Inc(Index);
P := Pos(':',IP); if P = 0 then P := Length(IP)+1;
End;
{ address a:b:c::f:g:h }
{ Result now a : b : c : f : g : h : 0 : 0, ZeroAt = 2, Index = 6 }
{ Result after a : b : c : 0 : 0 : f : g : h }
if ZeroAt = 0 then
Begin
Move(IPv6.u6_addr16[ZeroAt+1],IPv6.u6_addr16[(8-Index)+ZeroAt+1],2*(Index-ZeroAt-1));
FillChar(IPv6.u6_addr16[ZeroAt+1],2*(8-Index),0);
End;
Result := IPv6;
End;
Begin
StrToNetAddr6('1:2:3:4:5:6:7:8');
StrToNetAddr6('1:2:3::7:8');
StrToNetAddr6('1:2:3:4:5:6::');
StrToNetAddr6('::4:5:6:7:8');
StrToNetAddr6('::7:8');
StrToNetAddr6('1:2::');
StrToNetAddr6('::8');
StrToNetAddr6('::');
End;
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
