-Wall -Wcast-qual and SYSINIT

1999-01-27 Thread Matthew Dillon
Right now we have a problem with struct sysinit. The problem is that some SYSINIT functions supply a function taking a const void * and a const pointer for data, and other SYSINIT functions supply a function taking a void * and a non-const pointer for data. What this means

indent(1) and style(9) (was: btokup() macro in sys/malloc.h)

1999-01-27 Thread Greg Lehey
On Thursday, 28 January 1999 at 14:16:25 +1100, Bruce Evans wrote: >> It would be nice if style(9) documented the options to give indent(1) >> to match the `approved' layout convections. (This would reduce the >> effort involved in importing large chunks of code). > > This is impossible, since ind

Re: devstat and atapi-cd.c

1999-01-27 Thread S�ren Schmidt
It seems Kenneth D. Merry wrote: > Gary Jennejohn wrote... > > Are there any plans to add devstat support to atapi-cd.c, a la scsi_cd.c ? > > > > Is it even considered to be desirable ? > > I think it is desireable. I think the best person to do it is probably > Soren or someone else who is fami

Re: btokup().. STYLE(9)

1999-01-27 Thread Matthew Dillon
:I think that style(9) should be modified to include :"Parenthesis may be used to improve the readbility of complex :expressions even if not strictly required." :instead of the stupid phrase presently there. :also: :"Braces around code blocks should be allowable even when not strictly :needed, for

Re: cvs commit: src/sys/i386/eisa ahb.c

1999-01-27 Thread Matthew Dillon
:> > Bullshit. You don't know what the fuck you are talking about. :> :> I don't know that you screwed up in your quest to fix a warning? Gee, :> forgive me for sounding suprised, but: :> :> "Matt, you screwed up with your fix that tried to fix a -Wall warning". :> The fix was wrong. Wrong

Re: btokup() macro in sys/malloc.h

1999-01-27 Thread Julian Elischer
I could drive there from here :-) On Wed, 27 Jan 1999, John Polstra wrote: > > On 28-Jan-99 John Birrell wrote: > > John Polstra wrote: > >> > >> Hear ye, hear ye! Be it here noted and archived for all eternity that > >> on January 27, 1999 Pacific Time, John Polstra was, for one fleeting > >

Re: DEVFS, the time has come...

1999-01-27 Thread Alfred Perlstein
On Wed, 27 Jan 1999, Archie Cobbs wrote: > Harlan Stenn writes: > > > Also the eth[0..x] thing means you can replace your ethernet card with a > > > new one of a different type without having to look through your config > > > code for references to ed0 or whatever. > > > > Just to ask, what happe

Re: DEVFS, the time has come...

1999-01-27 Thread Scott Michel
> I think Solaris (?) requires you to do this, it's called "plumbing > your interfaces" or something (according to Julian). Solaris requires "interface plumbing" as the result of STREAMS; you have to push IP on top of the interface driver. For all intents and purposes, the device name identifies a

Re: DEVFS, the time has come...

1999-01-27 Thread Kenneth D. Merry
Leif Neland wrote... > > > On Wed, 27 Jan 1999, Archie Cobbs wrote: > > > Doug Rabson writes: > > > And another thing. Why can't we use a non-driver-specific name for the > > > disk? Most users simply don't care whether the driver was fd, wfd, wd or > > > anything. They just want to get to th

Re: btokup().. STYLE(9)

1999-01-27 Thread Julian Elischer
I think that style(9) should be modified to include "Parenthesis may be used to improve the readbility of complex expressions even if not strictly required." instead of the stupid phrase presently there. also: "Braces around code blocks should be allowable even when not strictly needed, for the pur

Re: DEVFS, the time has come...

1999-01-27 Thread Leif Neland
On Wed, 27 Jan 1999, Archie Cobbs wrote: > Doug Rabson writes: > > And another thing. Why can't we use a non-driver-specific name for the > > disk? Most users simply don't care whether the driver was fd, wfd, wd or > > anything. They just want to get to their files without any fuss. > > I ag

Re: DEVFS, the time has come...

1999-01-27 Thread Archie Cobbs
Harlan Stenn writes: > > Also the eth[0..x] thing means you can replace your ethernet card with a > > new one of a different type without having to look through your config > > code for references to ed0 or whatever. > > Just to ask, what happens when the probe order changes and your multiple > N

Re: btokup() macro in sys/malloc.h

1999-01-27 Thread Mike Smith
> > In my experience, the resulting > > code tends to be more portable across architectures with different > > pointer/long sizes and endian-ness. > > This is where I disagree. Too often people cast away the bugs and end > up with overflow and sign problems. Since we haven't tried this yet, and

Re: kern/subr_scanf array index of signed char

1999-01-27 Thread Archie Cobbs
Matthew Dillon writes: > :>Actually, it could very well be that I don't. I didn't want to spend > :>the time to check to see if the compiler warned on unsigned-char array > :>indexes. You can change it back if unsigned char array indexes do not > :>produce a warning. > : > :Sloppy

Re: btokup() macro in sys/malloc.h

1999-01-27 Thread Archie Cobbs
Nate Williams writes: > > In fact, style(9) should say: > > > > If at all possible, your code should compile without warnings > > when the gcc -Wall flag is given. > > I disagree. As has been shown many times in the past (and I suspect the > down-under constituent will show that at least a c

Re: btokup() macro in sys/malloc.h

1999-01-27 Thread Nate Williams
> :And introduced at least one. If you were a programmer under my charge, > :I'd tell you to use the warnings to fix only those bugs you are sure of > :and leave the others alone. > > Nate, if you were a programmer under my charge you'd be heading out > the door with your final paycheck.

Re: btokup() macro in sys/malloc.h

1999-01-27 Thread Matthew Dillon
: :And introduced at least one. If you were a programmer under my charge, :I'd tell you to use the warnings to fix only those bugs you are sure of :and leave the others alone. Nate, if you were a programmer under my charge you'd be heading out the door with your final paycheck. Your at

Re: btokup() macro in sys/malloc.h

1999-01-27 Thread Nate Williams
> :> then we need to update sytle(9) to reflect that. > :> > :> In fact, style(9) should say: > :> > :> If at all possible, your code should compile without warnings > :> when the gcc -Wall flag is given. > : > :I disagree. As has been shown many times in the past (and I suspect the > :down-

Re: btokup() macro in sys/malloc.h

1999-01-27 Thread Nate Williams
> > > Fixing warnings with bad casts is a problem, sure, but asking people > > > to write code without casts (if possible) that will compile cleanly with > > > -Wall is a reasonable thing to ask IMO. > > > > Agreed. But most of the new code written does indeed compile with > > -Wall. It's the co

Re: btokup() macro in sys/malloc.h

1999-01-27 Thread John Birrell
Nate Williams wrote: > > Fixing warnings with bad casts is a problem, sure, but asking people > > to write code without casts (if possible) that will compile cleanly with > > -Wall is a reasonable thing to ask IMO. > > Agreed. But most of the new code written does indeed compile with > -Wall. It

Re: btokup() macro in sys/malloc.h

1999-01-27 Thread Andrew Kenneth Milton
+[ John Birrell ]- | John Polstra wrote: | > Bah! You might be able to hit Bruce over there in oz. But to hit me, | > you'd need an ICBM. Give me purity or give me death! Bwahahahahah! | | Nah, I even tried poisoning Sydney's water with something

Re: btokup() macro in sys/malloc.h

1999-01-27 Thread Nate Williams
> > 'warnings' fixes will be wrong and hide bogus code), making -Wall a goal > > causes people to cover up bad code with bad casts and such. > > > > '-Wall' is *NOT* a good design goal. > > Fixing warnings with bad casts is a problem, sure, but asking people > to write code without casts (if poss

Re: btokup() macro in sys/malloc.h

1999-01-27 Thread John Birrell
John Polstra wrote: > Bah! You might be able to hit Bruce over there in oz. But to hit me, > you'd need an ICBM. Give me purity or give me death! Bwahahahahah! Nah, I even tried poisoning Sydney's water with something I can't spell, but even that didn't kill off Bruce. The government told peop

Re: NIS with HPUX 10.20

1999-01-27 Thread Bruce Evans
>> If installworld assumes single-user mode, why do we install -C >> ld-elf.so.1 ? The first time I asked this question, I didn't mention >> ... >Why _not_ use -C? What is the point in replacing a file with the same file? >install -C will replace the file if the new file is diffrent. Plain insta

Re: btokup() macro in sys/malloc.h

1999-01-27 Thread Matthew Dillon
:I think you must mean the "Sydney-down-under constituent". There *is* :a difference. 8-) : :> 'warnings' fixes will be wrong and hide bogus code), making -Wall a goal :> causes people to cover up bad code with bad casts and such. :> :> '-Wall' is *NOT* a good design goal. : :Fixing warnings with

Re: DEVFS, the time has come...

1999-01-27 Thread Daniel O'Connor
On 28-Jan-99 Harlan Stenn wrote: > > code for references to ed0 or whatever. > Just to ask, what happens when the probe order changes and your multiple > NICs start popping up on the wrong eth port? Thats why I mentioned wiring them down a la SCSI. > Or will be be able to wire them down in th

Re: btokup() macro in sys/malloc.h

1999-01-27 Thread John Polstra
On 28-Jan-99 John Birrell wrote: > John Polstra wrote: >> >> Hear ye, hear ye! Be it here noted and archived for all eternity that >> on January 27, 1999 Pacific Time, John Polstra was, for one fleeting >> moment, purer than Bruce! :-) > > OK, so now we have to shoot you too. Oh well, so be it.

Re: DEVFS, the time has come...

1999-01-27 Thread Harlan Stenn
> Also the eth[0..x] thing means you can replace your ethernet card with a > new one of a different type without having to look through your config > code for references to ed0 or whatever. Just to ask, what happens when the probe order changes and your multiple NICs start popping up on the wrong

Re: btokup() macro in sys/malloc.h

1999-01-27 Thread Matthew Dillon
:> then we need to update sytle(9) to reflect that. :> :> In fact, style(9) should say: :> :> If at all possible, your code should compile without warnings :> when the gcc -Wall flag is given. : :I disagree. As has been shown many times in the past (and I suspect the :down-under constituent

RE: One answer, one question.

1999-01-27 Thread Jeroen Ruigrok/Asmodai
On 27-Jan-99 Kris Kennaway wrote: > What's there to compile with netscape? It's provided in binary form, > which means it's statically linked with some libraries at build time by > the netscape people (e.g. the motif library), and is dynamically linked > against some of the a.out libraries on your

Re: kern/subr_scanf array index of signed char

1999-01-27 Thread Matthew Dillon
:>Actually, it could very well be that I don't. I didn't want to spend :>the time to check to see if the compiler warned on unsigned-char array :>indexes. You can change it back if unsigned char array indexes do not :>produce a warning. : :Sloppy thinking. How would you know if y

Re: btokup() macro in sys/malloc.h

1999-01-27 Thread John Birrell
John Polstra wrote: > On 28-Jan-99 Bruce Evans wrote: > > Nah, style(9), not to mention the example of btokup() in Lite1 and Lite2, > > requires paretheses here (in btokup(), and probably in the bad example in > > style(9), because the expression would be really confusing without them :-). > > Hea

Re: btokup() macro in sys/malloc.h

1999-01-27 Thread John Birrell
Nate Williams wrote: > > Anyway, if we're going to -Wall'ify the kernel (as we should) > > then we need to update sytle(9) to reflect that. > > > > In fact, style(9) should say: > > > > If at all possible, your code should compile without warnings > > when the gcc -Wall flag is given. > > I

Re: "JAIL" code headed for -current.

1999-01-27 Thread Nate Williams
> > > suser(NOJAIL, bla, bla); > > >or > > > suser(0, bla, bla); > > > > Oh, goody, more gratuitious incomaptibilities with everyone else. > > Incompatibility, yes, but gratuitous? Sure. It could be done by adding a new call w/out being gratitious and still giving the same function

Re: btokup() macro in sys/malloc.h

1999-01-27 Thread John Polstra
On 28-Jan-99 Bruce Evans wrote: >>The added parentheses don't make any difference, semantically. This >>change probably wouldn't meet the criteria spelled out in style(9): >> >> Unary operators don't require spaces, binary operators do. Don't use >> parentheses unless they're required for

Re: btokup() macro in sys/malloc.h

1999-01-27 Thread Nate Williams
> Anyway, if we're going to -Wall'ify the kernel (as we should) > then we need to update sytle(9) to reflect that. > > In fact, style(9) should say: > > If at all possible, your code should compile without warnings > when the gcc -Wall flag is given. I disagree. As has been shown many times

Re: About to commit NTFS driver

1999-01-27 Thread Luigi Rizzo
> Hello! > > Are there any disagrees with an idea to commit a NTFS > driver into current: ... > Driver is readonly, specialy developed for freebsd, > supports most of NTFS's features. while readonly access is great, a problem i always have with NT machines is to access the NTFS (or a file on it)

Re: DEVFS, the time has come...

1999-01-27 Thread Daniel O'Connor
On 27-Jan-99 Wilko Bulte wrote: > > I agree.. and same thing goes for Ethernet drivers. I actually > > like the way Linux always has "eth0", "eth1", ... (which we could > Yeagh... what is wrong with ed0, de0, fxp0 etc that needs changing? Is this > just a matter of taste or is there more to it?

Re: btokup() macro in sys/malloc.h

1999-01-27 Thread Bruce Evans
>> Is this parenthesization correct ? >> >> OLD >> >> #define btokup(addr)(&kmemusage[(caddr_t)(addr) - kmembase >> >> PAGE_SHIFT]) >> >> NEW >> >> #define btokup(addr)(&kmemusage[((caddr_t)(addr) - kmembase) >> >> PAGE_SHIFT]) Yes. It is the same as before the "cleanup"

Re: "JAIL" code headed for -current.

1999-01-27 Thread Daniel C. Sobral
Sean Eric Fagan wrote: > > > suser(NOJAIL, bla, bla); > >or > > suser(0, bla, bla); > > Oh, goody, more gratuitious incomaptibilities with everyone else. Incompatibility, yes, but gratuitous? -- Daniel C. Sobral(8-DCS) d...@newsguy.com If you sell y

Re: DEVFS, the time has come...

1999-01-27 Thread Wilko Bulte
As Archie Cobbs wrote... > Doug Rabson writes: > > And another thing. Why can't we use a non-driver-specific name for the > > disk? Most users simply don't care whether the driver was fd, wfd, wd or > > anything. They just want to get to their files without any fuss. > > I agree.. and same thin

Re: "Argument by Authority"

1999-01-27 Thread Greg Lehey
On Thursday, 28 January 1999 at 5:48:31 +0200, Robert Nordier wrote: > Greg Lehey wrote: > >> On Wednesday, 27 January 1999 at 14:38:23 -0500, Mike O'Dell wrote: >>> >>> just for a calibration, >>> i asked Dennis Ritchie his opinion of "the right behavior" >>> >>> his comment about posix might be

Re: removing f2c from base distribution

1999-01-27 Thread Chuck Robey
On Thu, 28 Jan 1999, Daniel C. Sobral wrote: > Nate Williams wrote: > > > > > > A lot of people use a lot of things out of ports. Why should Fortran > > > > be different? > > > > > > Because Berkeley Unix has /always/ included a FORTRAN compiler. > > > > And they have /always/ included games. N

Re: kern/subr_scanf array index of signed char

1999-01-27 Thread Bruce Evans
>:Matthew Dillon writes: >:> goto match_failure; >:> } else { >:> p0 = p = va_arg(ap, char *); >:> - while (ccltab[*inp]) { >:> + while (ccltab

Re: removing f2c from base distribution

1999-01-27 Thread Daniel C. Sobral
Nate Williams wrote: > > > > A lot of people use a lot of things out of ports. Why should Fortran > > > be different? > > > > Because Berkeley Unix has /always/ included a FORTRAN compiler. > > And they have /always/ included games. Next issue. Mmmm... can I get a VAX port going with this argum

Re: "Argument by Authority"

1999-01-27 Thread Robert Nordier
Greg Lehey wrote: > On Wednesday, 27 January 1999 at 14:38:23 -0500, Mike O'Dell wrote: > > > > just for a calibration, > > i asked Dennis Ritchie his opinion of "the right behavior" > > > > his comment about posix might be the trump card, although > > i'd like to see chapter and verse if that's t

Re: btokup() macro in sys/malloc.h

1999-01-27 Thread Archie Cobbs
Bruce Evans writes: > >In fact, style(9) should say: > > > > If at all possible, your code should compile without warnings > > when the gcc -Wall flag is given. > > Avoiding warnings is more an engineering than a stylistic matter. > You turn on warnings to help avoid bugs that the compiler can f

Re: removing f2c from base distribution

1999-01-27 Thread Bruce Albrecht
Garrett Wollman writes: > < > said: > > > > A lot of people use a lot of things out of ports. Why should Fortran > > be different? > > Because Berkeley Unix has /always/ included a FORTRAN compiler. So FreeBSD v12.4, released in 2026, had better include a FORTRAN compiler, because Berk

Re: removing f2c from base distribution

1999-01-27 Thread W Gerald Hicks
From: "Daniel C. Sobral" > > A lot of people use a lot of things out of ports. Why should Fortran > be different? > Right on. If anything, I'd like to see the "ports" system continue its evolution to becoming able to build nearly any component of the system. (including patched kernel builds an

Re: DEVFS, the time has come...

1999-01-27 Thread Archie Cobbs
Daniel O'Connor writes: > > Anyway, it's not automatic now either: > > > >network_interfaces="lo0 ed0" # List of network interfaces (lo0 is > > loopback). > >ifconfig_lo0="inet 127.0.0.1" # default loopback device configuration. > >ifconfig_ed0="inet 192.168.1.1" > >...etc... >

Re: btokup() macro in sys/malloc.h

1999-01-27 Thread Bruce Evans
>It would be nice if style(9) documented the options to give indent(1) >to match the `approved' layout convections. (This would reduce the >effort involved in importing large chunks of code). This is impossible, since indent(1) is buggy and out of date with both KNF and C. Bruce To Unsubscribe:

