Really you should use a proper library function that has been tested across decades and has encoutered all sorts of "unexpected" inputs and has been made robust against that sort of things. That's my whenever parsing input files you somehow think you need to write the number parsing again yourself. You can use something as a filter as a workaround for the problems right now, but modifying OpenScad to produce files that happen to work on some random other program is not the way to proceed forward.
![convert obj to stl no bullshit convert obj to stl no bullshit](https://europepmc.org/articles/PMC6546300/bin/nihms-1527803-f0011.jpg)
But you should not blame OpenScad for the bugs in that other program. If OpenScad triggers a bug in another program, then it is nice that OpenScad helps making that other program better. If the author of a program makes the mistake of trying to implement the "read a number" routine again by himself and makes a mistake of not expecting some valid input, then that's a bug in that program. Now whenever parsing input files you somehow think you need to write the number parsing again yourself. It is the parsing program that should simply use a "read-a-float" library function that has support for all possible representations of the number "thousand".
#CONVERT OBJ TO STL NO BULLSHIT 32 BIT#
The form "1000", without decimal point is the most compact, why would it be illegal? It is still a valid (and perfectly representable) 32 bit floating point number (whereas 1.1 for example cannot be represented perfectly as a single precision float). A program that accepts numbers should accept all possible number formats.
![convert obj to stl no bullshit convert obj to stl no bullshit](https://hackaday.com/wp-content/uploads/2019/11/Prusa-say-use-3MF-file-format-featured.jpg)
The most complicated "number" format example is 1.0E3 for the number "thousand".