This is the mail archive of the egcs@egcs.cygnus.com mailing list for the EGCS project. See the EGCS home page for more information.
On 9 Feb 1999, Nick Burrett wrote: > > You could always just fix your code. "change", not "fix". The code is correct, and has been correct for a long time. Yes, I could. But where the hell does it all end? Do I every other month have to make changes to the kernel because the compiler keeps changing normal interfaces? What is to say that some "bright" person isn't going to make other changes to how inline works, and disallow some other random feature for no technical reason. If you guys even had a _technical_ reason for changing things, I'd understand. As it is, I really don't look forward to working with people who want to change compiler interfaces on a day-to-day basis. That's like me changing system call behaviour without testing whether old applications still work. "Oh, it's not really specified by POSIX, so the fact that it's been done by people that way for eight years doesn't matter, I want to change it because I feel like it". > In the case of 'skb_put' and 'skb_push' > gcc will inline the function if you remove the offending if statement. There is no "offending" statement that I see. Every single thing in the thing is standard C with regular, documented GCC extensions. > Perhaps you should find a better way to obtain the current value of the > program counter. Why not create a macro, say CURPC, that obtains the current > value of the program counter in an architecture dependent manner e.g. by > using an asm() statement ? Ehh, even better: I could make "skb_over_panic()" be a function that looks up the return address with __builtin_return_address(0), and then I wouldn't need to worry at all, right? Except for the fact that __builtin_return_address() is (a) not really documented, or at least it didn't use to be and (b) doesn't work with most gcc versions out there. Richard has fixed it in the current egcs tree, but that's pretty recent. > If you don't want to use an asm() statement then create a small assembler > function to get your program counter. The overhead is insignificant considering > you are only going to emit a kernel panic anyway. The overhead of working with a compiler that doesn't change daily for no technical reason would be even less significant. Linus