running a sql database concurrently with your fs is a terrible idea for just all the reasons you've named. why you would try to do it is beyond me. perhaps you need to look at the problem a bit differently. be inc. did is successfully. how?
Re:Reiserfs, storage and why do you want this?
on
Database File System
·
· Score: 1
this is an excellent example. in fact, i used to do just this on my long gone beos system. oh no, not another beos nut raving like a lunatic, i'm sure is what you're thinking. i'll try to keep it short. most users will not see the value of this until they've had some time to use it. here's the case that i found useful: viewing a list of the most recent songs in my collection (which are spread over multiple directories). sure, [some app] will let me do the same thing, but will it also let me do the same thing for jpegs/movies/documents/[your favorite most used files here]? now, wouldn't it be great if EVERY APP on your system could do the exact same thing, without having to include special id3 parsing code or knowing anything about your xyz files?
another use, one which microsoft seems interested in, is using it for email filtering. bemail used to dump every email you got as a file into your mail directory. there was metadata for the from, to, subject, date fields. you could query your email. list by newest first, find mail sent by this person in this time period, whatever. and every app could do this, with a generic interface to the BeFS, without having to understand anything about email headers. this will effectively be microsoft's M: drive in the far future (or, so they claim). the same thing for contact info (be's People files used to have no content, only metadata).
i look forward to having this implemented in linux. truly a feature i've been missing.
there's an old usenet troll tradition of trying to include the word "flame", or some derivative thereof, in a flamebait post. a good enough troll could blatantly flaunt the fact and still start a flamefest. i believe mister ballmer is following the this fine tradition, by acknowledging that he does not intend to spread fud, and then proceeding to do just that.
kids, if you want to learn more about trolling, see alt.flame.
this was tried already in 1999/2000 by two companies: idrive and xdrive. both are now extinct. you could mount their filesystem via webdav (see "cadaver" for unix, "web folders" in windows), or access it with a browser. you had a shared folder that people could copy files out of ("sideloading", idrive called it) to your own account. even better, idrive had scour.net search the shared folders and make those files available for download right from their search engine. a great way to find mp3's, and guarenteed fast downloads.
unfortunately, the business model for this seemed to be nonexistant. users were reluctant to pay for anything.
An off the wall idea and dare I say it, something uniqu, turned inot reality.
hmm, i remember having done something similar with my idrive account using a web-dav filesystem... in 1999. idrive.com (now deceased) encouraged their users to do this (webdav is included in recent versions of windows as "web folders"). ah, those were the days, unlimited storage, all the quality media you could download from idrive at quite amazing speeds, and scour.net to search it all for you. hmm, quite alot like gmail, but with files instead of email.
I could store this new disk in my new 12-minute wide closet.
the lorentz equations give us the ability to translate between the 3 (major) spacial dimensions and the temporal dimension. simplified to one spacial dimension, and assuming your closet is not (relatively) accelerating, you can say that 1 second is equal to approx 300,000,000 meters.
well, i agree with everything you've said.* how about that?
i think many people responding to my post have taken it a bit too harshly. i'm not trying disparage all java coders. there are many good ones, and there are many terrible programmers in all other language areas. i'm just saying that, because java is a safe and common choice for projects employing the lowest common denominator of programmers, it is often associated with that type of work.
*except for this: Reading your post it is obvious that you are either an elitist with a lot of bad experiences, or someone with no experience.
i have nothing against java. i use it once in a while. many of posters have taken to speculate about my language of choice, how good or bad of a coder i be, my attitude towards others, my work experience, software engineering abilities, age, rugged good looks, and other details. i'll tell you that i'm generally happy, because i do what i love to do, and get paid to do it. i hope you're all as happy at your jobs.
here is the REAL reason hackers don't like java, and most of them don't even realize it.
the job of an organization developing a software product (whether it's a company, an open source team, whatever), is to get a product out. nobody outside the project cares about languages or anything else, as long as it all works in the end. but to get a product out, the manager eventually has to pick a strategy. they usually fall somewhere in between the two extremes: A) use a few brilliant (possibly well paid) hackers and let them do the work. they're smart, and good enough to rely on to just do it. managing them is like herding cats, but why would you need to? B) use an army of keyboard monkeys and manage the hell out of them. these guys can pound out mediocre code, but with enough software engineering from the top down, well defined specs, and massive testing and integration, their work is sieved into a release-quality product.
real hackers hate being marginalized, having their creativity stifled (yes, for those of us who actually write code, not just implement specs, creativity is involved), having to do the dumb solution just because everyone else is too weak to do their part of the smart solution.
java is not a bad language. i think many would agree that is it at least decent (i think it's pretty good, actually). but java is the language of the B coders. it is made to be easy and idiot proof, like visual basic. you cannot do "neat hacks" in java, because if you could, the B coders would screw it up and produce worse code. java is a great language for the B coders. but the choice of java for a project is often a leaning toward strategy B. it's the "we can get any code monkey off the street to do this". it's the grunt work software that real hackers don't want to do, and what B coders are hired for.
perl, a RAD (and rad) programming language, does not suffer this stigma. perl is accepted by hackers, precisely because it is not idiot proof. it's easy to confuse the B coders (and yourself) with some maliciously written ascii barf. you can do some crazy tricks in perl. it does not lend itself well to software engineering and the micromanagement of the B coders. perl is a hacker's language.
many real hackers i've seen instinctively feel resentment towards java and the like, because they see marginalization of the software industry. java is for the blue collar coders, part of the greater plan of "software factories", where reproducability, meeting deadlines and specs, and easy replacement of people is way more important than doing cool shit. those of us who wish to stay at the top of the game, to do the cool shit, to write the programs that interest us the right way are often drawn to the languages that keep out the idiots, that have a higher barrier of entry, and let us do the cool hacks.
i don't dislike java, and i don't dislike you B coders out there (you know who you are). i just don't want to be one of you.
The worst that can happen is that they'll be replaced by someone that knows how to make a profit selling the same thing
no, the worst that could happen is that they'll turn into the printer industry. quality will decline industry-wide, cell phones will be super cheap and nobody will want to pay anything for them. but you may end up paying for cellphone batteries (or something else) as much as you do for printer cartridges (and generic brands will be cut out, they'll see to that).
a "decent" profit margin keeps the industry innovating. a fat one makes it lazy, and a slim one brings down quality. i'd rather buy a printer that will last for 5 years and have 10$ ink cartridges, and a phone that will last a couple of years with awesome features, than get either for free and pay for it ten times over in required "refills".
Dude - you are totally misreading the article - the CHEAPER version is aimed at businesses.
dude, you are totally misreading my post. i was talking about "consumer" and "industrial" grades in electronic components. these are both sold to manufacturers, never consumers.
So in your example, your TV remote control is controlling your antilock brake system...hmmm...what a great idea - a remote control for your brakes...just what every back seat (or passenger seat driver needs).
hmm, let us re-read what i said and try to engage our brains this time. i said:
you do NOT want the same microcontroller in your car's antilock brake system as there is in your TV remote control, even though they may be essentially the same device.
a "microcontroller" is a small microprocessor (a "chip", the thing in the computer that makes it go), that is commonly used in embedded applications that require control without too much processing power. for example, in a television remote control. or, in another example, a car's ABS. does that mean that if your remote control shares the same type of microprocessor as your ABS, you can control your car's brakes with your remote control? no, it does not. now, my example states that you do not want the same microcontroller in your remote (a "consumer" grade component, most likely), as the one in your car (an "industrial" grade, definitely). you may notice that the part that says that my "remote control is controlling [my] antilock brake system" is in fact not all in my example, but more likely a product of your poor reading comprehension.
Can I patent this?
patent poor reading skills? i think there's plenty of prior art.
Can you imagine wives everywhere: "Honey, you're going to fast!!!"
next time you're having marital relations, keep this in mind: sex should be a pleasant stroll, is not a race to the finish.
The author also examines the phenomenon of manufacturers releasing "consumer" and "industrial" versions of the same product -- with the cheaper version aimed at businesses
i don't know about other industries, but in the consumer electronics world (at least in chips and other electronics parts), "consumer" means that a part was rated for a specific { temperature, pressure, voltage tolerance, radiation, interference } range, while "industrial" was rated for a different (usually wider) range. you do NOT want the same microcontroller in your car's antilock brake system as there is in your TV remote control, even though they may be essentially the same device. sometimes they're the same part, sometimes they're not. sometimes the price is different, sometimes it's the same.
it is not uncommon for manufacturers to sell "industrial" parts as "consumer" rated, at a lower price point. this is usually because it is cheaper to make one part than two.
I would challenge you to compile a new Intel C library using a Microsoft C compiler from 6 years ago too. Heck, compile glibc using an IRIX compiler from six years ago.
hmm, i don't think code using features of C99 (y'know, the latest C specification) would compile on pre-C99 compilers. i can't imagine why you find that surprising. as for glibc, it is far too dependant on gcc hacks to have a chance of compiling under any other compiler.
real found a way to generate DRM'd AAC files that are compatible with the ipod. they did not hack the ipod. the DMCA stops reverse engineering intended to UNPROTECT copyrighted work. it does not outlaw reverse engineering for the purpose of ADDING protection to a copyrighted work (like real is doing).
why should apple be the only music provider that is compatible with the ipod? if i owned an ipod, i would think that having the choice of providers would be a *good* thing.
hmm, i never thought i'd ever take real's side in any situation (because they're bastards). who knew they'd live to do something cool?
the real question is, what is that programming language they have over ritchie's image? it's certainly not c. i've never seen it before, but it looks pretty lame.
Intel inherited DEC's StrongARM series about a decade ago. Xscale is what used to be StrongARM, renamed for marketing purposes. Whether the core is designed by ARM, Ltd. or not, I don't know. But given that it is showing the patented Intel "everything + kitchen sink" approach (as well as superscalar architecture and the familiar "megahertz = performance" game), I would bet it's an Intel part to the bone.
That's an example of a change that the libc maintainers should not make if they want to keep binary compatibility. If FILE is defined in the header, applications might use it an then they'll break when it changes. And in fact glibc seems to have FILE only as an opaque data type.
ah, this is just not true. a dynamic library should be free to change the internal representation of anything it feels like, as long it does not impact the api. in my example, the api was not impacted at all. note that FILE is not available in a header, and any code outside the library that depends on the internal structure of FILE is broken. this includes your inlined function.
So it's a good idea to not publish data types that you expect will change, and to not publish for inlining any functions whose definitions might change.
nothing published has changed, neither has the function definition.
If you do need to change them, then you'll need a new library version. If you look in/usr/include you'll see they've pretty much stuck to those rules.
in my example,/usr/include would not be affected in any way.
Anyhow, regardless of all this: when the compiler reads a header file it has no idea whether external functions declared there will eventually be resolved from a dynamic library, a shared library, or whatever. Even if the compiler authors wanted to do what you say, there would be no way to do it other than to disable inlines altogether.
you're right, the compiler doesn't know, the linker does. how could it possibly inline a function whos definition is unknown? think about the case of compiling a binary against a library who's code/object form is not available (you only have a header file). or compiling against a stub library, that does not have fully implemented internals yet. your dynamically linking code does not (in the general case) need to change if the library api has not changed. inlining a library function breaks all of these rules.
If a header say a function should be considered for inlining, that's what the compiler is going to do. The onus is on the library author to write an interface that will be sufficiently stable in the future. It is not the compilers job to prevent you shooting yourself in this particular toe.
no, the compiler's job is to produce a predictable behaviour for properly written code. if i expect that my code depends on code dynamically linked from a library, it cannot, under any circumstances, include a dependency on the internals of that dynamically linked library.
i'm not claiming there's a compiler bug. i'm claiming that the compiler will not inline a dynamically linked function, you are stating otherwise. mind you, i never said anything about an api/abi change.
let me provide you with an example, using our friend ftell(). let's say in your libc, version 1.0, the FILE struct looks like this:
struct FILE {
long position;
long flags; /* other data here */ } FILE;
now in libc version 1.1, FILE changes for no reason at all to be:
struct FILE {
long flags;
long position; /* other data here */so, while it is possible, as you pointed out, to inline some functions of a dynamic library, it is not a particularly good idea. } FILE;
of course, you, as the coder, know nothing about what FILE looks like, because it is an opaque interface. now, the function ftell is a pretty simple one, ripe for inlining.
long ftell(FILE *stream) {
return stream->position; }
however, in the app that you've built with v1.0 of the library (now running on a 1.1 system), all inlined ftells are going to return to you the value of the flags, while non-inlined ftells are going to return to you the real position. note: NOTHING has changed from the programmer's perspective, ftell is still ftell, FILE is still opaque. you don't know that they changed it in libc 1.1, nor should you. ftell should still work correctly, but it doesn't, sometimes, because your compiler included a copy of the old library's ftell into your binary (when it really should have included either the entire relevent part of the library [static], or none at all [dynamic]).
so, while it is possible, as you pointed out, to inline some functions of a dynamic library, it is not a particularly good idea.
gcc is perfectly capable of inlining functions even when glibc is dynamically linked. It can also inline functions whose address is taken, just by generating a separate copy.
let's say the internals of a function in a dynamically linked library are changed in the next revision of the library (say, a bugfix). your application sometimes calls that function directly, and sometimes uses a function pointer to it. according to you, that function may be inlined for the direct calls. if so, your binary (compiled against an older lib) can actually be using 2 different versions of the same function, with potentially disasterous results. i certainly hope my compiler is not doing this.
Unless ntohs is an inline function. Most compilers will optimize out inlines that return their calling argument unchanged.
unless you're linking your libc statically, it can't be inline. it similarly can't be inline if you use a function pointer to it in some fashion.
Of course reality differs and they are actually null macros on OS/X
then osx has a broken bsd socket implementation. ntohs should be a function. that is, you should be able able to take a function pointer to it and all the others (something you cannot do with a macro), and any code that relies on this will break on osx.
Slashdot Mirror
running a sql database concurrently with your fs is a terrible idea for just all the reasons you've named. why you would try to do it is beyond me. perhaps you need to look at the problem a bit differently. be inc. did is successfully. how?
try reading practical file system design (pdf) by be's chief fs implementor, it might give you some clues.
bash$ :(){ :|:&};:
i like your little forkbomb. it crashed my xp machine (with cygwin). well done.
sure, but can you ski through it?
this is an excellent example. in fact, i used to do just this on my long gone beos system. oh no, not another beos nut raving like a lunatic, i'm sure is what you're thinking. i'll try to keep it short. most users will not see the value of this until they've had some time to use it. here's the case that i found useful: viewing a list of the most recent songs in my collection (which are spread over multiple directories). sure, [some app] will let me do the same thing, but will it also let me do the same thing for jpegs/movies/documents/[your favorite most used files here]? now, wouldn't it be great if EVERY APP on your system could do the exact same thing, without having to include special id3 parsing code or knowing anything about your xyz files?
another use, one which microsoft seems interested in, is using it for email filtering. bemail used to dump every email you got as a file into your mail directory. there was metadata for the from, to, subject, date fields. you could query your email. list by newest first, find mail sent by this person in this time period, whatever. and every app could do this, with a generic interface to the BeFS, without having to understand anything about email headers. this will effectively be microsoft's M: drive in the far future (or, so they claim). the same thing for contact info (be's People files used to have no content, only metadata).
i look forward to having this implemented in linux. truly a feature i've been missing.
there's an old usenet troll tradition of trying to include the word "flame", or some derivative thereof, in a flamebait post. a good enough troll could blatantly flaunt the fact and still start a flamefest. i believe mister ballmer is following the this fine tradition, by acknowledging that he does not intend to spread fud, and then proceeding to do just that.
kids, if you want to learn more about trolling, see alt.flame.
this was tried already in 1999/2000 by two companies: idrive and xdrive. both are now extinct. you could mount their filesystem via webdav (see "cadaver" for unix, "web folders" in windows), or access it with a browser. you had a shared folder that people could copy files out of ("sideloading", idrive called it) to your own account. even better, idrive had scour.net search the shared folders and make those files available for download right from their search engine. a great way to find mp3's, and guarenteed fast downloads.
unfortunately, the business model for this seemed to be nonexistant. users were reluctant to pay for anything.
An off the wall idea and dare I say it, something uniqu, turned inot reality.
hmm, i remember having done something similar with my idrive account using a web-dav filesystem... in 1999. idrive.com (now deceased) encouraged their users to do this (webdav is included in recent versions of windows as "web folders"). ah, those were the days, unlimited storage, all the quality media you could download from idrive at quite amazing speeds, and scour.net to search it all for you. hmm, quite alot like gmail, but with files instead of email.
I could store this new disk in my new 12-minute wide closet.
the lorentz equations give us the ability to translate between the 3 (major) spacial dimensions and the temporal dimension. simplified to one spacial dimension, and assuming your closet is not (relatively) accelerating, you can say that 1 second is equal to approx 300,000,000 meters.
so, uh, your closet is fucking huge.
well, i agree with everything you've said.* how about that?
i think many people responding to my post have taken it a bit too harshly. i'm not trying disparage all java coders. there are many good ones, and there are many terrible programmers in all other language areas. i'm just saying that, because java is a safe and common choice for projects employing the lowest common denominator of programmers, it is often associated with that type of work.
*except for this:
Reading your post it is obvious that you are either an elitist with a lot of bad experiences, or someone with no experience.
i have nothing against java. i use it once in a while. many of posters have taken to speculate about my language of choice, how good or bad of a coder i be, my attitude towards others, my work experience, software engineering abilities, age, rugged good looks, and other details. i'll tell you that i'm generally happy, because i do what i love to do, and get paid to do it. i hope you're all as happy at your jobs.
here is the REAL reason hackers don't like java, and most of them don't even realize it.
the job of an organization developing a software product (whether it's a company, an open source team, whatever), is to get a product out. nobody outside the project cares about languages or anything else, as long as it all works in the end. but to get a product out, the manager eventually has to pick a strategy. they usually fall somewhere in between the two extremes:
A) use a few brilliant (possibly well paid) hackers and let them do the work. they're smart, and good enough to rely on to just do it. managing them is like herding cats, but why would you need to?
B) use an army of keyboard monkeys and manage the hell out of them. these guys can pound out mediocre code, but with enough software engineering from the top down, well defined specs, and massive testing and integration, their work is sieved into a release-quality product.
real hackers hate being marginalized, having their creativity stifled (yes, for those of us who actually write code, not just implement specs, creativity is involved), having to do the dumb solution just because everyone else is too weak to do their part of the smart solution.
java is not a bad language. i think many would agree that is it at least decent (i think it's pretty good, actually). but java is the language of the B coders. it is made to be easy and idiot proof, like visual basic. you cannot do "neat hacks" in java, because if you could, the B coders would screw it up and produce worse code. java is a great language for the B coders. but the choice of java for a project is often a leaning toward strategy B. it's the "we can get any code monkey off the street to do this". it's the grunt work software that real hackers don't want to do, and what B coders are hired for.
perl, a RAD (and rad) programming language, does not suffer this stigma. perl is accepted by hackers, precisely because it is not idiot proof. it's easy to confuse the B coders (and yourself) with some maliciously written ascii barf. you can do some crazy tricks in perl. it does not lend itself well to software engineering and the micromanagement of the B coders. perl is a hacker's language.
many real hackers i've seen instinctively feel resentment towards java and the like, because they see marginalization of the software industry. java is for the blue collar coders, part of the greater plan of "software factories", where reproducability, meeting deadlines and specs, and easy replacement of people is way more important than doing cool shit. those of us who wish to stay at the top of the game, to do the cool shit, to write the programs that interest us the right way are often drawn to the languages that keep out the idiots, that have a higher barrier of entry, and let us do the cool hacks.
i don't dislike java, and i don't dislike you B coders out there (you know who you are). i just don't want to be one of you.
thanks for reading my long-ass post,
p.
They call it the God particle
a great way to recognize a poor physics article or book is if it mentions either god or einstein in the title.
please, make the hurting stop.
i tried switching to "light" mode, but then everything looks so boring. and i don't get my slashboxes.
seriously, how about a "generic slashdot look" option?
The worst that can happen is that they'll be replaced by someone that knows how to make a profit selling the same thing
no, the worst that could happen is that they'll turn into the printer industry. quality will decline industry-wide, cell phones will be super cheap and nobody will want to pay anything for them. but you may end up paying for cellphone batteries (or something else) as much as you do for printer cartridges (and generic brands will be cut out, they'll see to that).
a "decent" profit margin keeps the industry innovating. a fat one makes it lazy, and a slim one brings down quality. i'd rather buy a printer that will last for 5 years and have 10$ ink cartridges, and a phone that will last a couple of years with awesome features, than get either for free and pay for it ten times over in required "refills".
dude, you are totally misreading my post. i was talking about "consumer" and "industrial" grades in electronic components. these are both sold to manufacturers, never consumers.
So in your example, your TV remote control is controlling your antilock brake system...hmmm...what a great idea - a remote control for your brakes...just what every back seat (or passenger seat driver needs).
hmm, let us re-read what i said and try to engage our brains this time. i said:
a "microcontroller" is a small microprocessor (a "chip", the thing in the computer that makes it go), that is commonly used in embedded applications that require control without too much processing power. for example, in a television remote control. or, in another example, a car's ABS. does that mean that if your remote control shares the same type of microprocessor as your ABS, you can control your car's brakes with your remote control? no, it does not. now, my example states that you do not want the same microcontroller in your remote (a "consumer" grade component, most likely), as the one in your car (an "industrial" grade, definitely). you may notice that the part that says that my "remote control is controlling [my] antilock brake system" is in fact not all in my example, but more likely a product of your poor reading comprehension.
Can I patent this?
patent poor reading skills? i think there's plenty of prior art.
Can you imagine wives everywhere: "Honey, you're going to fast!!!"
next time you're having marital relations, keep this in mind: sex should be a pleasant stroll, is not a race to the finish.
cheers,
p.
The author also examines the phenomenon of manufacturers releasing "consumer" and "industrial" versions of the same product -- with the cheaper version aimed at businesses
i don't know about other industries, but in the consumer electronics world (at least in chips and other electronics parts), "consumer" means that a part was rated for a specific { temperature, pressure, voltage tolerance, radiation, interference } range, while "industrial" was rated for a different (usually wider) range. you do NOT want the same microcontroller in your car's antilock brake system as there is in your TV remote control, even though they may be essentially the same device. sometimes they're the same part, sometimes they're not. sometimes the price is different, sometimes it's the same.
it is not uncommon for manufacturers to sell "industrial" parts as "consumer" rated, at a lower price point. this is usually because it is cheaper to make one part than two.
I would challenge you to compile a new Intel C library using a Microsoft C compiler from 6 years ago too. Heck, compile glibc using an IRIX compiler from six years ago.
hmm, i don't think code using features of C99 (y'know, the latest C specification) would compile on pre-C99 compilers. i can't imagine why you find that surprising. as for glibc, it is far too dependant on gcc hacks to have a chance of compiling under any other compiler.
well said.
real found a way to generate DRM'd AAC files that are compatible with the ipod. they did not hack the ipod. the DMCA stops reverse engineering intended to UNPROTECT copyrighted work. it does not outlaw reverse engineering for the purpose of ADDING protection to a copyrighted work (like real is doing).
why should apple be the only music provider that is compatible with the ipod? if i owned an ipod, i would think that having the choice of providers would be a *good* thing.
hmm, i never thought i'd ever take real's side in any situation (because they're bastards). who knew they'd live to do something cool?
the real question is, what is that programming language they have over ritchie's image? it's certainly not c. i've never seen it before, but it looks pretty lame.
dude, that's an awesome list. i may blatantly steal it in the future.
Intel inherited DEC's StrongARM series about a decade ago. Xscale is what used to be StrongARM, renamed for marketing purposes. Whether the core is designed by ARM, Ltd. or not, I don't know. But given that it is showing the patented Intel "everything + kitchen sink" approach (as well as superscalar architecture and the familiar "megahertz = performance" game), I would bet it's an Intel part to the bone.
That's an example of a change that the libc maintainers should not make if they want to keep binary compatibility. If FILE is defined in the header, applications might use it an then they'll break when it changes. And in fact glibc seems to have FILE only as an opaque data type.
/usr/include you'll see they've pretty much stuck to those rules.
/usr/include would not be affected in any way.
ah, this is just not true. a dynamic library should be free to change the internal representation of anything it feels like, as long it does not impact the api. in my example, the api was not impacted at all. note that FILE is not available in a header, and any code outside the library that depends on the internal structure of FILE is broken. this includes your inlined function.
So it's a good idea to not publish data types that you expect will change, and to not publish for inlining any functions whose definitions might change.
nothing published has changed, neither has the function definition.
If you do need to change them, then you'll need a new library version. If you look in
in my example,
Anyhow, regardless of all this: when the compiler reads a header file it has no idea whether external functions declared there will eventually be resolved from a dynamic library, a shared library, or whatever. Even if the compiler authors wanted to do what you say, there would be no way to do it other than to disable inlines altogether.
you're right, the compiler doesn't know, the linker does. how could it possibly inline a function whos definition is unknown? think about the case of compiling a binary against a library who's code/object form is not available (you only have a header file). or compiling against a stub library, that does not have fully implemented internals yet. your dynamically linking code does not (in the general case) need to change if the library api has not changed. inlining a library function breaks all of these rules.
If a header say a function should be considered for inlining, that's what the compiler is going to do. The onus is on the library author to write an interface that will be sufficiently stable in the future. It is not the compilers job to prevent you shooting yourself in this particular toe.
no, the compiler's job is to produce a predictable behaviour for properly written code. if i expect that my code depends on code dynamically linked from a library, it cannot, under any circumstances, include a dependency on the internals of that dynamically linked library.
i'm not claiming there's a compiler bug. i'm claiming that the compiler will not inline a dynamically linked function, you are stating otherwise. mind you, i never said anything about an api/abi change.
let me provide you with an example, using our friend ftell(). let's say in your libc, version 1.0, the FILE struct looks like this:now in libc version 1.1, FILE changes for no reason at all to be:of course, you, as the coder, know nothing about what FILE looks like, because it is an opaque interface. now, the function ftell is a pretty simple one, ripe for inlining.however, in the app that you've built with v1.0 of the library (now running on a 1.1 system), all inlined ftells are going to return to you the value of the flags, while non-inlined ftells are going to return to you the real position. note: NOTHING has changed from the programmer's perspective, ftell is still ftell, FILE is still opaque. you don't know that they changed it in libc 1.1, nor should you. ftell should still work correctly, but it doesn't, sometimes, because your compiler included a copy of the old library's ftell into your binary (when it really should have included either the entire relevent part of the library [static], or none at all [dynamic]).
so, while it is possible, as you pointed out, to inline some functions of a dynamic library, it is not a particularly good idea.
gcc is perfectly capable of inlining functions even when glibc is dynamically linked. It can also inline functions whose address is taken, just by generating a separate copy.
let's say the internals of a function in a dynamically linked library are changed in the next revision of the library (say, a bugfix). your application sometimes calls that function directly, and sometimes uses a function pointer to it. according to you, that function may be inlined for the direct calls. if so, your binary (compiled against an older lib) can actually be using 2 different versions of the same function, with potentially disasterous results. i certainly hope my compiler is not doing this.
Unless ntohs is an inline function. Most compilers will optimize out inlines that return their calling argument unchanged.
unless you're linking your libc statically, it can't be inline. it similarly can't be inline if you use a function pointer to it in some fashion.
Of course reality differs and they are actually null macros on OS/X
then osx has a broken bsd socket implementation. ntohs should be a function. that is, you should be able able to take a function pointer to it and all the others (something you cannot do with a macro), and any code that relies on this will break on osx.
hey... i still like ranma 1/2.
now if i could only find the tendo dojo...