Re: Bug in qmail port's Makefile, where to report?
Am 19.06.2013 00:38, schrieb Joe Schaefer: I looked on freshports for a way to file a bug report but didn't see anything. Freshports is a second-hand source. The first-hand source is the MAINTAINER line in the Makefile :-) I have a one-character patch to the Makefile that needs incorporation. Any tips for how to contact the ports maintainers for qmail? Mail the maintainer, possibly carbon copying the po...@freebsd.org list so others can patch locally until the maintainer gets around to dealing with the fix. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: Importing tradcpp (traditional (KR-style) C macro preprocessor) into base?
Am 12.06.2013 00:11, schrieb Baptiste Daroussin: Hi, I have been working in importing tradcpp (developped by David A. Holland from NetBSD) into the ports tree, it is a traditional (KR-style) C macro preprocessor BSD licensed. I first worked on it so that imake can work properly without gcc. I discovered that some part of the base system still needs a traditional preprocessor, like (calendar), what I propose it to import tradcpp into the base system (not the version in port right now but what will become version 0.2). It mostly behave like gcpp, and I'm able to properly use calendar along with tradcpp with this small patch: http://people.freebsd.org/~bapt/tradcpp.diff Any objections against me importing it? Shouldn't we fix calendar and imake so that they can use a modern cpp, instead of going back 25 years? Or am I missing the point here? ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: tape (sa0) on sparc64 ?
Am 17.05.2013 02:56, schrieb Zaphod Beeblebrox: On Thu, May 16, 2013 at 8:30 PM, Greg 'groggy' Lehey g...@freebsd.orgwrote: On Thursday, 16 May 2013 at 19:56:14 -0400, Zaphod Beeblebrox wrote: On Thu, May 16, 2013 at 5:08 PM, Bob Bishop r...@gid.co.uk wrote: On 16 May 2013, at 21:51, Zaphod Beeblebrox wrote: [about my tape drive not working] The obvious question: can you write tapes and read them back? My experience with DDS tapes was of extreme unreliability. The age doesn't make things any easier. Well... therein lies my other suspicion. I don't have any DDS4 tapes to try writing, but the DDS3 tapes I have fail to write. ... but they don't even try. The tape spools up when inserted and mt offl works (ejects the tape) and the drive doesn't indicate any error at this point --- but it doesn't even try to start moving for either read or write. Have you used dd, tar, or pax, to actually write data? I suppose newer DDS drives would not actually engage the tape to their head drum until you were actually reading/writing, in order to reduce wear and tear of tape and heads. Not that it helps you now: Personally, after a few first steps with DDS1DC and DDS2, I dropped helical scan stuff because I often found that I could read tapes only on the same drive that had written them (I had three drives around in the late 1990s/early 2000); no matter if the heads were cleaned or not, and I moved on going for for optical disks and linear tape (which includues MLR/SLR, DLT, SuperDLT, LTO; personally I used SLR2, SLR4DC and SLR6 aka SLR24). ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: Providing a default graphical environment on FreeBSD
Am 17.09.2012 21:52, schrieb Lorenzo Cogotti: Even the userbase/time spent developing ratio matters. What also matters is the interest that a system shows in something, I think it's obvious that FreeBSD can't get much attention as a desktop system if no effort is put into it. It is not a bad thing being tied to the server concept, but I just think FreeBSD would also be an excellent desktop system with a little effort. There is Debian/kFreeBSD - Debian on a FreeBSD kernel. Not sure how useful it is, and it probably lacks FreeBSD's userland, but well, just a point. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: Providing a default graphical environment on FreeBSD
Am 17.09.2012 17:35, schrieb Lorenzo Cogotti: Hi, I was wondering about the possibility of FreeBSD to provide an official supported graphical environment. Currently FreeBSD doesn't provide any standard desktop environment, this means that, in a way much similar to Linux, a developer cannot know in advance which GUI will be available on the system. This leads to another problem, again much similar to Linux, tools are usually provided in a text based fashion only, because that's the only sure and reliable way a tool can work in a relatively dependency free and independent way. As another effect, many utilities and graphical tools are provided for a toolkit, but not for another, needlessly duplicating efforts and applications, achieving barely half the result. What is the particular problem? All major toolkits ultimately talk X11, and most applications that I have seen will work in any desktop environment. I for one prefer a reasonable text-tool to a half-baked playful GUI that leaves half of the questions unanswered because the author has no faint clue as to how to properly present a complex technical situation. The idea would be choosing a default desktop environment and providing it as the official supported way to develop GUI applications on FreeBSD, thus tools provided on FreeBSD would be able to get official GUIs and supported graphical tools in a standard and non-redundant fashion, like a GUI for tools like pkgng, geli(8), gpart(8). This choice would also be motivated by the fact that often technologies move toward Linux support, like GNOME3, dbus and consolekit, without taking into account BSD. As though someone cared. End users could not care less, they just want their stuff to work and get the job done. You don't get developers just because you follow an obsolete standard. If you want to make sure that the tools that you'd like to see not move toward[s] Linux support, then (a) make sure they are aware there's more than their favourite Linux distro, (b) help them out. Regarding Linux dependencies, there are few and far between, and most features do not rely on particular kernel support -- and where they do, abstracting that, or providing FreeBSD support, is far more useful than trying to make someone follow a desktop that died a decade ago. Popularity matters in open source. Particularly with desktops. -- Matthias Andree ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: Providing a default graphical environment on FreeBSD
Am 17.09.2012 19:51, schrieb Lorenzo Cogotti: Il 17/09/2012 19:26, Adrian Chadd ha scritto: What are you trying to achieve? Are you trying to write a set of utilities for FreeBSD that are GUI in nature? And you'd like to know which toolkit is blessed for a consistent, integrated feel and development environment? Adrian Right now I was interested in creating a desktop oriented automounter, in order to experiment with devd (I don't know if something useful will actually come out of it). I then faced the problem that there are lots of GUI toolkits, lots of scenarios to take into account, lots of desktop environments available, basically the problem is the same that Linux has with its non existing userland. Meaning that you have not separated the issues that matter: (A) the actual automounting stuff, with details such as user permissions, (B) from the graphical presentation, (C) from the integration into desktops. These are segregated concerns! The XDG and freedesktop stuff, like it or not, managed to get some arrangements made that are followed by GNOME and KDE, for instance. Oh, and yes, someone has to make choices and decisions here. If you want to continue letting people choose freely, this will not ever change. A FreeBSD project (like geli or gpart) could even go as far as providing an official GUI utility next to the text based utility, without hoping for the specific desktop project to provide it (like devd integration). Who cares - the stuff you name is required so early in the boot process that you will create a nice hen-and-egg problem around which file system you have the gazillion of GUI files in. And possibly providing a working abstraction that just has a sane API is far more useful than any of your talk about graphics and desktops. -- Matthias Andree ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: dtrace in FreeBSD 7.2
Am Freitag, den 16.09.2011, 14:30 -0600 schrieb Charlie Martin: I need to add some custom static dtrace probes in 7.2 apps; the online documentation refers only to 9 however. Can someone tell me how to replace what's done in bsd.dtrace.mk for 7.2? FreeBSD 7.2 is quite old and wasn't under extended support, hence it is no longer supported. Consider upgrading. -- Matthias Andree ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: [PATCH] __FreeBSD_cc_version in sys/cdefs.h
Am 05.07.2011 12:11, schrieb Dimitry Andric: On 2011-07-04 18:30, Robert Millan wrote: This patch fixes a (harmless) warning whensys/cdefs.h is parsed by upstream version of GCC. -#if __FreeBSD_cc_version = 31 defined(__GNUC__) !defined(__INTEL_COMPILER) +#if defined(__FreeBSD_cc_version) __FreeBSD_cc_version = 31 defined(__GNUC__) !defined(__INTEL_COMPILER) As far as I can see, this code only gives warnings when compiled with gcc 4.5 or higher, and when using the -Wundef flag. Isn't it easier to just remove the -Wundef flag here? Additionally, it looks like the C standard is a bit vague about whether the preprocessor uses short-circuited boolean evaluation (although gcc's manual says it does), so I'm not sure whether this patch solves the problem properly either. The CPP #if argument is a /constant-expression/, according to KR's The C Programming language 2nd ed., so it shall short-circuit. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: [PATCH] Remove -nostdinc in aicasm
Am 02.07.2011 17:25, schrieb Benjamin Kaduk: On Sat, 2 Jul 2011, Robert Millan wrote: The userland aicasm utility in sys/dev/aic7xxx/aicasm/Makefile is being built with -nostdinc -I/usr/include options. Unfortunately this breaks building aicasm on systems using the upstream version of GCC, where -nostdinc disables more search directories than are enabled by -I/usr/include. There is a functional difference between '-nostdinc -I/usr/include -I.' even when the standard include search path is just /usr/include -- the standard include paths are always searched last (unless -nostdinc is given), even if they are explicitly listed on the command line. If there are conflicting definitions in /usr/local/foo.h and ./foo.h, this gimmick can be necessary to pull in the correct version. (I've needed to do this when packaging software for the freebsd ports collection, though with /usr/local/include replacing '.'.) Note that there are GCC-version-specific directories for the more intricate details such as stdarg.h and compiler-specific builtins -- you don't get those with -I/usr/include either. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: IPv4 socket bind using IPv6 socket on openjdk6 breaks udp send
Am 25.06.2011 13:28, schrieb Steven Hartland:
- Original Message - From: Matthias Andree
matthias.and...@gmx.de
I'm adding back in -java as based on you comments it may well be
something in the jdk passing invalid values down to the kernel
syscall.
The socket bind works fine and the packets sent to the server arrive
and are processed by the app but when it tries to reply using
send the result is:-
java.io.IOException: Invalid argument
at java.net.PlainDatagramSocketImpl.send(Native Method)
at java.net.DatagramSocket.send(DatagramSocket.java:629)
using truss we see the following:-
socket(PF_INET6,SOCK_DGRAM,0)= 20 (0x14)
setsockopt(0x14,0x29,0x1b,0x7edf0318,0x4,0x0) = 0 (0x0)
setsockopt(0x14,0x,0x20,0x7edf031c,0x4,0x0) = 0 (0x0)
bind(20,{ AF_INET6 [3800::10:0:0:0]:20736 },28) = 0 (0x0)
..
sendto(20,\M^?\M^?\M^?\M^?I\aMultiplay :: ...,82,0x0,{ AF_INET6
[3800::10:0:0:0]:20736 },0x1c) ERR#22 'Invalid argument'
You're trying to send to your own address, but you're likely not using
the loopback interface for that. Is that permitted by your firewall
configuration and routing?
No I'm not its replying to the sender.
Yes you are, check your trace: The sendto address and port are the same
as the bound address.
In the java code we have:-
socket.send( new DatagramPacket( data, data.length,
src.getSocketAddress() ) );
Where src is the src packet. This works fine on IPv4 only machines and
when the jdk is told to use only IPv4 stack. So its not a problem with
the java code itself but could well be an issue with the
What data type is it?
sockstat shows it binding correctly
root java 894 21 tcp4 85.236.109.212:25675 *:*
This is unrelated, as it has fd #21 not #20 as in the socket/bind/sendto
calls. You've quoted the wrong line from sockstat output.
Oops sorry cut and paste error (wrong line) heres the correct line.
root java 894 20 udp4 85.236.109.212:25675 *:*
While a datagram socket, it does not match the socket()/bind() above.
An INET6-domain datagram socket would be listed as udp6 here. Are you
sure you're tracing the right VM and are looking at the right thread?
If so, is the incriminated traffic actually going through socket #20?
Is src.getSocketAddress() actually returning an IPv6 address?
SocketAddress is an abstract class. For my lack of Java knowledge: are
there any automatic type promotions on the Java side?
What's the Java code for binding to the socket and fetching the query
packet?
The jvm automatically sets this on all sockets for compatibility for
this exact reason. I'm not rulling out an issue with the IPv6 - v4
routing in the kernel though.
That is prohibited, so there isn't IPv6 - IPv4 routing. All IPv6
traffic remains in the IPv6 domain.
Are you sure that's what you seeing? It's not a match for what you give
above, but anyways it's an implementation artifact because the tcp code
for v4 and v6 used to be shared and the udp code separate.
Thats not how the jdk works, its ment to be 100% transparent but isn't.
You mean the JRE.
It is best to set up one IPv4 and one IPv6 listening socket.
I don't believe there is any way to do this in java it either uses the
IPv4 stack only or the IPv6 stack only hence relies on the kernel
routing IPv4 packets through the IPv6 stack.
Thats the reason the jdk explicitly enables this for all the ports it
creates, which was added as a back port of the jdk7 fixes which can
be seen here:-
http://www.freebsd.org/cgi/cvsweb.cgi/ports/java/openjdk6/files/patch-set
Check the URL above, perhaps that helps your understanding a bit. I
presume 3800::10:0:0:0 is your server?
Not that I'm aware of, here's the output from ifconfig if anyone can
tell me different, as I'm new to IPv6 and don't follow how its mapped
yet.
ifconfig
igb0: flags=8843UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST metric 0 mtu 1500
options=1bbRXCSUM,TXCSUM,VLAN_MTU,VLAN_HWTAGGING,JUMBO_MTU,VLAN_HWCSUM,TSO4
ether 00:25:90:2c:3c:b0
inet 85.236.109.212 netmask 0xff00 broadcast 85.236.109.255
inet6 fe80::225:90ff:fe2c:3cb0%igb0 prefixlen 64 scopeid 0x1
inet6 2001:4db0:20:2::1337 prefixlen 64nd6
The 2001:something is your local address. If you bind to 3800::
something that won't work. You couldn't bind an IPv4 address of
10.9.8.7 on this interface either.
igb1: flags=8802BROADCAST,SIMPLEX,MULTICAST metric 0 mtu 1500
options=1bbRXCSUM,TXCSUM,VLAN_MTU,VLAN_HWTAGGING,JUMBO_MTU,VLAN_HWCSUM,TSO4
ether 00:25:90:2c:3c:b1
media: Ethernet autoselect (1000baseSX full-duplex)
status: active
This iface has no addresses at IP level at all.
lo0: flags=8049UP,LOOPBACK,RUNNING,MULTICAST metric 0 mtu 16384
options=3RXCSUM,TXCSUM
inet 127.0.0.1 netmask 0xff00
inet6 ::1 prefixlen 128
inet6 fe80::1%lo0 prefixlen 64 scopeid 0x3
Re: IPv4 socket bind using IPv6 socket on openjdk6 breaks udp send
Just so we have pointers in the public archives: alternatives to truss are strace (in ports) and ktrace/kdump; and to obtain socket statistics, try lsof (from ports, too) possibly with -i and optionally -n and/or -P option. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: IPv4 socket bind using IPv6 socket on openjdk6 breaks udp send
Removing -java@ list because the VM is an application on top of the
kernel's network stack, and the issue isn't Java-specific.
Am 24.06.2011 23:11, schrieb Steven Hartland:
We're trying to get our machines IPv6 enabled but in doing so this
seems to break java apps using openjdk6 for UDP sends.
The server seems quite happy to send and receive TCP packets on
IPv6 socket that are bound to IPv4 addresses, but the same is not
true for UDP.
Coincidence, and not guaranteed to work, and possibly using IPv4-mapped
IPv4 addresses (i. e. :::10.11.12.13 style).
See the v6-related sections of
http://www.freebsd.org/doc/en/books/developers-handbook/ipv6.html
The socket bind works fine and the packets sent to the server arrive
and are processed by the app but when it tries to reply using
send the result is:-
java.io.IOException: Invalid argument
at java.net.PlainDatagramSocketImpl.send(Native Method)
at java.net.DatagramSocket.send(DatagramSocket.java:629)
using truss we see the following:-
socket(PF_INET6,SOCK_DGRAM,0)= 20 (0x14)
setsockopt(0x14,0x29,0x1b,0x7edf0318,0x4,0x0) = 0 (0x0)
setsockopt(0x14,0x,0x20,0x7edf031c,0x4,0x0) = 0 (0x0)
bind(20,{ AF_INET6 [3800::10:0:0:0]:20736 },28) = 0 (0x0)
..
sendto(20,\M^?\M^?\M^?\M^?I\aMultiplay :: ...,82,0x0,{ AF_INET6
[3800::10:0:0:0]:20736 },0x1c) ERR#22 'Invalid argument'
You're trying to send to your own address, but you're likely not using
the loopback interface for that. Is that permitted by your firewall
configuration and routing?
sockstat shows it binding correctly
root java 894 21 tcp4 85.236.109.212:25675 *:*
This is unrelated, as it has fd #21 not #20 as in the socket/bind/sendto
calls. You've quoted the wrong line from sockstat output.
Note: net.inet6.ip6.v6only was set to the default 1 but changing
it to 0 has no effect on the issue.
You aren't using IPv4 mapped addresses, and you haven't stated whether
you're using wildcard listeners. Only in that case would it matter.
inet6(4) reads:
IPV6CTL_V6ONLY(ip6.v6only) Boolean: enable/disable the prohib-
ited use of IPv4 mapped address on AF_INET6 sock-
ets. Defaults to on.
An ideas why tcp in this setup works fine for udp fails only on
send?
Are you sure that's what you seeing? It's not a match for what you give
above, but anyways it's an implementation artifact because the tcp code
for v4 and v6 used to be shared and the udp code separate.
It is best to set up one IPv4 and one IPv6 listening socket.
Check the URL above, perhaps that helps your understanding a bit. I
presume 3800::10:0:0:0 is your server?
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: Keeping /etc/localtime up-to-date
Am 29.03.2011 09:53, schrieb per...@pluto.rain.com: Matthias Andree matthias.and...@gmx.de wrote: Am 28.03.2011 19:57, schrieb dieter...@engineer.com: I have been running FreeBSD and NetBSD with /etc/localtime being a symlink for years and have not seen any problems as a result. In that case, /etc and /usr/share/timezone (or whatever) need to be in the same physical file system ... If they're in the same physical FS there's no need for a symlink. You might as well use a hardlink. And then discuss how all the time zone configuration tools deal with /etc/localtime - truncate/overwrite, direct overwrite, rename-a-replacement-file and all that. No. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: Keeping /etc/localtime up-to-date
Am 28.03.2011 19:57, schrieb dieter...@engineer.com: And while I (think I) recall that the equivalent of /etc/localtime was implemented in some version of SunOS many years ago as a symlink, I believe that approach could be problematic for FreeBSD, as it could impose some unintended requirements on some of the start-up scripts. I have been running FreeBSD and NetBSD with /etc/localtime being a symlink for years and have not seen any problems as a result. In that case, /etc and /usr/share/timezone (or whatever) need to be in the same physical file system. Adds interesting software effects for those file systems where a directory is a filesystem with its own dev and thereabouts, such as AFS. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: [GSoC] About the idea: Unicode support in vi
Am 23.03.2011 10:13, schrieb Alexey Shuvaev: On Wed, Mar 23, 2011 at 12:39:44AM -0500, Zhihao Yuan wrote: Hi, I'm a Computer Science student at Northern Illinois University, and I used FreeBSD for a long time. I'm interested in the idea that to improve the nvi in the base system. My proposal is slightly different: I want to fork nvi and make it iconv-awared (or mbyte-mode tunable, like tcsh), so that it can deal with more encodings. Can that be a GSoC project proposal? +1 here! ports/editors/nvi-devel is another starting point here. As far as I understand it is a further development of nvi which is in base. What I don't like about it is a dependency on databases/db3 and changed (worse, in my opinion) handling of keystrokes in 'insert' mode. But it is iconv-aware implementation already. nvi-devel is bit-rotten. Most releases date from 2004, and there was a patchlevel-release in 2007 apparently, since then it's been left to bit rot. I'm thinking about just killing databases/db3 and see what happens with nvi-devel. I tried convincing it to work with db41, and while it compiles, it somehow abuses Berkeley DB in a way I don't see during debugging and barfs with Invalid argument on a DB-open call on a recovery file. Also, the documentation says it depends on 3.1, but then we've been using 3.3 for ages, but even the first release of nvi-devel to use Berkeley DB was released when 4.2 was already out. There seems to be some code to make it work (which in itself is buggy it uses broken comparisons for its version checks), but it doesn't work for reasons I don't see with gdb. Berkeley DB doesn't like the way it's being used and errors out with EINVAL. However, I don't care enough to build a debug-enabled version of Berkeley DB to see where abandoned nvi-devel might abuse bdb. vim works for me, supports Unicode, and for fewer dependencies, we have vim-lite. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: [GSoC] About the idea: Unicode support in vi
Am 23.03.2011 16:06, schrieb Alexey Shuvaev: Yes, nvi-devel is not developed any more, but I was saying that nvi in base is even older than nvi-devel, and it is worth looking at it. At least for the iconv support. As for the BDB, maybe strip it just out, if possible? I don't believe it's possible, because it uses a RECNO database that is backed by a text file, i. e. it crucially relies on it for data management apparently. But at least db51 and db42 work fine, apparently it was a db41-specific incompatibility that broke nvi-devel 1.81.6_4. Compiling WITH_BDB_HIGHEST=yes should help for the nonce. We're fixing the port to use 4.2 at least. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: man 3 getopt char * const argv[] - is const wrong ?
Am 15.02.2011 04:19, schrieb Julian H. Stacey: and the SUS is available free of charge, that's Again you fail to post a precise complete URL for free open anonymous reference. One might wonder your involvment with open.org/ISO/IEEE. I don't care to do the searching for you, nor discuss any of this, in particular because you are distracting from your actual getopt(3) concern with random sidesteps. And that's already one more reason that I've given than you've deserved. Let's stick to the technical discussion. language, 2nd edition, then getopt() isn't even in my printed book's index. Yet again: The point is to find the latest specification of C language const Before considering latest getopt(). No it isn't, that is another of your distractions. The explanations about const are all there and you haven't yet clarified your concern about const-ness of the argv pointers in said getopt argument. I don't care about policies, standardization, affiliations, unless you document the technical concern that you see in the const in getopt()'s char * const argv[] argument. And before that happens I'm not even interested in a pseudo-technical discussion. Try comp.lang.c for a change. -- Matthias Andree ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: man 3 getopt char * const argv[] - is const wrong ?
Am 16.02.2011 19:31, schrieb Julian H. Stacey: Bruce Cran wrote: It seems registration is required for the SUS, but you can get POSIX.1-2008 free at http://pubs.opengroup.org/onlinepubs/9699919799/ . Thanks Bruce. I browsed it but couldn't find a C spec. Opengroup.org server restricted the URL to a constant: http://pubs.opengroup.org/onlinepubs/9699919799/nframe.html Depends on your browser features - you need a frame-capable browser for the URL that Bruce posted. But POSIX.1-2008 is the same as the Single Unix Specification v4 or IEEE Std 1003.1-2008. Neither gives you the C specification. Hoping for full URLs (or more) I tried: http://ieeexplore.ieee.org/xpl/mostRecentIssue.jsp?reload=truepunumber=4694974 It needed a login. I created one. IEEE harvested my address then responded: Full text access is unavailable with your individual subscription IEEE does, quite obviously, not have ISO standards. -- Matthias Andree ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: man 3 getopt char * const argv[] - is const wrong ?
Am 16.02.2011 20:02, schrieb Joerg Sonnenberger: On Wed, Feb 16, 2011 at 07:41:02PM +0100, Matthias Andree wrote: But POSIX.1-2008 is the same as the Single Unix Specification v4 or IEEE Std 1003.1-2008. Minor correction, it is SUS v3 Issue 7. No it isn't. See http://www.unix.org/version4/ieee_std.html -- Matthias Andree ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: man 3 getopt char * const argv[] - is const wrong ?
Am 16.02.2011 21:13, schrieb Joerg Sonnenberger: On Wed, Feb 16, 2011 at 08:26:04PM +0100, Matthias Andree wrote: Am 16.02.2011 20:02, schrieb Joerg Sonnenberger: On Wed, Feb 16, 2011 at 07:41:02PM +0100, Matthias Andree wrote: But POSIX.1-2008 is the same as the Single Unix Specification v4 or IEEE Std 1003.1-2008. Minor correction, it is SUS v3 Issue 7. No it isn't. See http://www.unix.org/version4/ieee_std.html POSIX.1-2008 is simultaneously IEEE Std 1003.1™-2008 and The Open Group technical Standard Base Specifications, Issue 7. Let's agree on that :) http://pubs.opengroup.org/onlinepubs/9699919799/mindex.html Fine. :) Note that The Open Group Technical Standard Base Specifications isn't the same as the Single Unix Specification. -- Matthias Andree ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: man 3 getopt char * const argv[] - is const wrong ?
Am 14.02.2011 03:41, schrieb Julian H. Stacey: Well, instead of ranting, An inadvisable epithet ! Maybe you never had the luxury of working when one could buy a slim KR, it was all one needed. Now ISO sell standards, Not all free download. For C I've only found enormous PDFs. Some downloads may not be newest/or might need logins or license or payment. Apache.org set a better example of free unobstructed hypertexted access to all versions of eg http.conf etc. Where have you been living the past two decades? It's been a not so recent development that small language cores (C, Java) are accompanied by humongous amounts of documentation for standard libraries... I understand the concerns about licensing, yet I see standards as reference material, and the SUS is available free of charge, that's about as much as I care for the current discussion. Take the political parts up with the respective entities and/or possibly the FreeBSD foundation. Using Unix C since '77, '82, I 'appreciate' C is a heavily evolved = bent language. Const as case in point: FreeBSD getopt seems to conflict with KR#2 so ... If KR #2 is supposed to be Kernighan Ritchie, The C Programming language, 2nd edition, then getopt() isn't even in my printed book's index. It would be nice to download a new C standard for reference. Is Yes. the newest definition of C free public access ? Is there a URL I never bothered to check. Check the final drafts that are getting voted becomes standard yes/no on, they are usually free. -- Matthias Andree ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: man 3 getopt char * const argv[] - is const wrong ?
Am So, 13.02.2011, 13:20 schrieb Julian H. Stacey: Hi Hackers Ref.: man 3 getopt int getopt(int argc, char * const argv[], const char *optstring); Ref.: KR 2nd Ed P.211 last indent, 2nd sentence The purpose of const is to announce [objects] that may be placed in read-only memory, and perhaps to increas[e] opportunities for optimization optstring is obviously const, but I don't see that argv can calim to be const ? Hi Julian, the prototype is in line with the Single Unix Specification v4 aka IEEE Std. 1003.1-2008 (sorry no URL, I have checked my local copy, check http://www.opengroup.org/ you can access it free of charge after registering name and email address). The const basically states that the argv[] elements (i. e. the char * pointers) are const[ant], or, read another way, that getopt promises not to mess with the *pointers* but is free to modify the actual strings pointed to (with the usual constraints of not assuming they can be extended, for instance) - and I don't see the problem in that. Does that help? If not, please explain you confusion in a bit more detail. Best Matthias -- Matthias Andree ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: man 3 getopt char * const argv[] - is const wrong ?
Am 13.02.2011 18:15, schrieb Julian H. Stacey: Hi, Thanks to all respondents, I'll re-read comments in a bit, I went searching for reference: Matthias wrote: the prototype is in line with the Single Unix Specification v4 aka IEEE Std. 1003.1-2008 (sorry no URL, I have checked my local copy, check http://www.opengroup.org/ you can access it free of charge after registering name and email address). Thanks, but I didn't find it. Julian, Deep link sent off-list. Start page http://www.unix.org/online.html - sorry that the opengroup.org links led you onto long-winded detours. ( I used X Open's Search but wan't easy, (I recall fat green cardboard boxes from XOpen 20+ years back) : impression remains: opaque unattractive. Part of the attraction of C was a slim light affordable volume, 1cm thick, well written, 2 indexes, easy reading, carrying reference :-) Well, instead of ranting, you might just appreciate the difference between the core language and ANSI-C (1989/1990) standard library features, and the enhanced environment that Unix provides nearly two decades later... Try gcc -std=c89 -pedantic-errors on your average Unix software for a change... :) HTH Matthias ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: [PATCH] Add HISTORY to strlen(3) and strstr(3) man pages
Am 04.12.2010 12:33, schrieb Marin Atanasov Nikolov: Hello, Could someone review the attached patches and possibly commit them? The patches add HISTORY for the strstr(), strnstr(), strlen() and strnlen() functions. Thanks, Marin I find it hard to believe the versions especially for strstr and strlen. -- Matthias Andree ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: Coverity warning: strncpy(cpi-dev_name, cam_sim_name(sim), DEV_IDLEN);
Alfred Perlstein schrieb: I notice this code sprinkled through the sources: strncpy(cpi-dev_name, cam_sim_name(sim), DEV_IDLEN); This trips up coverity because it does not know for sure that the string returned by cam_sim_name() is going to be DEV_IDLEN-1 characters long. Right. strncpy/strncat are examples for features that the C standards libc had better not ever had, similar to [f]gets... Should we switch these calls to strlcpy? Is there a smarter thing to do to code more defensively? if dev_name is a vector of char or equally sized types: (cpi-dev_name)[DEV_IDLEN-1] = '\0'; However, rather than relying on implicit assumptions and inefficiencies, I'd still prefer memset + strlcpy. -- Matthias Andree ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: regenerating /var/db/pkg
Am 22.04.2010 14:49, schrieb Diane Bruce:
On Tue, Apr 20, 2010 at 10:11:24PM -0400, Aryeh M. Friedman wrote:
I acciddentally rm'ed my /var/db/pkg and want to know is it possible to
rgenerate it (I have portmaster and portupgrade installed)
You would have to write a script which went through each file in
/usr/local/bin and /usr/local/lib (mostly sufficient) and examined
every single pkg-plist looking for the corresponding file. Then you
know what port the file was generated by. Needless to say, this would
be somewhat horrible.
Diane,
it's not *that* bad. Consider this algorithm:
1. scan for files under /usr/local/{bin,include,lib,libexec,sbin} and sort or
hash the list - perhaps guess just a port name from an executable in
/usr/local/bin
2. Repeat:
2.1 use the next file from the list and search for it
2.2 once you have a port name for this file, obtain the packing list and
remove it from the file list in 1. This cuts down the list from 1 quite a bit.
3. Now print the list of ports found,
and print the list of files not found in ports
Surely and index of plist files in port default configurations could help big
time, but even a blunt ( cd /usr/ports find . -mindepth 3 -maxdepth 3 -name
pkg-plist -exec egrep FILENAME '{}' + ) might be reasonable given sufficient RAM
so that it runs from cache for the 2nd file you inquire.
If that is too slow, a step between 1 and 2 could procure all pkg-plists as some
sort of FILEINDEX file to accelerate searches.
HTH
Matthias
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: To sendmail or to postfix that is the question?
Dag-Erling Smørgrav wrote on 2010-03-11: Matthias Andree matthias.and...@gmx.de writes: sendmail's configuration was never a black art unless you needed features beyond what the m4 macro set supported. The m4 macro set is a fairly recent development. If more than a decade is a fairly recent development, then you're right. -- Matthias Andree ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: To sendmail or to postfix that is the question?
Am 10.03.2010 17:47, schrieb Steven Hartland: Ok so I'm looking to replace our current windows mail server using mdaemon with a FreeBSD solution, having looked around there seems to be differing opinions of which is the best option to go with between sendmail and postfix. The best -- well, you'll know that with hindsight if you've tried both. The problem with looking for info on this is that a lot of the high listed articles in Google etc are from way back when, 2000 - 2007 during which time quite a bit can change. So what are peoples current day experience with the two options? A few key question come to mind:- 1. Has sendmail's config moved away from the black art it once was? 2. Is postfix that much easier? 3. What would people use for: 3.1. POP / IMAP support? 3.2. Web Mail? 3.2. AV / Spam filtering? sendmail's configuration was never a black art unless you needed features beyond what the m4 macro set supported. Instead, it was a matter of reading the README file and the op.* manual, writing/adjusting the .mc files, and grinding the .mc file through m4 to process it into the .cf files. Postfix can be easier to configure, and I personally prefer it over sendmail -- and it appears to have had fewer and milder security issues and a more security-aware design - and it's been faster in my setups. Still you need to understand what you're doing, and Postfix has evolved into a feature-rich MTA, so you don't get to know it in an hour of reading. I've deployed a few postfix + Dovecot + amavisd-new setups; these systems don't need webmail. I used to use sqwebmail on a few sites. -- Matthias Andree ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: 2 bytes allocated problems
Am 24.02.2010, 20:55 Uhr, schrieb Dag-Erling Smørgrav d...@des.no:
Why is there a 0 after the 'i'? Because when you write abcdefghi, the
compiler actually stores abcdefghi\0. That's the definition of
string in C: a sequence of characters immediately followed by a 0. If
you don't want the 0 there, you have to do something like this:
char a[9] = { 'a', 'b', 'c', 'd', 'e', 'f', 'g', 'h', 'i' };
char a[9] = abcdefghi;
suffices. The compiler knows there isn't room for the terminal '\0' and
omits it.
char a[] = abcdefghi;
would append the implicit \0 and reserve 10 bytes for a.
but then you don't have a string, just an array of 9 chars.
Not that the compiler itself could/would tell the difference after
initialization, or that it would even care. It's the library functions
that expect strings that care about the \0.
Beyond that, I recommend a C book to Andrey.
--
Matthias Andree
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
seeking and seekability (was: tar tfv /dev/cd0 speedup patch)
Am 19.02.2010, 06:03 Uhr, schrieb Tim Kientzle kient...@freebsd.org: Joerg Sonnenberger wrote: On Thu, Feb 18, 2010 at 07:34:59PM +0100, Juergen Lock wrote: Ok here is a new version of the patch with these things fixed and the Linux case added: (Linux case not tested yet, and yes I did this on stable/8.) Why the check at all? Shouldn't devices that don't allow seek fail that? E.g. for devices, just try to seek ahead and fallback to normal reading? That was the initial implementation in libarchive, but I had a number of reports of that not working for tape drives. I recently dug out and connected an old DDS drive I had in the closet, so I should probably try again and see if I misunderstood something along the way. I'd already written this in a private email to Tim before I came across this continued discussion on -hackers@, I'll paste a modified version of my own part: I strongly believe that someone should really fix lseek() in FreeBSD outside GEOM. There is precedence, namely http://www.freebsd.org/cgi/query-pr.cgi?pr=kern/60313 and it was never properly fixed. The PR was closed because the actual reported problem on da(4) no longer occurred since FreeBSD 5 after the GEOM migration, and my issue was with da(4) on FreeBSD 4. Now I'm learning that the very same bug persists through -CURRENT nearly a decade later: after lseek devices such as sa(4) will return garbage (i. e. from the unchanged offset) rather than failing. It should be sorted out before 8.1. Am I naive if I expect lseek to return (off_t)-1 with errno == ESPIPE on non-seekable devices? I'll concede that sa(4) is neither socket nor pipe nor fifo in the strict sense, but all share the non-seekability. If lseek() can't know the device isn't seekable, subsequent I/O operations should return EIO along with a proper kernel log message for the first occasion per process, but that would not help applications or libarchive for that matter - they will need a canonical way to find out if a device is seekable. Unfortunately FreeBSD maps many physical block devices that are unbuffered to character special device nodes, so the obvious way of calling [f]stat() and then checking S_ISBLK(st.st_mode) will return FALSE even for devices that can seek. -- Matthias Andree ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: Checksum mismatch -- will transfer entire file
Am 31.12.2009, 16:45 Uhr, schrieb Dimitry Andric dimi...@andric.com: On 2009-12-31 04:32, Victor Sudakov wrote: I cvsup the FreeBSD CVS repository daily from cvsup.ru.freebsd.org. Both the client and the server run CVSup Software version: SNAP_16_1h, Protocol version: 17.0. Recently I noticed that there are lots of messages Checksum mismatch -- will transfer entire file about all kinds of downloaded files, e.g. src/lib/libc/posix1e/acl_delete_entry.c,v: Checksum mismatch -- will transfer entire file I also see a bunch of these, almost every time I do a csup. Looking back in my logs, I see that it goes back until at least 2009-07-05... I suspect (without any proof) that this is only for src, because that is converted from a live SVN repository to CVS for the sake of CVSup distribution, while all other repositories are still CVS natively. -- Matthias Andree ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: Suggestion: rename killall to fkill, but wait five years to phase the new name in
Am 22.12.2009 11:33, schrieb Dag-Erling Smørgrav: man pkill And that one is also provided on Solaris. -- Matthias Andree ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
header file bug sys/types.h sys/file.h vs. _XOPEN_SOURCE standard
Greetings,
this little C program (which is actual a minimum excerpt from
sysutils/e2fsprogs) fails to compile on - among others - 8.0-PRERELEASE:
$ cat fail.c
#define _XOPEN_SOURCE 600
#include sys/file.h
$ gcc -W -Wall -O -c fail.c
In file included from fail.c:2:
/usr/include/sys/file.h:161: error: expected specifier-qualifier-list
before 'u_int'
I can get the code to compile by removing the #define _XOPEN_SOURCE 600.
This happens here:
146 /*
147 * Userland version of struct file, for sysctl
148 */
149 struct xfile {
150 size_t xf_size;/* size of struct xfile */
151 pid_t xf_pid; /* owning process */
152 uid_t xf_uid; /* effective uid of owning process
*/
153 int xf_fd; /* descriptor number */
154 void*xf_file; /* address of struct file */
155 short xf_type;/* descriptor type */
156 int xf_count; /* reference count */
157 int xf_msgcount;/* references from message queue */
158 off_t xf_offset; /* file offset */
159 void*xf_data; /* file descriptor specific data */
160 void*xf_vnode; /* vnode pointer */
!! 161 u_int xf_flag;/* flags (see fcntl.h) */
162 };
The flow here is as follows:
1. sys/file.h (non-standard header) includes sys/types.h (POSIX/XSI
standard header) and implictly sys/cdefs.h
2. since _XOPEN_SOURCE is defined, nonstandard symbols such as u_int
aren't defined by the standard headers (this is in line with IEEE Std
1003.1-2008)
3. sys/file.h uses this non-standard and undefined u_int and breaks.
I've talked to Theodore Y. Ts'o, who is the sysutils/e2fsprogs upstream
maintainer and proposed to remove the _XOPEN_SOURCE definition (my idea
was that the code shouldn't be claiming standards compliance while it uses
non-standard headers), but he refused that (since it would break the
e2fsprogs build on Solaris).
Should non-standard system headers break if an application defines one of
the standard feature test macros? Or could sys/file.h be changed (for
instance by replacing u_int by unsigned int) to tolerate POSIX and XSI
feature test macros?
TIA.
Cheers
--
Matthias Andree
mandree freebsd org
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: kern/99979: Get Ready for Kernel Module in C++
Václav Haisman [EMAIL PROTECTED] writes: Binary compatibility is always a problem, no mater the language used. Besides, doesn't the FreeBSD kernel build system always compile all modules? It can be configured in make.conf if you want only a subset of modules. Deciding that some features are bad beforehand, before you evaluate them is IMO bad idea. Let interested people write a bunch of C++ modules with the complete language before deciding on what shouldn't be used. No, that won't work -- plus you need a bunch of run-time support (libstdc++ isn't exactly something that belongs into the kernel you know). -- Matthias Andree ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: kern/99979: Get Ready for Kernel Module in C++
(please don't Cc me on list replies; chopping down the Cc list) On Tue, 11 Jul 2006, [EMAIL PROTECTED] wrote: Just as you said, C++ is more complicated than C. However, without C++ exception and other advanced features, it hasn't brought much complexity to C++ runtime library. Early C++ compiler even translates C++ code into C code before real compilation. But what's the point of C++ if it is mutilated below minimum standard compliance levels so that you can no longer call it C++? This discussion has been through for other systems such as Linux long ago, and it wasn't lack of manpower, but lack of technical feasibility, or in other words, what was still useful for a kernel wasn't that much different from C any more. C99 already adressed several concerns of C89, and ISTR that FreeBSD kernels are C99 code these days. We can judge whether a C++ feature can or cannot be imported into FreeBSD kernel by assemble code generated by GNU CC. Great, make the whole kernel depend on compiler internals. Can you imagine a single vendor who'd have interest in hauling so many dependencies into their software and handle all the support? I can't. Write a C stub and put the rest into userspace where C++ works. For example, I think C++ exception handling is really poorly suited for low-level code. Which chops off one of C++'s legs to stand on. Well, you can LOOK DOWN UPON me, but I believe you cannot throw doubt on FreeBSD's actuality: so weak USB support (kernel crash easier than many other OSs that we laughed at and that we are laughing at), so weak PCI device support. Talking of USB, have you ever used a USB 2.0 Hi-Speed hub (single TT) with Linux and plugged TWO devices into it and see Linux fail to talk to the device you plugged in later? No? If so, you have zero clue how bad USB support can get. And that's not the only problem Linux USB has had or still has. Please look at files in /sys/pci/ and /sys/dev/*/. Why do so many PCI device drivers repeat: pci_read_config( ... ) ... sc-vr_res = bus_alloc_resource_any( ... ); ... sc-vr_irq = bus_alloc_resource_any( ... ); ... Is this kind of awful writing just of FreeBSD's style? In contrast, with C++, we can avoid many code repeating among device drivers. How would C++ avoid such? Generic programming, RTTI support and such stuff requires an awful lot of compile-time code generation and runtime library support. If we would have constructed an object model in C++, a programmer who master Microsoft MFC, Darwin I/O Kit could easily write a device drive with the device's hardware data sheet. And errata, and talking to the device happens in C-like programming anyways... -- Matthias Andree ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Return value of malloc(0)
Pat Lashley [EMAIL PROTECTED] writes: BUT, that said, the safest and most portable coding practice would be: // The C standard does not require malloc(0) to return NULL; // but whatever it returns MUST NOT be dereferenced. ptr = ( size == 0 ) ? NULL : malloc( size ) ; Safest (avoiding null derefence) would instead be: ptr = malloc(size ? size : 1); BTW: // is not a valid C89 comment, but a GCC-ism. -- Matthias Andree ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Alternative compiler toolchain ?
Dan Nelson [EMAIL PROTECTED] writes: In the last episode (Jul 01), Jean-Marc Lienher said: I've found some other compilers on the web: http://fabrice.bellard.free.fr/tcc/ (LGPL) tcc is very fast, probably has the most modern C parser of the lot, and might even be able to build world except that the shared binaries it generates aren't able to be loaded by our rtld. It looks like tcc only emits the bare minimum to get Linux to run the executable, and I don't know enough about the ELF format to fill in the blanks. I never managed to get tcc compiled stuff (GNU libc or dietlibc) to run under Linux, but haven't pursued the issue beyond that point. -- Matthias Andree ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Return value of malloc(0)
Johannes Weiner [EMAIL PROTECTED] writes: Hi, On Wed, Jun 28, 2006 at 08:10:45PM +0200, Andre Albsmeier wrote: If you use malloc(0) and are crazy enough to access the 'allocated' memory we give you a SIGSEV to show you how dumb you are :-). They should check the return value of malloc() in any case for successful allocation.. shouldn't they? The value returned from malloc(0) must not be dereferenced whatever it was. It was 0x800, which doesn't count as failure. -- Matthias Andree ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Return value of malloc(0)
Johannes Weiner [EMAIL PROTECTED] writes: On Thu, Jun 29, 2006 at 06:09:37PM +0200, Matthias Andree wrote: The value returned from malloc(0) must not be dereferenced whatever it was. It was 0x800, which doesn't count as failure. But this would be appropriate for catching the error: if ((foo = malloc(0)) == foo) /* make noise */ wouldn't it? No, sir. Operator precedence: assign first, and then compare, thus the comparison will always be true (else you'd be comparing to undefined values, which isn't any better). You might as well write: foo = malloc(0); /* make noise */ There is no way to see a 0x800 return from malloc(0) as error. -- Matthias Andree ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Return value of malloc(0)
On Thu, 29 Jun 2006, Harti Brandt wrote: Operator precedence is just for parsing, not for evaluation. The compiler may well first evaluate the foo on the right side of the == (by fetching it) and then go an call malloc and assign foo. Right, thanks for reminding me. I don't usually write code that depends on evaluation order... except with the short-circuiting stuff || or . splint 3.1.1 complains about this issue BTW, but neither GCC 4.1.0 nor ICC 8.1.028 on Linux nor FreeBSD lint complain. I used gcc -Wall which is specified to include -Wsequence-point... It is actually undefined behaviour, I think, so it may well make explode your near-by atom power plant. It had better not... -- Matthias Andree ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
PATCH: fix bogus unset abort in /bin/sh (been pending for TWO YEARS)
[WARNING: Reply-To and Mail-Followup-To set to funnel the discussion.]
Greetings,
FreeBSD's /bin/sh has a long-standing bug that causes premature abort of
a script when set -e is set and a nonexistant variable is unset.
This violates IEEE Std 1003.1 and harms portability of scripts to FreeBSD.
http://www.opengroup.org/onlinepubs/009695399/utilities/unset.html
Either test of these must print good else the shell is b0rked:
/bin/sh -c 'set -e ; BONK= ; unset BONK ; unset BONK ; echo good'
/bin/sh -c 'set -e ; f() { :; } ; unset -f f ; unset -f f ; echo good'
After merging the patch below and MFC'ing, please close standards/45738.
This patch (against 5.3-BETA) fixes the problems for me (yes I know it
is not very helpful without more context but I can't paste half the
files here for the mailing list):
--- src/bin/sh/exec.c.orig Thu Apr 15 05:08:30 2004
+++ src/bin/sh/exec.c Sat Sep 18 13:16:34 2004
@@ -701,7 +701,7 @@
delete_cmd_entry();
return (0);
}
- return (1);
+ return (0);
}
/*
--- src/bin/sh/var.c.orig Thu Apr 15 05:08:31 2004
+++ src/bin/sh/var.cSat Sep 18 13:16:34 2004
@@ -761,7 +761,7 @@
}
}
- return (1);
+ return (0);
}
--
Matthias Andree
Encrypted mail welcome: my GnuPG key ID is 0x052E7D95 (PGP/MIME preferred)
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to [EMAIL PROTECTED]
