Posts by jephthah

my suspicion is that you are losing track of how many times you have opened / closed the file pointer, and that you are trying to read a pointer that is not opened.or close a pointer that is not opened.

this would explain why you're getting a segmentation fault. this is a common error that happens when you start using globals inside subroutines, it's just generally bad practice for that reason.

of course i could be wrong .... buti don't have anything else to go on, since you've only given subroutine.

it definitely is very suspicious though. i would rewrite the program to not use global file pointers.

so you're using global file pointers and accessing them inside a subroutine?

that's a bad idea. if you open a file outside a subroutine and then need to access it inside a subroutine, you should pass the file pointer to the subroutine.

otherwise it's hard to tell whats going on because you've only showed your sub

^ that works better than my first attempt, and much more elegant than my second.

nice job

Hummmm. Seems your function needs a tad bit more work. But its close.

int main()
{
    char str[] = "now \tis     the   time  for   all    good    men\n";
    capitalizeFirsts(str);
    puts(str);
    return 0;
}

Results

Now     is     The   Time  for   All    good    men

Press any key to continue . . .

good catch :P

i only planned for single spaces between words. as it happens, the function handles odd number of spaces, but not even number.

change the function to this, and it should be nearly bulletproof:

void capitalizeAll(char *buf)
{
	int capNext = 0;

	*buf=toupper(*buf);
	while (*buf++ != '\0')
	{
		if (capNext)
		{
			*buf=toupper(*buf);
			capNext = 0;
		}
		if (*buf <= ' ')
			capNext=1;
	}
}

your program, as posted in #7, with the changes i call in #8, is working just fine for me.

other than the fact i had to comment out #include lab7.h ... im using exactly what you posted.

EDIT:

i see what you did. in your latest program you removed the lines:

firstUpper(prodscrip);
puts(prodscrip);

just curious, how much help did you have writing the rest of the program? did you write it yourself?

your "getstring" function is buggering things up. your have a redeclaration for prodscrip that is local to that function, so when it returns back to "main( )" there's nothing for it to use, and you overrun the buffer.

"fprint" and "gets" work nice enough, i dont see what the benefit is for a separate function anyhow. you should always avoid scanf() whenever possible.

from your main( ) routine, remove the line

getstring(prodscrip,"product description");

and replace it with

printf("Enter the product description : ");
gets(prodscrip);

that will work.

call it from anywhere you want to.

if you have any string, lets call it "myString", and it has a bunch of text in it, when you make this call

captializeFirsts(myString);

after the function comes back, all the first characters in each word within "myString" will be capitalized.

if there's only one word in "myString", only the first letter of that word will be capitalized. if theres a hundred word, each of the hundred words will be capitalized.

it appears you're trying to close a file pointer before it has been opened.

strtok will work to be sure, but you have to watch out that it will stomp all over your original string.

another way is to use pointers. make sure you can understand, and explain, how this works

void capitalizeFirsts(char *buf)
{
    *buf=toupper(*buf);            // first char CAP
    while (*buf++ != '\0')
        if (*buf == ' ')           // look for space
            *buf=toupper(*++buf);  // CAP next char
}

so, i guess that means the <sys/socket.h> library?

post the code you're using to bind and we can see whats going on.

which socket library are you using?

well, i guess that's a trick to squeeze a couple more out.

but if you're going to try and do a "real" factorial program (not just this intro to functions), you'll need to use one of the known prime number factorization programs.

no point in reinventing the wheel.

solutions involve using either

#include <conio.h>

or

#include <windows.h>

neither of which are portable. for Linux/Solaris, you would use the

#include <ncurses.h>

library

http://www.blurtit.com/q616731.html
http://www.daniweb.com/forums/thread34554.html
http://www.unix.com/high-level-programming/33023-blinking-text.html

it does work in 2's complement. i hope i didn't say something to indicate it doesn't.

consider a 4 bit number. if it's signed the range is from -(2^3) to (2^3)-1, that is, from -8 to +7 including 0. that is a total of 16 (2^4) unique numbers. if it's UNsigned, the range is from (0) to (2^4)-1, that is, from 0 to 15. that is still a total of 16 (2^4) unique numbers. apply this concept to any 'n'-bit number. so for the 64-bit number (long long) you'll still only have 2^64 unique numbers regardless if it's unsigned or signed.

as for larger factorials, i suppose you could use "double". it will give you positive range up to about 1x10E+37, with 10 digits of precision. that will give you the (approximate) value of up to 33! ... if you wanted to get fancy, you could test the input and use "long long" for values < 21 and "double" for values above that.

integers larger than 2^64 will require the use of large number caches and advanced programming beyond what your class (or myself!) should attempt to get into :P

yes... sort of. using "unsigned" increases the range of positive integers by a power of 2, because it removes the need to handle negatives.

so, for "unsigned long long", you'd have the range from (0) to (2^64) - 1 ... instead of the range -(2^63) to (2^63)-1 that you'd have for just "long long" ... but it would not give you 2^128 numbers... you'll still only have 2^64 unique numbers available, whether you use "unsigned" or not.

