Re: Where is stack of program?
On 08:45 Tue 11 Jun , Konstantin Belousov wrote: > On Mon, Jun 10, 2013 at 08:44:25PM +0400, Vagner wrote: > > Hi! > > I need method of finding in struct vm_map or vm_object segments of > > memory which is situated in the stack. > > Can you help me please? > > Note that the stack is per-thread. The concept is somewhat machine-specific, > some architectures utilize two stacks, on some the stack is purely software > convention. > > You did not specified what context your code is to be run, e.g. is > it kernel or user space ? Assuming it is kernel since you mentioned > vm_something. The least error prone route is the thread context (frame) > -> tf_esp on i386 (or tf_rsp on amd64) -> lookup of the map entry in the > process p_vmspace. > > In reality, the stack is often fragmented, since the stack grow code > does not coalesce the adjacent grow-down map entries. I asket the question because in my servers run very large daemons (writed their own). Then daemons get signal for create coredump, downtime approximately 1h. This is very long for daemons in production. Often in coredump for debug need only stack and current frame of code, but in function, which initialise for create dump of memory haven't this possibility. Linux have /proc/self/coredump_filter for settings what segments included in core file, but in our FreeBSD I don't find this:( Help me for find solution please -- Respectfully, Stanislav Putrya System administrator FotoStrana.Ru Ltd. ICQ IM: 328585847 Jabber-GoogleTalk: root.vagner mob.phone SPB: +79215788755 mob.phone RND: +79525600664 email: vagner[at]bsdway.ru email: putrya[at]playform.ru email: root.vagner[at]gmail.com site: bsdway.ru site: fotostrana.ru ( ) ASCII ribbon campaign X - against HTML, vCards and / \ - proprietary attachments in e-mail ___ 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] multiple instances of ipfw(4)
Hello Luigi, On Mon, Jun 10, 2013 at 7:30 PM, Luigi Rizzo wrote: > On Mon, Jun 10, 2013 at 06:52:01PM +0200, Ermal Lu?i wrote: > > On Mon, Jun 10, 2013 at 5:01 PM, Luigi Rizzo wrote: > ... > > > if i understand well, this has no runtime overhead as the ifp has > > > the index of the context it refers to ? > > > Or you need an additional IPFW_CTX_RLOCK() ? > > > > > > > Theoretically you would need for correctness the read lock. > > It has never been hit in pfSense hence no further investigation on it has > > been done. > > It can be made even a read mostly lock or to prevent the race the write > > lock > > of the pfil hooks so no packets are passed through?! > > adding another lock (even just a read lock) around invocations is > undesirable in my opinion. I'd rather check if there is already > some other lock which is already held so we can use it to protect > the list of contexts. > > > > Comments on the control/config path: > > > - in ipfw_ctl(), handling IP_FW_CTX_GET i am worried that you might > > > overflow the temporary buffer when building the list. You compute > > > the length under rlock, release the lock, malloc(), then fill the > > > list without checking if the total size is still correct. > > > This kind of code is terribly boring to write, but essentially > > > you need a bound check in the second loop and possibly > > > retry if you notice that you need more memory. > > > "ipfw show" addresses the problem by failing and requesting the > > > user application to pass a larger buffer. > > > > > > > Yeah that probably can be fixed. > > During implementation it was considered enough rare operation to not > > justify further thought. > > well, unlike the previous problem (locking), this has a very simple fix > and no performance implications so there are really no excuses... > > > If you agree with the above i can redo the patch again with the above > > changes for review? > > i would just be happy with the fix to IP_FW_CTX_GET and a big red flashing > comment in the place where the context is being accessed. > Or if you can find another lock to recycle, fine. > > cheers > luigi > regenerated patch at the same location https://github.com/pfsense/pfsense-tools/blob/master/patches/RELENG_10_0/CP_multi_instance_ipfw.diff I actually changed some more things to provide a more correct implementation. The only thing about this is that manual page and rc scripts need to be changed for this as well. How you propose to handle this? -- Ermal ___ 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: Beyond Buildworld Dev Summit Working Group Report
On Jun 10, 2013, at 10:02 PM, Glen Barber wrote: > On Mon, Jun 10, 2013 at 09:25:39PM -0700, Tim Kientzle wrote: >>> • Crochet with VM images [TimKeintzle], [GlenBarber], [ColinPercival] >> >> Per Colin, there's no way for "mere mortals" to upload machine >> images to Amazon, so there's little point in pursuing that. >> >> I did recently add support to Crochet for building VMWare VM images >> directly. Works pretty well; I've been using it to build throw-away >> images for testing. This goes a step further than what Glen >> has recently announced; so far, he's just building the VMDK disk >> image, Crochet fills in the rest of the VM configuration files. >> >> It should be routine to duplicate the approach to support other >> VM environments (e.g., Parallels, VirtualBox, OFA). My time is >> limited but I'm happy to assist if someone else wants to work on it. >> > > I do intend to look at how Crochet does this, because I think your > implementation is far more user friendly and cross-application > compatible. > > I'll certainly pick your brain on it, if you don't mind. Key point: VM images are directories which contain a number of different files. The disk image is just one of those. For VMWare (and others I've looked at), the VM directory contains: * Disk image - this can be a straight disk image (which is what Crochet currently uses) or a structured/sparse/compressed "virtual disk" * Disk descriptor -- this specifies the format of the disk image and the parameters of the virtual disk drive. * VM descriptor -- this describes the rest of the virtual hardware. VMWare seems to be the simplest of the ones I've looked at: the descriptor files are lists of key/value pairs and the VMWare software can boot a VM even from a pretty skeletal definition. It didn't take me very many tries to get Crochet to build a VMWare image that VMWare Fusion was comfortable booting. It helps that the VMWare file formats are pretty well documented: In particular: http://sanbarrow.com Parallels and OFA both use more complex XML configuration files -- everything has an ID and there are lots of cross-references. I've toyed with building Parallels VMs but haven't gotten very far yet. qemu-img seems like a nice tool for generating a virtual disk image, but it doesn't currently know how to create compressed VMWare disks. I've skimmed VMWare's documentation and it doesn't look too hard to build a compressed VMWare disk if someone would like to tackle that. ;-) Tim signature.asc Description: Message signed with OpenPGP using GPGMail
Re: Where is stack of program?
On 12:05 Tue 11 Jun , Vagner wrote:
> On 08:45 Tue 11 Jun , Konstantin Belousov wrote:
> > On Mon, Jun 10, 2013 at 08:44:25PM +0400, Vagner wrote:
> > > Hi!
> > > I need method of finding in struct vm_map or vm_object segments of
> > > memory which is situated in the stack.
> > > Can you help me please?
> >
> > Note that the stack is per-thread. The concept is somewhat
> > machine-specific,
> > some architectures utilize two stacks, on some the stack is purely software
> > convention.
> >
> > You did not specified what context your code is to be run, e.g. is
> > it kernel or user space ? Assuming it is kernel since you mentioned
> > vm_something. The least error prone route is the thread context (frame)
> > -> tf_esp on i386 (or tf_rsp on amd64) -> lookup of the map entry in the
> > process p_vmspace.
> >
> > In reality, the stack is often fragmented, since the stack grow code
> > does not coalesce the adjacent grow-down map entries.
>
> I asket the question because in my servers run very large daemons (writed
> their own). Then daemons get
> signal for create coredump, downtime approximately 1h. This is very long for
> daemons in
> production. Often in coredump for debug need only stack and current
> frame of code, but in function, which initialise for create dump of
> memory haven't this possibility. Linux have /proc/self/coredump_filter
> for settings what segments included in core file, but in our FreeBSD I
> don't find this:( Help me for find solution please
>
My solution.
I added new option MALLOC_OPTIONS ("S") in environment variable for malloc(3).
Also I added new `if' in function pages_map at libc/stdlib. In this `if' I
added option MAP_NOCORE
(mmap(2)) for segments allocated with MAP_PRIVATE | MAP_ANON. Patch file
attached.
As a result: I have a corefile with stack and text of program ~ 2Mb (above
- 2Gb).
Thanks to all
--
Respectfully,
Stanislav Putrya
System administrator
FotoStrana.Ru Ltd.
ICQ IM: 328585847
Jabber-GoogleTalk: root.vagner
mob.phone SPB: +79215788755
mob.phone RND: +79525600664
email: vagner[at]bsdway.ru
email: putrya[at]playform.ru
email: root.vagner[at]gmail.com
site: bsdway.ru
site: fotostrana.ru
( ) ASCII ribbon campaign
X - against HTML, vCards and
/ \ - proprietary attachments in e-mail
Index: lib/libc/stdlib/malloc.c
===
--- lib/libc/stdlib/malloc.c (revision 249257)
+++ lib/libc/stdlib/malloc.c (working copy)
@@ -1155,9 +1155,11 @@
#ifndef MALLOC_PRODUCTION
static bool opt_abort = true;
static bool opt_junk = true;
+static bool opt_stackcore = false;
#else
static bool opt_abort = false;
static bool opt_junk = false;
+static bool opt_stackcore = false;
#endif
#ifdef MALLOC_TCACHE
static size_t opt_lg_tcache_nslots = LG_TCACHE_NSLOTS_DEFAULT;
@@ -1797,8 +1799,12 @@
* We don't use MAP_FIXED here, because it can cause the *replacement*
* of existing mappings, and we only want to create new mappings.
*/
- ret = mmap(addr, size, PROT_READ | PROT_WRITE, MAP_PRIVATE | MAP_ANON,
+ if (opt_stackcore)
+ ret = mmap(addr, size, PROT_READ | PROT_WRITE, MAP_PRIVATE | MAP_ANON | MAP_NOCORE,
-1, 0);
+ else
+ ret = mmap(addr, size, PROT_READ | PROT_WRITE, MAP_PRIVATE | MAP_ANON,
+ -1, 0);
assert(ret != NULL);
if (ret == MAP_FAILED)
@@ -5623,6 +5629,9 @@
case 'P':
opt_stats_print = true;
break;
+case 'S':
+ opt_stackcore = true;
+ break;
case 'q':
if (opt_lg_qspace_max > LG_QUANTUM)
opt_lg_qspace_max--;
___
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"
Importing tradcpp (traditional (K&R-style) C macro preprocessor) into base?
Hi, I have been working in importing tradcpp (developped by David A. Holland from NetBSD) into the ports tree, it is a traditional (K&R-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? regards, Bapt pgpYMMUnszxFD.pgp Description: PGP signature
Re: Importing tradcpp (traditional (K&R-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 (K&R-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: Importing tradcpp (traditional (K&R-style) C macro preprocessor) into base?
On Wed, Jun 12, 2013 at 12:11:24AM +0200, Baptiste Daroussin wrote: > Hi, > > I have been working in importing tradcpp (developped by David A. Holland from > NetBSD) into the ports tree, it is a traditional (K&R-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? > > regards, > Bapt I rewrote calendar already to not use cpp at all. There is an open PR on it. - Diane -- - d...@freebsd.org d...@db.net http://www.db.net/~db ___ 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 (K&R-style) C macro preprocessor) into base?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 On 06/11/13 15:11, Baptiste Daroussin wrote: > Hi, > > I have been working in importing tradcpp (developped by David A. > Holland from NetBSD) into the ports tree, it is a traditional > (K&R-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? Looking at the manual page, it looks like that the only reason is to support #include's? I think it would be better to just fix it than importing a new (old) preprocessor... Cheers, - -- Xin LI https://www.delphij.net/ FreeBSD - The Power to Serve! Live free or die -BEGIN PGP SIGNATURE- iQEcBAEBCgAGBQJRt6ZKAAoJEG80Jeu8UPuzrX4IAJj1hg/+Vh8oGuc2vVeuAU0W 6brYFkZFlgIicyC2k6BFuVU6jTyn3KelFyMxVgzk2S/5fI6lHh6YCHB/XRCDEzHg GG1TELsFKOgAUsA1xp/uDIKTJKqR2Wef2J3oaCl2L5FL0z/cySopPMLOcd08MiCA wOgr3qcPAfaxROOQJaZTs6lbUOs1zKB7RrtuCaYUB5fEwJ4uZwyKmkZtqEAK7WGT 8gDA78nfKxOLHE4XOBE1McO3sFrCQQoj+uAKS0tbRt4+qAD8rRq4T8H5BEk+eNqF NSPjFRKFrTXKSTnK4U+MBOcw7DhlOcabAz9Lpl6nD5hOzz2mUk4YG3pH/jY9zhg= =dsBw -END PGP SIGNATURE- ___ 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 (K&R-style) C macro preprocessor) into base?
On Wed, Jun 12, 2013 at 12:23:44AM +0200, Matthias Andree wrote: > 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 (K&R-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? > To be more specific, some people have express some concern about the lack of support for traditional cpp in base, that's why I'm proposing this, now personnaly I don't care if tradcpp remains in ports (for imake, imake is not a matter of fixing imake, but rather all the users of imake). If we think it is not worth having a traditional cpp, I won't import it. cpp has not be design at first for this kind of usage, but someone of our vendors rely on a traditional cpp anyway. Just it exists, it is rather small, it is BSDL and actively maintainer, so :) concerning calendar(1) another approach is available here: bin/178463 regards, Bapt pgpmRBOgMOwVs.pgp Description: PGP signature
Re: Importing tradcpp (traditional (K&R-style) C macro preprocessor) into base?
On Tue, Jun 11, 2013 at 03:35:54PM -0700, Xin Li wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA512 > > On 06/11/13 15:11, Baptiste Daroussin wrote: > > Hi, > > > > I have been working in importing tradcpp (developped by David A. > > Holland from NetBSD) into the ports tree, it is a traditional > > (K&R-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? > > Looking at the manual page, it looks like that the only reason is to > support #include's? I think it would be better to just fix it than > importing a new (old) preprocessor... Diane has proposed a patch to go that way: http://www.freebsd.org/cgi/query-pr.cgi?pr=bin%2F178463&cat= If one wants to review Bapt pgp_jtHvxMfWp.pgp Description: PGP signature
Re: Importing tradcpp (traditional (K&R-style) C macro preprocessor) into base?
On Tue, Jun 11, 2013 at 03:35:54PM -0700, Xin Li wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA512 > > On 06/11/13 15:11, Baptiste Daroussin wrote: > > Hi, > > > > I have been working in importing tradcpp (developped by David A. > > Holland from NetBSD) into the ports tree, it is a traditional > > (K&R-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? > > Looking at the manual page, it looks like that the only reason is to > support #include's? I think it would be better to just fix it than > importing a new (old) preprocessor... > > Cheers, > - -- > Xin LI https://www.delphij.net/ > FreeBSD - The Power to Serve! Live free or die > -BEGIN PGP SIGNATURE- > > iQEcBAEBCgAGBQJRt6ZKAAoJEG80Jeu8UPuzrX4IAJj1hg/+Vh8oGuc2vVeuAU0W > 6brYFkZFlgIicyC2k6BFuVU6jTyn3KelFyMxVgzk2S/5fI6lHh6YCHB/XRCDEzHg > GG1TELsFKOgAUsA1xp/uDIKTJKqR2Wef2J3oaCl2L5FL0z/cySopPMLOcd08MiCA > wOgr3qcPAfaxROOQJaZTs6lbUOs1zKB7RrtuCaYUB5fEwJ4uZwyKmkZtqEAK7WGT > 8gDA78nfKxOLHE4XOBE1McO3sFrCQQoj+uAKS0tbRt4+qAD8rRq4T8H5BEk+eNqF > NSPjFRKFrTXKSTnK4U+MBOcw7DhlOcabAz9Lpl6nD5hOzz2mUk4YG3pH/jY9zhg= > =dsBw > -END PGP SIGNATURE- > ___ > 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" http://people.FreeBSD.org/~db/calendar.diff removes cpp from calendar. There is also an open PR 178463 - Diane -- - d...@freebsd.org d...@db.net http://www.db.net/~db ___ 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 (K&R-style) C macro preprocessor) into base?
On Wed, Jun 12, 2013 at 12:11 AM, Baptiste Daroussin wrote: ... Regarding tradcpp: I would rather see us try to fix the applications in base instead of import a new cpp. If this proves too difficult I have no objections to this particular implementation, On Wed, Jun 12, 2013 at 12:42 AM, Diane Bruce wrote: > removes cpp from calendar. > > There is also an open PR 178463 I already had a few comments about this diff: - " limited subset " in the man page does not explain what limit. - It doesn't seem to support #ifdef at all -- Eitan Adler ___ 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 (K&R-style) C macro preprocessor) into base?
On Wed, Jun 12, 2013 at 12:23:44AM +0200, Matthias Andree wrote: > Am 12.06.2013 00:11, schrieb Baptiste Daroussin: > > I have been working in importing tradcpp (developped by David A. > > Holland from NetBSD) into the ports tree, it is a traditional > > (K&R-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? A modern cpp is only suitable for preprocessing C code. It makes various assumptions about syntax that make it work better for preprocessing actual C code but worse for text that is not C. Calendar and imake use the traditional cpp for preprocessing non-C text. There is already a patch for removing the dependency on cpp in calendar. I think that makes more sense than importing a traditional cpp (assuming there are no other users in base that cannot be fixed). The "fix" for imake is probably not to use it. Ports that need imake can continue to use it if it depends on a traditional cpp port. A further point of confusion is that things that want a "traditional cpp" in fact want an equivalent of "gcpp -traditional". This is in fact the point of tradcpp and why the old preprocessors do not work. -- Jilles Tjoelker ___ 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 (K&R-style) C macro preprocessor) into base?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 On 06/11/13 15:50, Eitan Adler wrote: [...] > - " limited subset " in the man page does not explain what limit. - > It doesn't seem to support #ifdef at all Why ifdef is needed? (ifndef is here to avoid duplicated inclusion, I don't think there is valid usage for ifdef). Cheers, - -- Xin LI https://www.delphij.net/ FreeBSD - The Power to Serve! Live free or die -BEGIN PGP SIGNATURE- iQEcBAEBCgAGBQJRt6vsAAoJEG80Jeu8UPuz/EkH/jY8jLItQ6ESfeujLw+72mQ3 Hmitiotg7UHj4ltUs1gazrc5/OGqxZaIOSiAM4aeNa1QDh4WVKaRgFrNg1R1QQCX VLZAzDa9lmSCL9P2RIy7zLgsmY8WsPNKzS051mOEpVDTB56MmXedmllZF//qMaXa S6oMi+nXZXcOlmhyAKRc8J3SAdT40OQDniX2MasE5KnjNL0wE7sZgVK2i4mkT7Tp KTOg0zu0Ezv7kxny/Kbh3curllKyKb+9ca5C4rfmcK41M4GXhQRMqrm3of1uS+3Z 8mSb57cqK3xBJO2JATt46chUlXfT2lxG8/ByiJs8zziT2+G++jEFGTnyzH5DTKY= =vL2S -END PGP SIGNATURE- ___ 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 (K&R-style) C macro preprocessor) into base?
On Tue, Jun 11, 2013 at 03:59:56PM -0700, Xin Li wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA512 > > On 06/11/13 15:50, Eitan Adler wrote: > [...] > > - " limited subset " in the man page does not explain what limit. - > > It doesn't seem to support #ifdef at all > > Why ifdef is needed? (ifndef is here to avoid duplicated inclusion, I > don't think there is valid usage for ifdef). I accidentally left it in is the short answer and I never got around to removing it. ;) It's easy enough to remove, I can re-roll a diff removing #ifdef since it isn't really needed. > > Cheers, > - -- > Xin LI https://www.delphij.net/ > FreeBSD - The Power to Serve! Live free or die > -BEGIN PGP SIGNATURE- > > iQEcBAEBCgAGBQJRt6vsAAoJEG80Jeu8UPuz/EkH/jY8jLItQ6ESfeujLw+72mQ3 > Hmitiotg7UHj4ltUs1gazrc5/OGqxZaIOSiAM4aeNa1QDh4WVKaRgFrNg1R1QQCX > VLZAzDa9lmSCL9P2RIy7zLgsmY8WsPNKzS051mOEpVDTB56MmXedmllZF//qMaXa > S6oMi+nXZXcOlmhyAKRc8J3SAdT40OQDniX2MasE5KnjNL0wE7sZgVK2i4mkT7Tp > KTOg0zu0Ezv7kxny/Kbh3curllKyKb+9ca5C4rfmcK41M4GXhQRMqrm3of1uS+3Z > 8mSb57cqK3xBJO2JATt46chUlXfT2lxG8/ByiJs8zziT2+G++jEFGTnyzH5DTKY= > =vL2S > -END PGP SIGNATURE- > ___ > 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" - Diane -- - d...@freebsd.org d...@db.net http://www.db.net/~db ___ 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 (K&R-style) C macro preprocessor) into base?
On Tue, Jun 11, 2013 at 06:04:39PM -0500, Diane Bruce wrote: > On Tue, Jun 11, 2013 at 03:59:56PM -0700, Xin Li wrote: > > -BEGIN PGP SIGNED MESSAGE- > > Hash: SHA512 > > > > On 06/11/13 15:50, Eitan Adler wrote: > > [...] > > > - " limited subset " in the man page does not explain what limit. - > > > It doesn't seem to support #ifdef at all > > > > Why ifdef is needed? (ifndef is here to avoid duplicated inclusion, I > > don't think there is valid usage for ifdef). > > I accidentally left it in is the short answer and I never got around > to removing it. ;) It's easy enough to remove, I can re-roll a diff > removing #ifdef since it isn't really needed. Which I just did. > > > > > Cheers, - Diane -- - d...@freebsd.org d...@db.net http://www.db.net/~db ___ 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"
