Dear folks,
Do you know if their are memory manipulation functions in lisp
similar to sizeof, malloc etc in C?
Is there a family of functions like these primitive to lisp?
My need of this hour is a function which can return the byte size of
objects in memory.
Thanx and Regards,
Aman
In article <············@registered.motzarella.org>,
Aman Goel <····@cleartrip.com> wrote:
> Dear folks,
>
> Do you know if their are memory manipulation functions in lisp
> similar to sizeof, malloc etc in C?
> Is there a family of functions like these primitive to lisp?
>
> My need of this hour is a function which can return the byte size of
> objects in memory.
>
> Thanx and Regards,
> Aman
There is nothing like this in portable Common Lisp.
For ideas about layouts of objects and their size
you need to look at implementation specific functionality.
You may have some luck allocating a bunch of data and checking
(ROOM) before and after.
What are you interested in? CLOS objects? Or all kinds of objects?
--
http://lispm.dyndns.org
From: John Thingstad
Subject: Re: memory functions in lisp similar to sizeof, malloc etc. of C
Date:
Message-ID: <op.tqp2ccgqpqzri1@pandora.upc.no>
On Fri, 13 Apr 2007 12:11:24 +0200, Aman Goel <····@cleartrip.com> wrote:
> Dear folks,
>
> Do you know if their are memory manipulation functions in lisp
> similar to sizeof, malloc etc in C?
> Is there a family of functions like these primitive to lisp?
>
> My need of this hour is a function which can return the byte size of
> objects in memory.
>
> Thanx and Regards,
> Aman
Not really. The ANSI spec does not specify such functionality.
But foreign function interfaces have functions that deal with memory in a
C like manner.
You might download CFFI and use the functions there.
This library is a portable layer above the specific foreign function
interface and runs on most systems.
Things like foreign-alloc, foreign-free, foreign-type-size map to the
things you ask for.
(There is also a library called UFFI which does this, but it runs on
slightly fewer systems.)
Are these objects C objects or Lisp objects?
It might help if I knew more about the problem. Perhaps you are asking for
the wrong thing..
Lisp is, after all, not C.
--
Using Opera's revolutionary e-mail client: http://www.opera.com/mail/
John Thingstad wrote:
> On Fri, 13 Apr 2007 12:11:24 +0200, Aman Goel <····@cleartrip.com> wrote:
>
>> Dear folks,
>>
>> Do you know if their are memory manipulation functions in lisp
>> similar to sizeof, malloc etc in C?
>> Is there a family of functions like these primitive to lisp?
>>
>> My need of this hour is a function which can return the byte size of
>> objects in memory.
>>
>> Thanx and Regards,
>> Aman
>
> Not really. The ANSI spec does not specify such functionality.
> But foreign function interfaces have functions that deal with memory in
> a C like manner.
> You might download CFFI and use the functions there.
> This library is a portable layer above the specific foreign function
> interface and runs on most systems.
> Things like foreign-alloc, foreign-free, foreign-type-size map to the
> things you ask for.
> (There is also a library called UFFI which does this, but it runs on
> slightly fewer systems.)
>
> Are these objects C objects or Lisp objects?
> It might help if I knew more about the problem. Perhaps you are asking
> for the wrong thing..
> Lisp is, after all, not C.
>
>
> --Using Opera's revolutionary e-mail client: http://www.opera.com/mail/
I am receiving a file, uploaded from the browser and sent as a post
parameter to the server (the Hunchentoot server)
I want to find the size of the uploaded file to make sure it is within
certain limit before manipulating it.
I could do this by reading thru a stream to the file, but I want to find
a better (generic) way to find size of objects in lisp.
~ Aman
From: Edi Weitz
Subject: Re: memory functions in lisp similar to sizeof, malloc etc. of C
Date:
Message-ID: <uslb4wjqg.fsf@agharta.de>
On Fri, 13 Apr 2007 17:43:06 +0530, Aman Goel <····@cleartrip.com> wrote:
> I am receiving a file, uploaded from the browser and sent as a post
> parameter to the server (the Hunchentoot server)
>
> I want to find the size of the uploaded file to make sure it is
> within certain limit before manipulating it.
And in C you'd do that with sizeof? That certainly wouldn't work.
In Common Lisp, if it's a file, you can use FILE-LENGTH. If you
already have the uploaded file in memory, then you'll most likely have
it in some kind of sequence, so you can use LENGTH.
--
Lisp is not dead, it just smells funny.
Real email: (replace (subseq ·········@agharta.de" 5) "edi")
On Apr 13, 2:18 pm, Edi Weitz <········@agharta.de> wrote:
> On Fri, 13 Apr 2007 17:43:06 +0530, Aman Goel <····@cleartrip.com> wrote:
> > I am receiving a file, uploaded from the browser and sent as a post
> > parameter to the server (the Hunchentoot server)
>
> > I want to find the size of the uploaded file to make sure it is
> > within certain limit before manipulating it.
>
> And in C you'd do that with sizeof? That certainly wouldn't work.
It works just fine for me:
char *p = ...;
if (sizeof(p) > 4) { ... error ...}
else {
...
}
What I don't understand is why my browser keeps truncating my files to
only be 4 long. Can anyone help me with that or is it just stoopid
IE?!?!?!
From: Didier Verna
Subject: Re: memory functions in lisp similar to sizeof, malloc etc. of C
Date:
Message-ID: <muxr6qowh2k.fsf@uzeb.lrde.epita.fr>
"Thomas F. Burdick" <········@gmail.com> wrote:
> It works just fine for me:
>
> char *p = ...;
> if (sizeof(p) > 4) { ... error ...}
> else {
> ...
> }
>
> What I don't understand is why my browser keeps truncating my files to
> only be 4 long. Can anyone help me with that or is it just stoopid
> IE?!?!?!
It's a security measure. Look carefully at how your filename
appears in the listing: *p. It contains a star, which means that the
file is actually an executable. So it is truncated to prevent trojan
attacks, yet preserving the magic number for you to investigate.
--
Didier Verna, ······@lrde.epita.fr, http://www.lrde.epita.fr/~didier
EPITA / LRDE, 14-16 rue Voltaire Tel.+33 (1) 44 08 01 85
94276 Le Kremlin-Bic�tre, France Fax.+33 (1) 53 14 59 22 ······@xemacs.org
From: Ken Tilton
Subject: Re: memory functions in lisp similar to sizeof, malloc etc. of C
Date:
Message-ID: <hQPTh.10$3z5.1@newsfe12.lga>
Aman Goel wrote:
> John Thingstad wrote:
>
>> On Fri, 13 Apr 2007 12:11:24 +0200, Aman Goel <····@cleartrip.com> wrote:
>>
>>> Dear folks,
>>>
>>> Do you know if their are memory manipulation functions in lisp
>>> similar to sizeof, malloc etc in C?
>>> Is there a family of functions like these primitive to lisp?
>>>
>>> My need of this hour is a function which can return the byte size of
>>> objects in memory.
>>>
>>> Thanx and Regards,
>>> Aman
>>
>>
>> Not really. The ANSI spec does not specify such functionality.
>> But foreign function interfaces have functions that deal with memory
>> in a C like manner.
>> You might download CFFI and use the functions there.
>> This library is a portable layer above the specific foreign function
>> interface and runs on most systems.
>> Things like foreign-alloc, foreign-free, foreign-type-size map to the
>> things you ask for.
>> (There is also a library called UFFI which does this, but it runs on
>> slightly fewer systems.)
>>
>> Are these objects C objects or Lisp objects?
>> It might help if I knew more about the problem. Perhaps you are asking
>> for the wrong thing..
>> Lisp is, after all, not C.
>>
>>
>> --Using Opera's revolutionary e-mail client: http://www.opera.com/mail/
>
>
> I am receiving a file, uploaded from the browser and sent as a post
> parameter to the server (the Hunchentoot server)
>
> I want to find the size of the uploaded file to make sure it is within
> certain limit before manipulating it.
>
> I could do this by reading thru a stream to the file, but I want to find
> a better (generic) way to find size of objects in lisp.
As the jokers are implying, unless the file comes with header
information you can parse, you do have to read through it to find out
where it ends. This is true in any language, including C, which is why
folks here are confused. sizeof is about longwords and ints and structs
taking up so much room, not about how big files are. sizeof on a file
pointer will be four if it is a 32-bit pointer, not the size of the
file. malloc takes a size parameter in the sense you are using, but if
you apply sizeof to a variable holding the pointer it too will say 4, if
it is a 32-bit pointer variable.
otoh, if you read the file into an adjustable array in Lisp, you can
take the length of the array afterwards. Lisp has that meta-info. But
you are trying not to read the whole file, so not sure this helps.
kzo
--
http://www.theoryyalgebra.com/
"Algebra is the metaphysics of arithmetic." - John Ray
"As long as algebra is taught in school,
there will be prayer in school." - Cokie Roberts
"Stand firm in your refusal to remain conscious during algebra."
- Fran Lebowitz
"I'm an algebra liar. I figure two good lies make a positive."
- Tim Allen
From: John Thingstad
Subject: Re: memory functions in lisp similar to sizeof, malloc etc. of C
Date:
Message-ID: <op.tqqo68o0pqzri1@pandora.upc.no>
On Fri, 13 Apr 2007 20:18:50 +0200, Ken Tilton <···@theoryyalgebra.com>
wrote:
>
> As the jokers are implying, unless the file comes with header
> information you can parse, you do have to read through it to find out
> where it ends. This is true in any language, including C, which is why
> folks here are confused. sizeof is about longwords and ints and structs
> taking up so much room, not about how big files are. sizeof on a file
> pointer will be four if it is a 32-bit pointer, not the size of the
> file. malloc takes a size parameter in the sense you are using, but if
> you apply sizeof to a variable holding the pointer it too will say 4, if
> it is a 32-bit pointer variable.
Of course all files stored by a operating system have header information
it parses. This includes the size. (Whose the joker here?)
Common Lisp's function file-length.
For binary files length is the number of element type entities in stream.
So is you open a file and set the type to a octet you should get the
number of octets
(deftype octet (unsigned-byte 8))
(a C byte)
--
Using Opera's revolutionary e-mail client: http://www.opera.com/mail/
From: Ken Tilton
Subject: Re: memory functions in lisp similar to sizeof, malloc etc. of C
Date:
Message-ID: <x2TTh.16$%n3.9@newsfe12.lga>
John Thingstad wrote:
> On Fri, 13 Apr 2007 20:18:50 +0200, Ken Tilton <···@theoryyalgebra.com>
> wrote:
>
>>
>> As the jokers are implying, unless the file comes with header
>> information you can parse, you do have to read through it to find out
>> where it ends. This is true in any language, including C, which is
>> why folks here are confused. sizeof is about longwords and ints and
>> structs taking up so much room, not about how big files are. sizeof
>> on a file pointer will be four if it is a 32-bit pointer, not the
>> size of the file. malloc takes a size parameter in the sense you are
>> using, but if you apply sizeof to a variable holding the pointer it
>> too will say 4, if it is a 32-bit pointer variable.
>
>
> Of course all files stored by a operating system have header information
> it parses. This includes the size.
Yeah, but who knows how to parse headers geenrically? And anyway, that
is obviously not what the OP was looking for, given that they wanted (a)
a generic solution (b) related to language objects (c) in terms of memory.
> (Whose the joker here?)
> Common Lisp's function file-length.
Well whaddya know. I do GUIs, leave file work to the chimps. You win a
banana.
kt
--
http://www.theoryyalgebra.com/
"Algebra is the metaphysics of arithmetic." - John Ray
"As long as algebra is taught in school,
there will be prayer in school." - Cokie Roberts
"Stand firm in your refusal to remain conscious during algebra."
- Fran Lebowitz
"I'm an algebra liar. I figure two good lies make a positive."
- Tim Allen
Ken Tilton wrote:
>
>
> John Thingstad wrote:
>> On Fri, 13 Apr 2007 20:18:50 +0200, Ken Tilton
>> <···@theoryyalgebra.com> wrote:
>>
>>>
>>> As the jokers are implying, unless the file comes with header
>>> information you can parse, you do have to read through it to find
>>> out where it ends. This is true in any language, including C, which
>>> is why folks here are confused. sizeof is about longwords and ints
>>> and structs taking up so much room, not about how big files are.
>>> sizeof on a file pointer will be four if it is a 32-bit pointer, not
>>> the size of the file. malloc takes a size parameter in the sense you
>>> are using, but if you apply sizeof to a variable holding the pointer
>>> it too will say 4, if it is a 32-bit pointer variable.
>>
>>
>> Of course all files stored by a operating system have header information
>> it parses. This includes the size.
>
> Yeah, but who knows how to parse headers geenrically? And anyway, that
> is obviously not what the OP was looking for, given that they wanted (a)
> a generic solution (b) related to language objects (c) in terms of memory.
>
>> (Whose the joker here?)
>> Common Lisp's function file-length.
>
> Well whaddya know. I do GUIs, leave file work to the chimps. You win a
> banana.
>
> kt
>
Using file-length does solve the problem when the object is a file,
although it doesn't always give the right answer due to conversion
between the line-break characters used in different OS's.
But I am a little surprised by the fact that lisp doesn't natively
support finding size of objects in memory. Is it because lisp was never
meant to be used for the same stuff as C e.g. low(system) level
programming. Using UFFI seems to be the only way out.
~ Aman
Aman Goel <····@cleartrip.com> wrote:
+---------------
| But I am a little surprised by the fact that lisp doesn't
| natively support finding size of objects in memory.
+---------------
Remember that "Lisp", or as we mostly talk about here, Common Lisp,
is *not* a single implementation, but a specification of syntax
and semantics. The ANSI Common Lisp Standard, in particular, goes
to great lengths *not* to constrain the implementation of any
particular feature beyond the minimum necessary to ensure the
desired semantics (roughly). In particular, there is no requirement
whatsoever that any given CL object be represented as a fixed-size
contiguous string of bits in memory, and in fact, many CL types
are *not* so represented in most implementations. So what would
"the" size of an object be, given that its size can vary at runtime
*without* changing the object's identity?!? -- which, for some
implementations and some objects, it can. [Hint: Hash tables.]
[Hint#2: Streams.] [Hint#3: CLOS objects.]
-Rob
-----
Rob Warnock <····@rpw3.org>
627 26th Avenue <URL:http://rpw3.org/>
San Mateo, CA 94403 (650)572-2607
From: John Thingstad
Subject: Re: memory functions in lisp similar to sizeof, malloc etc. of C
Date:
Message-ID: <op.tqrnfttkpqzri1@pandora.upc.no>
On Sat, 14 Apr 2007 09:23:15 +0200, Aman Goel <····@cleartrip.com> wrote:
>
> But I am a little surprised by the fact that lisp doesn't natively
> support finding size of objects in memory. Is it because lisp was never
> meant to be used for the same stuff as C e.g. low(system) level
> programming. Using UFFI seems to be the only way out.
>
> ~ Aman
Common Lisp is a specification of behaviour for a family of Lisp languages.
It describes a common interface. Size, layout etc. are implementation
specific. So although your Lisp almost certainly has these facilities there
is no standard way. As you mentioned UFFI or CFFI is the best way to go if
you want to iron out some of these wrinkles in a portable way.
--
Using Opera's revolutionary e-mail client: http://www.opera.com/mail/
(message (Hello 'Aman)
(you :wrote :on '(Sat, 14 Apr 2007 12:53:15 +0530))
(
AG> But I am a little surprised by the fact that lisp doesn't natively
AG> support finding size of objects in memory.
using LENGTH function you can find size of string, vector, array or
whatever. that value should be ok for any algorithms you implement.
you might complain that this does not directly report you amount of
bits/bytes. but that value is implementation-dependant. you should not use
it in any portable algorithm. if you're really interested how much space it
actually uses, you can check your implementation's manual (or maybe source
code in some cases). on some systems sizeof(char) == 1, on other it might be
2 and even 4. some implementation might not support directly storing unboxed
values in array.
actually, there's absolutely NO WAY to find out how much space does data
occupy. even in C -- there is overhead for memory block align, for
supplementary heap structures etc. so, C won't tell you how much space does
your structure occupy. in fact, C won't tell you how much space did you
allocate. there's no standard function for this. Microsoft C has _msize --
but it's not portable to use it.
so, your surprise comes from general lack of knowledge of programming
languages -- you do not know C as well.
however, we might need information about size of objects in memory to
determine how much such objects we can allocate. there is function for this
practical purpose -- it's called ROOM. it's not possible to use it's output
in algorithm, since it's obviously non portable, but one can use it for
analysis of performance on a concrete implementation -- e.g. allocate some
1000 objects and see how does it influence free/allocated memory. btw i'm
using it quite intensively when programming some high performance
applications.
one can say that it would be better if ROOM return some number that can be
used inside algorithms -- for example, for planning cache size etc. but it's
damn hard to return any sensible value -- memory allocations are very
complex and it's extremely hard to predict how many objects it's possible to
allocate on heap. (it's not a problem of Lisp -- there is such thing as
address space fragmentation on OS level, so even if you have 500 MB free you
can fail to allocate some 10 MB continuous space). it's not even possible to
use free memory value for some heuristics -- on modern operating systems
virtual memory backed up by disk is frequently used, so OS and Lisp
implementation that works on top of it can report lots of free memory, but
if one uses it swapping will happen, and performance will drop terribly, up
to the point when application is not usable.
thus, it's easy to understand why there is no API for memory management in
standard Common Lisp -- if somebody really needs it badly, he can use
features of concrete implementation.
so, we can summarize that 'size of object in memory' is very vague value
even for C, and certainly high-level abstraction of Common Lisp make it even
more vague. it's possible exactly know all 'sizes of objects' only for such
low-level language as assembler, and only if you are not using high-level
operating system with virtual memory etc.
)
(With-best-regards '(Alex Mizrahi) :aka 'killer_storm)
"I am everything you want and I am everything you need")
On Apr 14, 12:22 pm, "Alex Mizrahi" <········@users.sourceforge.net>
wrote:
> on some systems sizeof(char) == 1, on other it might be
> 2 and even 4.
Nonsense. sizeof(char) is 1 by definition. In order to do systems
programming in C, there are a million little implementation-dependent
details. Try porting most Unix C programs to a compiler where char is
16 bits wide, or int isn't big enough to hold a void *.
(The larger point being that CL makes quite a bit more effort than C
to have portable semantics, and thus makes you actively reach for
implementation-specific facilities when trying to do systems level
programming)
From: Kent M Pitman
Subject: Re: memory functions in lisp similar to sizeof, malloc etc. of C
Date:
Message-ID: <uhcrgqr81.fsf@nhplace.com>
"Thomas F. Burdick" <········@gmail.com> writes:
> On Apr 14, 12:22 pm, "Alex Mizrahi" <········@users.sourceforge.net>
> wrote:
> > on some systems sizeof(char) == 1, on other it might be
> > 2 and even 4.
>
> Nonsense. sizeof(char) is 1 by definition. In order to do systems
> programming in C, there are a million little implementation-dependent
> details. Try porting most Unix C programs to a compiler where char is
> 16 bits wide, or int isn't big enough to hold a void *.
>
> (The larger point being that CL makes quite a bit more effort than C
> to have portable semantics, and thus makes you actively reach for
> implementation-specific facilities when trying to do systems level
> programming)
I would put the larger point more strongly than this, even though I
agree with the conclusion here for as far as it goes.
The short form of my extended point is that Lisp is a language of
expression, not a language of implementation.
I would say that Lisp is not even ABOUT the question of controlling
data layout, hence asking a question about the data layout chosen is
antithetical to what Lisp is offering you. Lisp is not about
micro-managing. Offering sizeof in Lisp would be inviting people to
use it, sort of like making sure the president of a multi-national
corporation has the email addresses of every employee in his address
book, cluttering his completion space so that every time he wanted to
send an email to a vice president it ended up telling him after the
first few characters of the name that it was still ambiguous, because
he might have meant to send to a file clerk halfway around the world.
It's all about abstraction, and abstraction is all about complexity
control.
The Lisp Way, if there can be said to be such a thing, is more
commonly to create an option for the creation of a datastructure of
kind x such that you can later say the thing people really want to
say, which is, "make me something big enough to hold an x". That is,
focus on the thing you want done, not silly little operators that
presuppose implementation and bind you to an implementation. That's
what leave things flexible for portability. Everytime you make things
more specific, you take away a bit of flexibility. So instead Lisp
tries to understand why people want these operators and to satisfy the
high-level needs instead, hoping where possible not to expose
implementational detail that would later tie its hands. The omission
of sizeof, in CL at least, is therefore not an accident, but something
of an intention... at least as I see it. It's certainly not like we
didn't know about the function when we standardized the language, and
we could have provided it if it made sense or would have worked well
with what we did offer.
In truth, what Lisp does is what people using static languages want,
too, it's just that it has to be done by programmers not language
designers. No one actually looks for numbers coming out of sizeof.
They just set constants to the size of something without looking, and
then later make other things of the same size or compare them to see
if they have adequate size... so rather than giving you operators that
say this is what you want to say, they make you (some would say "let
you") implement those operators every time...
(message (Hello 'Thomas)
(you :wrote :on '(16 Apr 2007 00:36:48 -0700))
(
??>> on some systems sizeof(char) == 1, on other it might be
??>> 2 and even 4.
TFB> Nonsense. sizeof(char) is 1 by definition.
#ifdef UNICODE
typedef wchar_t char_t;
#else
typedef char char_t;
#endif
now sizeof(char_t) can be 1, 2 or 4 :)
actually i meant size of LISP char in bytes -- i was unable to find better
designator for this value..
)
(With-best-regards '(Alex Mizrahi) :aka 'killer_storm)
"I am everything you want and I am everything you need")
"Alex Mizrahi" <········@users.sourceforge.net> writes:
> (message (Hello 'Thomas)
> (you :wrote :on '(16 Apr 2007 00:36:48 -0700))
> (
>
> ??>> on some systems sizeof(char) == 1, on other it might be
> ??>> 2 and even 4.
>
> TFB> Nonsense. sizeof(char) is 1 by definition.
>
> #ifdef UNICODE
> typedef wchar_t char_t;
> #else
> typedef char char_t;
> #endif
>
> now sizeof(char_t) can be 1, 2 or 4 :)
>
> actually i meant size of LISP char in bytes -- i was unable to find better
> designator for this value..
typedef struct{
char* name;
uint8* utf8value;
int is_letter;
int is_digit;
int available_in_encoding[NB_OF_ENCODING];
} character;
sizeof(character)==56
So what?
char is a standard C type, and by definition, sizeof(char)==1
That is, sizeof returns integral numbers in units of sizeof(char).
--
__Pascal Bourguignon__
http://www.informatimago.com/
http://pjb.ogamita.org/
From: John Thingstad
Subject: Re: memory functions in lisp similar to sizeof, malloc etc. of C
Date:
Message-ID: <op.tqvqt7t2pqzri1@pandora.upc.no>
> char is a standard C type, and by definition, sizeof(char)==1
> That is, sizeof returns integral numbers in units of sizeof(char).
>
>
The number of BYTE's actually.
I should say octets I suppose.
But in C a byte is 8 bits.
(a char can be signed, a byte isn't)
--
Using Opera's revolutionary e-mail client: http://www.opera.com/mail/
On Mon, 16 Apr 2007 16:07:09 +0200, John Thingstad wrote:
>> char is a standard C type, and by definition, sizeof(char)==1
>> That is, sizeof returns integral numbers in units of sizeof(char).
>>
>>
>
> The number of BYTE's actually.
> I should say octets I suppose.
> But in C a byte is 8 bits.
> (a char can be signed, a byte isn't)
No, it isn't. C doesn't know anything about bytes, or didn't until ISO
added int8_t and uint8_t in inttypes.h. (Well, that tells it about
octets, it still doesn't really know anything about bytes.) There are
machines with non-8-bit bytes.
The original quote is correct. sizeof(char)==1 is the definition of char,
and has more to do with the granularity of address arithmetic than it does
about the bit-depth of the type.
I've used machines with char being 8, 16, 24 and 32 bits wide in
the last ten years. Machines with char being a 32-bit type are still
quite common, in the DSP realm, although most new designs do have 8-bit
addressability, mostly so that they handle existing C code more
idiomatically.
Cheers,
--
Andrew
From: Ari Johnson
Subject: Re: memory functions in lisp similar to sizeof, malloc etc. of C
Date:
Message-ID: <m2mz183vwd.fsf@hermes.theari.com>
"Thomas F. Burdick" <········@gmail.com> writes:
> On Apr 14, 12:22 pm, "Alex Mizrahi" <········@users.sourceforge.net>
> wrote:
>> on some systems sizeof(char) == 1, on other it might be
>> 2 and even 4.
>
> Nonsense. sizeof(char) is 1 by definition. In order to do systems
> programming in C, there are a million little implementation-dependent
> details. Try porting most Unix C programs to a compiler where char is
> 16 bits wide, or int isn't big enough to hold a void *.
On the most common 64-bit platforms, sizeof(int) != sizeof(void *).
Linux/amd64 and MacOS X both do LP64, where longs and pointers are 64
bits but ints remain 32. By contrast, on 64-bit Windows you have
LLP64, where long longs and pointers are 64 bits and longs and ints
are both 32.
In order to do any programming in C, not just system programming,
there are a million little implementation-dependent details. That's
why other languages are better for non-system programming: they
abstract away those implementation details.
From: Edi Weitz
Subject: Re: memory functions in lisp similar to sizeof, malloc etc. of C
Date:
Message-ID: <u3b332h5z.fsf@agharta.de>
On Sat, 14 Apr 2007 12:53:15 +0530, Aman Goel <····@cleartrip.com> wrote:
> Using file-length does solve the problem when the object is a file,
> although it doesn't always give the right answer due to conversion
> between the line-break characters used in different OS's.
If you use the right element type, you will /always/ get the right
answer.
> But I am a little surprised by the fact that lisp doesn't natively
> support finding size of objects in memory. Is it because lisp was
> never meant to be used for the same stuff as C e.g. low(system)
> level programming.
Nonsense.
--
Lisp is not dead, it just smells funny.
Real email: (replace (subseq ·········@agharta.de" 5) "edi")
On Apr 13, 8:13 pm, Aman Goel <····@cleartrip.com> wrote:
> John Thingstad wrote:
> > On Fri, 13 Apr 2007 12:11:24 +0200, Aman Goel <····@cleartrip.com> wrote:
>
> >> Dear folks,
>
> >> Do you know if their are memory manipulation functions in lisp
> >> similar to sizeof, malloc etc in C?
> >> Is there a family of functions like these primitive to lisp?
>
> >> My need of this hour is a function which can return the byte size of
> >> objects in memory.
>
> >> Thanx and Regards,
> >> Aman
>
> > Not really. The ANSI spec does not specify such functionality.
> > But foreign function interfaces have functions that deal with memory in
> > a C like manner.
> > You might download CFFI and use the functions there.
> > This library is a portable layer above the specific foreign function
> > interface and runs on most systems.
> > Things like foreign-alloc, foreign-free, foreign-type-size map to the
> > things you ask for.
> > (There is also a library called UFFI which does this, but it runs on
> > slightly fewer systems.)
>
> > Are these objects C objects or Lisp objects?
> > It might help if I knew more about the problem. Perhaps you are asking
> > for the wrong thing..
> > Lisp is, after all, not C.
>
> > --Using Opera's revolutionary e-mail client:http://www.opera.com/mail/
>
> I am receiving a file, uploaded from the browser and sent as a post
> parameter to the server (the Hunchentoot server)
>
> I want to find the size of the uploaded file to make sure it is within
> certain limit before manipulating it.
>
> I could do this by reading thru a stream to the file, but I want to find
> a better (generic) way to find size of objects in lisp.
IIRC the HTTP protocol has an *optional* argument specifying the
length of the transmission.
Unfortunately as I mentioned this is an *optional* argument. It can
always be terminated by just disconnecting.
>
> ~ Aman