On Mon, Mar 03, 2003 at 12:08:04AM +0100, Jens Rehsack wrote:
Now, that OpenWatcom is released, the FreeBSd port of it should follow.
And maybe someone will try to compile the kernel and world with it.
I hate to be the skeptic, but looking at OpenWatcom 1.0, it only produces
dos and win32
From: David O'Brien [EMAIL PROTECTED]
To: Jens Rehsack [EMAIL PROTECTED]
Cc: [EMAIL PROTECTED]
Sent: Wednesday, March 05, 2003 10:01 AM
Subject: Re: PATCH: type errors in src-tree
On Mon, Mar 03, 2003 at 12:08:04AM +0100, Jens Rehsack wrote:
Now, that OpenWatcom is released, the FreeBSd
On Tue, Mar 04, 2003 at 11:01:25PM -0800, David O'Brien wrote:
On Mon, Mar 03, 2003 at 12:08:04AM +0100, Jens Rehsack wrote:
Now, that OpenWatcom is released, the FreeBSd port of it should follow.
And maybe someone will try to compile the kernel and world with it.
I hate to be the
On Sun, 2 Mar 2003, Jens Rehsack wrote:
JRBarney Wolff wrote:
JR This is an example of what I was pointing out:
JR
JR On Sun, Mar 02, 2003 at 01:53:33AM +0100, Jens Rehsack wrote:
JR ...
JR
JR@@ -1444,22 +1420,19 @@
JR *none- response sent
JR *
JR */
JR-void
JR-send_resp ( intf,
John Polstra writes:
In article [EMAIL PROTECTED],
Dag-Erling Smorgrav [EMAIL PROTECTED] wrote:
This is wrong. caddr_t should be uniersally replaced with void *.
Not quite. There is (or at least used to be) a lot of code that
assumed you could do address arithmetic on a caddr_t. You
Mark Murray wrote:
John Polstra writes:
In article [EMAIL PROTECTED],
Dag-Erling Smorgrav [EMAIL PROTECTED] wrote:
This is wrong. caddr_t should be uniersally replaced with void *.
Not quite. There is (or at least used to be) a lot of code that
assumed you could do address arithmetic on a
On Sunday 02 March 2003 18:08, Jens Rehsack wrote:
Now, that OpenWatcom is released, the FreeBSd port of it should follow.
And maybe someone will try to compile the kernel and world with it. If
that would work, this would be great, because the watcom compiler
generates much better code than
Jens Rehsack [EMAIL PROTECTED] writes:
Of course. Very often in ilmid.c the type caddr_t was used, and nearly
the same count of 'const char *'s was used. I've searched the include
files for caddr_t (core address) and found it defined as 'char *', so
I decided to used commonly caddr_t - maybe
Dag-Erling Smorgrav wrote:
Jens Rehsack [EMAIL PROTECTED] writes:
Of course. Very often in ilmid.c the type caddr_t was used, and nearly
the same count of 'const char *'s was used. I've searched the include
files for caddr_t (core address) and found it defined as 'char *', so
I decided to used
In article [EMAIL PROTECTED],
Dag-Erling Smorgrav [EMAIL PROTECTED] wrote:
This is wrong. caddr_t should be uniersally replaced with void *.
Not quite. There is (or at least used to be) a lot of code that
assumed you could do address arithmetic on a caddr_t. You can't do
that on a void *,
John Polstra [EMAIL PROTECTED] writes:
Dag-Erling Smorgrav [EMAIL PROTECTED] wrote:
This is wrong. caddr_t should be uniersally replaced with void *.
Not quite. There is (or at least used to be) a lot of code that
assumed you could do address arithmetic on a caddr_t. You can't do
that on
Sorry for resending (3rd time), but I've found a small typo in the patch
of sbin/atm/ilmid/ilmid.c
Jens
--- sbin/atm/ilmid/ilmid.c.orig Wed Jan 1 18:48:45 2003
+++ sbin/atm/ilmid/ilmid.c Sat Mar 1 13:29:05 2003
@@ -162,7 +162,7 @@
union {
int ival;
Juli Mallett wrote:
* De: Jens Rehsack [EMAIL PROTECTED] [ Data: 2003-03-01 ]
[ Subjecte: Re: PATCH: type errors in src-tree ]
Sorry for resending (3rd time), but I've found a small typo in the patch
of sbin/atm/ilmid/ilmid.c
- u_char **bufp;
- Objid *objid
Juli Mallett wrote:
* De: Jens Rehsack [EMAIL PROTECTED] [ Data: 2003-03-01 ]
[ Subjecte: Re: PATCH: type errors in src-tree ]
caddr_t is discouraged, with preference of writing an actual type. caddr_t
is just an obfuscation. I'm unclear what it gains in your context.
Okay, sorry
On Sat, Mar 01, 2003 at 11:09:03PM +0100, Jens Rehsack wrote:
...
- u_char **bufp;
+ caddr_t *bufp;
...
Of course. Very often in ilmid.c the type caddr_t was used, and nearly
the same count of 'const char *'s was used. I've searched the include
files for caddr_t (core
Barney Wolff wrote:
On Sat, Mar 01, 2003 at 11:09:03PM +0100, Jens Rehsack wrote:
Shouldn't we care about u_char vs char? On some machines it matters,
and on all machines compilers tend to notice and generate warnings.
Yes, usually we should. But I reviewed the code and didn't found a
reason
Barney Wolff wrote:
On Sat, Mar 01, 2003 at 11:09:03PM +0100, Jens Rehsack wrote:
Shouldn't we care about u_char vs char? On some machines it matters,
and on all machines compilers tend to notice and generate warnings.
Just another question: I turned on '-ansi' and got some warning about a
* De: Jens Rehsack [EMAIL PROTECTED] [ Data: 2003-03-01 ]
[ Subjecte: Re: PATCH: type errors in src-tree ]
Barney Wolff wrote:
On Sat, Mar 01, 2003 at 11:09:03PM +0100, Jens Rehsack wrote:
Shouldn't we care about u_char vs char? On some machines it matters,
and on all machines
Juli Mallett wrote:
* De: Jens Rehsack [EMAIL PROTECTED] [ Data: 2003-03-01 ]
[ Subjecte: Re: PATCH: type errors in src-tree ]
Barney Wolff wrote:
On Sat, Mar 01, 2003 at 11:09:03PM +0100, Jens Rehsack wrote:
Shouldn't we care about u_char vs char? On some machines it matters
Juli Mallett wrote:
ANSI is preferred, but mixing style with functional changes is discouraged.
I get the impression your change to width-specified values has a real
correlation to what things need to use, and thus it might fix brokenness
with systems not ILP32.
Sorry, it's getting late here -
This is an example of what I was pointing out:
On Sun, Mar 02, 2003 at 01:53:33AM +0100, Jens Rehsack wrote:
...
@@ -1444,22 +1420,19 @@
* none- response sent
*
*/
-void
-send_resp ( intf, Hdr, resp )
- int intf;
- Snmp_Header *Hdr;
- u_char
Barney Wolff wrote:
This is an example of what I was pointing out:
On Sun, Mar 02, 2003 at 01:53:33AM +0100, Jens Rehsack wrote:
...
@@ -1444,22 +1420,19 @@
* none- response sent
*
*/
-void
-send_resp ( intf, Hdr, resp )
- int intf;
- Snmp_Header *Hdr;
-
Barney Wolff wrote:
This is an example of what I was pointing out:
On Sun, Mar 02, 2003 at 01:53:33AM +0100, Jens Rehsack wrote:
...
@@ -1444,22 +1420,19 @@
* none- response sent
*
*/
-void
-send_resp ( intf, Hdr, resp )
- int intf;
- Snmp_Header *Hdr;
-
On Sun, Mar 02, 2003 at 02:33:55AM +0100, Jens Rehsack wrote:
...
+ n = write ( ilmi_fd[intf], resp+1, resp[0] );
Here's a case where it matters whether something is u_char or char.
write(2) takes a size_t as its third arg, and extension of a char to
that may not be the same as for
Hi,
sorry for resending, but I've seen that all people who submit patches
wrote 'PATCH' in their subject line.
Ok, rest of the mail:
I made some experiments with the optimization switches of the cc of
FBSD-CURRENT, and if I turned on -finline-functions, the link of
src/bin/cat fails, because
25 matches
Mail list logo
