Re: Unfortunate dynamic linking for everything
So far, I haven't seen anyone in this thread seriously argue against either of these points. I'll seriously argue against the 2nd point above. I don't know of a SINGLE person that uses /bin/sh as their interactive shell when multi-user. Not ONE. Every Bourne shell'ish user I've ever met uses Bash, ATT ksh, pdksh, zsh. I'm one... I have to operate on many disparate systems with the same home directory some of the bourne-shell variants (e.g. HP/UX's ksh) will lock-up on my simple bourne-shell .profile. So - I stick with the plain/old/boring sh. - Dave R. - -- [EMAIL PROTECTED]Work: (919) 676-0847 Get your mainframe programming tools at http://www.dignus.com ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Final fix for correlation problem (was Re: rand() is broken)
I'm afraid I don't understand the fix... and how it seems to affect the historical behaviour of srand()/rand(). How does it address the understanding that if I use srand(28), I will get exactly the same sequence of numbers srand(28) produced yesterday, last week, last year? I have worked with programs that depend on exactly that behavior. That is, given the same input seed - I expect to see the same random sequence again. This requirement would seem to indicate that changing srand()/rand() isn't really possible... And, also, I believe, why random() was introduced... Please, oh please, don't change that behavior in srand()/rand(). - Dave Rivers - -- [EMAIL PROTECTED]Work: (919) 676-0847 Get your mainframe programming tools at http://www.dignus.com To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: I've just had a massive file system crash
Greg Lehey [EMAIL PROTECTED] wrote: It has three file systems, one of which came up dirty. fsck -y reported thousands of errors, and when it was finished, my home directory and some other files were gone, and all the subdirectories of my home directory were in lost+found, a total of 1.4 GB. Most of the errors appear to be duplicate Inode numbers. Don't be too hasty to blame UFS. Everytime this has happened to me (even on Linux) it has been because the disk drive was failing. It has happened to me *many* times with IDE drives. I wind up replacing about 1/4 of them every year, on average. But, I did go through a run of those bad IBM drives :-) Did you happen to drop the laptop? :-) - Dave Rivers - -- [EMAIL PROTECTED]Work: (919) 676-0847 Get your mainframe programming tools at http://www.dignus.com To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: gcc 3.2.1 optimization bug ?
For the source code below, compiling gcc -O2/-O3 seem to produce
incorrect code.
---
#include stdio.h
int main(int argc, char* argv[])
{
unsigned int x = 0x12345678;
unsigned short tmp;
printf(%x\n, x);
tmp = ((unsigned short *)x)[0];
((unsigned short *)x)[0] = ((unsigned short *)x)[1];
((unsigned short *)x)[1] = tmp;
printf(%x\n, x);
return 0;
}
---
Several people have pointed out that using volatile will
help with your code.
But - even with the use of volatile - your code is invalid ANSI
C.
You are doing something called type punning - which is illegal.
Basically, you can't reference a datum via a different type
and expect it to do anything meaningful.
When you take x, you have and (unsigned int *) type. When you
then cast that to an (unsigned short *) and then dereference it,
you are referencing the datum 'x' via a different type.
(consider, for example, a situation where `unsigned short' had
the same alignment requirements as `unsigned int', your example
would not address what you were thinking...)
The C99 standard relaxed this rule somewhat, allowing (char *)
pointers to be used to reference any datum. So, you could
use memcpy() to accomplish what you're looking for, as in:
unsigned short array[2];
memcpy(array, x, sizeof(array));
but - while valid, that also suffers from several issues...
Your code appears to simply want to swap the two (assumed) words in
an integer. That could be accomplished with shifts, etc...
This code makes all kinds of assumptions about the size of
`int' and `short' - but represents an alternative approach:
unsigned int t;
unsigned int x;
t = (x 0x) 16;
x = 16;
x |= t;
Assuming `int' was 32-bits wide - this, or something similar,
might be a more portable approach.
- Dave Rivers -
--
[EMAIL PROTECTED]Work: (919) 676-0847
Get your mainframe programming tools at http://www.dignus.com
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message
Re: gcc 3.2.1 optimization bug ?
Harti Brandt [EMAIL PROTECTED] wrote:
Well, I just had a long discussion with a collegue about the topic. The
main problem is in the ISO-C standard, section 6.7 point 4 which states:
All declarations in the same scope that refer to the same object or
function shall specify compatible types.
This makes any fiddeling with a pointer of a type, that is different from
the type of the variable illegal. It also makes fiddeling with unions and
structs illegal. As far as I understand types are compatible when they
have the same type and type qualifiers. Structs are partly compatible when
they start with fields of the same type. So the only way to legally swap
integer values of any size is via arithmetic. Of course unions and
pointers may work with the given compiler version and optimisation level.
But, nothing in the standard guarantees you anything.
That's it exactly!
It may be possible that 6.5 (7) the last sentence allows you to access your
32-bit or 64-bit value character-wise (although I'm not sure).
harti
The C99 standard does seem to add an exception for access via
character pointers. The C89 standard did not have that clause.
As far as the union question - the answer is that you cannot
read from a union from a different member than it was stored
to.
For example:
char ch;
union {
int x;
char c;
} my_union;
my_union.x = 10;
ch = my_union.c;
Technically, this is illegal in ANSI C, and not guaranteed to work. Although
it will likely work in just about every reasonable environment.
(For some definition of work :-) )
- Dave Rivers -
--
[EMAIL PROTECTED]Work: (919) 676-0847
Get your mainframe programming tools at http://www.dignus.com
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message
Re: gcc 3.2.1 optimization bug ?
Harti Brandt [EMAIL PROTECTED] wrote:
Hmm, I though the following would work:
void
foo(unsigned short *s)
{
unsigned short temp;
temp = s[0];
s[0] = s[1];
s[1] = temp;
}
main()
{
int i = 0x12345678;
foo(i);
printf(%08x\n, i);
}
because how would the compiler in main() know, that you do something wrong
in foo(). But... if you compile this with -O5, it does not work! This is
because the compiler inlines foo() into main and the program prints junk like
0x12342804.
Nope - that doesn't work either. The call to foo() is not compatible
with the prototype (in fact, the Systems/C compiler issues a warning
on this:
Warning #2034: passing argument 1 from incompatible pointer type
I believe gcc would as well.
- Dave Rivers -
--
[EMAIL PROTECTED]Work: (919) 676-0847
Get your mainframe programming tools at http://www.dignus.com
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message
Re: gcc 3.2.1 optimization bug ?
Harti Brandt [EMAIL PROTECTED] wrote: Yes, of course, but one would assume it to work (I suppose there is a large amount of code that assumes it will work). Not a safe assumption at all. For example, what if the alignment requirements for `short' and `int' are different (as they frequently are.) Then, dereferencing one type via another type will likely blow-up. (This is often the case on a SPARC platform when dereferencing `int *' pointers from `char' data.) ANSI requires that a diagnostic be generated in this case, there are some compilers in the world that make this a strict error. I just tried to give a counter example to your hope, that every sane compiler would do the right thing with using a union for casting. I would also assume that every sane compiler would do the right thing for the above code. The compiler does what it can - but it doesn't mean the code will work. So - the best the compiler can do is say Hey! You've done something that might not work, but we're going to keep going anyway. IMHO, the C-standard is broken with regard to the rules for type compatibility. As far as I remember these rules came into the standard from one or two well-known PC compiler vendors that wanted to allow very aggressive optimisation to show good benchmark results. The 'restrict' keyword seems to be also an outcome of this. I believe the rules were motivated by two things. The need for optimizations as you point out. Without the type-punning rule, a decent optimizer has to assume everything is aliased at every pointer dereference, which denies many nice optimizations. The second is the reality of common hardware in the world (e.g. SPARC) where doing this is quite dangerous. - Dave Rivers - -- [EMAIL PROTECTED]Work: (919) 676-0847 Get your mainframe programming tools at http://www.dignus.com To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: aout support broken in gcc3
Terry Lambert [EMAIL PROTECTED] wrote: Bruce Evans wrote: Isn't this too old and security-holed to use? It stopped being packaged a few releases ago. 4.5R has mainly: /usr/local/lib/netscape-linux/communicator-linux-4.79.bin: ELF 32-bit LSB executable, Intel 80386, version 1 (SYSV), dynamically linked (uses shared libs), stripped and mozilla. I personally use the FreeBSD native Netscape. I'd like to as well - but I found that with version 4.5 and later (the move to XFree86 4.x) that the FreeBSD Netscape refused to run. There is a rather long discussion of what I found in the -stable archives I believe... - Dave R. - -- [EMAIL PROTECTED]Work: (919) 676-0847 Get your mainframe programming tools at http://www.dignus.com To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: PATCH: wchar_t is already defined in libstd++
David O'Brien [EMAIL PROTECTED] wrote:
On Mon, Jun 17, 2002 at 06:16:45PM -0400, Garrett Wollman wrote:
On Mon, 17 Jun 2002 18:02:17 -0400 (EDT), Thomas David Rivers
[EMAIL PROTECTED] said:
The correct approach (and, I have to admit to not
glancing at your patch) would be:
#ifndef __cplusplus
typedef _BSD_WCHAR_T_ wchar_t
#endif
Actually, the correct approach would be to avoid defining
_BSD_WCHAR_T_ when compiling C++. This way, it only needs to be done
I am much more likely to force the libstdc++ build to use our
_BSD_WCHAR_T_. Our types should be centralized and not in some hidden
vendor software that often makes wrong assumptions about us.
I accidently sent a reply to just David, so please forgive
the duplicate.
I think there is a misunderstanding here...
It's not that the vendor software has hidden the definition
of `wchar_t'. The C++ standard mandates that `wchar_t' be
a builtin type, just like `int'.
This is so function overloading can distinguish based on the
`wchar_t' type.
That is, these would be two *different* functions in a standard-
conforming implementation:
void
foo(unsigned int)
{
}
void
foo(wchar_t)
{
}
If `wchar_t' is simply a typedef provided by the headers,
then the implementation isn't C++ standard conforming.
Also note that the source above is C++ standard conforming,
you don't need to #include anything to get the definition
of `wchar_t'.
gcc v3.x finally gets this correct - and we have to adjust
the headers to no longer define a typedef for wchar_t
in this situation.
This is not a situation of gcc being wrong - it's the
opposite - gcc is getting closer to right :-)
- Dave Rivers -
--
[EMAIL PROTECTED]Work: (919) 676-0847
Get your mainframe programming tools at http://www.dignus.com
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message
Re: Sony Vaio, LinkSys EC2T 5.0-CURRENT ...
Marc G. Fournier [EMAIL PROTECTED] wrote: Morning all ... After getting nowhere with the Surecom EP-428X that I picked up, I went out today and grabbed one of the Linksys EC2T, figuring it's on the list of supported devices I found, and I think I'm s close ... First, I'm running a VAIO PCG-Z505S ... I've upgraded to 5.0-CURRENT as of May 21st, mainly due to the Surecom, but figure I'll stay there for the Linksys ... If I run 'pccardd -f /etc/defaults/pccard.conf' from the command line, it comes back that its matched the card, followed by a line that states: 'driver allocation failed for Linksys(...): Inappropriate ioctl for device' According to dmesg, I have: pcic0: Ricoh RL5C475 PCI-Cardbus Bridge irq 9 at device 10.0 on pci0 pcic0: PCI Memory allocated: 0x4400 pccard0: PC Card bus (classic) on pcic0 If I pull out the card, the machine itself hangs ... and searching on Google, it talks about pccard + shared interrupts ... and on this, the internal ethernet (fxp0) is using irq 9 and the USB controller (uhci0) is using irq 9 ... So, I'm pretty much at an impasse right now as to what to try next ... does anyone have an experiences with this combination and/or suggestions on what to try next ... ? Thanks ... I'm having similar problems with a Sony VAIO F480 and 4.5-RELEASE. (see my postings on the -stable list.) (Same Ricoh RL5C475 chip.) No suggestions at the moment... Warner Losh has the idea that some interrupt is being masked, an interrupt that probably shouldn't be. - Dave Rivers - -- [EMAIL PROTECTED]Work: (919) 676-0847 Get your mainframe programming tools at http://www.dignus.com To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: moused(8): char signed-ness problem with gcc 3.1
Terry Lambert [EMAIL PROTECTED] wrote: Thomas David Rivers wrote: Well - it's not counter-intuitive on many machines... For example, on the IBM mainframe - there is an instruction to load a character into a register - but not one that loads *and* sign-extends. So, you can get much better code if characters are unsigned by default. Sounds like time to get out the wire wrap tools... and fix the hardware, not the software. Ha! That may not be a bad idea :-) So in our C/C++ compilers for the mainframe, the default is unsigned as well. I wonder if the AIX people were looking for mainframe compatibility in this decision, or was it motivated by the PowerPC instruction set? Does anyone know what the Mac default is (since they are PowerPC based as well?) RS/6000's didn't used to use PPC processors at all; so it's probably intentional software compatability. I'm confused then - the one we have here seems to. There was a version of something very RS/6000-like that didn't, but I thought RS/6000s did... - Dave Rivers - -- [EMAIL PROTECTED]Work: (919) 676-0847 Get your mainframe programming tools at http://www.dignus.com To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: moused(8): char signed-ness problem with gcc 3.1
I observed gcc 2.95.4 and gcc 3.1 interpret (or maybe optimize) the
following code differently (CFLAGS=-O):
int main(void)
{
unsigned char i = 127;
printf(%d\n, ((char)(i 1)) / 2);
return 0;
}
gcc 2.95.4 says it's -1, whereas gcc 3.1 says it's 127. On FreeBSD
char should be signed, so I suspect it's a (optimization) bug of gcc
3.1 which should be fixed. Or we'll have to do a mass audit of the
whole src tree to check and fix the similar expressions.
Let's examine the what the right answer should be:
First - in the expression (i 1) - the unsigned char `i' will
be promoted to a signed int through the correct integral promotion
rules, then left-shifted 1 bit. The result of that is an int.
So - this becomes:
((char)(254)) / 2 ;
The expression:
(char)(254)
is then also promoted to int when it participates
in the division operation. So, the value 254 is
converted into a (signed) char, and then converted
to an int. Converting 254 to a signed character
should result in an integer value of -2.
Then, -2 / 2 becomes -1.
If characters were unsigned by default, you do
get the value 127...
So - yes - it seems gcc 3.1 does have a problem...
- Dave Rivers -
--
[EMAIL PROTECTED]Work: (919) 676-0847
Get your mainframe programming tools at http://www.dignus.com
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message
Re: moused(8): char signed-ness problem with gcc 3.1
Terry Lambert [EMAIL PROTECTED] wrote: Bill Fenner wrote: gcc 3.1 simply defaults to unsigned chars. 127 1 = 254; 254 / 2 = 127. My machine is too slow to test this expeditiously, but I'm trying adding #define DEFAULT_SIGNED_CHAR 1 into freebsd-native.h . I will bet today's lunch money that you have found it for sure. I guess we will have to go around adding signed everywhere, if it's no longer the default. Unsigned is a stupid, counter-intuitive default, and has been, ever since I first used AIX. My bet is a conspiracy by AIX folks so that Open Source software will work on AIX without them having to fix their stupid defaults. 8-) 8-). Well - it's not counter-intuitive on many machines... For example, on the IBM mainframe - there is an instruction to load a character into a register - but not one that loads *and* sign-extends. So, you can get much better code if characters are unsigned by default. So in our C/C++ compilers for the mainframe, the default is unsigned as well. I wonder if the AIX people were looking for mainframe compatibility in this decision, or was it motivated by the PowerPC instruction set? Does anyone know what the Mac default is (since they are PowerPC based as well?) - Dave Rivers - -- [EMAIL PROTECTED]Work: (919) 676-0847 Get your mainframe programming tools at http://www.dignus.com To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: HEADS UP: installworld gotchas
On Sun, 11 Feb 2001, Peter Wemm wrote:
Matt Dillon wrote:
:
: This is a major change to libc. The library maj must be bumped if you
: intend to change the sizeof(FILE), or every single third party applicatio
n
: that uses stdio will break.
:
: -Matt
Oh wait, is libc already bumped in current verses 4.2? If so then I gues
s
we don't bump libc's maj. God help anyone using current though!
-Matt
I cant help but wonder why on earth we didn't have it like this from the
start:
[...]
That compiles fine. The __stdin thing is in case somebody likes the idea
of #undef stdin or #ifdef stdin for some reason.
In fact, I can't imagine *any* reason not to do this. At least this would
insulate us from future nasties in FILE size changes, and would have
saved us in this case.
Wouldn't this change/break code like the following?
main()
{
FILE **fp;
fp = stdin;
my_func(fp);
}
That is, previously stdin would work... in this new situation,
you would get __stdin which is not the same... is it?
- Dave Rivers -
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: interesting problem
Alfred Perlstein [EMAIL PROTECTED] wrote: * Tony Johnson [EMAIL PROTECTED] [000927 18:26] wrote: OK Well Here is the issue. If I put in the 2 boot floppies I get a page fault 12 after I press Q for "quit" on the visual kernel config. If I can save a crash dump before any FS's are mounted or even before I tell FBSD where to put the crash dump, I'd really like to know this... I'd like to read a handbook page on thisb since some people think I just haven't read it. At this point in an install, if you could tell me (and the rest of the FreeBSD users) where I could get the boot floppies to save a crash dump (because I haven't even gotten this far) then I would appreciate this amd be more then happy to substantiate this by sending you a crash dump. Do you realize how much developer time you're wasting by thrashing around cluelessly on the list demanding help? Here's a clue: Forget about your damn irq problem, boot with the disks installed, then read section of the handbook about crashdumps, compile a debug kernel and figure out what the problem is. Fix it and send us a patch. Or you could simply run -stable. Alfred, Just playing `devils advocate' here. But, in some initial install situations, exactly how is the user, even the most knowledgeable one, supposed to do much of anything if the install itself doesn't work? Not too much chance of building a kernel, getting a crashdump, etc... Although it may be something we want to put off for awhile, being able to gather debugging information during a failed install would be rather nice. I'm not sure how this could happen; perhaps a crashdump to an MSDOS file system (if available)? Or, straight to a partition with some recovery program that reads the dump? Or, over a serial line? [Just tossing out ideas.] Maybe ficl can get involved and manage this? I would keep this as one of those "maybe nice to have in the ideal future" ideas - but it's something to ponder... - Dave Rivers - -- [EMAIL PROTECTED] Work: (919) 676-0847 Get your mainframe (370) `C' compiler at http://www.dignus.com To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: VMWare on -current, how fast should I expect it to be?
Julian Elischer ([EMAIL PROTECTED]) wrote: Nik Clayton wrote: Hi guys, For those of you running VMWare (2) on -current, how fast do you expect it to be? I'm running it quite successfully on a 750MHz PIII w/ 128MB RAM, and the following disk controller / disk atapci0: Intel PIIX4 ATA33 controller port 0xfc90-0xfc9f at device 7.1 on pci0 ata0: at 0x1f0 irq 14 on atapci0 ata1: at 0x170 irq 15 on atapci0 ad0: 17301MB FUJITSU MHJ2181AT [35152/16/63] at ata0-master using UDMA33 This is -current from about three weeks ago. It works, but it's a bit slow. Applications themselves run at a reasonable speed, but every now and then (can be as frequent as 10-15 seconds) use only virtual disks and see if it still happens. I found (on vmware 1) that using the raw disks was a recipe for poor performance. Since we don't have block devices any more, we are screwed in this regard. Virtual disks (files) are however buffered and so can sometimes work faster. I'm confused... I thought one of the justifications for removing the block devices was "look - Linux doesn't have any." So, if Vmware runs on Linux, and Linux doesn't have any block devices, why would Vmware need block devices? [Of course, I'm speaking in absence of knowledge - does Linux have/not have block devices?] - Dave Rivers - -- [EMAIL PROTECTED] Work: (919) 676-0847 Get your mainframe (370) `C' compiler at http://www.dignus.com To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: netscape
Hi, I have installed netscape4-navigator and I can't launch its. I've got following message: ld.so failed: Can't find shared library "libXt.so.6.0" What can I do? Piotr Wozniak You need to install the XFree86 a.out library package. It's in the packages directory from the 4.1-RELEASE.. I bet there's something there for -current as well. - Dave Rivers - -- [EMAIL PROTECTED] Work: (919) 676-0847 Get your mainframe (370) `C' compiler at http://www.dignus.com To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
AFS.
Just F.Y.I I understand that, today, IBM is announcing it will open-source AFS via the IBM Public Source license.. Some quotes I've seen: "IBM announced today the open source contribution of a high-performance file system technology and talent to strengthen collaboration in the enterprise." "The contribution of AFS Enterprise File System gives the community a remote file system with a proven track record that features high performance and scalability in rigorous computing environments. AFS is designed to protect data access by authenticating users, providing a very secure, easily manageable working environment that supports a wide variety of operating platforms, including Linux." "IBM will actively work with the open source community to extend AFS development. In September, 2000 the source code for AFS will be available through the IBM Public Source License..." Might be interesting - Dave Rivers - -- [EMAIL PROTECTED] Work: (919) 676-0847 Get your mainframe (370) `C' compiler at http://www.dignus.com To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: HEADS UP: Destabilization due to SMP development
What about doing the changes on a branch with the understanding that the branch will *replace* HEAD when it stabilises ? This sounds odd at first glance, but it means that others are forced to MFC into the smp branch - if they don't they lose. Anybody that's not confident to be able to merge into the smp branch will simply be in the same position - merge or hold off. They'd also be just as likely to break the smp work with their commits as if the smp work was done in HEAD. Isn't this the same thing as breaking the head and keeping every thing else (that is the pre-broken 5.0) on a branch... Just sorta rotating the tree a little... And, isn't this the same idea as -stable? If that's all true - I'd suggest that those who really want stability might be better served with the -stable branch for the interim. If you need a totally-brand-new-feature, then MFC that to -stable and get it there... The point of -current is to be breakable - the extent of the breaking isn't known ahead of time. -current can be broken for a long time by simply breaking several small things - say, one a day for several months. The difference here seems to be the forethought in the announcement; which I take as good planning... i.e. instead of being broken for some unknown reasons, we're simply saying that we know it's broken... If you can't live with a broken situation, then I humbly suggest staying with -stable. I suppose I can sum this up with "isn't this already handled?" - Dave Rivers - -- [EMAIL PROTECTED] Work: (919) 676-0847 Get your mainframe (370) `C' compiler at http://www.dignus.com To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: db 1.85 -- 2.x or 3.x?
Brad Knowles wrote: At 10:00 AM -0500 2000/5/2, Dan Nelson wrote: .. means that a user that wanted to use FreeBSD in a commercial application would not be able to simply sell his product; he would have to get a license from Sleepycat. I asked the Keith about this and he said it was wrong.. (to my memory). I recall he said that as it would be grandfathered into freeBSD, (because we had 1.x already) and that anyone running their software under freeBSD could do so without added licencing, because it was already present on the platform. Ah - but that's "running under FreeBSD" - what about taking the FreeBSD source and using it in a different product... Just what does "running under FreeBSD" mean, anyway? If I sell a black box and use FreeBSD as the internal OS, but don't call it FreeBSD - is it "running under FreeBSD?" What if, for example, what if a product came together that was the Linux kernel with the FreeBSD command set? Is that "running under FreeBSD?" Would you be forced to send out your complete sources in that event? This is where the license issues are... - Dave Rivers - To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: MLEN and crashes
Peter Jeremy [EMAIL PROTECTED] wrote: On 3/04, John Polstra wrote: [don't allocate big structs on kernel stack] Many years ago, I wrote a tool that analysed stack requirements by parsing the assembler output from the compiler. It determined the stack frame requirements and built a call flow graph to determine total stack depth. It had some hooks to allow indirect function calls to be specified manually. It couldn't handle alloca() (and equivalents), but they were forbidden by the design standards. Just wondering... How did you address recursive functions, or were they also forbidden by design standards? - Dave Rivers - To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Panic (ffs) #2
And here we are again.
This time on another disk:
dev = #amrd/0x20004, block = 2048, fs = /news/spool
panic: ffs_blkfree: freeing free block
Debugger("panic")
Stopped at Debugger+0x35: movb$0,in_Debugger.372
db trace
Debugger(c01e7ee3) at Debugger+0x35
panic(c01f27e0,c01f27c0,c1ccc894,800,c1d0d0d4) at panic+0x70
ffs_blkfree(c1db6d00,800,2000,0,d98cfe44) at ffs_blkfree+0x1dd
Aha! The Dave Rivers' memorial panic rears its ugly head!
This is exactly the panic's I reported years ago; but we've never
been able to track down... [Even the same block number I believe]
You may want to scan the archives to read more about my investigations;
which never went anywhere... (sigh) I describe a way to reproduce
it on some versions of FreeBSD, you might want to see if you can
get a reliable reproduction, etc...
- Dave Rivers -
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: Vmware and -current
seems to work fine, except that now we don't have block devices any more so every time it gets stuff off disk, it's REALLY SLOW. I guess a virtual machine is the "App that no-one could put their finger on" that really could do with buffered (caching) devices. Hmmm I wonder what it would take to bring them (block devices) back... probably out of the question at this point... of course this is w98. FreeBSD 1.1.5 and freebsd 3.3 seem run as well but I've only run them off virtual disks (which therefore have buffering) - Dave Rivers - To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: cc taking a signal 11
Hi,
While I'm at it, a co-worker gave this one to me earlier today.
cc: Internal compiler error: program cc1 got fatal signal 11
4.0-CURRENT FreeBSD 4.0-CURRENT #0: Mon Dec 20 01:45:25 EST 1999
FreeBSD(root)/tmp %cc -v
Using builtin specs.
gcc version 2.95.2 19991024 (release)
FreeBSD(root)/tmp %cc -O foo.c -o foo.o -c
cc: Internal compiler error: program cc1 got fatal signal 11
static void getsig11(parfree,dbl,lambda)
long parfree;
double *dbl;
double *lambda;
{
long i, j;
j = -1;
for(i = 0; i parfree; i++) {
j += i+1;
dbl[j] *= (1.0 + *lambda);
}
return;
}
Yes, the algorithm looks funny, but is correct. The program will
compile correctly if the 'j += i+1;' is changed to 'j = i+1;' or if
the variable 'lambda' is changed from a pointer to an actual value.
Anyone want to take a stab at this? I'm not a big compiler
person myself... (Dave, you there?).
Yes - I'm here :-)
Typically - signal 11 problems from GNU's front-end are hardware
memory issues
I will add that a quick test on a 3.3 system compiles this just
fine (Systems/C compiles it as well.)
I would suspect hardware problems first.
As I have learned from painful experience, *always* use ECC or at least
parity memory...
- Dave R. -
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: cc taking a signal 11
Nawww... I've tried this on a bunch of different machines.. as a matter of fact it replicates with gcc version 2.7.2.1 from December of last year. I find it hard to believe that I have 80 machines that all exhibit the exact same memory failure... :-) -John Yep - others have reported the problem is gcc... I'd suggest taking this up with Cygnus (http://www.cygnus.com) - Dave R. - To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: sysinstall: is it really at the end of its lifecycle?
Adam Strohl [EMAIL PROTECTED] wrote: On Wed, 15 Dec 1999, Daniel C. Sobral wrote: Hey, I like CUI. I'd rather install with a CUI than a GUI, all other things being equal. And besides some quirks here and there, I really like sysinstall. Its nice, but its not where it should be. But the fact is that when we get featured in a magazine article, user-friendly install == GUI. No GUI, it's not an user-friendly install. End of review. You can kick and scream all you want, that's the way it is. Either we live by these rules, or we loose. A VESA GUI based sysinstall replacement would probably be small enough to fit on a floppy, yet still have the friendlyness that a new user/reviewer would look for. If we follow jkh's outline, making another "front end target" for the script shouldn't be that hard. You have X, VESA Syscons, and Text Syscons. The script says "ok, prompt user for blah", under X it opens a window, under Text some ASCII dialog, and under VESA a little window. This is important to note... 25% of all the installs I do are on MGA (remember monochrome graphics adapter - a hercules card.) So, I would not be in favor of any replacement that required a VESA or VGA platform... - Dave Rivers - To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: syscons extension: propellers
One potential drawback is that it would probably bloat the syscons code slightly. - Donn Uhh... "slightly"? - Dave R. - To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: HEADSUP: wd driver will be retired!
In message [EMAIL PROTECTED] Julian Elischer writes: : more importantly we lost the aha driver for a while. No we didn't. Well, the aha driver did loose support for the 1542A cards, but the aha driver was done so that cam could be committed to the tree. Maybe you are confusing things with the aic driver? Also, the cam uha driver hasn't gotten past the cp aha - query replace aha with uha stage... Warner I lost support on my 1542B until I came up with a patch, which I believe was incorporated into 3.3-R. - Dave R. - To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Now that sigcontext is gone ...
Just how much code will break? Boehm-gc, maybe. Modula-3, maybe. I can't remember whether it catches both signals or just SIGBUS. I believe electric-fence would change as well. - Dave R. - To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: ATTENTION PLEASE: g77 in base system.
Marc G. Fournier wrote: On Thu, 8 Apr 1999, Brian Handy wrote: On 9 Apr 1999, Dag-Erling Smorgrav wrote: [4 people said YES! Add g77!] I beg your pardon? You're adding g77 to the system because you know of four people who would find it useful? Where's the logic in that? Well, statistically speaking, that's a bunch of ayes and no noes. Lots of things happen via implicit acceptance. (I was one of the people who spoke up in favor of this after David mentioned this.) If you do add it to the base system, make it optional. I don't care if it defaults to on, as long as I have the option to turn it off. This doesn't seem unreasonable. (I also really like Chuck's idea of adding gcj in the same light.) Geez, and I used to think it was only the commercial OSs that had a problem with bloat and creeping featurisms ... :( Chuck's idea makes more sense...how many programs does the average system run that needs a fortran compiler? *raised eyebrow* Personally, I'm not sure g77 is needed, but let me play devil's advocate here and turn your question around: How many programs does the average system not run because the system doesn't have a FORTRAN compiler? That seems to be a more pertinent question... and - a good bit more difficult to answer. - Dave Rivers - (My personal preference is to put it in there, with an option to disable it in make world. ) To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
