| 01:23.59 | *** join/#brlcad SWPadnos_ (n=Me@dsl245.esjtvtli.sover.net) |
| 02:15.26 | *** join/#brlcad Twingy (n=justin@74.92.144.217) |
| 03:23.14 | *** join/#brlcad Twingy (n=justin@74.92.144.217) |
| 08:10.55 | CIA-5 | BRL-CAD: 03brlcad * 10brlcad/src/libbu/linebuf.c: windows (vc8) throws an assertion if setvbuf is called with a size of zero: ((2 <= size) && (size <= INT_MAX)) .. presumably they want a buffer big enough to stash their \r\n or somesuch. |
| 08:23.04 | CIA-5 | BRL-CAD: 03brlcad * 10brlcad/src/libbu/linebuf.c: go with a BUFSIZE buffer instead of min to reduce write flushing |
| 08:31.53 | CIA-5 | BRL-CAD: 03brlcad * 10brlcad/src/libbu/linebuf.c: er, define BUFSIZE for setvbuf |
| 08:37.31 | Maloeran | It's just amusing to see it being "robust" enough to try to handle OSes that don't conform to specifications |
| 08:46.06 | brlcad | yep, it can |
| 08:53.26 | brlcad | the "specifications" didn't always exist, too .. and most have gone through various iterations of what is strictly required, what is recommended, how compliant implementations are if at all, etc |
| 09:31.07 | *** join/#brlcad clock_ (i=clock@84-72-63-118.dclient.hispeed.ch) |
| 11:10.24 | *** join/#brlcad clock_ (i=clock@84-72-63-118.dclient.hispeed.ch) |
| 11:48.40 | *** join/#brlcad clock_ (i=clock@84-72-63-118.dclient.hispeed.ch) |
| 12:55.57 | *** join/#brlcad SWPadnos_ (n=Me@dsl245.esjtvtli.sover.net) |
| 13:49.46 | *** join/#brlcad clock_ (i=clock@84-72-63-118.dclient.hispeed.ch) |
| 16:18.18 | clock_ | lol - lol :) |
| 16:18.33 | clock_ | POSIX loser, brl-cad ruler :) |
| 19:53.32 | *** join/#brlcad clock_ (i=clock@84-72-63-118.dclient.hispeed.ch) |