On Thu, Jun 07, 2001 at 12:47:30PM -0500, Jacques A. Vidrine wrote:
> C99 says of uintptr_t only that for any valid pointer p, the following
> is true:
>
> (void *)(uintptr_t)p == (void *)p
>
> Likewise for intptr_t. I read that as covering both code and data
> pointers.
C89, at least,
> There is none. No default fstab exists.
Maybe it comes from the /etc/fstab that is unpacked into ram disc,
that is extracted from the 2.88M boot floppy, that is part of a bootable CD ?
( BTW if you'r going to get into questions around bootable cdroms etc,
it's a frequent area of interest on
Assar Westerlund wrote:
>
> Terry Lambert <[EMAIL PROTECTED]> writes:
> > This all came from IP headers being 14 bytes long, instead
> > of 16.
>
> Hu? An IPv4 header (not including options) is 20 bytes long.
Sorry; ethernet header.
The problem is the 14 bytes making the code unaligned on
a
[EMAIL PROTECTED] wrote:
>
> This thread is baffling. The bottom line is that you cant
> trust data coming into your machine, and you have to
> checksum it. The link level check only verifies that what
> was sent by the last forwarding point is the same as what
> you got, but in NO WAY implies t
:leaving the dirhash structure attached to the inode when its hash
:array is freed.
:
:An updated patch is available at
:
: http://www.maths.tcd.ie/~iedowse/FreeBSD/dirhash.diff3
:
:I haven't had a chance to do more than a minimal amount of testing,
:so there may be many issues remaining.
:
This is a bug report for perl from [EMAIL PROTECTED],
generated with the help of perlbug 1.26 running under perl 5.00503.
-
[Please enter your report here]
>From perlfunc(1):
oct EXPR ...
(If EXPR happens t
Your e-mail has been received by the Perl Bug Squashing Team.
Original subject: oct() doesn't handle binary strings
A Bug ID (20010609.007) has been assigned and is shown in the subject of this email.
Please include this bug ID in the subject line of any followup messages.
This is a
> Ok, I've got the quick and dirty way working for testing (a nine line
> clone handler works great for that), but I think Brian's suggestion is
> probably best for a real solution especialy since it's rather easier to
> check for permissions before allowing creation this way. My current
> patch
On Sat, Jun 09, 2001 at 12:49:40AM -0700, Damien Neil wrote:
> On Thu, Jun 07, 2001 at 12:47:30PM -0500, Jacques A. Vidrine wrote:
> > C99 says of uintptr_t only that for any valid pointer p, the following
> > is true:
> >
> > (void *)(uintptr_t)p == (void *)p
> >
> > Likewise for intptr_t.
> Tell me: at what point are you willing to trust the data?
>
> Is "the card plus the motherboard" my machine, or is it
> just "the motherboard"?
>
> The cards support offloading the checksum to hardware;
> you are saying that it is never reasonable to do this.
No, that's not what's being said.
In a message dated 06/09/2001 1:21:45 PM Eastern Daylight Time,
[EMAIL PROTECTED] writes:
> [EMAIL PROTECTED] wrote:
> >
> > This thread is baffling. The bottom line is that you cant
> > trust data coming into your machine, and you have to
> > checksum it. The link level check only verifie
Hello,
FreeBSD 4.x has no support to nsswitch, and even the -CURRENT supports
only very few, predefined methods such as files, nis, nisplus for user
authentication in nsswitch.conf. Dynamically loadable modules can't be
used, for example nss_ldap for authentication via LDAP.
There are patches to
I have the need to read a whole pile of DEC Rainbow 100 floppies. I
can do it on the DEC Rainbow, but that's a huge pita since it isn't
networked. I'd like to either connect a RX-50 drive to my machine, or
use a 1.2M 5.25" floppy drive that I can scrounge easily enough to do
the deed.
80 trac
On Sun, 10 Jun 2001, Gyori Sandor wrote:
> Hello,
>
> There are patches to solve this problem at
> http://www.nectar.com/freebsd/nsswitch
> but only a part of them was built in to -CURRENT (the statical part).
>
> Could anybody tell me why? This is a serious deficiency of FreeBSD which
> has be
On Sat, Jun 09, 2001 at 09:24:22PM +0100, Brian Somers wrote:
> I think it'd be better to use the solaris ``plumb'' keyword. I can't
> recall how it works (something like ``ifconfig gif0 plumb'' - I
> haven't got a Solaris machine handy here), but it seemed cleaner,
> making it more obvious wh
> Has anybody done this before? Any pointers?
I'm very familiar with the RX50 on the Rainbow. I wrote the "copy protected
disk copier" for it in that bygone era. AR!!
The Rainbow ran several operating systems, CPM, CPM/86, MSDOS 2, and MSDOS 3.
The Rainbow had both a z80 cpu and an 8088
Mark Hittinger wrote:
>
> MSDOS world only and not CPM. I'd bet there are utilities on simtel20 that
> would read a CPM format floppy in 40 track format. I formatted them on the
A quick search returned 10 matches with this one looking like what you
want.
http://www.simtel.net/pub/pd/44392.sht
In message <[EMAIL PROTECTED]> Mark Hittinger writes:
: I'd actually recommend trying to use kermit to get the data out via the
: serial port first :-) There is a rainbow kermit out there.
Not an option. I have about 100 floppies to transfer. I know I could
set this up, but 9600 baud is just t
In message <[EMAIL PROTECTED]> James Housley writes:
: Mark Hittinger wrote:
: >
: > MSDOS world only and not CPM. I'd bet there are utilities on simtel20 that
: > would read a CPM format floppy in 40 track format. I formatted them on the
:
: A quick search returned 10 matches with this one lo
On Sat, Jun 09, 2001 at 07:02:14PM -0700, Brooks Davis wrote:
> On Sat, Jun 09, 2001 at 09:24:22PM +0100, Brian Somers wrote:
> > I think it'd be better to use the solaris ``plumb'' keyword. I can't
> > recall how it works (something like ``ifconfig gif0 plumb'' - I
> > haven't got a Solaris ma
20 matches
Mail list logo
