wtm@neoucom.UUCP (Bill Mayhew) (11/30/86)
Hi people, I just ran into a minor annoyance with the Lattice C compiler that we have here at work. If memory stikes me right, it's version 3.02. I discovered that when I read argv[n][n] that the string isn't always terminated with a \0 as you'd expect. This seems to happen mostly (if not only) when the string contains ascii characters that are digits. Strings in argv[] that have digits in them seem to be terinated with 0xff ( <DEL> ) some of the time, other times \0 as you'd expect. I never noticed the effect until one of our poeple started using file names containing digits (which we read from argv[]), and it took a while before we hit one. What I was doing was parsing the string until I hit the zero at the end, so I was getting an extra character or two of junk tacked on to the end of what appeared to be the legitimate file name. For the momenet. I'm going to assume that in this specialized case that either 0x00 or 0xff can be a valid string terminator. Is there a better way to do it? If what I described is a real bug rather than my imagination, is it an artifact of something that CLI does while scanning the command line before passing off to my program, or is LCstartup goofing it up? My apologies if this discussion went around before, but I didn't notice it. --Bill Bill Mayhew Divsion of Basic Medical Sciences Northeastern Ohio Universities' College of Medicine Rootstown, OH 44272 USA phone: 216-325-2511 (...!cbatt!neoucom!wtm would be a good path)
page@ulowell.UUCP (Bob Page) (12/01/86)
wtm@neoucom.UUCP (Bill Mayhew) wrote in article <329@neoucom.UUCP>: >For the momenet. I'm going to assume that in this specialized case >that either 0x00 or 0xff can be a valid string terminator. Is >there a better way to do it? I'd say go for it, until you hear more official word from Lattice. Not many applications (including CLIs) are normally going to be sending 0xff to the program. >If what I described is a real bug rather than my imagination, is it >an artifact of something that CLI does while scanning the command >line before passing off to my program, or is LCstartup goofing it >up? Well, I bet it's a Lattice problem. Another annoying problem with Lattice's startup code is that they limit the number of arguments that can be passed to a program. Strange but true. I suggest everyone contact then and get them to remove this restriction. The fact is, some day you will want to use a CLI replacement that does wildcard expansion rather than have an application program do it -- wouldn't it be a drag to say 'grep foo * */*' and have grep only see some of the files, because Lattice's startup code didn't feel like passing the rest through? ..Bob PS Manx does not have the argument passing restriction. -- Bob Page, U of Lowell CS Dept. ulowell!page, page@ulowell.CSNET
dillon@CORY.BERKELEY.EDU (Matt Dillon) (12/01/86)
>For the momenet. I'm going to assume that in this specialized case >that either 0x00 or 0xff can be a valid string terminator. Is >there a better way to do it? In C, the string terminator is always and forever will be \0. The problem is with the startup code which translates the non-standard CLI string to an argv[] list. I also believe the CLI command line has a length associated with it???? why not use that? -Matt
cmcmanis@sun.uucp (Chuck McManis) (12/02/86)
A couple of people have mentioned that they didn't like the way the
Lattice code handled putting the arguments into argc and argv. If
you have version 3.03 or below (Amiga C 1.1 = Lattice 3.03) then
your best bet is to get the new main.c module off the developers
"include" disk. (beta, gamma, release, doesn't matter) Or you can
hack the copy you have (it's in the 'source' directory on the Lattice
disk, I don't know where it would be on the Amiga C disk)
One of the new features of the 3.10 compiler is that if you have been
launched (nice term) from the workbench argv points to the workbench
startup message. Also file handles (like stdin) are now Amiga Filehandles
and *not* and index into a table so you can't assume they are file
numbers 0,1,and 2 but you can use Andy Finkel's method of tracking
down the window that they are connected to and modifying it.
Final note, for 3.03 and Amiga C users, if your code gets a recoverable
alert at startup under 1.2 check the c.a module is sources to make sure
it either clears D0 or sets it to LIBRARY_REV before it calls OpenLibrary
on the Dos library.
--
--Chuck McManis
uucp: {anywhere}!sun!cmcmanis BIX: cmcmanis ARPAnet: cmcmanis@sun.com
These opinions are my own and no one elses, but you knew that didn't you.carolyn@cbmvax.cbm.UUCP (Carolyn Scheppner) (12/03/86)
In article <329@neoucom.UUCP> wtm@neoucom.UUCP (Bill Mayhew) writes: > > I just ran into a minor annoyance with the Lattice C >compiler that we have here at work. If memory stikes me right, >it's version 3.02. > >I discovered that when I read argv[n][n] that the string isn't >always terminated with a \0 as you'd expect. This seems to happen >mostly (if not only) when the string contains ascii characters that >are digits. > Version 3.02 had many problems with pointers to characters. There may also be errors in the startup code's parsing of the command line. Also, if you are doing math inside []'s such as [n+1], this often does not compile correctly in 3.03. The same bug may be present in 3.02. If you are dealing with pointers to chars, don't use 3.02. I have a short program that just echos the args passed to it. It was compiled with 3.03 and uses the LStartup code. It has no problem with ASCII numeric characters. I also fed one of my 3.03 AStartup programs some numeric filenames with no difficulty. I really suspect that 3.02's byte handling bugs are the source of your problem. I think you can take your 3.02 to your dealer for an upgrade to 3.03. -- =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Carolyn Scheppner -- CBM >>Amiga Technical Support<< UUCP ...{allegra,caip,ihnp4,seismo}!cbmvax!carolyn PHONE 215-431-9180 =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=