lua-users home
lua-l archive

[Date Prev][Date Next][Thread Prev][Thread Next] [Date Index] [Thread Index]


On Feb 22, 2014, at 19:16 , Francisco Olarte wrote:
-- A patch has been suggested that fixes this, at the expense of some subtle behavior changes that only occur if you rely on the old NUL behavior

Several patches have been suggested to what some people, myself
included in the past, considered a bug. Subtle, behaviour changes due
to bug fixes are not normally considered worth backwars compatibility

Now I have the mail open, and as I've been cited twice, I'd like to
restate that Iwithdraw my patch after finding the speed penalty and do
not consider it, or any of the others, adequate ( mine first is slow,
mine using a fscanf is just library gimnastics, funny to share for
stating what fscanf can do but not that useful, the one by Rene I
think is dependent on undocumented behaviour and I find it ( sorry
rene, just an opinion ) fugly  )

Yeah, fugly, … just trying to make the best out of the C function while
trying to preserve the performance.

While I do not really like to beat this dead horse even further, … I
still find this "undefined" behavior not really elegant and matching
to Lua's otherwise quite high standards of elegance and cleanness.

Although by now Roberto is probably already shivering with each
email with this subject in his inbox, one more proposal to fix this
in a clean way could be: your gets loop but not using the buffer
management advance function in "luaL_addchar(buffer, c);", but
call fgetc in a tight loop with the existing buffer resizing with
LUAL_BUFFERSIZE. That could potentially be much faster.
However, as most people are against any improvement here I did 
not yet benchmark that, … yet.

I do not really see why others have such reservations against
improving Lua to better handle this kind of binary files. Seriously,
separating a stream at '\n' is not that difficult, nor should it be that

 ExactCODE GmbH, Jaegerstr. 67, DE-10117 Berlin | | | |