Working on the OS FAQ [Mega-Tokyo Wiki]

[bubach]

How come that the FAQ don?t have anything about setting pmode/gdt etc?
IMHO: Linking to bona fide osdev is a good thing, but shouldn?t the FAQ have atleast some basic info on this?
[hr]
(Note by Solar: The resulting discussion was extracted to a thread of its own: Bootloaders and the scope of the FAQ.)

[Schol-R-LEA]

It's because basic C doesn't know inline, but GCC knows __inline__.

I was under the impression that C99 introduced an [tt]inline[/tt] modifier into vanilla C, but that the semantics were different from those of both C++ and GNU C. Certainly that is what the following sites assert.

http://www.greenend.org.uk/rjk/2003/03/inline.html
http://gcc.gnu.org/onlinedocs/gcc/Inline.html
http://www.comeaucomputing.com/techtalk/c99/#inline
http://c.ittoolbox.com/documents/document.asp?i=2619
http://www.kuro5hin.org/story/2001/2/23/194544/139

Are these incorrect, then? I do understand that some C99 changes aren't widely supported, but that's different from saying that it's not part of the language standard. Surely one can reasonably expect support for a standard that is now five years old, though admittedly there are quite a few older compilers around. Seeing that other C99 specific issues have come up (i.e., gcc's implementation of <stdint.h>), I would think that it would be reasonable to assume C99 support from new compilers at this point.

[Solar]

It's because basic C doesn't know inline, but GCC knows __inline__.

I was under the impression that C99 introduced an [tt]inline[/tt] modifier into vanilla C...

Sorry, incorrect wording. With "basic C" I was referring to C89. C99, while definitely a significant improvement, is still somewhat "exotic" to most people.

[bubach]

All C compilers i ever owned, had inline way before 1999.

[Solar]

Doesn't change the fact that "inline" wasn't a part of C prior to C99, and if you tell GCC to go -pedantic it will stubbornly refuse to compile "inline" unless you tell it -std=c99.

You have to distinguish between what a given compiler can do and what the language is defined to do. What your 1995 compiler of choice did when you said "inline" might be very different from what C99 defines "inline" to. So we better say __inline__ and make it clear we mean the GCC "inline", not the C99 one.

[bubach]

OT: are they any other free (and good) C compilers out there, that dosn?t have the ugly syntax of GCC ?

[Solar]

OT: are they any other free (and good) C compilers out there, that dosn?t have the ugly syntax of GCC ?

Depends on what "ugly syntax" you mean. I don't assume you mean the uglyness of C/C++ itself, or the command line syntax, though. (The latter is pretty much the same for all compilers I know.)

If you refer to the GCC extensions like __inline__ or __asm__, either those other compilers don't have similar extensions, or they are comparably ugly.

[bubach]

i guess it?s the inline that makes it so ugly (or maybe the os-devers that can?t make their code look good), becasue all snippets in gcc style that i have seen looks horrible.

[df]

was doing some admin work on the faq this morning...

is there an easy way to remove the current revision of a page and revert back to the previous edit of the page?

someone dumped looooads of spam into pypeclikers page and the only way I could fix it was to view an older version and copy it to the new version... when all I wanted to do was 'revert to previous version'. delete page would have deleted the entire thing right??

[Solar]

You don't have to copy. When you navigate to an older version of the page, you can edit / save the older version - overwriting the newer one.

Easier than copy&paste.

[DennisCGc]

Hi, just to let you guys know:

When I'm going to the OS FAQ's page (http://www.osdev.org/osfaq2/) I'm getting this error/warning:

Code: Select all

lib/Request.php:299: Warning[2]: ob_start(): output handler 'ob_gzhandler' cannot be used after 'URL-Rewriter'

Bug in the WIKI or somebody edited the php file ?

[df]

i started seeing this the other day and it confuses me. nothing has changed on the server that I am aware of. certainly I didnt do anything...

its very weird.... ill ssh in tomorow and look things over.

[Solar]

Just wild guessing (as I don't know a thing about the server you're running this on), but maybe the provider enabled some stuff in the Apache that wasn't there before - like compression?

[df]

hmm this is a provider that wouldnt upgradew my php4.0.6 to 4.1 or anything. its an ooold box with linux 2.0.something on it.

holyshit. apparently they just upgraded us to 4.3.9... aah a host of new opportunities... i can finally look to upgrading the damn board software...

[df]

I looked the error up...

Since it only happened on the upgrade of php... and lo! in the phpwiki...

apparently its a mozilla bug! I am looking to upgrade from 1.3.4 to 1.3.10 anyway... (but i dont think its fixed in 1.3.10 but we will see.....)

Code: Select all

Warning[2: ob_start(): output handler 'ob_gzhandler' cannot be used after 'URL-Rewriter']

I get the same error message as the one listed below only mine appears at the top of the page and is slightly different.

lib/Request.php:299: Warning2?: ob_start(): output handler 'ob_gzhandler' cannot be used after 'URL-Rewriter'

I don't get the error on IE browsers, but I get it using Mozilla Firebird. I've taken a look at the FixedBugs and the FAQ. I've also enabled compression to be false in index.php The weird thing is, if I click the "php wiki" image in the upper-right corner, the error message goes away. However, it comes back if I close the browser, or leave the wiki, view another website and come back to it. Is there anything else I might be missing?

    Fixed in current CVS. --ru