what i was saying is that the difference between 20! and 21! is too great for the additional range supplied by "unsigned" to be of any help, in this case.

never mind about posting the 'sizeof' vars back here. it's definitely your code that is causing the problem, not the compiler. i just wrote a program similar to yours that works. i could just post it i suppose, but that wouldn't help you out much.

the main problem is that your 'num' is declared (in both cases) as an int, yet you're trying to return one instance of it back through through the factorial function as an unsigned long long.

redeclare num as a 64-bit long. you might want to give one of the 'num's a different name just for clarity... it gets confusing when you have different variables in different functions that use the same name. confusing for the reader (and programmer!)... compiler doesnt care.

interesting though, how yours turned out, it actually gives the correct answer for 13! = 6227020800, which is clearly greater than a 32-bit number. it definitely does break down after that.

FYI, you dont really need to do "unsigned long long"... "long long" will suffice -- both of them happen to cross the 64-bit boundary at 21!, so neither of them work past 20!

compile the following program, run it, and print the results back here

#include <stdio.h>
int main()
{
  printf("sizeof(char) == %d\n", sizeof(char));
  printf("sizeof(short) == %d\n", sizeof(short));
  printf("sizeof(int) == %d\n", sizeof(int));
  printf("sizeof(long) == %d\n", sizeof(long));
  printf("sizeof(long long) == %d\n", sizeof(long long));

  return 0;
}

this will show you that 12! is good for longs, but you do indeed need a long long for 13! and greater.

meanwhile the real problem is in your type casting.

.

I'm asuming you already understand the relationship between hexadecimal(base16), decimal(base10), and binary (base2), and that any integer value can be represented simultaneously by either of these systems.

LINE 8: the hexadecimal value "8000" in binary looks like this "1000 0000 0000 0000"

it is the "bit mask" that checks the highest (most significant) bit in the value being tested.

the check is accomplished by using the "bitwise AND" operator: "&". it performs an AND function on each and every bit in the value against the 0x8000 bitmask. look up "bitwise AND" if you dont understand this.

LINE 12: this shifts the value being tested one bit to the left, causing the next highest bit to become the MSB (most significant bit) and thus be the one that is checked by the bitmask in LINE 8.

this is accomplished by using the "logical shift left" operator: "<<" it shifts each bit one place to the left, dropping the MSB off the left end (lost forever), and padding 0's into the empty LSB spot on the right.

you should use your IDE (development environment) debugging functionality to step through this program and watch the values change in binary and/or hex, along with the string value that contains all '1' and '0' characters to represent the binary value.

did you get it to work, friendfx?

i think we are two trains passing each other in the night.

I work in a shop selling computer h/w and electronic kits/components and custmers regularly use

i'm sure they do ... but which manufacturers are "they", that you're talking about working "fine"?

i mean, certainly *all* the various manufacturers don't work fine. because I've had *some* that don't work worth a damn, or they only work intermittently. often these are off-brand devices some people buy cheap off the internet. not to mention that even the good ones can fail.

Now, I don't know about his particular brand off the top of my head. It probably is fine.

but before I go debugging any code, i'm going to verify the hardware works first. I already learned that lesson, the hard way. Because I'm slightly dense, I learned it a few times. :P

connecting one serial cable to the other, and running two instances of HyperTerminal on the two different ports will verify whether or not it works correctly.

but the thing to remember is both of your com ports are acting as a DTE ... in order to communicate straight through, one has to be a DTE and one a DCE. the difference between DTE (data terminal emulator) and DCE (data communication equipment) is that the TX and RX pins are swapped (pins 2 and 3, on a DB-9)

therefore you need a "null modem" cable to communicate between two com ports on two DTE machines (ie, typical PCs). In other words, cross over your pins 2 and 3 and retry :-) here's a good reference

since you're not using handshaking, your task is much easier. if you can get both of the COM ports to communicate back and forth -- in each direction -- then the problem is not your USB-Serial converter. If it's not the hardware, and you're certain your code is correct, then I would think its a Windows application setting. Perhaps your API limits the default Com Ports to COM1 - COM4 ?

if you get a chance, try using TeraTerm. it's open source freeware, and highly configurable, and IMO much better application than HyperTerminal. I think you'll like it.

ive done a lot of work with COM ports, both real and virtual. Generally, I've not had problems accessing any of the com ports that are assigned by USB-RS232 converters. Ive gone all the way up to COM16 or maybe higher.

when ive had problems, its been for one of two reasons:

(1) the default Windows COM settings is preventing the use of any com ports numbers above a certain default number, typically "COM4"... there is a way to set this higher, pretty easy once you find it. Unfortunately my home computer is running Linux so I can't recall where this setting is found.

(2) sometimes USB - RS232 converters made by lower-end manufacturers have problems. especially with handshaking. If all else fails try a different manufacturer.

First what i would do is make sure you can talk through the USB-RS232 cable manually. Use TeraTerm or PuTTy or HyperTerm or whatever terminal emulator you like. Make sure that your converter cable actually works via COM5 in the emulator as the "real" port does on COM1 separate from your program. If it does work, and your program truly is apples-for-apples, then I would work on tracing down the problem i described above in (1).

good luck