Re: yacc spacing
Am 21.02.2014 um 03:54 schrieb Ted Unangst t...@tedunangst.com:
While I was poking around yacc, I noticed that skeleton.c used a
handrolled fputs instead of calling the function. Fixing that, I
noticed the code wasn't indented nicely. Fixing that, I figured if
I've already messed with output.c, I should indent that file too.
Which brings us this. The functional change to skeleton.c is all the
way at the bottom. Otherwise it mostly replaces four spaces with a
tab, except where it replaces two spaces with a tab, except where it
replaces some other amount of whitespace.
[...]
void
write_section(char *section[])
{
-int c;
-int i;
-char *s;
-FILE *f;
-
-f = code_file;
-for (i = 0; (s = section[i]); ++i)
-{
- ++outline;
- while ((c = *s))
- {
- putc(c, f);
- ++s;
+ int c;
You do not need c here anymore, right?
+ int i;
+ char *s;
+ FILE *f;
+
+ f = code_file;
Why not shorten to FILE *f = code_file; ?
+ for (i = 0; (s = section[i]); ++i) {
+ ++outline;
+ fputs(s, f);
+ putc('\n', f);
Why this local assignment to f anyway and not
just fputs(s, code_file) and putc(\n', code_file)?
}
- putc('\n', f);
-}
}
Otherwise, ok jung@
Re: yacc spacing
On 02/21/14 09:52, Joerg Jung wrote: Am 21.02.2014 um 03:54 schrieb Ted Unangst t...@tedunangst.com: Otherwise it mostly replaces four spaces with a tab Isn't a TAB 8 characters? regards, chris
Re: rm reference to obsolete functions
Hi, Jan Klemkow wrote on Wed, Jan 29, 2014 at 08:44:05PM +0100: I've made a little diff to clean up some manpages with references to the obsoleted functions usleep(1), alarm(3). Actually, i like this diff and would like to commit it, for the following reason: We include pointers in SEE ALSO when they are likely to help readers. That's not the case here. From section 1 pages, pointers to section 2 and 3 are rarely helpful because readers of section 1 usually look for ready-to-use utilities, not for programming interfaces. Still, i like keeping a very small number of pointers to the main syscalls and library functions used for the implementation because that may help programmers to find the most important code examples more quickly than by wading through /usr/src/. But in sleep(1), this is clearly overdone, and Jan's diff trims it down to a more reasonable level. I might even remove sleep(3) as well, nanosleep(2) points to it anyway, and sleep(1) doesn't even use it. From sleep(3), a pointer to usleep(3) is no longer helpful. If you are considering to use sleep(3) in your code, you might reconsider and use nanosleep(2) or setitimer(2) instead, when you discover their existence. But it doesn't make sense at all to use usleep(3) instead, that would merely harm portability for no benefit. So why point to it? On the other hand, if you find usleep(3) in old code and wonder what it does, you are looking at the usleep(3) manual in the first place and don't need the pointer either. OK? Ingo Index: bin/sleep/sleep.1 === RCS file: /cvs/src/bin/sleep/sleep.1,v retrieving revision 1.19 diff -u -p -r1.19 sleep.1 --- bin/sleep/sleep.1 3 Sep 2010 09:53:20 - 1.19 +++ bin/sleep/sleep.1 29 Jan 2014 19:39:14 - @@ -109,9 +109,7 @@ done .Xr at 1 , .Xr nanosleep 2 , .Xr setitimer 2 , -.Xr alarm 3 , -.Xr sleep 3 , -.Xr usleep 3 +.Xr sleep 3 .Sh STANDARDS The .Nm Index: lib/libc/gen/sleep.3 === RCS file: /cvs/src/lib/libc/gen/sleep.3,v retrieving revision 1.14 diff -u -p -r1.14 sleep.3 --- lib/libc/gen/sleep.3 18 Jul 2013 10:14:49 - 1.14 +++ lib/libc/gen/sleep.3 29 Jan 2014 19:39:31 - @@ -70,7 +70,7 @@ slept) in seconds. .Sh SEE ALSO .Xr sleep 1 , .Xr nanosleep 2 , -.Xr usleep 3 +.Xr setitimer 2 .Sh STANDARDS The .Fn sleep
Re: rm reference to obsolete functions
On Fri, Feb 21, 2014 at 11:45:26PM +0100, Ingo Schwarze wrote: Hi, Jan Klemkow wrote on Wed, Jan 29, 2014 at 08:44:05PM +0100: I've made a little diff to clean up some manpages with references to the obsoleted functions usleep(1), alarm(3). Actually, i like this diff and would like to commit it, for the following reason: We include pointers in SEE ALSO when they are likely to help readers. That's not the case here. From section 1 pages, pointers to section 2 and 3 are rarely helpful because readers of section 1 usually look for ready-to-use utilities, not for programming interfaces. Still, i like keeping a very small number of pointers to the main syscalls and library functions used for the implementation because that may help programmers to find the most important code examples more quickly than by wading through /usr/src/. But in sleep(1), this is clearly overdone, and Jan's diff trims it down to a more reasonable level. I might even remove sleep(3) as well, nanosleep(2) points to it anyway, and sleep(1) doesn't even use it. From sleep(3), a pointer to usleep(3) is no longer helpful. If you are considering to use sleep(3) in your code, you might reconsider and use nanosleep(2) or setitimer(2) instead, when you discover their existence. But it doesn't make sense at all to use usleep(3) instead, that would merely harm portability for no benefit. So why point to it? On the other hand, if you find usleep(3) in old code and wonder what it does, you are looking at the usleep(3) manual in the first place and don't need the pointer either. OK? Ingo Index: bin/sleep/sleep.1 === RCS file: /cvs/src/bin/sleep/sleep.1,v retrieving revision 1.19 diff -u -p -r1.19 sleep.1 --- bin/sleep/sleep.1 3 Sep 2010 09:53:20 - 1.19 +++ bin/sleep/sleep.1 29 Jan 2014 19:39:14 - @@ -109,9 +109,7 @@ done .Xr at 1 , .Xr nanosleep 2 , .Xr setitimer 2 , -.Xr alarm 3 , -.Xr sleep 3 , -.Xr usleep 3 +.Xr sleep 3 .Sh STANDARDS The .Nm Index: lib/libc/gen/sleep.3 === RCS file: /cvs/src/lib/libc/gen/sleep.3,v retrieving revision 1.14 diff -u -p -r1.14 sleep.3 --- lib/libc/gen/sleep.318 Jul 2013 10:14:49 - 1.14 +++ lib/libc/gen/sleep.329 Jan 2014 19:39:31 - @@ -70,7 +70,7 @@ slept) in seconds. .Sh SEE ALSO .Xr sleep 1 , .Xr nanosleep 2 , -.Xr usleep 3 +.Xr setitimer 2 .Sh STANDARDS The .Fn sleep what do you want here, really? in my opinion, readers of section one pages should not be pointed to code. yes, yes, yes, other people disagree. but no one using sleep(1) will care. so you propose to remove the Xr to alarm(). that's a function mandated by posix. why make people less aware of that interface? really? second, why replace, in sleep(3), the reference to usleep with setitimer? usleep(3) says it is obsoleted by nanosleep(2), not setitimer(2). and additionally the posix page for sleep() lists getitimer, not setitimer. that's the name of our page, too. so its one of those pick your colors, best ones win cases. are you sure this is making the docs clearer? really? my advice is to remove all 2/3 refs in sleep(1), and just zap the usleep ref in sleep(3). since people who never previously cared about this will now start caring, ask yourself whether it's worth it. jmc
Re: rm reference to obsolete functions
what do you want here, really? in my opinion, readers of section one pages should not be pointed to code. yes, yes, yes, other people disagree. but no one using sleep(1) will care. so you propose to remove the Xr to alarm(). that's a function mandated by posix. why make people less aware of that interface? really? I would like to propose a diff which modified the csh manual page, so it has an Xr to every function in libc which csh uses... It's a stupid model. Unless there is great benefit, there should be no Xr. With sleep, there is ABSOLUTELY ZERO BENEFIT to link to any section 2 manual pages. second, why replace, in sleep(3), the reference to usleep with setitimer? usleep(3) says it is obsoleted by nanosleep(2), not setitimer(2). and additionally the posix page for sleep() lists getitimer, not setitimer. that's the name of our page, too. That again is irrelevant. Ingo, you should delete them all. They serve no point. my advice is to remove all 2/3 refs in sleep(1), and just zap the usleep ref in sleep(3). since people who never previously cared about this will now start caring, ask yourself whether it's worth it. I agree completely. If the benefit is low, kill them, or leave the files alone. There are more important battles. Please do not churn up mud from the bottom by making pointless pick choose decisions.
Vax
I would like to thank the members of the community who deliver four vax machines to the project. Vax builds have started again!
Re: Vax
On 21 February 2014 18:21, dera...@cvs.openbsd.org wrote: I would like to thank the members of the community who deliver four vax machines to the project. Vax builds have started again! Snaps at 11! (i.e. November). :-) Ken
i386 install bug on recent snap
I can see why this one goes unnoticed. When I grab a snapshot and install on a test machine I make a practice of deleting the k partition because I don't need it and it takes ages to newfs it. (Slow Atom box) Today it caught me. Going through the usual accept defaults (as much as possible) I hit enter to leave the whole disk for OpenBSD and then chose E when the partition choices came up. entered d k cr then q cr Write new label? [y] appeared and as usual I hit cr To my surprise I was looking at the fdisk choices section again. What I missed at first was the Segmentation fault message crammed in between the partition stuff and the fdisk stuff. So I just left the k partition in and all went well. Completely repeatable. dmesg: OpenBSD 5.5-beta (GENERIC.MP) #237: Tue Feb 18 16:19:26 MST 2014 t...@i386.openbsd.org:/usr/src/sys/arch/i386/compile/GENERIC.MP cpu0: Intel(R) Atom(TM) CPU D525 @ 1.80GHz (GenuineIntel 686-class) 1.80 GHz cpu0: FPU,V86,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36, CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,NXE,LONG,SSE3,DTES64,MWAI T,DS-CPL,TM2,SSSE3,CX16,xTPR,PDCM,MOVBE,LAHF,PERF real mem = 2137223168 (2038MB) avail mem = 2090397696 (1993MB) mainbus0 at root bios0 at mainbus0: AT/286+ BIOS, date 06/23/11, BIOS32 rev. 0 @ 0xf0010, SMBIOS rev. 2.6 @ 0xfc8b0 (23 entries) bios0: vendor American Megatrends Inc. version 080015 date 06/23/2011 bios0: Standard XS35 acpi0 at bios0: rev 2 acpi0: sleep states S0 S3 S4 S5 acpi0: tables DSDT FACP APIC MCFG SLIC OEMB HPET GSCI acpi0: wakeup devices P0P1(S4) AZAL(S3) P0P4(S4) P0P5(S4) JLAN(S3) P0P6(S4) P0P7(S4) P0P8(S4) P0P9(S4) USB0(S3) USB1(S3) USB2(S3) USB3(S3) EUSB(S3) acpitimer0 at acpi0: 3579545 Hz, 24 bits acpimadt0 at acpi0 addr 0xfee0: PC-AT compat cpu0 at mainbus0: apid 0 (boot processor) mtrr: Pentium Pro MTRR support, 8 var ranges, 88 fixed ranges cpu0: apic clock running at 199MHz cpu0: mwait min=64, max=64, C-substates=0.1.0.0.0, IBE cpu1 at mainbus0: apid 2 (application processor) cpu1: Intel(R) Atom(TM) CPU D525 @ 1.80GHz (GenuineIntel 686-class) 1.80 GHz cpu1: FPU,V86,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36, CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,NXE,LONG,SSE3,DTES64,MWAI T,DS-CPL,TM2,SSSE3,CX16,xTPR,PDCM,MOVBE,LAHF,PERF cpu2 at mainbus0: apid 1 (application processor) cpu2: Intel(R) Atom(TM) CPU D525 @ 1.80GHz (GenuineIntel 686-class) 1.80 GHz cpu2: FPU,V86,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36, CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,NXE,LONG,SSE3,DTES64,MWAI T,DS-CPL,TM2,SSSE3,CX16,xTPR,PDCM,MOVBE,LAHF,PERF cpu3 at mainbus0: apid 3 (application processor) cpu3: Intel(R) Atom(TM) CPU D525 @ 1.80GHz (GenuineIntel 686-class) 1.80 GHz cpu3: FPU,V86,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36, CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,NXE,LONG,SSE3,DTES64,MWAI T,DS-CPL,TM2,SSSE3,CX16,xTPR,PDCM,MOVBE,LAHF,PERF ioapic0 at mainbus0: apid 4 pa 0xfec0, version 20, 24 pins ioapic0: misconfigured as apic 3, remapped to apid 4 acpimcfg0 at acpi0 addr 0xe000, bus 0-255 acpihpet0 at acpi0: 14318179 Hz acpiprt0 at acpi0: bus 0 (PCI0) acpiprt1 at acpi0: bus 3 (P0P1) acpiprt2 at acpi0: bus 1 (P0P4) acpiprt3 at acpi0: bus 2 (P0P5) acpiprt4 at acpi0: bus -1 (P0P6) acpiprt5 at acpi0: bus -1 (P0P7) acpiprt6 at acpi0: bus -1 (P0P8) acpiprt7 at acpi0: bus -1 (P0P9) acpiec0 at acpi0 acpicpu0 at acpi0 acpicpu1 at acpi0 acpicpu2 at acpi0 acpicpu3 at acpi0 acpitz0 at acpi0: critical temperature is 104 degC acpibtn0 at acpi0: SLPB acpibtn1 at acpi0: PWRB acpivideo0 at acpi0: GFX0 acpivout0 at acpivideo0: LCD_ bios0: ROM list: 0xc/0xda00! 0xce000/0x1800! 0xcf800/0x1000 pci0 at mainbus0 bus 0: configuration mode 1 (bios) 0:31:2: mem address conflict 0xfc00/0x400 pchb0 at pci0 dev 0 function 0 Intel Pineview DMI rev 0x02 vga1 at pci0 dev 2 function 0 Intel Pineview Video rev 0x02 intagp0 at vga1 agp0 at intagp0: aperture at 0xd000, size 0x1000 inteldrm0 at vga1 drm0 at inteldrm0 inteldrm0: 1024x768 wsdisplay0 at vga1 mux 1: console (std, vt100 emulation) wsdisplay0: screen 1-5 added (std, vt100 emulation) Intel Pineview Video rev 0x02 at pci0 dev 2 function 1 not configured azalia0 at pci0 dev 27 function 0 Intel 82801GB HD Audio rev 0x02: msi azalia0: codecs: IDT 92HD81B1X audio0 at azalia0 ppb0 at pci0 dev 28 function 0 Intel 82801GB PCIE rev 0x02: apic 4 int 16 pci1 at ppb0 bus 1 ppb1 at pci0 dev 28 function 1 Intel 82801GB PCIE rev 0x02: apic 4 int 17 pci2 at ppb1 bus 2 JMicron SD/MMC rev 0x80 at pci2 dev 0 function 0 not configured sdhc0 at pci2 dev 0 function 2 JMicron SD Host Controller rev 0x80: apic 4 int 18 sdmmc0 at sdhc0 JMicron Memory Stick rev 0x80 at pci2 dev 0 function 3 not configured jme0 at pci2 dev 0 function 5 JMicron JMC250 rev 0x03: msi, address 80:ee:73:28:4b:69 jmphy0 at jme0 phy 1: JMP211 10/100/1000 PHY, rev. 1 uhci0 at pci0 dev 29 function 0 Intel 82801GB USB rev 0x02: apic 4 int 23
