On Wed, Apr 24, 2019 at 5:41 PM Rainer Stratmann <
rainerstratm...@t-online.de> wrote:
> struct sockaddr_ll {
> unsigned short sll_family;
> unsigned short sll_protocol;
> intsll_ifindex;
> unsigned short sll_hatype;
> unsigned char sll_pkttype;
> unsigne
On Wed, 24 Apr 2019, Rainer Stratmann wrote:
struct sockaddr_ll {
unsigned short sll_family;
unsigned short sll_protocol;
intsll_ifindex;
unsigned short sll_hatype;
unsigned char sll_pkttype;
unsigned char sll_halen;
unsigned char sll_addr[8];
};
struct sockaddr_ll {
unsigned short sll_family;
unsigned short sll_protocol;
intsll_ifindex;
unsigned short sll_hatype;
unsigned char sll_pkttype;
unsigned char sll_halen;
unsigned char sll_addr[8];
};
type
sockaddr_ll = record
On Wed, 24 Apr 2019 17:16:05 +0200
Sven Barth via fpc-pascal wrote:
> Am 24.04.2019 um 15:28 schrieb Ryan Joseph:
> >
> >> On Apr 24, 2019, at 2:27 AM, Michael Van Canneyt
> >> wrote:
> >>
> >> I would think this should be allowed, yes. I see no reason to
> >> disallow it.
> > Agreed but Sve
Am 24.04.2019 um 15:31 schrieb Ryan Joseph:
On Apr 24, 2019, at 12:30 AM, Ben Grasset wrote:
Seems like it's mixed up in some way with the FPC-style enumerator operator, so the
"class" version is recognized but not actually implemented currently or
something.
The normal way for classes/rec
Am 24.04.2019 um 15:28 schrieb Ryan Joseph:
On Apr 24, 2019, at 2:27 AM, Michael Van Canneyt wrote:
I would think this should be allowed, yes. I see no reason to disallow it.
Agreed but Sven says something about published fields though. The property just
acts as simple alias so I don’t unde
> On Apr 24, 2019, at 2:27 AM, Michael Van Canneyt
> wrote:
>
> I would think this should be allowed, yes. I see no reason to disallow it.
Agreed but Sven says something about published fields though. The property just
acts as simple alias so I don’t understand what the problem could be eith
> On Apr 24, 2019, at 12:30 AM, Ben Grasset wrote:
>
> Seems like it's mixed up in some way with the FPC-style enumerator operator,
> so the "class" version is recognized but not actually implemented currently
> or something.
>
> The normal way for classes/records/objects is to implement a G
Op 4/24/2019 om 9:53 AM schreef Graeme Geldenhuys:
On 22/04/2019 00:14, Graeme Geldenhuys wrote:
yet when I compile/build my project, it still shows that
compiler hint (as can be seen in the attached screenshot).
Is nobody else experiencing this?
Try to put your includes and warnes after the
Suggestion: in the message $subj, can you add FPC version of that PPU?
so it will be "Wrong PPU found [FPC 2.7.8]" when FPC needs PPU for 3.2.0.
--
Regards,
Alexey
___
fpc-pascal maillist - fpc-pascal@lists.freepascal.org
http://lists.freepascal.org
On 24/04/2019 09:07, Michael Van Canneyt wrote:
> I get no warning. If I remove the statement, I get the warning.
Thanks Michael. So it seems it is something local to my system then. I
get warnings no matter what.
Do you have any compiler settings like -viewh in your ~/.fpc.cfg file?
I'm trying t
On Wed, 24 Apr 2019, Graeme Geldenhuys wrote:
On 22/04/2019 00:14, Graeme Geldenhuys wrote:
yet when I compile/build my project, it still shows that
compiler hint (as can be seen in the attached screenshot).
Is nobody else experiencing this?
{$warn 5024 off}
procedure TForm1.Edit1Chang
On 22/04/2019 00:14, Graeme Geldenhuys wrote:
> yet when I compile/build my project, it still shows that
> compiler hint (as can be seen in the attached screenshot).
Is nobody else experiencing this?
Regards,
Graeme
___
fpc-pascal maillist - fpc-
13 matches
Mail list logo