Re: Changing bzero, bcopy, memset, memcpy, etc... prototypes

1999-01-27 Thread Matthew Dillon
: :No. bzero() and bcopy() are for handling ordinary memory. There is no :proper way to volatilize them without pessimizing them. Adding volatile :to their prototypes won't actually make them handle volatile memory; it :just breaks the warnings. Some of the i586-optimized versions in fact :don'

Re: btokup() macro in sys/malloc.h

1999-01-27 Thread Peter Jeremy
Matthew Dillon wrote: >:style(9) should emphasize legibility and maintainability, rather than >:minimizing the number of extraneous (from the compiler's perspective) >:parenthesis. >As far as parenthesis go, it's irrelevant because -Wall pretty much >covers the most common mistakes. I was

Re: Changing bzero, bcopy, memset, memcpy, etc... prototypes

1999-01-27 Thread Bruce Evans
>I would like to propose changing the prototype for the kernel memory >zeroing and copying routines. > >Basically, the problem is that a whole hellofalot of drivers run >bzero and bcopy on volatile memory. The only way to remove the >warnings is to volatilize bzero and bcopy.

Re: DEVFS, the time has come...

1999-01-27 Thread Daniel O'Connor
On 28-Jan-99 Archie Cobbs wrote: > Well, if it's automatic then you can't necessarily wire it down > the way you want to.. you can't have both at the same time. > > Anyway, it's not automatic now either: > >network_interfaces="lo0 ed0" # List of network interfaces (lo0 is > loopback)

Re: bug in netatm/atm_cm.c ?

1999-01-27 Thread Joerg B. Micheel
On Wed, Jan 27, 1999 at 02:15:11PM -0800, Matthew Dillon wrote: > around line 2192. Shouldn't this be ap->aal.type == ATM_AAL5 ??? It definitely should, as the } else { branch on line 2211 is never reached. The reason it has not been discovered is that noone hardly ever uses anything other th

Re: btokup() macro in sys/malloc.h

1999-01-27 Thread Bruce Evans
>Anyway, if we're going to -Wall'ify the kernel (as we should) >then we need to update sytle(9) to reflect that. > >In fact, style(9) should say: > > If at all possible, your code should compile without warnings > when the gcc -Wall flag is given. Avoiding warnings is more an engineering than a

Re: kern/subr_scanf array index of signed char

1999-01-27 Thread Alfred Perlstein
On Wed, 27 Jan 1999, Archie Cobbs wrote: > Alfred Perlstein writes: > > avoids a warning. > > No it doesn't. The "(unsigned char)" avoids the warning: > > $ cat > foo.c > int foo(int *array, unsigned char index) { return array[index]; } > $ gcc -c -Wall -o foo foo.c > $ doh' yes, it i

Re: btokup() macro in sys/malloc.h

1999-01-27 Thread Brian Feldman
On Thu, 28 Jan 1999, Peter Jeremy wrote: > Matthew Dillon wrote: > >:> NEW > >:> > >:> #define btokup(addr)(&kmemusage[((caddr_t)(addr) - kmembase) >> > >PAGE_SHIFT]) > >: > >:The added parentheses don't make any difference, semantically. This > >:change probably wouldn't meet the crit

Re: btokup() macro in sys/malloc.h

1999-01-27 Thread Matthew Dillon
:Matthew Dillon wrote: :>:> NEW :>:> :>:> #define btokup(addr)(&kmemusage[((caddr_t)(addr) - kmembase) >> PAGE_SHIFT]) :>: :>:The added parentheses don't make any difference, semantically. This :>:change probably wouldn't meet the criteria spelled out in style(9): :> :>Then style(9)

Re: "Argument by Authority"

1999-01-27 Thread Greg Lehey
On Wednesday, 27 January 1999 at 14:38:23 -0500, Mike O'Dell wrote: > > just for a calibration, > i asked Dennis Ritchie his opinion of "the right behavior" > > his comment about posix might be the trump card, although > i'd like to see chapter and verse if that's the case. > > for what it's worth.

Re: btokup() macro in sys/malloc.h

1999-01-27 Thread Archie Cobbs
Garrett Wollman writes: > > Please do go ahead and update it.. the experts agree! > > I haven't seen any experts involved in this discussion yet. It's > probably after bedtime down there in oz. It was discussed before a couple of weeks ago, and I didn't hear anybody on the other side. I could be

Naming files in sys/kern

1999-01-27 Thread Garrett Wollman
< said: > It's not clear to me, when thinking of introducing a new file (say, for > auditing support :), what I should name it. Would it be kern_audit.c or > sys_audit.c? Depends on what it is auditing. If it only auditing the basic I/O operations, then it would go in sys_*.c. If it's a more g

Re: btokup() macro in sys/malloc.h

1999-01-27 Thread Peter Jeremy
Matthew Dillon wrote: >:> NEW >:> >:> #define btokup(addr)(&kmemusage[((caddr_t)(addr) - kmembase) >> >PAGE_SHIFT]) >: >:The added parentheses don't make any difference, semantically. This >:change probably wouldn't meet the criteria spelled out in style(9): > >Then style(9) needs t

Re: kern/subr_scanf array index of signed char

1999-01-27 Thread Archie Cobbs
Alfred Perlstein writes: > > Matthew Dillon writes: > > > - while (ccltab[*inp]) { > > > + while (ccltab[(int)(unsigned char)*inp]) { > > > > Just curious.. why do you need the "(int)" cast? > > avoids a warning. No it doesn't. The "(un

Re: btokup() macro in sys/malloc.h

1999-01-27 Thread Garrett Wollman
< said: > Please do go ahead and update it.. the experts agree! I haven't seen any experts involved in this discussion yet. It's probably after bedtime down there in oz. -GAWollman -- Garrett A. Wollman | O Siem / We are all family / O Siem / We're all the same woll...@lcs.mit.edu | O Siem

Changing bzero, bcopy, memset, memcpy, etc... prototypes

1999-01-27 Thread Matthew Dillon
I would like to propose changing the prototype for the kernel memory zeroing and copying routines. Basically, the problem is that a whole hellofalot of drivers run bzero and bcopy on volatile memory. The only way to remove the warnings is to volatilize bzero and bcopy. T

Re: kern/subr_scanf array index of signed char

1999-01-27 Thread Matthew Dillon
::> - while (ccltab[*inp]) { ::> + while (ccltab[(int)(unsigned char)*inp]) { : :Actually, it could very well be that I don't. I didn't want to spend :the time to check to see if the compiler warned on unsigned-char array :in

Re: kern/subr_scanf array index of signed char

1999-01-27 Thread Alfred Perlstein
On Wed, 27 Jan 1999, Archie Cobbs wrote: > Matthew Dillon writes: > > - while (ccltab[*inp]) { > > + while (ccltab[(int)(unsigned char)*inp]) { > > Just curious.. why do you need the "(int)" cast? avoids a warning. -Alfred To Unsubsc

Re: kern/subr_scanf array index of signed char

1999-01-27 Thread Matthew Dillon
:Matthew Dillon writes: :> goto match_failure; :> } else { :> p0 = p = va_arg(ap, char *); :> - while (ccltab[*inp]) { :> + while (ccltab[(int

Re: kern/subr_scanf array index of signed char

1999-01-27 Thread Archie Cobbs
Matthew Dillon writes: > goto match_failure; > } else { > p0 = p = va_arg(ap, char *); > - while (ccltab[*inp]) { > + while (ccltab[(int)(unsig

Re: btokup() macro in sys/malloc.h

1999-01-27 Thread Archie Cobbs
Matthew Dillon writes: > :> #define btokup(addr)(&kmemusage[((caddr_t)(addr) - kmembase) >> > PAGE_SHIFT]) > : > :The added parentheses don't make any difference, semantically. This > :change probably wouldn't meet the criteria spelled out in style(9): > > Then style(9) needs to be updat

Re: Hmmm.. more on the eis ahb bug

1999-01-27 Thread Steve Kargl
Julian Elischer wrote: > this is new code (CAM) > Whoops. Well, I've been running CAM at home 5 to 6 months without a problem. > > On Wed, 27 Jan 1999, Steve Kargl wrote: > > > Matthew Dillon wrote: > > > Could an Adaptec SCSI guru take a look at this code ? There's > > > probably so

Re: DEVFS, the time has come...

1999-01-27 Thread Archie Cobbs
Daniel O'Connor writes: > On 28-Jan-99 Archie Cobbs wrote: > > That would be easy part! :-) Something like this... > >$ ngctl mkpeer ed0: eth_iface upstream downstream > Heh.. It would be nice if it was automagic though.. Well, if it's automatic then you can't necessarily wire it down the way

Re: btokup() macro in sys/malloc.h

1999-01-27 Thread Julian Elischer
that line was confusing enough for me... I think style (9) needs to be relaxed a bit on that I think the bit about parns just intriduces bug "opportunities" and certainly the bit about braces DEFINATLY introduces bugs. Braces and parens allow humans to understand the and read the code with less c

Re: Hmmm.. more on the eis ahb bug

1999-01-27 Thread Julian Elischer
this is new code (CAM) On Wed, 27 Jan 1999, Steve Kargl wrote: > Matthew Dillon wrote: > > Could an Adaptec SCSI guru take a look at this code ? There's > > probably some poor sob running EISA who's scratching his head right > > now :-) > > I'm not a guru, but I have been running a

Re: Hmmm.. more on the eis ahb bug

1999-01-27 Thread Steve Kargl
Matthew Dillon wrote: > Could an Adaptec SCSI guru take a look at this code ? There's > probably some poor sob running EISA who's scratching his head right > now :-) I'm not a guru, but I have been running a 1742 at home for 4 to 5 years without any problems. If the code could cause

Hmmm.. more on the eis ahb bug

1999-01-27 Thread Matthew Dillon
Hmmm. Actually, this looks broken either way. It looks like it is trying to wait until the mbox is empty? But it breaks out of the loop if the mbox is busy or not-empty, from what I can tell. Could an Adaptec SCSI guru take a look at this code ? There's probably some po

bug in i386/eisa/ahb.c

1999-01-27 Thread Matthew Dillon
static __inline void ahbqueuembox(struct ahb_softc *ahb, u_int32_t mboxval, u_int attn_code) { u_int loopmax = 300; while (--loopmax) { u_int status; status = ahb_inb(ahb, HOSTSTAT); if ((status & HOSTSTAT_MBOX_EMPTY|HOSTSTAT_BUSY)

Coda Distributed Filesystem 5.0.1

1999-01-27 Thread jaharkes
Coda Distributed File System, version 5.0.1 Coda is a distributed file system like NFS and AFS. It is freely available under the GPL. It functions somewhat like AFS in being a "stateful" file system. Coda and AFS cache files on your local machine to improve performance. But Coda goes a step f

Re: NIS with HPUX 10.20

1999-01-27 Thread Zach Heilig
On Wed, Jan 27, 1999 at 02:12:10PM +0200, Sheldon Hearn wrote: > On Wed, 27 Jan 1999 22:41:46 +1100, Bruce Evans wrote: > > So that ld-elf.so.1 can be installed safely on an active system. > I assume I should take your "installed safely" to mean "not installed"? It is not installed because the b

Re: btokup() macro in sys/malloc.h

1999-01-27 Thread Matthew Dillon
:> NEW :> :> #define btokup(addr)(&kmemusage[((caddr_t)(addr) - kmembase) >> PAGE_SHIFT]) : :The added parentheses don't make any difference, semantically. This :change probably wouldn't meet the criteria spelled out in style(9): Then style(9) needs to be updated, because we have t

Re: removing f2c from base distribution

1999-01-27 Thread Tony Kimball
: A lot of people use a lot of things out of ports. Why should Fortran : be different? For g77, because it is integrated with the C compiler. The system has a lower maintenance cost if it is included. To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-current" in

Re: DEVFS, the time has come...

1999-01-27 Thread Daniel O'Connor
On 28-Jan-99 Archie Cobbs wrote: > That would be easy part! :-) Something like this... >$ ngctl mkpeer ed0: eth_iface upstream downstream Heh.. It would be nice if it was automagic though.. (Where's my kernel config option :) --- Daniel O'Connor software and network engineer for Genesis Soft

Re: btokup() macro in sys/malloc.h

1999-01-27 Thread John Polstra
In article <199901272128.naa56...@apollo.backplane.com>, Matthew Dillon wrote: > Is this parenthesization correct ? > > OLD > > #define btokup(addr)(&kmemusage[(caddr_t)(addr) - kmembase >> PAGE_SHIFT]) > > NEW > > #define btokup(addr)(&kmemusage[((caddr_t)(addr) - kmembas

Re: DEVFS, the time has come...

1999-01-27 Thread Archie Cobbs
Daniel O'Connor writes: > On 27-Jan-99 Archie Cobbs wrote: > > I agree.. and same thing goes for Ethernet drivers. I actually > > like the way Linux always has "eth0", "eth1", ... (which we could > > do using netgraph, with some work). > Me too :) > > Of course you'd have to be able to do thing

Re: DEVFS, the time has come...

1999-01-27 Thread Daniel O'Connor
On 27-Jan-99 Archie Cobbs wrote: > I agree.. and same thing goes for Ethernet drivers. I actually > like the way Linux always has "eth0", "eth1", ... (which we could > do using netgraph, with some work). Me too :) Of course you'd have to be able to do things like 'wire down' your ethernet car

Re: "JAIL" code headed for -current.

1999-01-27 Thread Nate Williams
> >But then we're still having an API change that doesn't have to be there. > > No, it's not. You missed the point. Julian mentioned that since there were no 3.0 lkm's that might user 'suser()', there is no ABI to stay compatible with, hence it's an ABI change that doesn't affect anything given

Re: "JAIL" code headed for -current.

1999-01-27 Thread Sean Eric Fagan
>But then we're still having an API change that doesn't have to be there. No, it's not. If you change suser() to: int suser(uc, ac) struct ucred *uc; u_short *ac; { return JAILsuser(0, uc, ac); } then suser() continues to have the same sem

Re: NIS with HPUX 10.20

1999-01-27 Thread Mattias Pantzare
> > No. installworld more or less assumes single user. > > This is really what I'm getting at. :-) > > If installworld assumes single-user mode, why do we install -C > ld-elf.so.1 ? The first time I asked this question, I didn't mention > single-user mode and your answer was that it's to protect

Re: "JAIL" code headed for -current.

1999-01-27 Thread Nate Williams
> Ah now I see what sean is aguing about.. > He has a point.. > > maybe using jailsuser() or something might be a better idea? > (On the other hand at 3.x existing KLD modules are not YET a problem > except for OSS) But then we're still having an API change that doesn't have to be there. Nate

Re: "JAIL" code headed for -current.

1999-01-27 Thread Julian Elischer
Ah now I see what sean is aguing about.. He has a point.. maybe using jailsuser() or something might be a better idea? (On the other hand at 3.x existing KLD modules are not YET a problem except for OSS) On Wed, 27 Jan 1999, Sean Eric Fagan wrote: > In article <199901271944.laa15317.kithrup.fre

Naming files in sys/kern

1999-01-27 Thread Robert Watson
I was wondering what the naming scheme for files in /usr/src/sys/kern was :). There seem to be several sorts of files there-- bus_if.mdevice_.m imgact_*.c inflate.c init_*.ckern_*.c link_*.cmake*.{pl,sh} md5c.c

RE: One answer, one question.

1999-01-27 Thread Kris Kennaway
On Wed, 27 Jan 1999, Jeroen Ruigrok/Asmodai wrote: > On 27-Jan-99 Brian Feldman wrote: > > I am certain VM_STACK is breaking Netscape. Ps isn't related, but I am > > having problems with it, even after rebuilding everything, kvm_mkdb'ing... > > :( > > OK, I'm going to rebuild NetScape against the

Re: bug in devfs_strategy() ???

1999-01-27 Thread Julian Elischer
yes, though luckily it turns out to not matter. except possibly on tapes.. the 2nd call in the raw case will probably finish immediatly as the B_DONE flag will be set. On Wed, 27 Jan 1999, Matthew Dillon wrote: > Aren't there are few BREAK statements missing from this ? > >

Re: "JAIL" code headed for -current.

1999-01-27 Thread Sean Eric Fagan
In article <199901271944.laa15317.kithrup.freebsd.curr...@kithrup.com> you write: >>all over the kernel: >> >> suser(NOJAIL, bla, bla); >>or >> suser(0, bla, bla); >Oh, goody, more gratuitious incomaptibilities with everyone else. And to followup to my own message, since nobody else has

-Wall, -Wcast-qual has been turned on

1999-01-27 Thread Matthew Dillon
-Wall and -Wcast-qual has been turned on in /usr/src/share/mk/bsd.kern.mk. Please note that you will see a lot of warnings ( but no fatal errors ) while compiling the kernel now until we can get it all cleaned up. I am working a first-pass cleanup now. Do not 'cleanup' the cod

RE: One answer, one question.

1999-01-27 Thread Kris Kennaway
On Wed, 27 Jan 1999 sth...@nethelp.no wrote: > > I haven't really messed with it too much, so right now I think it's related > > because testing makes it appear to be. i.e. if I have a kernel with VM_STACK > > Netscape will sig11 right after loading; without VM_STACK it's as stable as > > ever. I'

RE: Netscape | Mozilla

1999-01-27 Thread Kris Kennaway
On Wed, 27 Jan 1999, Luke wrote: > > I wrote a port for Linux Netscape if anyone wants it. I sent it in but it > > came back to me with some comments about netscape port proliferation. > > I tried that one but it wants linux_lib installed on /compat and > theres > no room. Do you know if

bug in nfs_access()

1999-01-27 Thread Matthew Dillon
bug in nfs_access(). nfs/nfs_vnops.c, line 414 or so. Fixed! This is a nasty one. I'm surprised it hasn't caused grief before -Matt Matthew Dillon

  1   2   >