herited from Delphi...
I don't have RTL built with full symbols right now, maybe someone else can
investigate?
Martok
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
> I have committed a patch. Please test and report if it is fixed.
> I don't have a 32-bit system available to test on...
Tested on win32: the overflow is fixed, 500M gets incremented by 125M.
I think the RunError is caused by the way ReallocMem works: growing from 869M to
1086M seems to be done
cident
but really are the same type.
Do you have any idea what could be done to work around this?
Thank you in advance,
Martok
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
each time), so I have a feeling this may be a side effect of some other part of
the code.
Does this sound familiar to anyone? If so, what could I do about it?
Regards,
Martok
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.free
ut then just
pointlessly add the second-most expensive operation in between ;-)
Regards,
Martok
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
>> Does it is possible that the LineInfo trace (-gl option) are broken (no
>> output)
>> in 3.0.2 version on Linux (at least)?
>
> Hm. Indeed. I can reproduce the issue :/
AFAIR lineinfo.pp only works with Stabs? Didn't the default c
Am 25.07.2017 um 19:31 schrieb Martok:
> As has just been pointed out to me, we all misdiagnosed that example.
Turns out this is not a new question, there is actually a very thorough
treatment of that very issue on SO:
<https://stackoverflow.com/questions/18195312/what-happens-if-you-stati
s-base
winunits-jedi
zorba
--
Martok
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
effect at all if we were to align
FPC with all the other Pascals out there.
Kind regards,
Martok
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
mented definition in
every other Pascal compiler. An assumption that even FPC follows only in this
one single spot.
This is unexpected and breaks unrelated code. That's the problem.
Good night,
Martok
___
fpc-devel maillist - fpc-devel@lists.freepascal.or
tions, instead of executing the else-blocks.
That code is completely unambiguous and well-defined if we assume Low-Level
Enumerations (which, coming from BP, I obviously always have).
Martok
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://
l with what I
> still consider to be bad programming.
Delphi optimizes always based on the full-range base type:
type
TB = (a,b,c,d,e); // Sizeof(TB)=1
TT = a..e;
var
t: TT;
begin
t:= TT(2);
if t <= e then // does not get removed
if Ord(t) <= 255 then// 'Condition
Am 14.07.2017 um 10:04 schrieb Marco van de Voort:
> In our previous episode, Martok said:
>> There is a fundamental difference in the type system between a somewhat
>> sensible
>> (if unexpected) assumption in FPC and a more practical documented definition
>> in
>
> OK, I see now: there is a difference between C enums and C++ enums. Your
> example was about C++ enums. My example was about C enums. The C enums
> are defined to allow any integer value, whereas C++ enums are strongly
> typed.
In the pages cited, there's no mention of valid ranges, only that
You (Florian) do realize that it's almost impossible to write a C++ program that
is not technically undefined? Their 'standards' are worse than our
'implementation-defined'.
FWIW, GCC agrees with Low-Level Enums, and given that clang regularly catches
hate when their 'optimizations' break stuff
t correctly does so
in DELPHI, with the same result as Delphi.
Added after Ondrej's message 20:52: Borland appears to have taken the route of
what he called a 'LOW-LEVEL enumeration' from the very beginning.
Martok
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Am 16.07.2017 um 19:58 schrieb Ondrej Pokorny:
> On 16.07.2017 19:24, Martok wrote:
>> The good thing about case statements is that they tell me of every other
>> programmer error: missing elements (if used without else)
> Off-topic: how can I enable this compiler hint?
Er
Am 16.07.2017 um 13:17 schrieb Jonas Maebe:
> Does that mean that you would consider the same transformation of a
> case-statement when using a subrange type as correct? And that putting a
> value outside the range of a subrange into such a variable as a
> programmer error? (as opposed to doing
Am 15.07.2017 um 12:40 schrieb Jonas Maebe:
> On 14/07/17 02:40, Martok wrote:
>> There is a fundamental difference in the type system between a somewhat
>> sensible (if unexpected) assumption in FPC and a more practical documented
>> definition in every other Pascal co
be Low-Level. QED.
> "Ungültiger Maschinenbefehl (Speicherabzug geschrieben)" = Invalid opcode
> (memory dump written).
> Why? Because it does not range check before entering the jump table.
I really should have noticed that. A ju
e discussed
here.
Regards,
Martok
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Booleans are not enums in Delphi (not even ordinals), but their own little
thing. "if boolean_expr" is always a jz/jnz, no matter what. They are defined as
0=FALSE and "everything else"=TRUE
However:
var
b : boolean;
begin
b:=boolean(3);
if b = True then
writeln(true)
else if b =
Addendum to this:
> This was also always my intuition that the else block is also triggered for
> invalid enum values (the docs even literally say that, "If none of the case
> constants match the expression value") - and it *is* true in Delphi.
There is a reason why this is true in Delphi:
> They are:
> http://docwiki.embarcadero.com/Libraries/XE5/en/System.Boolean
That prototype is a recent invention, it wasn't there in older versions. Also
the text sounds quite different somewhere else:
http://docwiki.embarcadero.com/RADStudio/XE5/en/Simple_Types#Boolean_Types
> Yes. What I
Am 02.07.2017 um 20:29 schrieb Ondrej Pokorny:
> On 02.07.2017 20:23, Florian Klämpfl wrote:
>> And the compiler writes no warning during compilation?
>
> It does indeed.
But about something else.
Can we please stop derailing from the main issue here?
> If we get a convenient way to assign
Good morning!
Am 02.07.2017 um 22:02 schrieb Florian Klämpfl:
> Am 02.07.2017 um 21:40 schrieb Martok:
>> Honestly, I still don't understand why we're even having this discussion.
>
> Because it is a fundamental question: if there is any defined behavior
> possible if a v
Am 02.07.2017 um 19:47 schrieb Florian Klämpfl:
> Am 02.07.2017 um 19:29 schrieb Martok:
>>type Percentile = 1..99;
>>var I: Percentile;
>>begin
>> I:= 99;
>> inc(I); // I is now 100
>
> Forgot the mention:
> Tried with $r+ :)
about something that
breaks input sanitation code (but only sometimes) is just... wow.
If anybody wants it, here's the patch I'll be rolling on the windows snapshots
from now on.
Have a good weekend,
Martok
Index: compiler/ncgset.pas
ld prefer discussing these instead of having to
prove that "not-as-defined"-behaviour is not the same as "undefined behaviour".
Kind regards,
Martok
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Hi all,
Am 02.07.2017 um 22:02 schrieb Florian Klämpfl:
> Am 02.07.2017 um 21:40 schrieb Martok:
>> Honestly, I still don't understand why we're even having this discussion.
> Because it is a fundamental question: if there is any defined behavior
> possible if a variable
> c
week-long discussion here
never happened anyway.
Martok
Am 10.05.2017 um 08:38 schrieb Mattias Gaertner:
> On Tue, 9 May 2017 14:59:16 +0200
> Michael Schnell <mschn...@lumino.de> wrote:
>
>> On 06.05.2017 09:39, Sven Barth via fpc-devel wrote:
>>> That might be
php?id=31758> for
reference.
Martok
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
tibility (yes it does
> matter)
> and we also ensure a uniform set of string tables.
If that was what happened, ok. But from the error message Matthias listed as (1)
I would assume that the actual string type is UCS2String, at least at some point
in the process.
Just my 2 cents...
Martok
didn't mean security as much as "my room-sized
mainframe crashes", but the point stands...
--
Martok
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
buf2[j]:=buf1[j];
for j:=1 to 1 do
CompareBytePatch(buf1,buf2,len); // or System.CompareByte
--
Regards,
Martok
Ceterum censeo b32079 esse sanandam.
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepasc
iction at work. I can also validate
Agner Fog's Instruction Timing Tables with it, so it can't be that bad ;-)
--
Regards,
Martok
Ceterum censeo b32079 esse sanandam.
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.or
lower on modern platforms than it used to be?
--
Regards,
Martok
Ceterum censeo b32079 esse sanandam.
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
alt(1);
i:= tfun();
if i <> 10 then
halt(2);
if s <> 12 then
halt(3);
writeln('ok');
end.
-
I would very much expect that to be the main cause of the observed crashes.
--
Regards,
Martok
___
fpc-devel maillist
anyone have more complete test cases, or maybe smaller affected projects?
--
Regards,
Martok
Ceterum censeo b32079 esse sanandam.
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
arning, and does indeed display it for the
test case. There is no indication anything might be wrong from FPC?
This kind of code is used even more than "that other thing", makes me wonder if
it's a good idea to break this at O3...
--
Regards,
Martok
_
Am 21.05.2018 um 17:44 schrieb Florian Klämpfl:
> I added raise, exit, goto and label as well.
Oh, label, right.
I'd say #0033614 can be resolved as "fixed in 39083" and #0033753 as "no change
required" then.
--
Regards,
Martok
__
bly prohibits most useful cases as well...
I'd say that closures + AST-level inlining + some dead store eliminations would
fix a lot of issues that currently have special case handling.
--
Regards,
Martok
___
fpc-devel maillist - fpc-de
p is left with break or exit, that's the
point. The ISO is not a very good reference for modern-ish Pascal.
--
Regards,
Martok
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
hes. The "Optimized IDE" profile is usable again. I'll post
the patch to the bug tracker, as we seem to have decided it is not a hack ;-)
--
Regards,
Martok
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/cg
once already, no
intention to do that again.
--
Regards,
Martok
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
ee if anything else remains.
--
Regards,
Martok
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
> Can you report that to the bugtracker of Lazarus?
Sure. Done as https://bugs.freepascal.org/view.php?id=33753
Martok
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
alects
handle them. It's been 28 years, there's probably consensus on some out there.
Could be useful as a guide for porting code as well.
Martok
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
my example has always worked (for me!) in FPC.
I am confused. Which sorta ties in to the whole "surprises" thing from before we
hijacked this thread...
--
Regards,
Martok
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lis
y don't understand how interfaces are
> implemented.
Thank you for the explanation! Saved for future reference.
I was thinking too much in terms of C++ pure virtual classes and their VMT and
forgot about the self translation trampoline functions.
--
Regards,
Martok
__
hen new flags are introduced.
Is there even a use case for the current behaviour? I.e., when would one
actually mean -Oolevel3 instead of -O3?
--
Regards,
Martok
Ceterum censeo b32079 esse sanandam.
___
fpc-devel maillist - fpc-devel@lists.freepa
rog/progsu58.html> claims {$OPTIMIZATION
ON} is equivalent to {$OPTIMIZATION LEVEL2}, which it never was since that
directive was introduced.
Slightly related, the Programmer's Guide lists ancient optimization switches in
11.3. Bug report coming in shortly.
--
Regards,
Martok
Ceterum censeo b3207
s alone (should) have no use
b) it's always been documented that way
c) it's used as if that was true in live code
Rough patch attached...
--
Regards,
Martok
Ceterum censeo b32079 esse sanandam.
Index: scandir.pas
===
--- scandi
ure if we
ever officially had it, but it is on the Wiki.
Martok
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Am 30.07.2018 um 14:24 schrieb Marcos Douglas B. Santos:
> Is performance more important than being correct? :|
In this project, the answer is always taken to be yes.
--
Regards,
Martok
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
h
generated is not technically a jump table, but a
typed dispatch table.
--
Regards,
Martok
Ceterum censeo b32079 esse sanandam.
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
d values of
the type of x, it is omitted.
--
Regards,
Martok
Ceterum censeo b32079 esse sanandam.
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
<https://github.com/martok/freepascal/compare/master...dev_inlining>.
Instead of marking a function as 'pure' at declaration, I took another way: make
normal inlining firstpass flexible enough that any "accidentally" pure function
can be collapsed at the call site.
As an extension
re allowed in an EXCEPT block. Come to think of it,
didn't we have another TRY/FINALLY/EXCEPT nesting issue that might have
something to do with that?
--
Regards,
Martok
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
alized optimizations
after inlining and before simplifying.
I'll have a look into that later - this would be useful for many cases
regardless of pure functions.
--
Regards,
Martok
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://l
rtain recursive functions.
--
Regards,
Martok
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
I did with constexpr() would basically be
guaranteed to work.
--
Regards,
Martok
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
not inlined" message.
> The final issue is that while a function might be pure, you might not want to
> inline it because of its complexity, especially if it's called multiple times
> with variable arguments.
That is very true. Should the "interpretation complexity" be limite
trongly preferring abstract purity to concrete user experience.
If it at least was consistent purity!
Sorry. Needed to be said.
--
Regards,
Martok
Ceterum censeo b32079 esse sanandam.
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://li
o work with assigned
values), but if we want to go there, something like this feature is absolutely
required (Ada has it).
In that case, off the top of my head, succ/pred, for, bitsizeof and maybe sizeof
need to be fixed as well.
--
Regards,
Martok
Ceterum censeo b32079 esse sa
v:= succ(v); // always invalid, no need for {$R+}!
end.
All this is not quite as easy to get right as it seems on the surface. But I do
like the the "v is TEnum" operator from the other side of this thread,
regardless of where this goes...
--
Regards,
Martok
Am 17.04.2018 um 01:51 schrieb Thorsten Engler:
> And the nil assignment variant is pretty much ubiquitous in any code
> involving dynamic arrays that I'm aware of.
Yes. I know ;-)
>> only the reserved/constant "nil" is compatible, and handled elsewhere
I asked specifically about assigning
var arr: array of byte;
begin
arr:= Pointer(0);
end.
What I'd like to know: do they check the "nil" literal, or pointers of value
nil?
--
Regards,
Martok
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.
eed it, in
Delphi mode, nothing should break on invalid enum values anyway (if it does, it
is a compiler error).
--
Regards,
Martok
Ceterum censeo b32079 esse sanandam.
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
erwise this is the same.
I hope this clears things up a bit.
--
Regards,
Martok
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
to dynarrays? It does
seem to be Delphi compatible, but I couldn't find any mention in either
documentation that this is possible - only the reserved/constant "nil" is
compatible, and handled elsewhere.
--
Regards,
Martok
___
fpc-devel
t;var is class"
handles nil values as "not an instance of class".
--
Regards,
Martok
Ceterum censeo b32079 esse sanandam.
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
The hint was added in response to
<https://bugs.freepascal.org/view.php?id=31717>.
Not very useful, other than to demonstrate 'inline' is rarely respected.
However, it probably wasn't the intention to generate it for intrinsics as well?
--
Regards,
Martok
Ceterum censeo b32079 esse sa
stract(hp).aligntype=119" and check what the actual
type of hp is? It could be that at some point a node gets its typ changed in an
invalid way?
aligntype should be either one of 2^[0..5], never something else...
This is where AddressSanitizer support would be *nice*.
--
Regards,
Martok
Ceteru
SetLength (result,len); // whatever
end;
For managed types, as far as I can tell:
- locals are initialized (even if there is a warning telling you they are not)
- tempvars are initialized *once*
- Result is never initialized (there is no warning telling you it is not).
--
Rega
tself, but since
we're counting single-digit cycles in other places...
--
Regards,
Martok
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
interfaces here with ARC records, but either I'm
missing something or the scope lifetime of tempvars there is even worse.
--
Regards,
Martok
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
ut it is not nearly
as efficient as it could be. See also Ryan's comments about slow
Interlocked*-calls a few weeks ago. Delphi's output for the same example is
better, giving the expected output.
Because of the tempvars, it is also not exactly what one might expect at first,
which is why
in.
Cheers,
Martok
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Am 27.12.2018 um 20:48 schrieb Jonas Maebe:
> No, there is not. If a def needs to be different depending on the
> language mode, you have to store it in the def.
Thought so. Thank you for confirming!
Cheers,
Martok
___
fpc-devel maillist
s now possible to discover forgotten items
or later additions by the other warning, removing these 'safety' else-clauses
would improve code quality.
What do you think?
--
Regards,
Martok
From e32addb6583c8b752c168fe221385566499625bb Mon Sep 17 00:00:00 2001
From: Martok
Date: Tue, 1 Jan 2019 18:5
something that is *very likely* unintended.
--
Regards,
Martok
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Am 14.01.2019 um 15:01 schrieb J. Gareth Moreton:
> Martok mentioned doing some checks differently in the bug report in question,
> such as 6 comparisons being faster than a jump table. Are there any others
> worth mentioning?
Not neccessarily faster, but in that code definitel
seconds.
--
Regards,
Martok
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
2115 provides a "nice" test case for things that can go wrong with
different word sizes, and is also a good test for the true label count.
--
Regards,
Martok
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.o
’s not clear where to begin looking.
Checking out the memory manager(s) could be useful as well - there are a lot of
small allocations, that generally tends to put much stress on it.
And any improvement there would also directly benefit user applications.
--
Reg
= 0 to COUNT - 1 do begin
for j := 0 to high(objs) do
objs[j]:= TObject.Create;
for j := 0 to high(objs) do
objs[j].Free;
end;
t2:= Gettickcount;
writeln((t2-t1)/COUNT:10:3, 'ms');
Readln;
end.
--
Regards,
Martok
___
fpc-de
se-based regular language parsing quite noisy.
--
Regards,
Martok
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
ow its provably wrong. No warning. This seems wrong,
considering what we just talked about on fpc-pascal.
--
Regards,
Martok
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
ot involved in development there." was actually true and I
haven't looked at it since, because it "just works" ;-)
Although, that *is* true again, so it's 50/50 if I would report it today.
--
Regards,
Martok
___
fpc-devel maillist - fpc-
and *will not
currently work with fppkg*. But you will get a working compiler.
I used '-o "%CD%\fpc.cfg"' exactly because fpcmkcfg does not handle relative
paths well.
--
Regards,
Martok
___
fpc-devel maillist - fpc-devel@lists.freepasca
t away from UTF8 anyways.
String codepages are not stable, there is almost never a point in explicitly
setting one...
--
Regards,
Martok
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
> Is this a known bug?
>
> (Btw. I tested on win32.)
Maybe this?
https://bugs.freepascal.org/view.php?id=33963
--
Regards,
Martok
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/lis
age manager, so my opinions very much
*should* be void.)
--
Regards,
Martok
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
reepascal\fppkg\config), hence break any time the compiler path
changes.
--
Regards,
Martok
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
uirks as
possible and then align the compiler to it (not the other way around). Having
less corner cases to juggle in one's mind may make things easier, and a formal
spec is also a good reference for future extensions to see if ideas are
orthogonal or not. But that's a whole different topic.
--
ator overload
mess is already completely unpredictable and super buggy.
Based on a specificity approach, the answer to your question would be obvious:
The latter if a is (a descendant of) TObject, a new specialization otherwise.
--
Regards,
Martok
___
having a different opinion of code duplication than
I do.
--
Regards,
Martok
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
; the most hilarious "weight 1"
autoconversion (see 0031215, which is also an overload bug).
--
Regards,
Martok
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
s.
I would prefer literally any other solution (such as the two-line-patch my
Windows trunk builds have contained for two years now), but this is the one that
gets merged. Go figure.
--
Regards,
Martok
Ceterum censeo b32079 esse sanandam.
___
fpc-devel mail
1 - 100 of 118 matches
Mail list logo
