|
|
|
|
|
|
| Author |
Message |
Brian Somers
*nix forums beginner
Joined: 04 Apr 2002
Posts: 14
|
 Posted: Thu Apr 04, 2002 9:20 pm Post subject:
Re: Your change to in.c to limit duplicate networks is causing trouble
|
|
|
| Quote: | As Brian Somers wrote:
The code now avoids adding a host route if the interface address is
0.0.0.0, and always treats a failure to add a host route as fatal
(previously, it masked EEXIST for some reason - I guessed because it
was trying to handle address re-assignment, but that works ok with
this patch).
I think that will be fatal for the sppp case with dynamic IP
address negotiation. We use 0.0.0.0 as the local IP address
for the unnegotiated PPP link then, with the idea that it's
still possible to route through the interface anyway. For
dial-on-demand PPP links (like on ISDN), the routed packets
will then trigger the dialout event. In the course of the
PPP negotiations, an actual local IP address will be negotiated
and assigned, but we first need some packets to pass through the
PPP layer in order to trigger this.
Perhaps it would still be possible to use per-interface routes
even after your change (-iface isp0 etc.), but currently, a number
of documents describe that it's possible to use local address
0.0.0.0 and still get normal routing behaviour for those links.
|
Hmm, valid point :(
So the code will have to become something like the attached ? This
is quite grotty, but I can't think of any clean way other than
somehow telling SIOCAIFADDR and SIOCSIFADDR not to add the host route
in the first place.
| Quote: | --
cheers, J"org .-.-. --... ...-- -.. . DL8DTL
http://www.sax.de/~joerg/ NIC: JW11-RIPE
Never trust an operating system you don't have sources for. 
|
--
Brian <brian@freebsd-services.com> <brian@Awfulhak.org>
http://www.freebsd-services.com/ <brian@[uk.]FreeBSD.org>
Don't _EVER_ lose your sense of humour ! <brian@[uk.]OpenBSD.org>
Index: in.c
===================================================================
RCS file: /home/ncvs/src/sys/netinet/in.c,v
retrieving revision 1.63
diff -u -r1.63 in.c
--- in.c 1 Apr 2002 21:31:06 -0000 1.63
+++ in.c 4 Apr 2002 23:18:36 -0000
@@ -661,7 +661,7 @@
{
register u_long i = ntohl(sin->sin_addr.s_addr);
struct sockaddr_in oldaddr;
- int s = splimp(), flags = RTF_UP, error;
+ int s = splimp(), flags = RTF_UP, error = 0;
oldaddr = ia->ia_addr;
ia->ia_addr = *sin;
@@ -723,17 +723,25 @@
return (0);
flags |= RTF_HOST;
}
- if ((error = rtinit(&(ia->ia_ifa), (int)RTM_ADD, flags)) == 0)
- ia->ia_flags |= IFA_ROUTE;
- if (error != 0 && ia->ia_dstaddr.sin_family == AF_INET) {
- ia->ia_addr = oldaddr;
- return (error);
+ /*-
+ * Don't add host routes for interface addresses of
+ * 0.0.0.0 --> 0.255.255.255 netmask 255.0.0.0. This makes it
+ * possible to assign several such address pairs with consistent
+ * results (no host route) and is required by BOOTP.
+ *
+ * XXX: This is ugly ! There should be a way for the caller to
+ * say that they don't want a host route.
+ */
+ if (ia->ia_addr.sin_addr.s_addr != INADDR_ANY ||
+ ia->ia_netmask != IN_CLASSA_NET ||
+ ia->ia_dstaddr.sin_addr.s_addr != htonl(IN_CLASSA_HOST)) {
+ if ((error = rtinit(&ia->ia_ifa, (int)RTM_ADD, flags)) != 0) {
+ ia->ia_addr = oldaddr;
+ return (error);
+ }
+ ia->ia_flags |= IFA_ROUTE;
}
-
- /* XXX check if the subnet route points to the same interface */
- if (error == EEXIST)
- error = 0;
/*
* If the interface supports multicast, join the "all hosts"
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-arch" in the body of the message |
|
| Back to top |
|
 |
Brian Somers
*nix forums beginner
Joined: 04 Apr 2002
Posts: 14
|
| Posted: Thu Apr 04, 2002 10:19 pm Post subject:
Re: Your change to in.c to limit duplicate networks is causing trouble
|
|
|
| Quote: | The code now avoids adding a host route if the interface address is
0.0.0.0, and always treats a failure to add a host route as fatal
(previously, it masked EEXIST for some reason - I guessed because it
was trying to handle address re-assignment, but that works ok with
this patch).
One effect of the masked EEXIST is to suppress the spurious error
which occurs when adding an alias IP address (SIOCAIFADDR) on the
same logical subnet as an existing IP address. Users have no way
of knowing that it's actually safe to simply ignore the error in
that situation, so the masking should probably be preserved.
|
Hmm, thanks for the pointer.
I think this now works - where it didn't before (although see
the new patch posted in response to Joergs mention of the sppp
problem).
The lack of the EEXIST hack in my patch means that this will work as
before:
ifconfig dc0 inet 172.16.0.5 netmask 0xffffff00
ifconfig dc0 inet 172.16.0.11 netmask 0xfffffff8
Where connections to 172.16.0.1-172.16.0.7 and 172.16.0.16-172.16.0.255
come from 172.16.0.5 and connections to 172.16.0.8-172.16.0.15 come from
172.16.0.11.
After the above however,
ifconfig dc0 inet 172.16.0.14 netmask 0xfffffff8
will (correctly) fail in the patched code. It fails because the
gateway/netmask combination produces a duplicate key in the routing
table, returning an error from rtinit(). Previously, this failure
was masked by the EEXIST hack, allowing the interface address update
without a corresponding host route.
I believe the old behaviour becomes obviously wrong when someone then
deletes the 172.16.0.11 interface address, blowing away the
associated host route and leaving no routing table entry to talk to
the 172.16.0.14 address.
So I don't think the old was was really safe after all :-/
| Quote: | Stephen
------------------
Stephen Macmanus #include <std_disclaimer.h
stephenm@bayarea.net
- - - if ((error = rtinit(&(ia->ia_ifa), (int)RTM_ADD, flags)) == 0)
- - - ia->ia_flags |= IFA_ROUTE;
- - - if (error != 0 && ia->ia_dstaddr.sin_family == AF_INET) {
- - - ia->ia_addr = oldaddr;
- - - return (error);
+ /*
+ * Don't add routing table entries for interface address entries
+ * of 0.0.0.0. This makes it possible to assign several such address
+ * pairs with consistent results (no host route) and is required by
+ * BOOTP.
+ */
+ if (ia->ia_addr.sin_addr.s_addr != INADDR_ANY) {
+ if ((error = rtinit(&ia->ia_ifa, (int)RTM_ADD, flags)) != 0) {
+ ia->ia_addr = oldaddr;
+ return (error);
+ }
+ ia->ia_flags |= IFA_ROUTE;
}
- - - /* XXX check if the subnet route points to the same interface */
- - - if (error == EEXIST)
- - - error = 0;
/*
* If the interface supports multicast, join the "all hosts"
|
--
Brian <brian@freebsd-services.com> <brian@Awfulhak.org>
http://www.freebsd-services.com/ <brian@[uk.]FreeBSD.org>
Don't _EVER_ lose your sense of humour ! <brian@[uk.]OpenBSD.org>
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-arch" in the body of the message |
|
| Back to top |
|
|
stephen macmanus
*nix forums beginner
Joined: 04 Apr 2002
Posts: 2
|
| Posted: Thu Apr 04, 2002 11:36 pm Post subject:
Re: Your change to in.c to limit duplicate networks is causing trouble
|
|
|
| Quote: | The code now avoids adding a host route if the interface address is
0.0.0.0, and always treats a failure to add a host route as fatal
(previously, it masked EEXIST for some reason - I guessed because it
was trying to handle address re-assignment, but that works ok with
this patch).
One effect of the masked EEXIST is to suppress the spurious error
which occurs when adding an alias IP address (SIOCAIFADDR) on the
same logical subnet as an existing IP address. Users have no way
of knowing that it's actually safe to simply ignore the error in
that situation, so the masking should probably be preserved.
Hmm, thanks for the pointer.
I think this now works - where it didn't before (although see
the new patch posted in response to Joergs mention of the sppp
problem).
The lack of the EEXIST hack in my patch means that this will work as
before:
ifconfig dc0 inet 172.16.0.5 netmask 0xffffff00
ifconfig dc0 inet 172.16.0.11 netmask 0xfffffff8
Where connections to 172.16.0.1-172.16.0.7 and 172.16.0.16-172.16.0.255
come from 172.16.0.5 and connections to 172.16.0.8-172.16.0.15 come from
172.16.0.11.
After the above however,
ifconfig dc0 inet 172.16.0.14 netmask 0xfffffff8
will (correctly) fail in the patched code. It fails because the
gateway/netmask combination produces a duplicate key in the routing
table, returning an error from rtinit(). Previously, this failure
was masked by the EEXIST hack, allowing the interface address update
without a corresponding host route.
|
All true. However, this change just redefines the desired behavior
in this situation. The current EEXIST hack prevents a "meaningless"
error message (in the sense that it is still possible to use the
172.16.0.14 address due to the existence of the earlier route).
This patch just restores the original behavior from earlier BSD
versions which reported an error for the reasons you mention.
I guess it's just a judgement call as to which one is more desirable.
| Quote: | I believe the old behaviour becomes obviously wrong when someone then
deletes the 172.16.0.11 interface address, blowing away the
associated host route and leaving no routing table entry to talk to
the 172.16.0.14 address.
So I don't think the old was was really safe after all :-/
|
Definitely true. An ideal solution would involve some type of
reference count for the route entry to maintain connectivity
without attempting to add a duplicate route which would always
cause an error.
It would be even easier if users didn't setup redundant addresses
like this one which serve no purpose! The people who do it,
however, are also the most likely to think the resulting error
indicates an actual problem with the new address assignment.
Stephen
------------------
Stephen Macmanus #include <std_disclaimer.h>
stephenm@bayarea.net
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-arch" in the body of the message |
|
| Back to top |
|
|
Brian Somers
*nix forums beginner
Joined: 04 Apr 2002
Posts: 14
|
| Posted: Fri Apr 05, 2002 1:08 am Post subject:
Re: Your change to in.c to limit duplicate networks is causing trouble
|
|
|
| Quote: | The code now avoids adding a host route if the interface address is
0.0.0.0, and always treats a failure to add a host route as fatal
(previously, it masked EEXIST for some reason - I guessed because it
was trying to handle address re-assignment, but that works ok with
this patch).
One effect of the masked EEXIST is to suppress the spurious error
which occurs when adding an alias IP address (SIOCAIFADDR) on the
same logical subnet as an existing IP address. Users have no way
of knowing that it's actually safe to simply ignore the error in
that situation, so the masking should probably be preserved.
Hmm, thanks for the pointer.
I think this now works - where it didn't before (although see
the new patch posted in response to Joergs mention of the sppp
problem).
The lack of the EEXIST hack in my patch means that this will work as
before:
ifconfig dc0 inet 172.16.0.5 netmask 0xffffff00
ifconfig dc0 inet 172.16.0.11 netmask 0xfffffff8
Where connections to 172.16.0.1-172.16.0.7 and 172.16.0.16-172.16.0.255
come from 172.16.0.5 and connections to 172.16.0.8-172.16.0.15 come from
172.16.0.11.
After the above however,
ifconfig dc0 inet 172.16.0.14 netmask 0xfffffff8
will (correctly) fail in the patched code. It fails because the
gateway/netmask combination produces a duplicate key in the routing
table, returning an error from rtinit(). Previously, this failure
was masked by the EEXIST hack, allowing the interface address update
without a corresponding host route.
All true. However, this change just redefines the desired behavior
in this situation. The current EEXIST hack prevents a "meaningless"
error message (in the sense that it is still possible to use the
172.16.0.14 address due to the existence of the earlier route).
This patch just restores the original behavior from earlier BSD
versions which reported an error for the reasons you mention.
I guess it's just a judgement call as to which one is more desirable.
I believe the old behaviour becomes obviously wrong when someone then
deletes the 172.16.0.11 interface address, blowing away the
associated host route and leaving no routing table entry to talk to
the 172.16.0.14 address.
So I don't think the old was was really safe after all :-/
Definitely true. An ideal solution would involve some type of
reference count for the route entry to maintain connectivity
without attempting to add a duplicate route which would always
cause an error.
It would be even easier if users didn't setup redundant addresses
like this one which serve no purpose! The people who do it,
however, are also the most likely to think the resulting error
indicates an actual problem with the new address assignment.
|
Well, it does serve a purpose - it allows the machine to accept
tcp connections on the .14 address (although udp requests get nicely
confused) and to bind to the .14 address before connect().
The resulting error *does* indicate that there's a problem with the
new address assignment; adding that .14 address with a conflicting
netmask should be considered wrong (and is treated as an error when
the EEXIST hack is removed). If they want to add another address to
the 172.16/28 subnet, they must use a netmask of 0xffffffff to get
the desired result.
The EEXIST hack is just permitting people to confuse themselves.
--
Brian <brian@freebsd-services.com> <brian@Awfulhak.org>
http://www.freebsd-services.com/ <brian@[uk.]FreeBSD.org>
Don't _EVER_ lose your sense of humour ! <brian@[uk.]OpenBSD.org>
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-arch" in the body of the message |
|
| Back to top |
|
|
Guest
|
| Posted: Tue Apr 09, 2002 8:06 pm Post subject:
Re: kern/33904: secure mode bug
|
|
|
Bug is in the code.
Perpetuated by policy error.
Silent DWIM/failure is never acceptable policy in any API.
Suggest this kludge be documented as a temporary security measure
with a specific termination date, e.g. Monday 6 February 2006
to give app writers four years to fix their code
after which the emergency broken kernel
can be restored to normal.
Cheers
--Devon
/"\
\ / ASCII Ribbon Campaign
X Help Cure HTML Mail
/ \
PS: I do not advocate any specific solution to the current defect,
there are many choices and I'm sure I haven't thought of them all,
here's one: Accept small changes, reject large ones. Giving the
caller half a time change is like giving the mom half a baby.
Apps can learn to ask for small time changes.
Some guiding principles:
* API quality is paramount
* Silent failure is never ok
* Silent DWIM is even worse
* necessity is not divinity (repent for we are all kludgers)
Most C coders ignore error status anyway,
maybe a clean UNIX system is a lost cause,
still no excuse for the current DWIM hack,
pure poison to allow UI kludges in the API,
blurring the concept of success or failure.
Date: Tue, 9 Apr 2002 11:02:55 -0700 (PDT)
From: <nsayer@FreeBSD.org>
Synopsis: secure mode bug
State-Changed-From-To: analyzed->feedback
State-Changed-By: nsayer
State-Changed-When: Tue Apr 9 11:01:58 PDT 2002
State-Changed-Why:
This is not a problem with the code, but rather the documentation.
I've asked for help in getting the man page fixed, but not heard
anything back.
http://www.freebsd.org/cgi/query-pr.cgi?pr=33904
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-arch" in the body of the message |
|
| Back to top |
|
|
Bill Fenner
*nix forums beginner
Joined: 21 Apr 2002
Posts: 13
|
| Posted: Sun Apr 21, 2002 4:26 pm Post subject:
Re: Overflowing sockaddr_dl's sdl_data buffer
|
|
|
I think that sdl_data should go back to being a variable-length buffer,
and the source routing stuff should be reimplemented somewhere else
(perhaps at the end of the variable-length buffer).
What uses the source-routing fields?
Bill
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-arch" in the body of the message |
|
| Back to top |
|
|
Terry Lambert
*nix forums Guru
Joined: 19 Mar 2002
Posts: 434
|
| Posted: Mon Apr 22, 2002 6:33 am Post subject:
Re: Overflowing sockaddr_dl's sdl_data buffer
|
|
|
Bill Fenner wrote:
| Quote: | I think that sdl_data should go back to being a variable-length buffer,
and the source routing stuff should be reimplemented somewhere else
(perhaps at the end of the variable-length buffer).
What uses the source-routing fields?
|
I know of several "script kiddie" tools which use it. Most sane
people turn it off on their routers, so mostly the tools don't work.
-- Terry
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-arch" in the body of the message |
|
| Back to top |
|
|
Bill Fenner
*nix forums beginner
Joined: 21 Apr 2002
Posts: 13
|
| Posted: Mon Apr 22, 2002 2:10 pm Post subject:
Re: Overflowing sockaddr_dl's sdl_data buffer
|
|
|
This is link-layer source routing; AFAIK only possible on token ring
LANs.
Bill
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-arch" in the body of the message |
|
| Back to top |
|
|
LUDWIG
*nix forums beginner
Joined: 23 Apr 2002
Posts: 1
|
| Posted: Tue Apr 23, 2002 12:46 pm Post subject:
Re:Pocitnice
|
|
|
Si želite oddiha ??
.....se odpravljate na dopust pa ne veste kam ??.....
HRVAŠKA ? ČRNA GORA?
Vabimo vas, da nas obiščete na naših spletnih straneh in si ogledate
našo pestro ponudbo ali pa nas obiščete v naši poslovalnici v Šentjanžu ali v Ljubljani.
Ponujamo vam najugodnejše potovalne aranžmaje na hrvaško in črnogorsko obalo.
7 dnevni polpenzion že od 18.00 SIT. Možnost najema apartmaja. Možno plačilo na več obrokov.
Trenutno akcija za prvomajska letovanja......
Pa kaj bi naštevali, prepričajte se sami. Neverjetno nizke cene počitnic.
Z veseljem vas pričakujemo na naslovu:
http://www.agencijasonja-sp.si
ali na tel.št 01/426 72 52
Lep pozdrav
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-arch" in the body of the message |
|
| Back to top |
|
|
Doug Barton
*nix forums addict
Joined: 24 Apr 2002
Posts: 91
|
| Posted: Wed Apr 24, 2002 7:22 pm Post subject:
Re: IP port ephemeral range
|
|
|
[ Re-directing to -arch to get a wider audience involved. ]
On Tue, 23 Apr 2002, Mike Silbersack wrote:
| Quote: |
On Tue, 23 Apr 2002, Doug Barton wrote:
Mike,
I appreciate your eagerness to get this change out to our
userbase, but I really think it's too big a change for releng_4. I
personallly would really like to see the whole thing backed out in that
branch, and give the code time to gel in -current. What do you think?
I think you stated it best a few days ago, Doug:
"I'm really beginning to sympathize with obrien's perspective that
doing anything useful around here isn't worth having to put up with the
kibitzing."
|
Funny you should quote that... while I still believe that it's
true, I eventually realized that _some_ of the kibitzing was valid, and
that some of the changes I merged into -stable were too much, so I backed
them out.
| Quote: | I'm happy to work with Paul. He has stated a valid complaint, and
has helped to determine what an acceptable solution would be. However, I
can't hold up MFCing changes forever just because people believe that
releng_4 should never change.
|
I am not suggesting that, nor do I believe it. In fact, quite the
opposite, I'm a vigorous campaigner for mfc's, especially during this
loooong development cycle for 5.0. However, I am concerned that the change
you've pushed through is too much of a POLA violation, if it's even a good
idea.
This change hasn't been put in a release yet, so it's not too late
to back it out of releng_4 with minimal disruption to the users.
| Quote: | The idea of just leaving such a change in -current for comment isn't
working. The change which started this debate was commited to current
over a month ago. Aside from Peter, I heard very little comment before
the change was MFC'd.
|
I've already apologized once for missing this discussion. I can't
imagine I'm the only one who did.
| Quote: | We have a month-long code freeze coming up, that should be more than
enough time for the changes to get tested.
|
Given that this is still a work in progress, I don't think one
month is enough. We are relying heavily on the 4.x branch to be something
users can cling to while we finish the 5.0 development. I think that this
is the wrong time for a change like this, even if you do get the bugs
worked out of -current.
--
"We have known freedom's price. We have shown freedom's power.
And in this great conflict, ... we will see freedom's victory."
- George W. Bush, President of the United States
State of the Union, January 28, 2002
Do YOU Yahoo!?
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-arch" in the body of the message |
|
| Back to top |
|
|
Garance A Drosihn
*nix forums Guru Wannabe
Joined: 21 Mar 2002
Posts: 190
|
| Posted: Thu Apr 25, 2002 10:11 pm Post subject:
Re: diff & patch problem with 'No newline'
|
|
|
Back in February, there was a discussion on the freebsd-standards
list about the behavor of freebsd's 'diff' and 'patch' with
respect to files which do not have a final newline character.
The latest gnu-diff command will create a patch which includes
the line:
\ No newline at end of file
if the last line of the file is changed, and if it does not
have a newline character. Our 'diff' does not do this,
because we specifically changed it to not do this. This was
done because our older version of patch does not know what
to do with the line. Back at the time, I blithely said:
At 11:20 PM -0500 2/9/02, Garance A Drosihn wrote:
| Quote: | At 4:01 AM +0000 2/10/02, Tony Finch wrote:
It is also useful to refer to `patch` when we talk about
`diff`, since the former is defined (in SUS) in terms of
the latter. And you also must consider how these tools
interact with the revision management systems that the
project uses.
This is true. As I mentioned, if we need to fix patch to
understand the extra line, then we should do that. Chances
are we should do that anyway, in case someone sends us a
patch generated from the diff on the list of operating
systems I listed as 'group 5'.
If no other operating system had this extra marker line,
then I would be reluctant to have FreeBSD add it. However,
given how much of the unix world considers that extra line
as "standard", including the two other BSD's, then I think
it's a good idea for us to also support it.
|
And now, a mere two months later, I finally looked into it.
Changing 'diff' is trivial, but the main issue is changing
'patch' to match.
I found out that NetBSD had made changes to 'patch' so it
does understand these lines. I copy&pasted those changes
into our version, and it looks like it works right. The
patch is pretty straightforward, and I would like to get
it into our patch in for 4.6-release (along with the minor
change to 'diff'). Any objections?
--
Garance Alistair Drosehn = gad@gilead.netel.rpi.edu
Senior Systems Programmer or gad@freebsd.org
Rensselaer Polytechnic Institute or drosih@rpi.edu
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-arch" in the body of the message |
|
| Back to top |
|
|
Garance A Drosihn
*nix forums Guru Wannabe
Joined: 21 Mar 2002
Posts: 190
|
| Posted: Thu Apr 25, 2002 10:16 pm Post subject:
Re: diff & patch problem with 'No newline'
|
|
|
At 8:11 PM -0400 4/25/02, Garance A Drosihn wrote:
| Quote: | The patch is pretty straightforward, and I would like to
get it into our patch in for 4.6-release (along with the
minor change to 'diff'). Any objections?
|
I guess it would help if I showed what the patch is...
NetBSD has apparently been running with this for a
few weeks.
Index: pch.c
===================================================================
RCS file: /home/ncvs/src/gnu/usr.bin/patch/pch.c,v
retrieving revision 1.17
diff -u -r1.17 pch.c
--- pch.c 2 Aug 2000 06:54:21 -0000 1.17
+++ pch.c 26 Apr 2002 00:14:33 -0000
@@ -434,6 +434,30 @@
/* about as informative as "Syntax error" in C */
}
+/*
+ * True if the line has been discarded (i.e. it is a line saying
+ * "\ No newline at end of file".)
+ */
+static bool
+remove_special_line(void)
+{
+ int c;
+
+ c = fgetc(pfp);
+ if (c == '\\') {
+ do {
+ c = fgetc(pfp);
+ } while (c != EOF && c != '\n');
+
+ return TRUE;
+ }
+
+ if (c != EOF)
+ fseek(pfp, -1, SEEK_CUR);
+
+ return FALSE;
+}
+
/* True if there is more of the current diff listing to process. */
bool
@@ -641,6 +665,15 @@
p_end--;
return FALSE;
}
+ if (p_end == p_ptrn_lines)
+ {
+ if (remove_special_line()) {
+ int len;
+
+ len = strlen(p_line[p_end]) - 1;
+ (p_line[p_end])[len] = 0;
+ }
+ }
break;
case '\t': case '\n': /* assume the 2 spaces got eaten */
if (repl_beginning && repl_could_be_missing &&
@@ -768,6 +801,14 @@
assert(fillsrc==p_end+1 || fillsrc==repl_beginning);
assert(filldst==p_end+1 || filldst==repl_beginning);
}
+
+ if (p_line[p_end] != NULL)
+ {
+ if (remove_special_line()) {
+ p_len[p_end] -= 1;
+ (p_line[p_end])[p_len[p_end]] = 0;
+ }
+ }
}
else if (diff_type == UNI_DIFF) {
long line_beginning = ftell(pfp);
@@ -865,6 +906,12 @@
p_Char[fillsrc] = ch;
p_line[fillsrc] = s;
p_len[fillsrc++] = strlen(s);
+ if (fillsrc > p_ptrn_lines) {
+ if (remove_special_line()) {
+ p_len[fillsrc - 1] -= 1;
+ s[p_len[fillsrc - 1]] = 0;
+ }
+ }
break;
case '=':
ch = ' ';
@@ -900,6 +947,12 @@
p_Char[filldst] = ch;
p_line[filldst] = s;
p_len[filldst++] = strlen(s);
+ if (fillsrc > p_ptrn_lines) {
+ if (remove_special_line()) {
+ p_len[filldst - 1] -= 1;
+ s[p_len[filldst - 1]] = 0;
+ }
+ }
break;
default:
p_end = filldst;
@@ -975,6 +1028,12 @@
p_len[i] = strlen(p_line[i]);
p_Char[i] = '-';
}
+
+ if (remove_special_line()) {
+ p_len[i-1] -= 1;
+ (p_line[i-1])[p_len[i-1]] = 0;
+ }
+
if (hunk_type == 'c') {
ret = pgets(buf, sizeof buf, pfp);
p_input_line++;
@@ -1006,6 +1065,11 @@
}
p_len[i] = strlen(p_line[i]);
p_Char[i] = '+';
+ }
+
+ if (remove_special_line()) {
+ p_len[i-1] -= 1;
+ (p_line[i-1])[p_len[i-1]] = 0;
}
}
if (reverse) /* backwards patch? */
--
Garance Alistair Drosehn = gad@gilead.netel.rpi.edu
Senior Systems Programmer or gad@freebsd.org
Rensselaer Polytechnic Institute or drosih@rpi.edu
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-arch" in the body of the message |
|
| Back to top |
|
|
Mike Barcroft
*nix forums beginner
Joined: 03 Apr 2002
Posts: 25
|
| Posted: Thu Apr 25, 2002 11:00 pm Post subject:
Re: diff & patch problem with 'No newline'
|
|
|
Garance A Drosihn <drosih@rpi.edu> writes:
| Quote: | And now, a mere two months later, I finally looked into it.
Changing 'diff' is trivial, but the main issue is changing
'patch' to match.
I found out that NetBSD had made changes to 'patch' so it
does understand these lines. I copy&pasted those changes
into our version, and it looks like it works right. The
patch is pretty straightforward, and I would like to get
it into our patch in for 4.6-release (along with the minor
change to 'diff'). Any objections?
|
Yes. I still maintain that files without a trailing new line are not
"text files", and should therefore be treated as binary files. Even
if we did consider these to be "text files", no standards that I'm
aware of define the behavior for this situation, so a non-standard
patch utility would be required to interpret these extensions. This
would make our generated diffs unportable in the same way as some of
the other vendors you mentioned as having this feature.
Best regards,
Mike Barcroft
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-arch" in the body of the message |
|
| Back to top |
|
|
Mike Barcroft
*nix forums beginner
Joined: 03 Apr 2002
Posts: 25
|
| Posted: Fri Apr 26, 2002 2:08 am Post subject:
Re: diff & patch problem with 'No newline'
|
|
|
M. Warner Losh <imp@village.org> writes:
| Quote: | There's lots of software (well, OK, subversion) that depends on the
old, historical behavior. The historical behavior of diff has been to
include the "this file doesn't end with a newline" message, not what
FreeBSD hacked it to do.
|
Perhaps the people working on Subversion still have time to fix that
designo before too many people start using it. Solaris 2.5.1, for
instance, returns "Warning: missing newline at end of file" on stderr
for this condition.
Best regards,
Mike Barcroft
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-arch" in the body of the message |
|
| Back to top |
|
|
Garance A Drosihn
*nix forums Guru Wannabe
Joined: 21 Mar 2002
Posts: 190
|
| Posted: Fri Apr 26, 2002 2:12 am Post subject:
Re: diff & patch problem with 'No newline'
|
|
|
At 9:00 PM -0400 4/25/02, Mike Barcroft wrote:
| Quote: | Garance A Drosihn <drosih@rpi.edu> writes:
And now, a mere two months later, I finally looked into it.
Changing 'diff' is trivial, but the main issue is changing
'patch' to match.
I found out that NetBSD had made changes to 'patch' so it
does understand these lines. I copy&pasted those changes
into our version, and it looks like it works right. The
patch is pretty straightforward, and I would like to get
it into our patch in for 4.6-release (along with the minor
change to 'diff'). Any objections?
Yes. I still maintain that files without a trailing new
line are not "text files", and should therefore be treated
as binary files. Even if we did consider these to be "text
files", no standards that I'm aware of define the behavior
for this situation, so a non-standard patch utility would
be required to interpret these extensions.
|
Well, here is a campaign speech for this little patch... :-)
Adding the support to 'patch' will not break any patch
which does follow the standard.
If we revert the change made to 'diff' several years ago,
then I admit we will occasionally create patches that are not
standard. Those patches will be non-standard in a well-known
and easily fixable format. This will create no insurmountable
(or even difficult) problem for anyone who receives the patch.
All a person has to do is delete the one line, and they will
have a patch which behaves exactly the same way as the patch
we currently produce. They can even do this blindly, using a
filter to strip out the line.
So, that's my pitch. I feel fairly strongly that there is a
real advantage in following the lead of Linux (+anyone using
gnu-diff) and NetBSD in this matter. How strongly do others
feel that we should stick to the letter of this standard,
because they feel the standard really has the right idea?
And if you feel that way, then could you please explain to me
what the advantage is? Can you come up with any tangible
benefit of the standard which would convince a linux user to
give up this non-standard extension which they have been
using for at least five years?
--
Garance Alistair Drosehn = gad@gilead.netel.rpi.edu
Senior Systems Programmer or gad@freebsd.org
Rensselaer Polytechnic Institute or drosih@rpi.edu
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-arch" in the body of the message |
|
| Back to top |
|
|
Google
|
|
| Back to top |
|
|
|
|
The time now is Tue Dec 02, 2008 5:59 am | All times are GMT
|
|
Web Advertising | Loans | MPAA | Credit Cards | Discount Magazines
|
|
Copyright © 2004-2005 DeniX Solutions SRL
|
|
|
|
Other DeniX Solutions sites:
Unix/Linux blog |
electronics forum |
medicine forum |
science forum |
|
|
Privacy Policy
|
Powered by phpBB © 2001, 2005 phpBB Group
|
|
FAQ
Search
Memberlist
Usergroups
Register
Profile
Log in to check your private messages
Log in
Forum index
»
*nix
»
BSD
»
FreeBSD
»
mail-lists
»
Architecture
