ANSI compliance, gcc(1) and FreeBSD
Apologies if this is the wrong list for this question but it seems the
best place to get a *definitive* answer.
In the ANSI Standard (KR 2e, A7.14 A7.15) it states that, in the
case of the ``'' operator, the right operand is evaluated only if
the left operand evaluates to non-zero, and, for ``||'', the right
operand is evaluated only if the left operand evaluates to zero.
My questions are: does gcc(1) honour this, and is it permitted to rely
on this behaviour in FreeBSD (base system)?, e.g., would the following
be acceptable if we wanted to guarantee that foobar was set to BAR
*only* if FOO was unset or NULL?
char *foobar;
if ((foobar = getenv("FOO")) != NULL || (foobar = getenv("BAR")) != NULL)
I couldn't find the answer in style(9).
Please Cc: me as I'm not subscribed to -hackers.
TIA
--
If I buy a copy of WinDelete, and it doesn't delete Windows,
am I entitled to my money back?
51.44°N FreeBSD - The Power To Serve http://www.freebsd.org
2.057°W My Webpage http://ukug.uk.freebsd.org/~mark
mailto:[EMAIL PROTECTED]http://www.radan.com
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
Re: ANSI compliance, gcc(1) and FreeBSD
On Sat, Jul 29, 2000 at 11:51:53AM +0100, Mark Ovens wrote: In the ANSI Standard (KR 2e, A7.14 A7.15) it states that, in the case of the ``'' operator, the right operand is evaluated only if the left operand evaluates to non-zero, and, for ``||'', the right operand is evaluated only if the left operand evaluates to zero. My questions are: does gcc(1) honour this, and is it permitted to rely on this behaviour in FreeBSD (base system)? Lots of C code would break if this wasn't honoured. Gcc deals with it just fine. David. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Linux NVIDIA drivers vs. default XFree86 drivers (WAS: RE: Video card support)
Moving to hackers@, where most discussions regarding the NVIDIA drivers seem to take place lately. Chris BeHanna wrote: I don't remember if it was this list on which I saw this discussion, or if it was hackers. Anyway, I looked at xfree86.org today, and noticed that there is accelerated support for ATI Mach64 and for NVIDIA TNT2 and GeForce256 boards, as well as many others. Is there some reason why this isn't "good enough," or do we really need actual drivers for these boards to get at their extra-nifty features (e.g., hardware backface culling, fog, bump maps, etc.)? The NVIDIA drivers for XFree86 are the result of a collaborative effort between NVIDIA, SGI and VA Linux. Concentration, as far as I know, has been focused on OpenGL development in the new DRI environment XFree86 4.0 provides. You could speculate that with fairly high calibre companies partaking in such an effort - where there's obviously a fair amount of financial investment - their drivers are going to perform better than those provided with XFree86. For those interested, it is the code of the accelerated OpenGL driver/libraries that NVIDIA are distributing as Linux binaries (i.e. closed-source). The only source that *is* provided is for the cards' kernel device driver. I remember reading somewhere on NVIDIA's site that the only reason they're providing *this* code is because Linux's kernel module loading mechanism prevents the introduction of foreign pre-compiled binary objects as system device drivers. So, effectively, a kernel device driver has to be compiled on the system natively before it can be used (?). It was something along those lines, anyway. Someone should tell NVIDIA there's a lot more to "Open Source" than just writing closed-source drivers for Linux. On a more technical note, given an accurate port of the kernel device driver (which would be trivial at best), is there any reason these Linux OpenGL drivers associated libraries can't just be branded as 'Linux' object types and handled as-per-normal by linux.ko? After all, it's the kernel driver's responsibility to manage all the Operating System's specific hardware resource management etc. I'm doubting it's that easy, though. Chris BeHanna Software Engineer (at yourfit.com) Regards, Trent. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Linux NVIDIA drivers vs. default XFree86 drivers (WAS: RE: Videocard support)
On Sat, Jul 29, 2000 at 11:59:17PM +0800, Trent Nelson wrote: On a more technical note, given an accurate port of the kernel device driver (which would be trivial at best), is there any reason these Linux OpenGL drivers associated libraries can't just be branded as 'Linux' object types and handled as-per-normal by linux.ko? After all, it's the kernel driver's responsibility to manage all the Operating System's specific hardware resource management etc. I thought the whole point of XFree4 new driver mechanism was that it was OS-neutral. It should be possible to run the same binary driver on all x86 platforms running XFree4 *without* recompiling. I don't know how this driver interacts with the kernel module, though. I'm not sure I even understand why a kernel module is needed in this case. -- Nimrod. http://www.geocities.com/rodd_27 To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Linux NVIDIA drivers vs. default XFree86 drivers (WAS: RE: Video card support)
On Sat, 29 Jul 2000, Nimrod Mesika wrote: I thought the whole point of XFree4 new driver mechanism was that it was OS-neutral. It should be possible to run the same binary driver on all x86 platforms running XFree4 *without* recompiling. I don't know how this driver interacts with the kernel module, though. I'm not sure I even understand why a kernel module is needed in this case. i believe it requires hooks into the kernel to make use of AGP, which is necessary for high performance 3d rendering. -garrett x--x | [EMAIL PROTECTED]garrett rooney | | http://www.rpi.edu/~rooneg unix geek | |--| | unrequited love is neat because it lasts so much longer - w. t. c. | x--x To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Linux NVIDIA drivers vs. default XFree86 drivers (WAS: RE: Video card support)
Garrett Rooney wrote: On Sat, 29 Jul 2000, Nimrod Mesika wrote: I thought the whole point of XFree4 new driver mechanism was that it was OS-neutral. It should be possible to run the same binary driver on all x86 platforms running XFree4 *without* recompiling. I don't know how this driver interacts with the kernel module, though. I'm not sure I even understand why a kernel module is needed in this case. i believe it requires hooks into the kernel to make use of AGP, which is necessary for high performance 3d rendering. More to the point, they want to use their high performance proprietary internal cross platform driver that they also use on Windows etc. They provide the OS interface glue to enable interfacing with the kernel. The driver then completely takes over the card management in kernel context - busmaster DMA, command fifo managenent, card memory management, the lot. A userland XFree driver cannot use DMA as it cannot know what the virtual- physical address mappings are. Cheers, -Peter -- Peter Wemm - [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED] "All of this is for nothing if we don't go to the stars" - JMS/B5 To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: ANSI compliance, gcc(1) and FreeBSD
Apologies if this is the wrong list for this question but it seems the
best place to get a *definitive* answer.
The best place to get a definitive answer about C is in the
Standard. The best place to get a definitive answer about gcc
is in the source.
In the ANSI Standard (KR 2e, A7.14 A7.15)
As a point of fact, KR-2, while largely correct, is not itself
the Standard.
it states that, in the
case of the ``'' operator, the right operand is evaluated only if
the left operand evaluates to non-zero, and, for ``||'', the right
operand is evaluated only if the left operand evaluates to zero.
This has been mandated ever since the days of the original
language definition (KR-1, 1978) and is absolutely required of
anything that purports to be a C compiler -- and yes, gcc is
conformant in this respect.
would the following
be acceptable if we wanted to guarantee that foobar was set to BAR
*only* if FOO was unset or NULL?
if ((foobar = getenv("FOO")) != NULL || (foobar = getenv("BAR")) != NULL)
The second getenv() will only be called if the first one returns
NULL. Of course, if the second getenv() also returns NULL, then
foobar will be set to NULL and the statement part of the "if"
will not be executed.
--
Greg Black -- [EMAIL PROTECTED]
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
Re: Linux NVIDIA drivers vs. default XFree86 drivers (WAS: RE: Videocard support)
actually you're not even getting kernel driver source for linux. What you're getting is an ugly binary blob that looks like the guts of an NT driver, plus enough source stuff to let the kernel hook to the binary blob. It's not pretty. And, as you might expect, it's a little prone to failure. ron To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Linux NVIDIA drivers vs. default XFree86 drivers (WAS: RE: Video card support)
Peter Wemm wrote: They provide the OS interface glue to enable interfacing with the kernel. The driver then completely takes over the card management in kernel context - busmaster DMA, command fifo managenent, card memory management, the lot. So, given a working FreeBSD-specific kernel device driver - can the Linux OpenGL driver/libraries provided be handled via linux.ko? Cheers, -Peter Regards, Trent. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Can ordinary users run libvgl applications?
Can ordinary users run libvgl applications? If so, how? To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
