Am 08.12.2019 um 18:41 schrieb Florian Klämpfl:
> As the delphi behavior is very i386/x86-64 specific, FPC deviates from
> it (not to mention that the non-i386 behavior was implemented years
> before a non-i386 delphi was available).
Jup, that's what I meant with "made runtime and compile time
> Indeed, this is by design. See
> https://wiki.freepascal.org/User_Changes_2.2.0#Floating_point_constants for
> how to explicitly specify a different precision.
That was long before the change Tomas discovered.
The gotcha here is about your fix to
Am 27.10.2019 um 17:48 schrieb Florian Klämpfl:
>> I guess the main difference is whether one prefers side-by-side
>> diffs or udiffs.
>
> In particular partial commits as well as conflict resolution work much
> better with TortoiseGit for me.
Oh yeah, conflict resolution is the thing nobody
> cover one single topic. Today, using e.g. TortoiseGit on Windows (sorry,
> on Linux there is no tool which comes close) such patches can be
> re-arranged without too much hazzle.
Just plain ol' git-gui can also do it. SmartGit is cross-platform and also
pretty nice. I guess the main
field to point to an error-raising routine rather than 'endlabel'
> (which occurs if there's no else block).
>
> Gareth aka. Kit
>
>
> <https://www.avast.com/sig-email?utm_medium=email_source=link_campaign=sig-email_content=emailclient>
> Virus-free. www.avast.com
> If you want to nitpick, the compiler will perform 1/2/4 byte writes for
> enums of those sizes, so the full reserved data is in fact
> used/initialised. Again: the only relevant part in this discussion is
> the valid values. The reserved/used/accessed/written/... storage size is
> unrelated to
d:
> https://forum.lazarus.freepascal.org/index.php/topic,45507.msg322059.html#msg322059
As I wrote in the last message, those points would be fully addressed by this
proposal. Choosing at declaration time is the only valid solution, all modes
will behave exactly the same once the
ing the intrinsics this is about) is just a hacky
workaround to the difference Jonas summarised above, IMHO.
--
Regards,
Martok
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
ute aEnum;
begin
if Read(aEnum, SizeOf(aEnum)) <> SizeOf(aEnum) then
Exit(False)
else begin
Result := (tmp >= Ord(Low(T))) and (tmp <= Ord(High(T)));
end;
end;
This *could* be optimized out by FPC, but not by a Borland compiler.
--
Regards,
Martok
Ceterum censeo b3207
types. Unless the optimizer removes the typeconvnodes...
Of course, this needs to be done everywhere a subrange is passed anywhere that
is not FPC, so it can't really fix anything.
--
Regards,
Martok
___
fpc-devel maillist - fpc-devel
this onto a particular stream implementation but instead provide a
general marshaller for it.
--
Regards,
Martok
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
ticular philosophy at all is what got this
interpretation of the language into this mess in the first place.
FPC is in dire need of a language specification effort. But I don't think anyone
who would be willing to drive it cares enough at that point.
-
y.
> So, in my book, an intrinsic to check for a correct value in the places where
> an
> invalid value can enter the system is a welcome language feature.
In my book it's absolutely insane that this is needed *just because* FPC wants
to be different, but yes, it is required.
--
Regard
> from outside.
Then you're not using them *in* the interface ;-)
--
Regards,
Martok
Ceterum censeo b32079 esse sanandam.
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
better than Delphi, nice :)
--
Regards,
Martok
Ceterum censeo b32079 esse sanandam.
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
ication': calling non-FPC
APIs or even just FPC libraries of possibly different version (see: Run-Time
Packages!)
Anything that even looks like a subrange cannot be used for these interfaces.
--
Regards,
Martok
Ceterum censeo b32079 esse sanandam.
_
en they rewrote the
content for Delphi Help.
--
Regards,
Martok
Ceterum censeo b32079 esse sanandam.
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
andles those correctly as well? That probably needs a few test cases?
--
Regards,
Martok
Ceterum censeo b32079 esse sanandam.
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
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
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
___
; 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
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.
--
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
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
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
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
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
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
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
in.
Cheers,
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
seconds.
--
Regards,
Martok
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
= 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
’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
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
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
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
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
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
<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
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
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
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
__
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
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
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
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
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
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
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
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
__
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
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
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
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
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
> 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
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
_
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
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
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
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.
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
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
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
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
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
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
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
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
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
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
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
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
s-base
winunits-jedi
zorba
--
Martok
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
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
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
> 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
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
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
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
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
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 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
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
>
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
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
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
1 - 100 of 118 matches
Mail list logo
