wild mix of
Int64 and Longint that our Streams inherited 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
name by accident
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
stack
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
ood local code but 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 defa
rcing everything UTF16 we ensure delphi compatibility (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 poin
.org/view.php?id=31758> for
reference.
Martok
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
guess this 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 wrote:
>
>> On 06.05.2017 09:39, Sven Barth via fpc-devel wrote:
>>> That might be the one from Micha
at, as a less synthetic example than some discussed
here.
Regards,
Martok
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
a bug 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: comp
of several more or less clever fixes for that
(except the obvious) and would 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
> Is this made safe by always having an else/otherwise? If so, could the
> compiler at least raise a warning if an enumeration was sparse but there
> was no else/otherwise to catch unexpected cases?
Interestingly, not in FPC.
This was also always my intuition that the else block is also triggere
Am 02.07.2017 um 10:40 schrieb Michael Van Canneyt:
> These cases are without exception covered by the " unchecked (aka explicit)
> typecast," part of Jonas's statement. Including Read(File).
Aye, that was kinda my point ;)
It is really hard to write code that interacts with the outside world with
> Yes, checking the data. I can easily create a similar problem as above with
> the "range checks" for
> the jump table by reading a negative value into the enum. Unfortunately, the
> checks are unsigned ...
Actually, fun fact, *fortunately* the checks are unsigned. Having a negative
value (or ge
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: because
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 = Fals
> 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 wanted
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 ordin
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+ :)
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
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 varia
unrelated side 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
tical documented 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@list
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
>
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 compile
.
Note that FPC doesn't accept this code in mode (Obj)FPC, but 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
#x27;s a lot of (future) work and care to deal 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 remove
y do that in all of
the *ToStr-functions, 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
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?
Erm, I wa
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 li
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
> 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
igns explicit enums with Delphi. Having
the range functions like that means we don't have to touch any optimizer code at
all - it gets the correct bounds. Same for range checking code.
Subranges continue to be strict (as the "convex hull" of the enumerati
r) do begin
arr[v]:=1;
end;
end.
Still no RC code, but now we can be wrong on both sides. Also the loop happily
iterates over the invalid values 1 and 2.
5)
{$r+}
var
a: TEnum;
b: TSubEnum;
begin
a:=tenum(5);
b:=a;
end;
That should include RC code, and be
must 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.
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
httpd22
httpd24
libcurl
libenet
libusb
libvlc
libxml2
mad
mysql
nvapi
oracle
winunits-base
winunits-jedi
zorba
--
Martok
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
probably 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
ranch prediction 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:/
(10) do
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://list
it
being slower 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
org/docs-html/prog/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
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
e the flags 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
==
support also drops ReactOS support. I'm not sure 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
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
losophy of
> strongly 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.free
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 es
tter how dd ends up in v
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.
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
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-
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 arbit
owing does in D10.2?
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
s that really need 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
ic type
OrdinalType = type Word;
Otherwise 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
oducible.
Does 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
then
halt(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
__
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
> 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
of time on 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
7;s snapshot, see if anything else remains.
--
Regards,
Martok
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
defined when the loop 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.freepas
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
_
that probably 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 mail
gn_abstract(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
C
esult:= nil;
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
avoid the 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
ith the generated code, but 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 m
a lot by itself, 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
from 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:
ly 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
statements are 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
or certain recursive functions.
--
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
htt
ing branch here
<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 c
on is pure, what 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
s 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"
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
ed 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
s 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
’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
tickcount;
for i := 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-builtin was done
after 10 seconds.
--
Regards,
Martok
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
at still works everywhere?
Bug 0032115 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.freep
ed 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
previous, since it is 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: Mart
t makes case-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
ot;, and now 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
r
will do 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
;
end;
begin
writeln(GetString(42));
end.
--
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 definitely smaller.
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
rm of package 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
> 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
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
maintain, as there wouldn't be the need for new
inlinennodes or entirely different node types.
--
Regards,
Martok
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
1 - 100 of 125 matches
Mail list logo
