On Fri, Dec 13, 2024 at 03:09:57PM -0800, Steve Kargl wrote: > On Fri, Dec 13, 2024 at 10:54:03PM +0100, Mikael Morin wrote: > > Le 13/12/2024 à 21:55, Steve Kargl a écrit : > > > On Mon, Dec 09, 2024 at 06:39:19PM -0800, Steve Kargl wrote: > > > > > > > > I've an almost complete implementation of F_C_STRING, > > > > but need a bit of insight on the inlining that I'm > > > > trying to implement. In pseudo-code, F_C_STRING is > > > > > > > > case 1. f_c_string(string) = trim(string) // c_null_char > > > > case 2. f_c_string(string, asis=.false.) = trim(string) // c_null_char > > > > case 3. f_c_string(string, asis=.true.) = string // c_null_char > > > > > > > > > > Here's where I'm stuck. > > > > > FX's message gave most of the information. > > More explicitly, what's missing is roughly: > > Thanks, Mikael. FX's message is/was indeed > helpful, but it seems I am/was getting confused > with gfc_se and stmtblock_t entities. Once I > got rid of errors of trying to add an 'gfc_se *' > or tree to a non-existent member of a block, I > would always get the else_branch (as if the > conditional was always false). >
Sigh. That didn't help. Mem: 660M Active, 2767M Inact, 56M Laundry, 1292M Wired, 752M Buf, 2914M Free Swap: 12G Total, 209M Used, 12G Free, 1% Inuse, 120K In PID USERNAME THR PRI NICE SIZE RES STATE C TIME WCPU COMMAND 67444 kargl 1 20 0 64T 5932K CPU0 0 0:16 100.07% z 1478 kargl 5 20 0 279M 35M select 1 241:20 0.64% Xorg 57629 kargl 17 20 0 2452M 127M select 0 0:02 0.59% firefox I'm fairly certain that 64T bytes should not be needed to append a character to a string. I'll take the easy out and implement a library routine. -- Steve
