> Op Thu, 13 Dec 2007 14:37:43 +0100 schreef Chris Dollin

>> pete wrote:

>>> Thad Smith wrote:

>>

>>>> Interesting. What are the license requirements on the code?

>>>
>>> It's just trivial code.

>>
>> Licensing isn't about whether the code is trivial or not.

>
> Yes it is. Any license on something trivial cannot be enforced. Except
> in an unreasonable justice system, of course...

> Tony Jackson wrote:

>> Hi

>> like to do is be able to ignore the dereference attempt and just carry
>> on - probably the next time round the loop the pointer will be OK. In
>> Java, I'd put a try block around the main loop, and if we catch an
>> exception then just jump back to the start of the main loop. What's the
>> corresponding thing in C?

>
> The corresponding thing in C, would be to save environment via setjmp,
> install a signal handler for SIGSEGV and do a longjmp when such a signal
> occurs.

> Ben Pfaff wrote:

>> lak writes:

>

>>> I want to know what is the variable length in c.
>>> I K&R they stated that atleast 31 character.
>>> But I give 1 lakhs length to a variable, but my compiler doesn't say
>>> any error.

>

>> The number of significant characters in an identifier varies
>> among implementations. It is at least 31 for internal
>> identifiers and 6 for external identifiers in C90, and higher
>> than that in each case for C99.

>

>> I don't know what a "lakh" is.

>
> 1E5, or GIYF.

>
> struct pageType { //data stucture for page
> int pageNo; //stores the page number (unique)
> char *data; //holds data from a text file
> struct pageType *next; //points to the next page
> struct pageType *previous; //points to the previous page
> };
>
> struct bufferType { //data structure for buffer -- Linked Queue
> struct pageType *front; //points to the front page of queue
> struct pageType *end; //points to the last page
> struct pageType *current; //points to the current page
> };
>
> The idea is basically, a buffer containing a certain amount of pages.
>
> But the problem is when I free a page's data. When i free the page's
> data, 9 times of all cases it works... but sometimes the compiler (or
> rather the OS) displays the following error: *** glibc detected *** ...

> Hello. My question is from Q20.1 from www.c-faq.com.
>
> The following is from the answer to Q20.1 from the website:
>
> #include
>
> polar_to_rectangular(double rho, double theta,
> double *xp, double *yp)
> {
> *xp = rho * cos(theta);
> *yp = rho * sin(theta);
> }
>
> And this is my version which I will use for my question:
>
> #include
>
> polar_to_rectangular(double rho, double theta,
> double *xp, double *yp) ...

> On 14 Dec 2007 at 18:22, Stephen Sprunk wrote:

>> "Brian" nospam.com> wrote in message
>> news:slrnfm5g26.hn7.nospam@nospam.invalid...

>>>>>I have been told that for extra efficiency we should always compile
>>>>>code with frame pointer ommited (-fomit-frame-pointer)

>>>>
>>>> Not using a frame pointer makes an extra register available for other
>>>> uses, which speeds things up on processors with few registers (in
>>>> particular, on x86 processors). Using one can make debugging easier,
>>>> though I think gdb can do most things without one.

>>>
>>> Wouldn't it be better then if the frame pointer was ommited by default
>>> unless debugging (-g) is switched on?

>>
>> Some debugging can be done without symbols, and it's easier with a frame
>> pointer.

>
> But if you are planning to debug, why wouldn't you include symbols (-g)? ...

>
> Statements don't return values. Expressions do.

> I'm quite new to C programming - I have more of a Java background: maybe
> someone here can advise me.
>
> I'm nearly finishing a little program but it has some hard-to-find bugs
> that basically lead to a couple pointers sometimes being NULL at the
> wrong time. As it stands the program just bombs out when it tries to
> dereference the NULL, which obviously isn't good (especially when it
> happens with the customer looking on!!).
>
> I don't think there's any serious problem to worry about, and what I'd
> like to do is be able to ignore the dereference attempt and just carry
> on - probably the next time round the loop the pointer will be OK.

> In Java, I'd put a try block around the main loop, and if we catch an
> exception then just jump back to the start of the main loop.

> James Kuyper verizon.net> writes:

>> AGRAJA wrote:

>>> how to convert unsigned to char?

>> Use the cast operator: (char)

>
> A cast is neither necessary nor helpful. Just assign it; the
> conversion is implicit.