On 4 Jun 1999 03:19:12 -0500, Nieminen Mika wrote:
>Ralf Muschall <rmu### [at] t-onlinede> wrote:
>: Probably because nobody wanted to write such a function,
>: ANSI libc.a does not contain one, and POV was written in a
>: time before GNU hackers told that all limits are evil.
>: AFAIK glibc has an extension (getline) which does the job.
>
>  filepos=ftell(InFile);
>  for(i=StartingQuoteIndex+1; getc(InFile)!='"'; i++);
>  fseek(filepos);
>  char* String=malloc(i-StartingQuoteIndex-1);
>  fgets(String, i-StartingQuoteIndex-1, InFile);
>
>  What's so difficult here?

This, from the docs:

 Note if you need to specify a quote mark in a string literal you must precede 
 it with a  backslash. For example
    "Joe said \"Hello\" as he walked in."
   is converted to
   Joe said "Hello" as he walked in.
 If you need to specify a backslash, most of the time you need do nothing 
 special. However  if the string ends in a backslash, you will have to specify 
 two. For example:
   "This is a backslash \ and so is this\\"
   Is converted to:
   This is a backslash \ and so is this\

Not that it's insurmountable or anything, but it does make the job a little 
more interesting than what you have there.

Post a reply to this message

On Thu, 03 Jun 1999 19:45:59 -0700, Jon A. Cruz wrote:
>Spider wrote:
>
>> Samuel van Egmond wrote:
>> >
>> > You are a very funny spider!!!
>> >
>> > Good one....
>> >
>> > Samuel.
>> LMAO ....
>> Actually, there are several bugs in the concat() code.. parser not
>> caring for end ) in some cases, not error reporting and some other
>> stuff.
>>
>> //Spider
>
>so, should I go in and tweak all the string handling to deal in Unicode,
>and also take out the limits while I'm in there?

No, you should tweak it to work in whatever the current encoding is.  
Not that there's any distinction, for now, but what if someone adds
a multibyte encoding later?  Keep in mind that that means the encoding 
has to be specified first, because it affects parsing, which is not like 
all the other global_settings.

Post a reply to this message

On 4 Jun 1999 09:58:51 -0500, Ron Parker wrote:
>No, you should tweak it to work in whatever the current encoding is.  
>Not that there's any distinction, for now, but what if someone adds
>a multibyte encoding later?  Keep in mind that that means the encoding 
>has to be specified first, because it affects parsing, which is not like 
>all the other global_settings.

Doh!  Of course there's a distinction.  A single-byte encoding could
easily contain the first byte of a double- or triple-byte UTF-8 character, 
so you'd have to be sensitive to encoding type even with the current choices.

Post a reply to this message

Ron Parker wrote:

> On 4 Jun 1999 09:58:51 -0500, Ron Parker wrote:
> >No, you should tweak it to work in whatever the current encoding is.
> >Not that there's any distinction, for now, but what if someone adds
> >a multibyte encoding later?  Keep in mind that that means the encoding
> >has to be specified first, because it affects parsing, which is not like
> >all the other global_settings.
>
> Doh!  Of course there's a distinction.  A single-byte encoding could
> easily contain the first byte of a double- or triple-byte UTF-8 character,
> so you'd have to be sensitive to encoding type even with the current choices.

But here's where the problems start to creep in.

If you start to allow arbitrary encodings, which do you use? A common thing for
programs in the past has been to use the default multibyte encoding of the
platform it is running on. That's nice for an isolated user, but breaks down
when you start to go global.

The old multibyte true-type patch did just this. It was for exactly this reason
that the patch was useable only on systems that were natively multibyte such as
Japanese or Chinese. So you'd get different results if you ran on a Chinese
system than if you ran on a Japanese system, OR it would just fail completely.

Probably the only way to keep the .pov files portable and generating identical
results on any platform (which I think is one of the design goals of POV-Ray)
would be to include the encoding support in POV-Ray. But, you can't include
everything, so where do you draw the line?

In my Unicode patch I have it converting only after text is passed down in for
generating objects, so the encoding is deferred (this was mainly to avoid
changing all the text handling). However, I did do a few base encodings.

We could just change things to handle the current US-ASCII and Unicode (UTF-8,
UTF-16). For nicer user support we could then add CP-1252 (Windows) and
MacRoman (but Mac has lots of problems). Notepad on NT can do Unicode versions
of text files, and for the rest, we could probably push the conversion burden
out onto the end-user (e.g. if you want to render Klingon text, you are
responsible for converting your Klingon into Unicode before sending it off to
POV-Ray.) If the entire program was changed to be based on Unicode instead of
single-byte text, this might help.

But then... what happens to all the text manipulation routines? Are end-user
scripts dependent on one character=one byte? What compatibility issues could
this cause? Hmmm....



(followups set to povray.programming)

Post a reply to this message

The code was just to give the idea, not to be the perfect final code
to directly copy-paste into the povray source.
  Of course you have to add various checkings in there, but you got the
idea, didn't you?

-- 
main(i,_){for(_?--i,main(i+2,"FhhQHFIJD|FQTITFN]zRFHhhTBFHhhTBFysdB"[i]
):5;i&&_>1;printf("%s",_-70?_&1?"[]":" ":(_=0,"\n")),_/=2);} /*- Warp -*/

Post a reply to this message

Nieminen Mika wrote:

[code which seeks back deleted]
>   What's so difficult here?

It is not difficult (it wouldn't be even in a version
which does not seek - just use fread into a malloced
buffer and double the size of that with realloc until done),
just in the past nobody cared about such problems.

For a test, try
find . -name '*.[ch]' -exec grep scanf {} \;
in the source tree of some program.

That's what gave us the internet worm and gives us
crashing MS stuff every day, and "Smashing the stack for
fun and profit" (title of a paper by AlephOne).
The BSD guys claim to have cleaned this kind of bugs out
of their code, otherwise I believe the whole world is still
messy.

Ralf

Post a reply to this message