Flávio Etrusco | 1 Dec 2009 01:05
Picon
Gravatar

Re: private integer is an illegal counter variable

On Sat, Nov 28, 2009 at 7:12 AM, Jürgen Hestermann
<juergen.hestermann@...> wrote:
>> And there are many reasons why there are so many string types nowadays.
>
> True.
>
>> Simply use {mode objfpc}{$h+} like lazarus suggests.
>
> I think the root cause of all these problems are generic types. They cause
> more trouble than they avoid. I would suggest that noone never uses such
> generic types but uses shortstring or ansistring (or...) as they need.
> Telling people to simply use this or that compiler switch is not the
> solution (you have to explain this over and over again). Generic types
> should be the exception and not the norm. It begs for trouble in many
> situations. Using strict types also lets the user read more about the nature
> of these types and therefore knows more about possible side effects. Someone
> who has shortstings in mind when using strings would surely use it in a
> different way as someone who has ansistrings in mind (provided he knows how
> they are handled by the compiler). And telling people clearly about the
> implementation of these different types is much better than obscuring them
> by generic types.
>

Maybe FPC could have a directive to disable/undeclare the 'string'
type/keyword ;-)

-Flávio
_______________________________________________
fpc-pascal maillist  -  fpc-pascal@...
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
(Continue reading)

Flávio Etrusco | 1 Dec 2009 01:58
Picon
Gravatar

Re: readonly variables

On Sun, Nov 29, 2009 at 1:11 PM, Jonas Maebe <jonas.maebe@...> wrote:
>
> On 29 Nov 2009, at 16:51, Anthony Walter wrote:
>
>> Having said all that, Jonas, what is the actual implemented behaviour
>> of FPC? Does it 0 initialize heap memory at startup or not?
>
> I guess you mean global data rather than heap (heap is what is handled by getmem/freemem/..., and there are
no guarantees regarding that memory).
>
> FPC currently initialises the global data to 0 on platforms that do not do this by themselves. When it turns
global variables into register variables, it will also initialise such registers with 0.
>
>> If not,
>> what is the justification for not doing so when this has been a long
>> established behaviour of Delphi?
>
> A justification could be that it causes code bloat in case of register variables, and that platforms which
do not zero global data memory by themselves are usually embedded devices where every operation counts
(both in terms of code size and in terms of energy usage).
>
>
> Jonas_______________________________________________

FWIW, IIRC the last time this issue (global variables initialization)
came up some FPC developer explained this was a platform specific
behavior and shouldn't be counted on, so I thought MvC was right in
this thread up to now...

-Flávio
(Continue reading)

Juha Manninen | 1 Dec 2009 13:03
Picon

String types in a wider perspective (was: private integer is an illegal counter variable)

On lauantai, 28. marraskuuta 2009 12:12:19 Jürgen Hestermann wrote:

> > And there are many reasons why there are so many string types nowadays.

>

> True.

>

> > Simply use {mode objfpc}{$h+} like lazarus suggests.

>

> I think the root cause of all these problems are generic types. They cause

> more trouble than they avoid. I would suggest that noone never uses such

> generic types but uses shortstring or ansistring (or...) as they need.

> Telling people to simply use this or that compiler switch is not the

> solution (you have to explain this over and over again). Generic types

> should be the exception and not the norm. It begs for trouble in many

> situations. Using strict types also lets the user read more about the

> nature of these types and therefore knows more about possible side

> effects. Someone who has shortstings in mind when using strings would

> surely use it in a different way as someone who has ansistrings in mind

> (provided he knows how they are handled by the compiler). And telling

> people clearly about the implementation of these different types is much

> better than obscuring them by generic types.

A generic "string" type makes a lot sense when switching between dynamic string types (AnsiString, UnicodeString...).

Delphi managed to do the switch almost transparently because they had designed their libraries well. Old code using AnsiString just worked after compiling it for UnicodeString.

The historical ShortString is handled very differently (explicit memory management etc.). It is a different type semantically and so it should be different also syntactically.

