Re: how to force all packets to be ipv4 not v6
Mario Lobo l...@bsd.com.br writes: On Sun, 31 Mar 2013 01:20:17 -0400 Aryeh Friedman aryeh.fried...@gmail.com wrote: I have a host that for ISP reasons must have a ipv6 addr as well as the ipv4 but the ISP does not offer external ipv6 routing but all the commanes (ssh, ftp, etc.) default to ipv6 and need special options to use 4 is there anyway to force them to always use 4? ___ 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 A kick and dirty way would be to comment the line: options INET6 # IPv6 communications protocols from your kernel config and recompile. That breaks the must have a ipv6 addr requirement. The way to do this without completely disabling IPv6 used to be to configure ipv6_prefer, but that appears to have been superseded by ip6addrctl_policy. ___ 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: Help porting Linux app - getting Free Memory and Real Memory
Peter Jeremy pe...@rulingia.com writes: On 2013-Mar-29 20:27:27 -0400, Rod Person rodper...@rodperson.com wrote: Everything is going we except that the program gives warnings that there isn't enough free memory on the system to perform certain actions. That premise sounds suspiciously like the upstream author doesn't understand how Unix VM works. To be more blunt, these checks may well be useless on Linux. On a quick look, you seem to maintain three ports: idutils, mspdebug, and jogl. I wouldn't expect a free-memory check to be appropriate on any of those. In any case, the definition of free memory is different between the VM systems in Linux and BSD . Even if the checks do make sense, the FreeBSD implementation would at the minimum have to include all of the pages that are allocated but not mapped. ___ 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: Help porting Linux app - getting Free Memory and Real Memory
Rod Person rodper...@rodperson.com writes: On 03/29/13 08:34, Lowell Gilbert wrote: Peter Jeremy pe...@rulingia.com writes: On 2013-Mar-29 20:27:27 -0400, Rod Person rodper...@rodperson.com wrote: Everything is going we except that the program gives warnings that there isn't enough free memory on the system to perform certain actions. That premise sounds suspiciously like the upstream author doesn't understand how Unix VM works. To be more blunt, these checks may well be useless on Linux. On a quick look, you seem to maintain three ports: idutils, mspdebug, and jogl. I wouldn't expect a free-memory check to be appropriate on any of those. Really? The port in question if graphics/fotoxx. I have no involvement in the others. For the latter two, I'm not even sure what they are. Oops. I apologize; I actually looked for ports maintained by the other person who responded to you. Very silly mistake on my part. I don't think a free-memory check is appropriate here, either. In any case, the definition of free memory is different between the VM systems in Linux and BSD . Even if the checks do make sense, the FreeBSD implementation would at the minimum have to include all of the pages that are allocated but not mapped. Yes I have read this. Fotoxx uses free memory calculation when applying effects to images. It looks at the image size then calculates how much memory it needs to apply an effect, such as image sharpening. For example, on a 4.5MB jpg file it seems to calculate that 40MB of free memory is need to apply sharpening to the image. 40MB doesn't seem like a lot of memory to me, but since the application way of figuring free memory is Linux specific the warning dialog appear, although it seem to have no ill effect on actually applying the sharpening effect. I would recommend removing the check completely. The upstream author should do this for the Linux version as well; it really doesn't make sense in a system that supports virtual memory. If you decide to support it anyway to make some kind of performance guarantees, you probably should check against all of user memory; free memory is by definition being underutilized. ___ 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: Help porting Linux app - getting Free Memory and Real Memory
Rod Person rodper...@rodperson.com writes: man 3 sysctl, list them as integer that is why I did this. unsigned long *is* an integer, but it's a different kind of integer than an int. This is an important distinction in the C language. ___ 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: snd_geode - where it is
Wojciech Puchar woj...@wojtek.tensor.gdynia.pl writes: i found it mentioned on older mailing list archives. Unfortunately all links to source are dead. There is no such driver now in FreeBSD-9. Is there any reason that it was removed, or it wasn't commited at all? any place where i can get it? I'm pretty sure it was part of the base system at one time, but that was a long time ago. It's not like it would drop into a modern GIANT-free FreeBSD anyway. Try OSS from ports, would be my first guess. ___ 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: lots of network interfaces
Wojciech Puchar woj...@wojtek.tensor.gdynia.pl writes: very usable at that point, ifconfig aside). The interfaces are a linked list, plus there's a separate kernel dive for each interface. The list (as opposed to individual interfaces) is i don't care how fast ifconfig displays them, just for how fast things like routing or ipfw rule like via tun196 would work. if it is hashed somehow - fine. if not - very bad. Not an issue, as I explained in a part of the message that you clipped out. ___ 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: lots of network interfaces
dte...@freebsd.org writes: I decided to stress-test the netgraph(4) subsystem one day and was able to create 65530 interfaces before it produced an error, refusing to create another. At that point, the system was still usable, but... It took over an hour for ifconfig to list all the interfaces. Simply typing ifconfig with no arguments and pressing ENTER would start spewing information on-screen for over an hour before it finished. (so I'd say that there could be some optimizations made; but nonetheless impressive that the system was still very usable at that point, ifconfig aside). The interfaces are a linked list, plus there's a separate kernel dive for each interface. The list (as opposed to individual interfaces) is really only accessed from userland, so optimizing these operations would need a really good use case to be worthwhile. The current implementation is not just very well known, it's good for hundreds to thousands of interfaces..For the output of ifconfig alone, it might be possible to grab more information in the original getifaddrs() (which makes a copy of the interface list), but that would make other operations with that function more expensive. ___ 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: Give users a hint when their locate database is too small.
Eitan Adler li...@eitanadler.com writes: What do people think of this? Maybe /usr/libexec/locate.updatedb is a better pointer? Yes, I would think locate.updatedb(8) would be the appropriate reference, because it's possible to build locate databases in ways and for reasons other than the weekly script. I assume that the precise cutoff value is chosen not because the number of bigrams is important but because the size of the bigram buffer is, and that it's only notated as (2*NBG) because BGBUFSIZE isn't defined in a header... commit fb03b777daf2c69bb9612902e38fdb25b256be72 Author: Eitan Adler li...@eitanadler.com Date: Mon Nov 12 22:05:55 2012 -0500 Give users a hint when their locate database is too small. Reviwed by: ??? Approved by: ??? MFC after:3 weeks diff --git a/usr.bin/locate/locate/locate.c b/usr.bin/locate/locate/locate.c index b0faefb..f0c8c37 100644 --- a/usr.bin/locate/locate/locate.c +++ b/usr.bin/locate/locate/locate.c @@ -292,7 +292,7 @@ search_mmap(db, s) err(1, `%s', db); len = sb.st_size; if (len (2*NBG)) - errx(1, database too small: %s, db); + errx(1, database too small: %s\nTry running /etc/periodic/weekly/310.locate, db); if ((p = mmap((caddr_t)0, (size_t)len, PROT_READ, MAP_SHARED, ___ 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: mtree(8) reporting of file modes
David Wolfskill da...@catwhisker.org writes: * mode is set to the (masked) mode of the (immediately) enclosing directory when it is visited in pre-order. (This is done in statd().) Not quite. It looks like when statd() is called on the enclosing directory itself, it walks all of the children to find the most common values, and issues a /set line to establish defaults. When it is subsequently called for each of the children in their own right, it only needs to list the properties that differ. Which isn't really illogical: it substantially reduces the size of the output (and vastly improves the readability-by-humans) in exchange for having to traverse the list of file entries twice. Maybe I'm confused, but certainly for my present purposes, and likely in general, I'd think it would make sense to just always report the file mode. Another alternative, in case there are use cases for the existing behavior, would be to provide either another key or a command-line flag that says give me all the modes. Am I the only one who would find such a change useful? Well, it's definitely only useful if you're using something besides mtree itself to parse the output file. I like having the defaults, because most of the time all of the files in a directory have the same permissions, and there are fewer distractions for my eye. I guess the question is why do *you* find the /set lines to (even just occasionally) not be useful? Be well. ___ 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: what is the RIGHT(TM) way to configure background DHCP?
deeptec...@gmail.com deeptec...@gmail.com writes: moving [ http://lists.freebsd.org/pipermail/freebsd-questions/2011-June/231301.html ] to the freebsd-hackers list, as there doesn't seem to be enough 1337 people in the freebsd-questions list. : You might want to try rewording your question, because it didn't make any sense the first time. [All of your examples were commented out, so it was no surprise that they didn't work.] I considered trying to use my chrystal ball to guess that you needed SYNCDHCP in your interface config, but you had obviously read the manual for rc.conf(5), so that seemed unlikely... ___ 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?
Steven Hartland kill...@multiplay.co.uk writes: A few key question come to mind:- 1. Has sendmail's config moved away from the black art it once was? Somewhat. The configurations are done with m4 these days, but there's a lot of black magic possible with the many potential combinations of features and options. 2. Is postfix that much easier? Yes. However, the black magic in sendmail is very powerful. 3. What would people use for: 3.1. POP / IMAP support? Separate problem. I use dovecot and I like it, but it's just a household server. 3.2. Web Mail? I don't do that, because I don't want to go to the effort of making sure it is and stays secure, but from what I hear I'd probably try squirrelmail first if I were doing it. 3.2. AV / Spam filtering? I use spamassassin. You can plug most other analyzers into it. ___ 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: SGID/SUID on scripts
Jonathan McKeown j.mcke...@ru.ac.za writes: On Thursday 23 July 2009 20:28:52 Lowell Gilbert wrote: That's clever, but how would it work in practice, while common shells and scripting languages may not implement their side of it? http://www.in-ulm.de/~mascheck/various/shebang/ claims that it's been implemented, in exactly the way described, in Solaris, OpenBSD and NetBSD (albeit as a kernel compile-time option in the latter two). (It's apparently also in IRIX and UnixWare). Given OpenBSD's admirable paranoia about security (hey, I'm a sysadmin: I never ask myself if I'm being paranoid, but if I'm being paranoid enough!) I'd have thought they would have explored the implications fully. They don't enable it by default, and they don't seem to recommend it. Certainly other stuff knows about it. As I said yesterday, Perl describes the problem in its perlsec manpage/perldoc. The perl interpreter even has a build-time option, SETUID_SCRIPTS_ARE_SECURE_NOW - and the correct setting is supposedly detected as part of configure. The problem I'm wondering about is that it doesn't matter what knows about it as long as there's an interpreter that *doesn't*. Anything that opens a script parameter on its own (there are other vulnerable approaches, but one's enough) will be insecure. I may well be missing something, of course. There may well be some problems to overcome, but this doesn't appear to be unexplored territory. Not entirely, but there may well be a reason it's never been in common use. - Lowell ___ 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: SGID/SUID on scripts
per...@pluto.rain.com writes: DarkSoul darks...@darkbsd.org wrote: Anthony Pankov wrote: SGID/SUID bits don't work with shell scripts, do they? They don't. ... if they were applied, the following would occur : - execve() syscall reads your script's shebang line, and the script interpreter is executed, receiving the specified arguments along with the script name. - The interpreter then open()s the script file to read it, and run the code. The problem you then are faced with, is that you have a time frame defined by the moment between the aforementioned execve() and open(), during which it could be possible to unlink/move/ whatever the shell script the interpreter is going to open. You guess where this is going, you have no absolute way of guaranteeing you are executing the file you initially planned on opening because execution/opening/reading is not, and can't be done atomically for shell scripts. In principle, it should be possible to fix this exposure by improving the interface between execve() and the interpreter: The execve() syscall already has the script file open to read the shebang line. Leave it open, and ensure that the interpreter receives the open descriptor as fd#3 just as 0, 1, and 2 are already used for stdin, stdout, and stderr. An interpreter supporting this approach would check whether stdscr (fd#3) is already open, and if so read from it instead of open()ing the script file. This should ensure that the script which gets executed is the same inode on which execve() saw the SGID/SUID bits set, even if the filesystem has been changed by the time the interpreter has gotten started. It would be the responsibility of whomever decided to set the SGID/SUID bits on a particular script to ensure that the interpreter involved supports the mechanism. I vaguely recall having seen a similar (or even identical) approach suggested some years ago. It may even have been implemented in some variant of Un*x. That's clever, but how would it work in practice, while common shells and scripting languages may not implement their side of it? ___ 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: proper types for printf()-ing pointers on amd64 that won't break
Steve Franks [EMAIL PROTECTED] writes: Hi, I'm trying to correct some warnings in a port marked ONLY_FOR_ARCHS=i386. They stem from casting a pointer (which I assume is a 64-bit unsigned) to unsigned int which is apparently 32 bits? I sort of thought int was supposed to be the atomic register size, but no doubt that would break more than it would help, so it's 32-bits. Anyways, what's the right way to fix this? The port actually works fine as-is on amd64, so I can only assume something was fixed for 7.1, or someone was being extra cautious with the i386 tag. The code: typedef unsigned int cardinal; ... fprintf(stderr, Mode Table Offset: $C + $%x\n, ((cardinal)map-mode_table) - ((cardinal)map-bios_ptr)); Can I just ditch the cast+%x and use %p? I don't have an i386 system to test on, and I don't want to break anything if I submit a patch... What is actually being printed isn't a pointer, but the difference between two pointers (I assume from your comments; the code included isn't enough to show where they come from). That means the correct type of what's being printed is size_t, which our printf seems to support with a z modifier. Removing the explicit casts or (if necessary), replacing them with something that is big enough will also be needed. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Question about http://torrents.freebsd.org:8080/index.html
Sean Bruno [EMAIL PROTECTED] writes: 2cents I just found it odd that that users couldn't just specify the file to download from the release torrent. It also makes it slightly(read almost negligible) harder to seed effectively as I would need to download more than one centralized torrent. Since I use the complete torrent for my purposes, I can only assist the folks who also download the entire torrent. /2cents You *can* do it both ways. Right after a release, I often download the everything torrent, then continue to seed that one while also seeding the partial torrents. I use file links to avoid needing to download the partial torrents separately. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: TCP Checksums in mbufs
Julian Elischer [EMAIL PROTECTED] writes: Lee Brotherston wrote: Hi, I have a bit of code I have written that uses pfil to access network traffic as it passes between interfaces on a FreeBSD router. One of the functions it performs is some incredibly basic rewrites of certain packets (keeping the same length, so no issues about sequence numbers), but it does alter the payload. I just wanted to check what is the proper way to be going about recalculating the checksums on the packet? I can write a function to do this and write this into the packet stored in the mbuf directly, however I wasn't sure if there was a more acceptable method such as flagging it to be re-checksum'd as it's routed, or to offload the computation to the NIC or something? Any thoughts, suggestions, etc very welcome! By the way, I'm not subscribed to the list right now, so I'd appreciate it if people could CC me on replies. Many thanks Lee there is an algorythm to recalculate the tcp/ip checksum when you replace a byte. you subtract the old value from the csum and add the new one, but not quite a as easy as that. Actually, it is as easy as that (once you handle the possible overflow). And it's exactly the way this kind of case is usually handled. I think it's given in one of the RFCs but I think it may also be used in the tcpmss port, or possibly the mss fixup code in ppp. I know I've used it somewhere but forget where :-) RFC 1071, but that doesn't include the code. Just the one-sentence explanation of what to do. [And several more sentences of explanation...] ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: TCP Checksums in mbufs
Julian Elischer [EMAIL PROTECTED] writes: Lee Brotherston wrote: Hi, I have a bit of code I have written that uses pfil to access network traffic as it passes between interfaces on a FreeBSD router. One of the functions it performs is some incredibly basic rewrites of certain packets (keeping the same length, so no issues about sequence numbers), but it does alter the payload. I just wanted to check what is the proper way to be going about recalculating the checksums on the packet? I can write a function to do this and write this into the packet stored in the mbuf directly, however I wasn't sure if there was a more acceptable method such as flagging it to be re-checksum'd as it's routed, or to offload the computation to the NIC or something? Any thoughts, suggestions, etc very welcome! By the way, I'm not subscribed to the list right now, so I'd appreciate it if people could CC me on replies. Many thanks Lee there is an algorythm to recalculate the tcp/ip checksum when you replace a byte. you subtract the old value from the csum and add the new one, but not quite a as easy as that. Actually, it is as easy as that. And it's exactly the way this kind of case is usually handled. I think it's given in one of the RFCs but I think it may also be used in the tcpmss port, or possibly the mss fixup code in ppp. I know I've used it somewhere but forget where :-) RFC 1071, but that doesn't include the code. Just the one-sentence explanation of what to do. [And several more sentences of explanation...] ___ 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: On Thu, Jun 29, 2006 at 11:44:23AM -0400, Pat Lashley wrote: No, our implementation is NOT legal. We always return the SAME value. To be legal, we should not return that value again unless it has been free()-ed. It is legal due to brain damaged definition of implementation defined behaviour, but it violates the spirit of the standard :-) Perhaps I'm misunderstanding the 'implementation defined behavior' choices in the standard. I thought that it could either 1) Return NULL; or 2) Behave as though it returned a 'minimum allocation' (which cannot be legally de-referenced). I went wandering through the C Working Group archives for the heck of it, and apparently a lot of people were confused over this, thinking either as you did or that unique meant it would a value unique to the usage of malloc(0). It's been clarified recently (and will be in the next revision of the standard) to the meaning you understood. Specifically: If the size of the space requested is zero, the behavior is implementation-defined: either a null pointer is returned, or the behavior is as if the size were some nonzero value, except that the returned pointer shall not be used to access an object. But if it did actually perform a minimum allocation'; wouldn't it have to return a different value every time to maintain the free() semantics? I think that's another way of looking at the same confusion. If minimum is zero, then using a sentinel value (as in FreeBSD) works. Our malloc() could be easily fixed to be standards-compliant by removing the special handling for ZEROSIZEPTR in malloc.c; then allocations of 0 bytes will be rounded up to 16, just like all other alloations of less than 16 bytes. However, that would lose much of the bug-finding advantage of the current behaviour. This is wandering into -standards territory, though. In any case, the answer to thread's original question is mozilla should fix its code to not assume malloc(0)==NULL. ___ 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)
Andre Albsmeier [EMAIL PROTECTED] writes: The manpage makes me think that when malloc is called with 0 as argument (and no V-flag had been set) the pointer it returns can actually be used (as a pointer to the so-called minimal allocation). It seems, that firefox thinks the same way :-). However, it is calculated in malloc.c as a constant and is always 0x800 (on my architecture). Any access to this area results in a SIGSEV. The C standard explicitly allows both behaviours, and requires the implementation to choose one of them. If it returns a non-NULL pointer, though, that pointer can *only* be used for passing back to free(). It may *not* be dereferenced. So firefox is wrong, and actually broken. I assume the behaviour is meant to show up programming errors: 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 :-). Yes. In this case the manpage is wrong (or, at least, mis-leading) and should be fixed (I could give it a try if someone actually is willing to commit it). I don't see what you are claiming is wrong. Can you give a brief description of you're suggesting. Apart from that, I suggest, we should run firefox (and maybe other mozilla apps) with MALLOC_OPTIONS=V. That would be reasonable, particularly for the time being. However, the firefox bug really should be fixed in the upstream sources. Writing past the end of an allocated buffer (which is what the code does, if you think about it) is a serious error. Another position could be that firefox is wrong because it NEVER may use ANY return value of a malloc(0), regardless of its content. The C language standard agrees with this position... ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Some mmap observations compared to Linux 2.6/OpenBSD
David Schultz [EMAIL PROTECTED] writes: On Sun, Oct 26, 2003, Dag-Erling Smrgrav wrote: Q [EMAIL PROTECTED] writes: Yes, it would appear this is a legacy thing that existed in the original 1994 import of the BSD 4.4 Lite source. Both FreeBSD and NetBSD still use this technique, but OpenBSD changed to using Red-Black trees back in Feb 2002. [...] I am wondering if there is a compelling reason why the technique used by OpenBSD could not be adapted to FreeBSD's VM system. Adapting OpenBSD's red-balck patches would require quite a bit of work as FreeBSD and OpenBSD have diverged quite a bit in this area. Though it is a good idea to change the list into a tree, I think you'd get more mileage by addressing the fundamental problem, which is the lack of a free list. The current code (in both FreeBSD and OpenBSD) searches a list or tree of allocated extents, sorted by location, looking for a pair that have sufficient space between them for the extent you want to create. We should instead keep track of free extents in a structure that makes it easy to locate one of the correct size. We probably need a dual structure, though, because we need to keep the free extents sorted both by size (to quickly find what we need) and by location (to facilitate aggregation of adjacent extents, without which we'd suffer horribly from address space fragmentation). I have no idea how much this means for real-life workloads though. Your idea of using a size-hashed freelist as well as a location-sorted list is appealing in its simplicity. Though it can cause a bit of fragmentation, it gives you constant time lookup. Bonwick's vmem allocator ([1], section 4.4.2 and following), apparently works quite well using this principle. A hash probably isn't the right data structure for either dimension (DES didn't say it was, I notice). Finding the next-largest available entry is a useful operation, here, so a list would be better than a hash. [Or a tree; the point is that exact-match isn't the only kind of search you need.] But regardless of the approach, someone has yet to demonstrate that this is actually a performance problem in the real world. ;-) Yes. Wouldn't be easy to test even if you wanted to, either... ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: A few questions about a few includes
Erik Trulsson [EMAIL PROTECTED] writes:
On Mon, Mar 04, 2002 at 09:35:29AM -0700, M. Warner Losh wrote:
In message: [EMAIL PROTECTED]
Erik Trulsson [EMAIL PROTECTED] writes:
: I think it is still there (and my draft copy says the same thing).
: I was thinking about the original C89 standard which does not allow it
: (and does not allow incomplete array types in structs). Guess I should
: have said which standard I was referring to.
struct foo {
char array[0];
};
appears to be in C-99 but not C-89. If you have the draft, so far the
only thing I've noticed that is different between the draft and the
final standard is that there's 10-15 more footnotes in the final
standard than were in the final draft.
Warner
Are you sure that is in C99?
What is allowed in C99 (but wasn't in C89) is
struct foo
{
int b;
char array[];
};
Note that you must have a 'normal' field before the incomplete array.
I don't think
char array[0];
is allowed in either of C89 or C99.
Correct on all counts. I'll cite the letter of the law from C99 if
anybody really cares.
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-hackers in the body of the message
Re: A few questions about a few includes
Harti Brandt [EMAIL PROTECTED] writes:
This should be
struct foo {
char array[];
};
according to C-99, on which gcc2 barfs. Don't know, whether gcc3 can
handle this.
C-99 requires a fully specified type before the unspecified array (and
requires said array to be the last element in the structure). So this
example is *not* valid in C99, but the following would be:
struct foo {
int bar;
char array[];
};
[Which makes sense; it forces a structure to have a non-zero size.]
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-hackers in the body of the message
