Nick Maclaren wrote:> In article <5pCdnWbp1rsoKaLeRVnyuw@pipex.net>, > Steve at fivetrees <steve@NOSPAMTAfivetrees.com> wrote: > >>"Nick Maclaren" <nmm1@cus.cam.ac.uk> wrote in message >>news:dhobjl$e2v$1@gemini.csx.cam.ac.uk... >>>Not so. In Fortran 77, it was possible to allocate all memory statically, >>>but it isn't generally possible. It can't be done in Fortran 90 or C. >> >><even_more_extreme_pedant_mode=ON> >> >>It *can* be done in C - by avoiding malloc ;). > > Problem one: in C, there is no memory management beyond stack scoped > except by using malloc. Any algorithm that requires more than that > can't be done if you don't use malloc.Well ... there *is* static allocation. Then subystems can their own private memory allocations.> Problem two: there are many library facilities that use malloc either > explicitly or implicitly - including almost all I/O - you would have > to avoid them, too.And, indeed, in systems that must operate indefinitely, one must not use libraries with such dependencies because any global general purpose heap (malloc/free) will fragment unless all blocks are the same size. Frequently, the same systems that have such requirements also have limited memory resources and so using a global malloc with as single fixed size block is unacceptable because of the wasted memory in small allocations. As a side note, its not the malloc that fragments heaps, its the continuous malloc/free cycle over time. For this reason, systems that must operate continuously for an indefinite period of time *can* use malloc/new at initialization ... as long as they don't use free/delete ... -- Michael N. Moran (h) 770 516 7918 5009 Old Field Ct. (c) 678 521 5460 Kennesaw, GA, USA 30144 http://mnmoran.org "So often times it happens, that we live our lives in chains and we never even know we have the key." The Eagles, "Already Gone" The Beatles were wrong: 1 & 1 & 1 is 1
Regarding calculation of free memory
Started by ●September 28, 2005
Reply by ●October 4, 20052005-10-04
Reply by ●October 4, 20052005-10-04
In article <slrndk4ool.et5.dave@fly.srk.fer.hr>, Drazen Kacar <dave@fly.srk.fer.hr> writes: |> |> However, I'm confused with the mention of "reverse engineering" in the |> above paragraph. For Solaris, at least, things one needs to do are fairly |> well documented[1]. It's also possible to automate the process, so one |> doesn't have to do it again and again by hand. |> |> Could you give me an example of something that required reverse |> engineering? One simple example is including two files that logically look like the following: extern int a = 1; extern int b = 1; and: extern int a = 1; extern int c = 1; In the context of external references to a, b and c, which will you get (a) searched for and (b) overridden? There are a zillion other examples, and I have seen at least a couple of dozen such issues arise in real programs. The point is that Solaris, like all or almost all modern systems, does not publish a specification of its linker and loader. It provides a guide on how to use it, which is not the same thing at all. Solaris 2.6 and before had some SERIOUS bugs in this area, but it was very hard to get them reported because there wasn't any document to say what should happen! Regards, Nick Maclaren.
Reply by ●October 4, 20052005-10-04
In article <buv0f.13759$e07.10785@news.cpqcorp.net>, "FredK" <fred.nospam@nospam.dec.com> writes: |> |> To bring up an antique that gets it right, the VMS linker would |> complain that there were multiple definitions and refuse to produce |> an executable. Which from time to time generates complaints |> from people porting from UNIX. Of course, they apparently don't |> realize that what they are producing on UNIX may not be correct, |> or only correct by accident. Without a precise specification, I would say that the very concept of correctness is absent. The best that can be hoped for is that it will do what the user intended it to do - if, indeed, the user had a definite intent in the matter. I have too often had people refuse to fix such inconsistencies because they were not prepared to make changes to code that they did not understand the intent of. But the same problem can arise in 'correct' code, where some of those linkages are weak externals or weak definitions. Fortran COMMON is a particularly fruitful source of confusion, as it is not quite a definition, not quite a reference and neither weak nor strong. Mix that with other types of symbol, and try to work out what should happen .... Regards, Nick Maclaren.
Reply by ●October 4, 20052005-10-04
"Nick Maclaren" <nmm1@cus.cam.ac.uk> wrote in message news:dhtsd0$dsi$1@gemini.csx.cam.ac.uk...> > In article <slrndk4ool.et5.dave@fly.srk.fer.hr>, > Drazen Kacar <dave@fly.srk.fer.hr> writes: > |> > |> However, I'm confused with the mention of "reverse engineering" in the > |> above paragraph. For Solaris, at least, things one needs to do arefairly> |> well documented[1]. It's also possible to automate the process, so one > |> doesn't have to do it again and again by hand. > |> > |> Could you give me an example of something that required reverse > |> engineering? > > One simple example is including two files that logically look like > the following: > > extern int a = 1; > extern int b = 1; > > and: > > extern int a = 1; > extern int c = 1; > > In the context of external references to a, b and c, which will > you get (a) searched for and (b) overridden? > > There are a zillion other examples, and I have seen at least a > couple of dozen such issues arise in real programs. > > The point is that Solaris, like all or almost all modern systems, > does not publish a specification of its linker and loader. It > provides a guide on how to use it, which is not the same thing > at all. Solaris 2.6 and before had some SERIOUS bugs in this area, > but it was very hard to get them reported because there wasn't any > document to say what should happen! >To bring up an antique that gets it right, the VMS linker would complain that there were multiple definitions and refuse to produce an executable. Which from time to time generates complaints from people porting from UNIX. Of course, they apparently don't realize that what they are producing on UNIX may not be correct, or only correct by accident. But then again, I also have problems with the general UNIX/C case sensitivity - having too many times ported code that had routines with the same name differing only by case, and where code randomly called the wrong one (usually in an error path where nobody bothered to debug it - heck, even in a POSIX based conformance test suite!).
Reply by ●October 4, 20052005-10-04
"FredK" <fred.nospam@nospam.dec.com> writes:>To bring up an antique that gets it right, the VMS linker would >complain that there were multiple definitions and refuse to produce >an executable. Which from time to time generates complaints >from people porting from UNIX. Of course, they apparently don't >realize that what they are producing on UNIX may not be correct, >or only correct by accident.Same for Solaris, but not when linking these objects dynamically where there are also matters as scoping (is the object visible or not) and ordering are important (you are allowed to replace certain functions in the C library, after all). a.c: b.c: ld: fatal: symbol `a' is multiply-defined: (file a.o type=OBJT; file b.o type=OBJT); ld: fatal: File processing errors. No output written to a.out>But then again, I also have problems with the general UNIX/C >case sensitivity - having too many times ported code that had >routines with the same name differing only by case, and where >code randomly called the wrong one (usually in an error path >where nobody bothered to debug it - heck, even in a POSIX >based conformance test suite!).That's not just an issue with case sensitivity but a similar situations can arise with other naming schemes. (And this one source of confusion is easily recmoved using a coding style which specifies how to use case. Casper -- Expressed in this posting are my opinions. They are in no way related to opinions held by my employer, Sun Microsystems. Statements on Sun products included here are not gospel and may be fiction rather than truth.
Reply by ●October 4, 20052005-10-04
In article <43429f8b$0$11074$e4fe514c@news.xs4all.nl>, Casper H.S. Dik <Casper.Dik@Sun.COM> writes: |> |> Same for Solaris, but not when linking these objects dynamically |> where there are also matters as scoping (is the object visible or not) |> and ordering are important (you are allowed to replace certain functions |> in the C library, after all). Precisely. And similar remarks apply to every modern Unix I have looked at, including Linux. Regards, Nick Maclaren.
Reply by ●October 4, 20052005-10-04
"Hank Oredson" <horedson@earthlink.net> writes:> "Michael N. Moran" <mike@mnmoran.org> wrote in message > > Of course you *can* call it from C, but you can't expect > > it to be there on all systems, especially "bare metal" > > embedded systems. > > The programmer must know her tools. If she is writing a > banking backroom system, she will not be interested in > porting it to a Blackberry, or an access point.Though some access points (WRT54G) already have sbrk(), and I'm sure it's not long until Blackberries have it too ;-) -- David Gay dgay@acm.org
Reply by ●October 4, 20052005-10-04
In article <LcD0f.13856$tj7.3768@news.cpqcorp.net>, FredK <fred.nospam@nospam.dec.com> wrote:> >I've yet to find UNIX code that sticks to a convention, and that is >remotely safe from boneheaded mistakes. Probably 80% or more >of the code I've seen doesn't use C prototypes, which would >have at least pointed out they wanted Delete() instead of delete() - >each of which had different parameters (for an example).Well, you haven't seen mine, then :-) Regards, Nick Maclaren.
Reply by ●October 4, 20052005-10-04
"Casper H.S. Dik" <Casper.Dik@Sun.COM> wrote in message news:43429f8b$0$11074$e4fe514c@news.xs4all.nl...> "FredK" <fred.nospam@nospam.dec.com> writes: > > >To bring up an antique that gets it right, the VMS linker would > >complain that there were multiple definitions and refuse to produce > >an executable. Which from time to time generates complaints > >from people porting from UNIX. Of course, they apparently don't > >realize that what they are producing on UNIX may not be correct, > >or only correct by accident. > > Same for Solaris, but not when linking these objects dynamically > where there are also matters as scoping (is the object visible or not) > and ordering are important (you are allowed to replace certain functions > in the C library, after all). > > a.c: > b.c: > ld: fatal: symbol `a' is multiply-defined: > (file a.o type=OBJT; file b.o type=OBJT); > ld: fatal: File processing errors. No output written to a.out >By dynamic linking, I assume some sort of runtime activation of a DLL? Not exactly sure what is meant.> >But then again, I also have problems with the general UNIX/C > >case sensitivity - having too many times ported code that had > >routines with the same name differing only by case, and where > >code randomly called the wrong one (usually in an error path > >where nobody bothered to debug it - heck, even in a POSIX > >based conformance test suite!). > > That's not just an issue with case sensitivity but a similar > situations can arise with other naming schemes. (And this > one source of confusion is easily recmoved using a coding > style which specifies how to use case. >I've yet to find UNIX code that sticks to a convention, and that is remotely safe from boneheaded mistakes. Probably 80% or more of the code I've seen doesn't use C prototypes, which would have at least pointed out they wanted Delete() instead of delete() - each of which had different parameters (for an example).
Reply by ●October 4, 20052005-10-04
Nick Maclaren wrote:> In article <1128388888.617990@haldjas.folklore.ee>, > Sander Vesik <sander@haldjas.folklore.ee> wrote:> >Ahem. Sorry, Nick, but at the very least in case of Solaris, it is very > >easy to find out what exactly it is that the dynamic linker does and > >comapre the results of different runs. This is certainly not advanced > >hacker level. > > Oh, really? It is (relatively) easy to find out what is loaded, > though even that needs fairly advanced knowledge. But finding out > which library and which symbol in that library is used to satisfy > another symbol in another library is not so easy. I had a problem > recently that came down to this. Nasty.It isn't that hard. Try this: env LD_DEBUG=bindings ls >/dev/null Works on Linux, too. -- .-. .-. Yes, I am an agent of Satan, but my duties are largely (_ \ / _) ceremonial. | | dave@fly.srk.fer.hr