This apparently small syntax detail has a wider symbolic message. When people here are seriously arguing about how important ShortString is ('cause you can save 3 bytes or something...) the message for potential new Pascal programmers is like:

"If you think ShortString as a default string type is important because it was invented at 1970 then welcome to our Old Farts' Freak Club. Otherwise please use some contemporary language."

I am almost an old fart by age but still I am looking for new innovations.

Whole computing is still very young and is advancing rapidly. Development tools must advance, too.

Now Object Pascal has a place in this ecosystem as a compiled language with clear syntax. Virtual machines are still memory hogs and C++ is ugly.

After 50 years nobody cares if virtual machines hog memory because computers will have so much resources but not yet so.

I am happy this language is evolving. Generics syntax is a good thing.

Virtual machines or garbage collections would not belong here but I guess they are not even planned.

Juha Manninen

_______________________________________________
fpc-pascal maillist  -  fpc-pascal@...
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Mattias Gaertner | 1 Dec 2009 13:43
Picon
Favicon

Re: String types in a wider perspective (was: private integer is an illegal counter variable)

On Tue, 1 Dec 2009 14:03:37 +0200
Juha Manninen <juha.manninen@...> wrote:

>[...]
> This apparently small syntax detail has a wider symbolic message. When people 
> here are seriously arguing about how important ShortString is ('cause you can 
> save 3 bytes or something...) the message for potential new Pascal programmers 
> is like:
> "If you think ShortString as a default string type is important because it was 
> invented at 1970 then welcome to our Old Farts' Freak Club. Otherwise please 
> use some contemporary language."
> I am almost an old fart by age but still I am looking for new innovations.
> Whole computing is still very young and is advancing rapidly. Development 
> tools must advance, too.
> Now Object Pascal has a place in this ecosystem as a compiled language with 
> clear syntax. Virtual machines are still memory hogs and C++ is ugly.
> After 50 years nobody cares if virtual machines hog memory because computers 
> will have so much resources but not yet so.

One of the innovations of the last years is the higher demand for
multi threaded apps.
Reference counted strings need atomic operations and are therefore
much slower as soon as you start another thread.
This could give shortstring a renaissance.

Mattias
_______________________________________________
fpc-pascal maillist  -  fpc-pascal@...
http://lists.freepascal.org/mailman/listinfo/fpc-pascal

Bruce Bauman | 1 Dec 2009 17:58

Validate heap/stack addresses

I’m trying to port/debug some ugly Pascal code.

 

Is there a way I can tell if an arbitrary address is within the heap or stack?

 

I want to do something like:

 

Assert(ValidHeapAddress(a))

Assert(ValidStackAddress(a))

 

to catch potential errors in the code.

 

I’m guessing any address between “end” and the current brk is a valid heap address.

 

Thanks.

 

-- Bruce

CONFIDENTIALITY NOTICE: This e-mail is confidential and intended solely for the use of the individual or entity to which it is addressed. If you are not the intended recipient, be advised that you have received this email in error and that any use, dissemination, forwarding, printing or copying of this e-mail is strictly prohibited. If you received this e-mail in error, please delete it from your computer and contact the sender.
_______________________________________________
fpc-pascal maillist  -  fpc-pascal@...
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Luca Olivetti | 1 Dec 2009 18:03

Re: String types in a wider perspective

En/na Mattias Gaertner ha escrit:

> One of the innovations of the last years is the higher demand for
> multi threaded apps.
> Reference counted strings need atomic operations and are therefore
> much slower as soon as you start another thread.

I always protect multithreaded sting access with a critical section.
Do you mean it is not needed?

Bye
--

-- 
Luca
_______________________________________________
fpc-pascal maillist  -  fpc-pascal@...
http://lists.freepascal.org/mailman/listinfo/fpc-pascal

Jonas Maebe | 1 Dec 2009 18:27
Picon
Favicon

Re: Validate heap/stack addresses


On 01 Dec 2009, at 17:58, Bruce Bauman wrote:

> Is there a way I can tell if an arbitrary address is within the heap or
> stack?
> 
> I want to do something like:
> 
> Assert(ValidHeapAddress(a))

That is not possible without installing your own memory manager that tracks all allocations. Also keep in
mind that this will never work for memory allocated by code outside your application (in some external library).

heaptrc has a function with similar functionality called checkpointer(), but
a) it's not exported
b) it checks for more than just heap allocations (it also checks for global data and stack)
c) it only works on some targets (the ones supported by -gc in 2.4.0 -- earlier FPC versions did not contain
any checks regarding supported targets for this feature, so it just caused crashes on some platforms) and
has not been maintained for ages (so I have no idea as to what its status is).

> Assert(ValidStackAddress(a))

This can be done by checking whether the address is <= sptr and >= stackbottom.

> to catch potential errors in the code.

If you are working on an Intel Linux or Mac OS X/i386 10.5.x platform, I would strongly recommend Valgrind.

> I'm guessing any address between "end" and the current brk is a valid
> heap address.

That is only true on some old systems (such as go32v2, and possibly some very old Linux FPC versions). In most
systems, the heap is no longer a contiguous region.

Jonas_______________________________________________
fpc-pascal maillist  -  fpc-pascal@...
http://lists.freepascal.org/mailman/listinfo/fpc-pascal

Jonas Maebe | 1 Dec 2009 18:28
Picon
Favicon

Re: String types in a wider perspective


On 01 Dec 2009, at 18:03, Luca Olivetti wrote:

> I always protect multithreaded sting access with a critical section.
> Do you mean it is not needed?

The reference counting of ansistrings/... is thread safe. Accessing the characters etc still requires
explicit synchronisation if at least one writer is involved.

Jonas_______________________________________________
fpc-pascal maillist  -  fpc-pascal@...
http://lists.freepascal.org/mailman/listinfo/fpc-pascal

Anthony Walter | 1 Dec 2009 18:51
Picon
Gravatar

Re: Validate heap/stack addresses

On Tue, Dec 1, 2009 at 11:58 AM, Bruce Bauman
<bruce.bauman@...> wrote:
> I’m trying to port/debug some ugly Pascal code.
>
> Is there a way I can tell if an arbitrary address is within the heap or
> stack?

Without hooking/replacing the memory manager, I don't believe you can
handle memory tracking this information. And even if you did hook
replace the memory manager it would still fail in places where you
interface with shared libraries that handle their own memory
management.

If don't mind using OS specific functions, Windows provides ways to
query process memory base address range and memory querying (which
returns the number of consecutive pages available for writing). For
that look at GetSystemInfo for memory page information, OpenProcess
with memory query flags (if you don't have the rights use
AdjustTokenPrivileges), and VirtualQueryEx to find consecutive valid
memory pages. I believe VirtualQueryEx works upon all process system
memory (code/stack/heap).
_______________________________________________
fpc-pascal maillist  -  fpc-pascal@...
http://lists.freepascal.org/mailman/listinfo/fpc-pascal

Anthony Walter | 1 Dec 2009 18:55
Picon
Gravatar

Re: Validate heap/stack addresses

Oh and for querying stack pointers, there should be an OS function
somewhere to give you the base stack pointer address and available
stack size, though I don't know the names of functions off the top of
my head.
_______________________________________________
fpc-pascal maillist  -  fpc-pascal@...
http://lists.freepascal.org/mailman/listinfo/fpc-pascal


Gmane