Personal computing discussed

Moderators: renee, SecretSquirrel, just brew it!

 
just brew it!
Administrator
Posts: 54500
Joined: Tue Aug 20, 2002 10:51 pm
Location: Somewhere, having a beer

Tue Aug 30, 2005 11:50 pm

Fearless Leader wrote:
Break down your problem into a series of simpler steps.

This way is inefficient but relatively simple.

1) Read in your text file into a big array of characters.
2) Parse out your text file into a list/array of lines.
3) Define a boolean flag and set it to false.
4) Traverse through your list/array of lines, character by character. If the flag is set to TRUE, make the character uppercase, if not, don't do anything to the character.
5) If you see "/*" set the flag to TRUE. When you see "*/" set the flag to FALSE.
6) Dump your list/array of lines to a new file.

I really dislike solutions like this. Use of fixed-length buffers is what got us into "buffer overflow exploit hell". Granted, nobody's going to try to exploit this program to break into a system... but this style of coding is a bad habit to get into.

bitvector wrote:
The string literal issue is definitely valid, but I seriously hope he doesn't have to deal with that because it would add a few complications including escaped double quotes and strings broken across lines. Neither of these would be a large problem if it wasn't for the fact that the escape character in question (the backslash) can be specified as a trigraph (??/). That means you at least have to add a few more characters of lookahead.

I doubt that a CS instructor would be sadistic enough to require the handling of trigraphs on an assignment like this. How many people -- even experienced C developers -- are even aware of them? :lol:

OTOH handling quoted strings correctly is a pretty reasonable requirement IMO...
Nostalgia isn't what it used to be.
 
bitvector
Grand Gerbil Poohbah
Posts: 3293
Joined: Wed Jun 22, 2005 4:39 pm
Location: San Francisco, CA

Wed Aug 31, 2005 12:03 am

just brew it! wrote:
I really dislike solutions like this. Use of fixed-length buffers is what got us into "buffer overflow exploit hell". Granted, nobody's going to try to exploit this program to break into a system... but this style of coding is a bad habit to get into.

Yes it is a bad habit in many cases. I wholly endorse fixed-length buffers for reading fixed-size chunks of file or network input (of course ensuring that the size given to the read call is right), but I don't think his suggestion was really along those lines. If you really want a huge array of a file and your platform affords it, use mmap.

just brew it! wrote:
I doubt that a CS instructor would be sadistic enough to require the handling of trigraphs on an assignment like this. How many people -- even experienced C developers -- are even aware of them? :lol:

Perhaps that's why the gcc manual used to say (2.7 era?) about the trigraphs option, "Support ANSI C trigraphs. You don't want to know about this brain-damage."

just brew it! wrote:
OTOH handling quoted strings correctly is a pretty reasonable requirement IMO...

Yeah, fair enough... good point.
 
just brew it!
Administrator
Posts: 54500
Joined: Tue Aug 20, 2002 10:51 pm
Location: Somewhere, having a beer

Wed Aug 31, 2005 1:31 am

bitvector wrote:
Perhaps that's why the gcc manual used to say (2.7 era?) about the trigraphs option, "Support ANSI C trigraphs. You don't want to know about this brain-damage."

The only reason I can think of for having them is to support C programming via arcane (and antique) input devices like Teletypes and converted IBM Selectric terminals. Backward compatibility is all well and good, but you've gotta draw the line somewhere... the iPod can't play Edison phonograph cylinders! :D
Nostalgia isn't what it used to be.
 
Flying Fox
Gerbil God
Posts: 25690
Joined: Mon May 24, 2004 2:19 am
Contact:

Wed Aug 31, 2005 11:34 am

I would be one of those "experienced" C programmers, and I didn't know this until I read this post.

Or perhaps I'm just not experienced enough? :roll:
 
bitvector
Grand Gerbil Poohbah
Posts: 3293
Joined: Wed Jun 22, 2005 4:39 pm
Location: San Francisco, CA

Wed Aug 31, 2005 11:42 am

Flying Fox wrote:
I would be one of those "experienced" C programmers, and I didn't know this until I read this post.

Or perhaps I'm just not experienced enough? :roll:

Well, in terms of practicality, a lot of this stuff is off the radar even to very experienced normal programmers who use C. I guess like a lot of systems programmers, I always liked useless C trivia and I also find it fun to be a pedant. That's where I picked a lot of it up. Even still, I didn't know a lot of crazy C stuff until I wrote a compiler.

Edit: Oh and if you read comp.lang.c regularly and you'll pick up a lot of trivia about obscure platforms (see my post about main's return value on VAX -- I'm way too young to know that first hand, so I thank comp.lang.c).
 
malebolgia
Gerbil Elite
Topic Author
Posts: 973
Joined: Fri Apr 05, 2002 7:00 pm
Location: USA

Wed Aug 31, 2005 1:12 pm

Thanks to some clever use of regular expressions I got my flex program working today. :lol:

Thanks much for all the help, once again guys.
 
malebolgia
Gerbil Elite
Topic Author
Posts: 973
Joined: Fri Apr 05, 2002 7:00 pm
Location: USA

Thu Sep 01, 2005 9:42 pm

Someone was telling me that gcc generates error messages as it encounters them in a source file. Is this correct? I always thought gcc read the entire source file first before generating the error messages.
 
Buub
Maximum Gerbil
Posts: 4969
Joined: Sat Nov 09, 2002 11:59 pm
Location: Seattle, WA
Contact:

Thu Sep 01, 2005 10:01 pm

How can it know what the errors are until it parses the code?
 
bitvector
Grand Gerbil Poohbah
Posts: 3293
Joined: Wed Jun 22, 2005 4:39 pm
Location: San Francisco, CA

Thu Sep 01, 2005 10:04 pm

malebolgia wrote:
Someone was telling me that gcc generates error messages as it encounters them in a source file. Is this correct? I always thought gcc read the entire source file first before generating the error messages.

Depends what type of error message. It scans and parses the file on the fly, so lexical and syntactic errors will be noted as they are encountered. Other errors may require a more coherent view of the entire compilation unit and may not be detected until the parsing is complete. The compiler transforms the original abstract syntax as parsed into successively lower-level intermediate representations and will make many passes over these representations. Some errors may not even be detected until the external linker is invoked.

Who is online

Users browsing this forum: No registered users and 1 guest
GZIP: On