Hello,
I am trying to flush the serial inque on Linux with no success. So far I
have:
procedure FlushInQue(lHandle: Longint);
var
QueSelector: Longint;
begin
QueSelector:= TCIFLUSH;
Fpioctl(lHandle, TCFLSH, @QueSelector);
end;
I can read incoming characters, so the connection is ok a
I Hope the following never goes away - I use this stuff all the time!
Types
-
Cardinal, Pointer, Integer
Always evaluate to the endian in use.
SizeOf(Cardinal)=SizeOf(Pointer)=SizeOf(Integer)
Offsets
---
If I have a record or a class - and dereference the pointer "nil" I can
always get
Op Thu, 22 Feb 2007, schreef Jason P Sage:
> I Hope the following never goes away - I use this stuff all the time!
>
> Types
> -
> Cardinal, Pointer, Integer
> Always evaluate to the endian in use.
> SizeOf(Cardinal)=SizeOf(Pointer)=SizeOf(Integer)
This isn't true:
* Cardinal: is always a
Hi,
Am Donnerstag, den 22.02.2007, 13:18 -0500 schrieb Jason P Sage:
> I Hope the following never goes away - I use this stuff all the time!
>
> Types
> -
> Cardinal, Pointer, Integer
> Always evaluate to the endian in use.
> SizeOf(Cardinal)=SizeOf(Pointer)=SizeOf(Integer)
>
>
> Offsets
> I can read incoming characters, so the connection is ok and lHandle is
> valid. I tried TCIOFLUSH as another QueSelector and tried also ioctl
> instead of Fpioctl.
termio.tcflush but that does
fpioctl(fd,TCIOflush,pointer(qsel));
> BTW, I am new to Linux (Ubuntu 6.06) and not really sure, w
Daniel Mantione Wrote:
>This isn't true:
>* Cardinal: is always an unsigned 32-bit integer
>* Pointer: can be 32-bit or 64-bit depending on processor
>* Integer: is a signed 16-bit or 32-bit integer depending on compiler mode
And you are absolutely correct. I forget this because I have the FPC
co
> As for Cardinal being only 32bit - that stinks because it's a major
> oversight on my part. Is there a data type equivalent to Cardinal for
> 64-bit? I mean - I tried to use a gambit of "processor size" independent
> variables for doing "low level" stuff - like pointer math.
qword is 64-bit
ptr
Since the advantages of pascal were being discussed I thought I'd
mention some of the
things that make me choose C over pascal for some things.
I don't actually think of these as 'pascal sucks because x'. It's more
of 'We need to add x'
It's more compiler than language based.
1. Inline func
Op Fri, 23 Feb 2007, schreef Neil Graham:
> Since the advantages of pascal were being discussed I thought I'd mention some
> of the
> things that make me choose C over pascal for some things.
>
> I don't actually think of these as 'pascal sucks because x'. It's more of
> 'We need to add x'
>
Daniël Mantione wrote:
We've got a inline procdir? Or are you referring to macros?
inline has the potential to do the trick but it's harder than something
from a #include based
system because with an include system the compiler actually gets to see
the original code
and can do a lot more.
Op Fri, 23 Feb 2007, schreef Neil Graham:
> Daniël Mantione wrote:
> > We've got a inline procdir? Or are you referring to macros?
> >
> inline has the potential to do the trick but it's harder than something from a
> #include based
> system because with an include system the compiler actually
11 matches
Mail list logo
