Post by thread:[OT]: C syntax question

Hi, I'm a newcomer to C, and there are a lot of things I simply don't understand yet - so I usually avoid them. However, I'm trying to port some code from one compiler to another. It was written for Hi-Tech C, and I use CC5Xfree. I'm getting one error message I can't seem to work around, and I don't know what exactly the problem is. There is a function defined like so: void MakePacket(unsigned int packet, unsigned char code, unsigned char num, unsigned char *str){...} and later on the program tries to do this: MakePacket(LCP,REQ,number,"\x0E\x02\x06\x00\x0A\x00\x00\x07\x02\x08\x02"); (Yes, that is from AN721, and yes, I'm trying to bit-bang IP...) The compiler says: MakePacket(LCP,REQ,number,"\x0E\x02\x06\x00\x0A\x00\x00\x07\x02\x08\x02"); ^------ Error C:\PROGRA~1\MPLAB\PPPTEST.C 430: Syntax error (or limitation) I've tried it with quotes (as it originally was), without the quotes, with single quotes, parentheses, etc. with no luck. Now, I realize I'm using a free version of CC5X or I could just email for support. I'm getting close to making a decision to actually buy a compiler, but I don't want to buy all of them, since I do this for fun and they're not cheap. That's why I need to figure out now if one or another is going to be a limiting factor as I learn more about C. So, that's why I'm asking here -- is there something I'm not aware of that will make this work, or does CC5X simply not support this type of thing? I've looked through the docs and a couple of C/C++ books and not found anything to shed any real light on this, though I admit I've spent a limited time with the books so far. Thanks, Dale --- The most exciting phrase to hear in science, the one that heralds new discoveries, is not "Eureka!" (I found it!) but "That's funny ..." -- Isaac Asimov

Dale, The last term in the argument list,(unsigned char *str), is a pointer. Does this compiler support pointers? Regards, Jim On Fri, 26 May 2000, Dale Botkin wrote: {Quote hidden}> > Hi, > > I'm a newcomer to C, and there are a lot of things I simply don't > understand yet - so I usually avoid them. However, I'm trying to port > some code from one compiler to another. It was written for Hi-Tech C, and > I use CC5Xfree. I'm getting one error message I can't seem to work > around, and I don't know what exactly the problem is. > > There is a function defined like so: > void MakePacket(unsigned int packet, unsigned char code, unsigned char > num, unsigned char *str){...} > > and later on the program tries to do this: > MakePacket(LCP,REQ,number,"\x0E\x02\x06\x00\x0A\x00\x00\x07\x02\x08\x02"); > > (Yes, that is from AN721, and yes, I'm trying to bit-bang IP...) The > compiler says: > > MakePacket(LCP,REQ,number,"\x0E\x02\x06\x00\x0A\x00\x00\x07\x02\x08\x02"); > ^------ > Error C:\PROGRA~1\MPLAB\PPPTEST.C 430: Syntax error (or limitation) > > I've tried it with quotes (as it originally was), without the quotes, with > single quotes, parentheses, etc. with no luck. > > Now, I realize I'm using a free version of CC5X or I could just email for > support. I'm getting close to making a decision to actually buy a > compiler, but I don't want to buy all of them, since I do this for fun and > they're not cheap. That's why I need to figure out now if one or another > is going to be a limiting factor as I learn more about C. So, that's why > I'm asking here -- is there something I'm not aware of that will make this > work, or does CC5X simply not support this type of thing? I've looked > through the docs and a couple of C/C++ books and not found anything to > shed any real light on this, though I admit I've spent a limited time with > the books so far. > > Thanks, > > Dale > --- > The most exciting phrase to hear in science, the one that heralds new > discoveries, is not "Eureka!" (I found it!) but "That's funny ..." > -- Isaac Asimov spam_OUTjimTakeThisOuTjpes.com

> MakePacket(LCP,REQ,number,"\x0E\x02\x06\x00\x0A\x00\x00\x07\x02\x08\x02"); Each of these escape sequences compiles to a single char of the specified hex value, so "\x00" compiles to binary 0, but zero is string terminator and can't be contained within a string. If the compiler let it go, MakePacket would fail because it would see the first \x00 as the end of the string. You need something like: const unsigned char IPhack[] = { 0x0e, 0x02, 0x06, 0x00, 0x0a ... }; and add packet length param to MakePacket e.g. MakePacket(LCP,REQ,number,IPhack,sizeof(IPhack));

On Fri, 26 May 2000, James Paul wrote: > Dale, > > The last term in the argument list,(unsigned char *str), is a > pointer. Does this compiler support pointers? Yes, I think so. From the readme file: "One dimensional arrays and single level pointers is implemented. Note that pointer and indexed arithmetic is currently limited to 8 bit. Assignment is allowed for 8, 16, 24 and 32 bit. char t[10], i, index, *p, x, temp;" And I think I screwed up in my first post, though I haven't a clue as to whether it will make a difference. the original function read like this: void MakePacket(unsigned int packet, unsigned char code, unsigned char num, const unsigned char *str){...} I had deleted the "const" because CC5X says it ignores const. Also, it's AN724, not 721 as I think I said originally. Dale --- The most exciting phrase to hear in science, the one that heralds new discoveries, is not "Eureka!" (I found it!) but "That's funny ..." -- Isaac Asimov

On Fri, 26 May 2000 rleggittKILLspamconcentric.net wrote: > > MakePacket(LCP,REQ,number,"\x0E\x02\x06\x00\x0A\x00\x00\x07\x02\x08\x02"); > Each of these escape sequences compiles to a single char of the specified > hex value, so "\x00" compiles to binary 0, but zero is string terminator > and can't be contained within a string. If the compiler let it go, > MakePacket would fail because it would see the first \x00 as the end of > the string. I don't think it made MakePacket fail, since I lifted this straight out of Microchip's AN724 source listing. See my reply to Jim, though, I did mistakenly leave out one bit of the function, the last term was const unsigned char *str, not unsigned char *str. I haven't learned anything about pointers and such yet - can you tell? > You need something like: > > const unsigned char IPhack[] = { 0x0e, 0x02, 0x06, 0x00, 0x0a ... }; > > and add packet length param to MakePacket e.g. > > MakePacket(LCP,REQ,number,IPhack,sizeof(IPhack)); I can see where this would work, though I'd also have to rewrite a considerable portion of MakePacket, I think. I'm looking at it and trying to get my brain cells wrapped around it now, in fact. Like I said, I'm not a programmer... though it's looking more and more like it all the time, at least where PICs are concerned. Dale --- The most exciting phrase to hear in science, the one that heralds new discoveries, is not "Eureka!" (I found it!) but "That's funny ..." -- Isaac Asimov

> > MakePacket(LCP,REQ,number,"\x0E\x02\x06\x00\x0A\x00\x00\x07\x02\x08\x02"); > Each of these escape sequences compiles to a single char of the specified > hex value, so "\x00" compiles to binary 0, but zero is string terminator > and can't be contained within a string. If the compiler let it go, > MakePacket would fail because it would see the first \x00 as the end of > the string. > > You need something like: > > const unsigned char IPhack[] = { 0x0e, 0x02, 0x06, 0x00, 0x0a ... }; > > and add packet length param to MakePacket e.g. > > MakePacket(LCP,REQ,number,IPhack,sizeof(IPhack)); > Erm... I don't think so. One only runs into problems with strings and nulls when you use the str stdlib functions. C persay has virtually no support for a "string". That behavior is implimented by libraries... at runtime. As long as the MakePacket() function doesn't pass that last const char pointer to a function that expects null terminated strings, or the function itself doesn't expect it, you are going to be OK on this point. Personally, I agree that your syntax is better; if you are passing binary data, use the array notation. It's more readable. As to the original question, make sure that your compiler can handle function definitions with that many arguments. Some PIC compilers have upper limits on the number of arguments you can pass to a function. Make sure that LCP isn't a preprocessor macro that expands to something you didn't expect. -d

On Fri, 26 May 2000, David Kott wrote: > As to the original question, make sure that your compiler can handle > function definitions with that many arguments. Some PIC compilers have > upper limits on the number of arguments you can pass to a function. Just to make sure, I tried passing it the whole thing, but with the last term reduced to 0x0E (no quotes). That was OK. When I add quotes, it doesn't work. > Make sure that LCP isn't a preprocessor macro that expands to something you > didn't expect. #define LCP 0xC021 // Link Configure Protocol packet Nope. I'm feeling more and more stupid by the minute... definitely going to stop by a bookstore on my way home tonight and pick up a C book. The only problem is that they seem to all assume you're coding on a Dos or UNIX box with all kinds of function libraries available, and they all seem to spend a LOT of time doing things like "cout<<blargh" that really don't chaff. Sigh. Would the K&R book on ANSI C be a good start? Dale --- The most exciting phrase to hear in science, the one that heralds new discoveries, is not "Eureka!" (I found it!) but "That's funny ..." -- Isaac Asimov

This constuct is in both K&R and ANSI C. I would expect it to work in most reasonable compilers. Of course, some "C" compilers for microcontrollers are not all that reasonable :-) Bob Ammerman RAm Systems (high function, high performance, low-level software) ----- Original Message ----- From: William Chops Westfield <.....billwKILLspam.....CISCO.COM> To: <EraseMEPICLISTspam_OUTTakeThisOuTMITVMA.MIT.EDU> Sent: Friday, May 26, 2000 7:17 PM Subject: Re: [OT]: C syntax question > Is "\xNN" a widely supported construct? > > BillW

> > Make sure that LCP isn't a preprocessor macro that expands to something you > > didn't expect. > > #define LCP 0xC021 // Link Configure Protocol packet > > Nope. I'm feeling more and more stupid by the minute... definitely going > to stop by a bookstore on my way home tonight and pick up a C book. The > only problem is that they seem to all assume you're coding on a Dos or > UNIX box with all kinds of function libraries available, and they all seem > to spend a LOT of time doing things like "cout<<blargh" that really don't > chaff. Sigh. Would the K&R book on ANSI C be a good start? > I don't think it would be an "good start", persay. I have a well thumbed copy of the K&R book, however I use it as a reference. I have never tried to read it as a tutorial. Unfortunately, I can't suggest a "just got started with C" book. Especially, as you noted, the preponderance of these books are written with the systems programmer in mind, not the embedded engineer. -d

On Tue, May 30, 2000 at 07:55:51AM -0400, David Kott wrote: > Unfortunately, I can't suggest a "just got started with C" book. Here are two: "A Book on C" by Kelley and Pohl "Programming in ANSI C" by Steven Kochan -- Clyde Smith-Stubbs | HI-TECH Software Email: clydespam_OUThtsoft.com | Phone Fax WWW: http://www.htsoft.com/ | USA: (408) 490 2885 (408) 490 2885 PGP: finger @spam@clydeKILLspamhtsoft.com | AUS: +61 7 3355 8333 +61 7 3355 8334 --------------------------------------------------------------------------- HI-TECH C: compiling the real world.